it-swarm-eu.dev

Jaká rizika jsou, pokud povolíme snímek potvrzující čtení na serveru sql?

Přečetl jsem zde , že některá další data budou uložena na řádek, abychom mohli vidět zhoršení výkonu, ale jaká jsou další rizika?

např. Ovlivní to obnovení databáze? Musíme ještě něco udělat, abychom to využili?

Mám v plánu provést tyto příkazy:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Věřím, že nám to přinese něco bližšího k Oracle, kde, pokud se jedna transakce aktualizuje, mohou ostatní transakce stále přečíst stará data. Je to správně?

Dívám se na to, protože mi chybí problémy se zamykáním v serveru SQL Server 2005. Doufám, že by to mohlo snížit příležitostné zablokování, které uživatelé uvidí, pomůže celkový výkon naší aplikace a povzbudí naše vývojáře, aby provedli více než jednu operaci na transakci bez strach.

73
Adam Butler

Souhrn

  1. Pokud máte problémy se zamykáním, máte problém s kódem: nejedná se o databázový stroj
  2. Není to kouzelná střela
  3. Můžete přidat další problémy

Zatížení

Také zvýší zatížení vašeho tempdb a CPU . Viz také:

Bezpečnost

Nejdůležitější je, že izolace snímků není v mnoha případech bezpečná ve výchozím nastavení . Přečtěte si "Snapshot izolace" (Wikipedia) pro další informace o anomáliích se skreslením. Další část je „Jak provést sériovou izolaci snímkování“.

Obecně tedy izolace snímků přináší některé problémy s udržováním netriviálních omezení na uživatele, který nemusí ocenit potenciální úskalí ani možná řešení. Nevýhodou tohoto převodu je lepší výkon.

Viz také:

49
gbn

Vím, že se jedná o staré vlákno, ale řekl bych do velké míry izolaci snímku is magická střela. To eliminuje všechny blokování mezi čtenáři a spisovateli. Bude to však ne zabránit spisovatelům v blokování jiných spisovatelů. Neexistuje žádný způsob, jak obejít.

Podle mých zkušeností je další zátěž na TEMPDB zanedbatelná a výhody verzování řádků při omezování blokovaných čtenářů jsou obrovské.

Pro informaci, verzování řádků (izolace snímků) je metoda, kterou Oracle používá po desetiletí k dosažení izolace bez blokování čteček a databází Oracle, na kterých jsem pracoval téměř 20 let zkušeností daleko méně problémů s blokováním než SQL Server ano. Většina vývojářů jazyka SQL však váhá s použitím izolace snímku, protože svůj kód testovali pouze na databázích, které používají výchozí nastavení.

36
Chuck

K dalším odpovědím přidejte několik dalších bodů:

SET ALLOW_SNAPSHOT_ISOLATION ON povoluje pouze izolaci snímku v databázi. Abyste toho mohli využít, musíte překódovat a SET TRANSACTION ISOLATION LEVEL SNAPSHOT pro transakce, na které se má vztahovat. Aby bylo možné zpracovat chyby konfliktu aktualizací, bude třeba změnit volací kód.

Po SET READ_COMMITTED_SNAPSHOT ON, příkazy při čtení potvrzují použití verzí řádků. Poznámka: Toto je úroveň příkazů - verze verzí řádků pro čtení pouze . U aktualizací je načten řádek „skutečný“ a použity zámky aktualizací. Viz část Shrnutí chování v Pochopení úrovní izolace na základě verzí řádků

Ať už jde o trasu, bez vyčerpávajícího testování, pravděpodobně do systému zavedete zcela novou sadu problémů.

26

Věřím, že nám to přinese něco bližšího k Oracle, kde, pokud se jedna transakce aktualizuje, mohou ostatní transakce stále číst stará data. Je to správně?

Ano, toto je správné .

Dobře stojí za přečtení odkazů v odpovědi gbn a věřím, že totéž platí pro výchozí Oracle Oracle MVCC jako pro SQL Server v režimu izolace snímků. Dodal bych, že pokud pochopíte potenciální úskalí, IMO výhody daleko převažují nad přidanými obtížemi (když mluvíme z pohledu Oracle) - a samozřejmě některé problémy se zamykáním legitimně zmizí, to je bod MVCC (existuje také třída problémy se zamykáním, které nezmizí kvůli problémům s kódem, ale předpokládám, že tomu rozumíte).

Ve všech našich projektech, které používají SQL Server DB, používáme SNAPSHOT ISOLATION. Žádné další 1205 chyby SQL, které nejsou způsobeny nesprávným kódem aplikace, ale výchozím zamykáním stránky a chováním řádků.

Dopad na výkon je minimální a dosud uběhlo 7 let, stovky milionů operací byly zpracovány v různých systémech, bez problémů ohledně SNAPSHOT ISOLATION.

Situace, kdy několik různých podprocesů aktualizuje obchodní kritické informace v jednom řádku paralelně, jsou mimořádně výjimečné a šance, že SNAPSHOT ISOLATION bude příčinou jakéhokoli problému s nekonzistencí, jsou velmi blízko nuly.

Pokud máte systém OLTP), který záměrně aktualizuje v několika vláknech jediný řádek na základě aktuálních dat v řadě, SNAPSHOTS samozřejmě není v takových případech přijatelný.

10