Proč používat úroveň izolace READ UNCOMMITTED?

Tato úroveň izolace umožňuje nečisté čtení. U jedné transakce se mohou objevit nepotvrzené změny provedené jinou transakcí.

Aby byla zachována nejvyšší úroveň izolace, DBMS obvykle získává zámky dat, což může vést ke ztrátě souběžnosti a vysoké režii zamykání. Tato úroveň izolace tuto vlastnost uvolňuje.

Možná se budete chtít podívat na článek na Wikipedii o READ UNCOMMITTED pro několik příkladů a další čtení.

Možná vás také bude zajímat článek na blogu Jeffa Atwooda o tom, jak on a jeho tým řešili problém se zablokováním v prvních dnech Stack Overflow. Podle Jeffa:

Ale je nolock nebezpečné? Mohli byste skončit čtením neplatných dat pomocí read uncommitted na? Ano, teoreticky. Nenajdete tu nouzi o astronauty s architekturou databází, kteří na vás začnou pouštět vědu o kyselinách a kromě toho spustí požární poplach v budově, když jim řeknete, že chcete vyzkoušet nolock .Je to pravda:teorie je děsivá. Ale tady je to, co si myslím:"Teoreticky není rozdíl mezi teorií a praxí. V praxi ano."

Nikdy bych nedoporučoval používat nolock jako obecná oprava hadího oleje „dobré na to, co vás trápí“ pro jakékoli problémy se zablokováním databáze, které můžete mít. Nejprve byste se měli pokusit diagnostikovat zdroj problému.

Ale v praxi přidáním nolock na dotazy, o kterých absolutně víte, že jsou jednoduché, přímočaré záležitosti pouze pro čtení, zdá se, nikdy nevedou k problémům... Pokud víte, co děláte.

Jedna alternativa k READ UNCOMMITTED úroveň, kterou možná budete chtít zvážit, je READ COMMITTED SNAPSHOT . Znovu cituji Jeffa:

Snímky spoléhají na zcela novou metodu sledování změn dat... více než jen mírná logická změna vyžaduje, aby server s daty zacházel fyzicky jinak. Jakmile je tato nová metoda sledování změn dat povolena, vytvoří kopii nebo snímek každé změny dat. Díky čtení těchto snímků namísto živých dat v dobách sporu již nejsou sdílené zámky při čtení potřeba a celkový výkon databáze se může zvýšit.