it-swarm-eu.dev

Welche Risiken bestehen, wenn wir einen festgeschriebenen Lese-Snapshot in SQL Server aktivieren?

Ich habe hier gelesen, dass einige zusätzliche Daten pro Zeile gespeichert werden, sodass wir möglicherweise einen Leistungsabfall feststellen, aber welche anderen Risiken gibt es?

z.B. Wird dies die Wiederherstellung der Datenbank beeinflussen? Müssen wir noch etwas tun, um dies auszunutzen?

Ich plane, diese Befehle auszuführen:

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

Ich glaube, dies wird uns Oracle näher bringen, wo andere Transaktionen, wenn eine Transaktion aktualisiert wird, die alten Daten noch lesen können. Ist das richtig?

Ich prüfe dies, weil ich es satt habe, Probleme in SQL Server 2005 zu sperren. Ich hoffe, dass dies die gelegentlichen Deadlocks, die unsere Benutzer sehen, verringert, die Gesamtleistung unserer Anwendung verbessert und unsere Entwickler dazu ermutigt, mehr als einen Vorgang pro Transaktion ohne auszuführen Angst.

73
Adam Butler

Zusammenfassung

  1. Wenn Sie Sperrprobleme haben, haben Sie ein Problem mit Ihrem Code: Es ist nicht das Datenbankmodul
  2. Es ist kein Wundermittel
  3. Sie können weitere Probleme hinzufügen

Laden

Es erhöht auch die Belastung Ihrer Tempdb und CPU . Siehe auch:

Sicherheit

Am wichtigsten ist, dass Snapshot-Isolierungen nicht sicher sind in vielen Fällen standardmäßig. Lesen Sie "Snapshot-Isolation" (Wikipedia) , um mehr über Schreibfehler zu erfahren. Der nächste Abschnitt ist "Serialisierung der Snapshot-Isolation", um dies zu umgehen.

Im Allgemeinen stellt die Snapshot-Isolation daher einen Teil des Problems dar, nicht triviale Einschränkungen für den Benutzer beizubehalten, der möglicherweise weder die potenziellen Fallstricke noch die möglichen Lösungen einschätzt. Der Vorteil dieser Übertragung ist eine bessere Leistung.

Siehe auch:

49
gbn

Ich weiß, dass dies ein alter Thread ist, aber ich würde zu einem großen Teil Snapshot-Isolation sagen is ein Wundermittel. Es wird alle Ihrer Blockierung zwischen Lesern und Schriftstellern beseitigen. Es wird jedoch nicht verhindern, dass Autoren andere Autoren blockieren. Daran führt kein Weg vorbei.

Nach meiner Erfahrung ist die zusätzliche Belastung der TEMPDB vernachlässigbar und die Vorteile der Zeilenversionierung bei der Reduzierung blockierter Leser sind enorm.

Als Referenz ist die Zeilenversionierung (Snapshot-Isolation) die Methode, mit der Oracle seit Jahrzehnten eine Isolation erreicht, ohne die Leser zu blockieren, und die Oracle-DBs, an denen ich seit fast 20 Jahren Erfahrung arbeite weit weniger Blockierungsprobleme als SQL Server tut. Die meisten SQL-Entwickler zögern jedoch, die Snapshot-Isolation zu verwenden, da sie ihren Code nur anhand von Datenbanken getestet haben, die die Standardeinstellung verwenden.

36
Chuck

Einige zusätzliche Punkte zu den anderen Antworten:

SET ALLOW_SNAPSHOT_ISOLATION ON aktiviert nur die Snapshot-Isolation in einer Datenbank. Um es zu nutzen, müssen Sie neu codieren und SET TRANSACTION ISOLATION LEVEL SNAPSHOT für die Transaktionen, für die es gelten soll. Der aufrufende Code muss geändert werden, um Aktualisierungskonfliktfehler zu behandeln.

Nach SET READ_COMMITTED_SNAPSHOT ON, Anweisungen beim Festschreiben verwenden die Zeilenversionierung. Beachten Sie, dass dies die Zeilenversionierung auf Anweisungsebene für ist und nur liest. Bei Aktualisierungen wird die "echte" Zeile abgerufen und Aktualisierungssperren angewendet. Weitere Informationen finden Sie im Abschnitt "Zusammenfassung des Verhaltens" in Grundlegendes zu zeilenversionsbasierten Isolationsstufen

In beiden Fällen werden Sie ohne umfassende Tests wahrscheinlich eine völlig neue Reihe von Problemen in das System einführen.

26

Ich glaube, dies wird uns Oracle näher bringen, wo andere Transaktionen, wenn eine Transaktion aktualisiert wird, die alten Daten noch lesen können. Ist das richtig?

Ja, das ist richtig .

Es lohnt sich, die Links in der Antwort von gbn zu lesen, und ich glaube, dass für das Standard-MVCC von Oracle dasselbe gilt wie für SQL Server im Snapshot-Isolationsmodus. Ich würde hinzufügen, dass, wenn Sie die potenziellen Fallstricke verstehen, die Vorteile von IMO die zusätzlichen Schwierigkeiten bei weitem überwiegen (aus Oracle-Sicht) - und natürlich einige Sperrprobleme zu Recht verschwinden, das ist der Punkt von MVCC (es gibt auch eine Klasse von Sperrprobleme, die aufgrund von Codeproblemen nicht behoben werden, aber ich gehe davon aus, dass Sie dies verstehen.

Wir verwenden SNAPSHOT ISOLATION in allen unseren Projekten, die SQL Server DB verwenden. Keine 1205 SQL-Fehler mehr, die nicht auf falschen Anwendungscode zurückzuführen sind, sondern auf das standardmäßige Seiten- und Zeilensperrverhalten.

Die Auswirkungen auf die Leistung sind minimal und bis jetzt sind 7 Jahre vergangen. Hunderte Millionen Vorgänge wurden in verschiedenen Systemen verarbeitet, ohne dass Probleme mit SNAPSHOT ISOLATION aufgetreten sind.

Situationen, in denen mehrere verschiedene Threads geschäftskritische Informationen in einer Zeile parallel aktualisieren, sind äußerst außergewöhnlich, und die Wahrscheinlichkeit, dass SNAPSHOT ISOLATION die Ursache für Inkonsistenzprobleme ist, liegt nahe Null.

Wenn Sie ein OLTP -System) haben, das eine einzelne Zeile basierend auf den aktuellen Zeilendaten in vielen Threads aktualisiert, sind SNAPSHOTS in solchen Fällen natürlich nicht akzeptabel.

10