it-swarm.com.de

Warum sollte die Isolationsstufe READ UNCOMMITTED verwendet werden?

Was sind im Klartext die Nachteile und Vorteile der Verwendung?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

in einer Abfrage für .NET-Anwendungen und Reporting Services-Anwendungen?

212
Kip Real

Diese Isolationsstufe ermöglicht unsaubere Lesevorgänge. Bei einer Transaktion werden möglicherweise nicht festgeschriebene Änderungen angezeigt, die von einer anderen Transaktion vorgenommen wurden.

Um die höchste Isolationsstufe aufrechtzuerhalten, erfasst ein DBMS normalerweise Sperren für Daten, was zu einem Verlust der Parallelität und einem hohen Sperrenaufwand führen kann. Diese Isolationsstufe entspannt diese Eigenschaft.

Vielleicht möchten Sie den Wikipedia-Artikel auf READ UNCOMMITTED für ein paar Beispiele und weiterführende Literatur lesen.


Vielleicht möchten Sie auch Jeff Atwoods Blog-Artikel lesen, wie er und sein Team ein Deadlock-Problem in den frühen Tagen von Stack Overflow gelöst haben. Nach Jeff:

Aber ist nolock gefährlich? Könnten Sie am Ende ungültige Daten lesen, wenn read uncommitted Aktiviert ist? Ja, theoretisch. Es mangelt Ihnen nicht an Astronauten mit Datenbankarchitektur, die beginnen, die ACID-Wissenschaft auf Sie abzulegen, und Sie werden den Gebäudefeueralarm nur auslösen, wenn Sie ihnen mitteilen, dass Sie es mit nolock versuchen möchten. Es ist wahr: Die Theorie ist beängstigend. Aber hier ist, was ich denke: "In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis. In der Praxis gibt es."

Ich würde niemals empfehlen, nolock als allgemeines "gut für was auch immer Sie" -Schlangenöl zu verwenden, um eventuelle Probleme mit dem Deadlock von Datenbanken zu beheben. Sie sollten zuerst versuchen, die Ursache des Problems zu diagnostizieren.

Aber in der Praxis scheint das Hinzufügen von nolock zu Abfragen, von denen Sie absolut wissen, dass sie einfach sind, keine Probleme zu verursachen. Solange Sie wissen, was Sie tun. ' mache ich.

Eine Alternative zur READ UNCOMMITTED - Stufe, die Sie in Betracht ziehen könnten, ist die READ COMMITTED SNAPSHOT. Jeff noch einmal zitieren:

Snapshots basieren auf einer völlig neuen Methode zur Nachverfolgung von Datenänderungen. Es handelt sich nicht nur um eine geringfügige logische Änderung, sondern es ist auch erforderlich, dass der Server die Daten physisch unterschiedlich verarbeitet. Sobald diese neue Datenänderungsverfolgungsmethode aktiviert ist, wird eine Kopie oder ein Schnappschuss jeder Datenänderung erstellt. Durch das Lesen dieser Snapshots anstelle von Live-Daten zu Konfliktzeiten werden Shared Locks beim Lesen nicht mehr benötigt, und die Gesamtleistung der Datenbank kann sich erhöhen.

194
Daniel Vassallo

Dies kann nützlich sein, um den Fortschritt langer Einfügeabfragen zu verfolgen, grobe Schätzungen vorzunehmen (wie COUNT(*) oder rough SUM(*)) usw.

Mit anderen Worten, die Ergebnisse, die von den Dirty Read-Abfragen zurückgegeben werden, sind in Ordnung, solange Sie sie als Schätzungen behandeln und keine kritischen Entscheidungen treffen, die auf diesen basieren.

35
Quassnoi

Mein Lieblingsanwendungsfall für read uncommited dient zum Debuggen von Vorgängen innerhalb einer Transaktion.

Starten Sie Ihre Software unter einem Debugger, während Sie die Codezeilen durchgehen, eine Transaktion öffnen und Ihre Datenbank ändern. Während der Code gestoppt ist, können Sie einen Query Analyzer öffnen, die Isolationsstufe Lesen ohne Commit einstellen und Abfragen durchführen, um zu sehen, was los ist.

Sie können es auch verwenden, um festzustellen, ob lang laufende Verfahren nicht funktionieren oder Ihre Datenbank korrekt aktualisieren.

Es ist großartig, wenn Ihr Unternehmen gerne übermäßig komplexe gespeicherte Prozeduren erstellt.

32
neves

Der Vorteil ist, dass es in manchen Situationen schneller sein kann. Der Nachteil ist, dass das Ergebnis falsch sein kann (Daten, die noch nicht festgeschrieben wurden, können zurückgegeben werden), und es gibt keine Garantie dafür, dass das Ergebnis reproduzierbar ist.

Wenn Ihnen die Genauigkeit am Herzen liegt, verwenden Sie diese Option nicht.

Weitere Informationen finden Sie unter MSDN :

Implementiert Dirty Read oder Sperren der Isolationsstufe 0, was bedeutet, dass keine gemeinsam genutzten Sperren ausgegeben und keine exklusiven Sperren berücksichtigt werden. Wenn diese Option aktiviert ist, können nicht festgeschriebene oder verschmutzte Daten gelesen werden. Werte in den Daten können geändert werden und Zeilen können vor dem Ende der Transaktion im Datensatz erscheinen oder verschwinden. Diese Option hat den gleichen Effekt wie das Setzen von NOLOCK für alle Tabellen in allen SELECT-Anweisungen in einer Transaktion. Dies ist die am wenigsten einschränkende der vier Isolationsstufen.

22
Mark Byers

Wann ist es in Ordnung, READ UNCOMMITTED Zu verwenden?

Faustregel

Gut: Große Summenberichte mit sich ständig ändernden Summen.

Riskant: Fast alles andere.

Die gute Nachricht ist, dass die Mehrheit der schreibgeschützten Berichte in die Kategorie Gut fällt.

Mehr Details...

Ok, um es zu benutzen:

  • Nahezu alle Aggregatberichte für Benutzer mit Blick auf aktuelle, nicht statische Daten, z. Jahresumsatz. Es besteht das Risiko einer Fehlerquote (möglicherweise <0,1%), die viel geringer ist als bei anderen Unsicherheitsfaktoren wie der Eingabe von Fehlern oder der Zufälligkeit, wann genau die Daten von Minute zu Minute aufgezeichnet werden.

Dies deckt wahrscheinlich den größten Teil dessen ab, was eine Business Intelligence-Abteilung beispielsweise bei SSRS tun würde. Die Ausnahme ist natürlich alles mit $ -Zeichen davor. Viele Leute machen Geld mit viel mehr Eifer als mit den dazugehörigen Kernmetriken, die erforderlich sind, um den Kunden zu bedienen und dieses Geld zu generieren. (Ich beschuldige Buchhalter).

Wenn riskant

  • Jeder Bericht, der bis zur Detailebene reicht. Wenn dieses Detail erforderlich ist, bedeutet dies normalerweise, dass jede Zeile für eine Entscheidung relevant ist. Wenn Sie eine kleine Teilmenge nicht abrufen können, ohne sie zu blockieren, liegt dies möglicherweise auch daran, dass sie gerade bearbeitet wird.

  • Historische Daten. Es macht selten einen praktischen Unterschied, aber während Benutzer verstehen, dass sich ständig ändernde Daten nicht perfekt sein können, sehen sie statische Daten anders. Dirty Reads schaden hier nicht, aber Double Reads können gelegentlich sein. Da statische Daten ohnehin nicht blockiert werden sollten, warum sollten Sie dies riskieren?

  • Fast alles, was eine Anwendung mit Schreibfunktionen versorgt.

Wenn auch das OK-Szenario nicht in Ordnung ist.

  • Verwenden Anwendungen oder Aktualisierungsprozesse große Einzeltransaktionen? Eine, die viele Datensätze entfernt und dann wieder einfügt, über die Sie Bericht erstatten? In diesem Fall können Sie NOLOCK für diese Tabellen wirklich nicht verwenden.
11
Adamantish

In Bezug auf die Berichterstellung verwenden wir sie für alle Berichtsabfragen, um zu verhindern, dass eine Abfrage Datenbanken blockiert. Wir können das tun, weil wir historische Daten abrufen und nicht Daten, die auf die Mikrosekunde genau sind.

5
Hugh Seagraves

Dadurch erhalten Sie Dirty Reads und können Transaktionen anzeigen, die noch nicht festgeschrieben wurden. Das ist die naheliegendste Antwort. Ich halte es nicht für eine gute Idee, dies nur zu verwenden, um Ihre Lesevorgänge zu beschleunigen. Es gibt andere Möglichkeiten, dies zu tun, wenn Sie ein gutes Datenbankdesign verwenden.

Es ist auch interessant zu bemerken, was nicht passiert. READ UNCOMMITTED ignoriert nicht nur andere Tabellensperren. Es verursacht auch keine eigenen Sperren.

Stellen Sie sich vor, Sie generieren einen umfangreichen Bericht oder Sie migrieren Daten mithilfe einer umfangreichen und möglicherweise komplexen SELECT-Anweisung aus Ihrer Datenbank. Dies führt zu einer gemeinsamen Sperre, die möglicherweise für die Dauer Ihrer Transaktion in eine gemeinsame Tabellensperre eskaliert wird. Andere Transaktionen können aus der Tabelle gelesen werden, Aktualisierungen sind jedoch nicht möglich. Dies kann eine schlechte Idee sein, wenn es sich um eine Produktionsdatenbank handelt, da die Produktion möglicherweise vollständig gestoppt wird.

Wenn Sie READ UNCOMMITTED verwenden, wird für die Tabelle keine gemeinsame Sperre festgelegt. Möglicherweise erhalten Sie das Ergebnis von einigen neuen Transaktionen, oder es hängt nicht davon ab, wo in der Tabelle die Daten eingefügt wurden und wie lange Ihre SELECT-Transaktion gelesen wurde. Sie können dieselben Daten auch zweimal abrufen, wenn beispielsweise eine Seitenteilung auftritt (die Daten werden an eine andere Stelle in der Datendatei kopiert).

Wenn es für Sie also sehr wichtig ist, dass Daten während der Ausführung von SELECT eingefügt werden können, kann es sinnvoll sein, READ UNCOMMITTED zu verwenden. Sie müssen berücksichtigen, dass Ihr Bericht möglicherweise einige Fehler enthält. Wenn er jedoch auf Millionen von Zeilen basiert und nur einige von ihnen bei der Auswahl des Ergebnisses aktualisiert werden, ist dies möglicherweise "gut genug". Ihre Transaktion kann auch insgesamt fehlschlagen, da die Eindeutigkeit einer Zeile möglicherweise nicht garantiert wird.

Ein insgesamt besserer Weg ist möglicherweise die Verwendung von SNAPSHOT ISOLATION LEVEL, aber Ihre Anwendungen müssen möglicherweise einige Anpassungen vornehmen, um dies zu verwenden. Ein Beispiel hierfür ist, wenn Ihre Anwendung eine exklusive Sperre für eine Zeile verwendet, um zu verhindern, dass andere Benutzer sie lesen und in der Benutzeroberfläche in den Bearbeitungsmodus wechseln. SNAPSHOT ISOLATION LEVEL hat auch erhebliche Leistungseinbußen (insbesondere auf der Festplatte). Aber Sie können das überwinden, indem Sie Hardware auf das Problem werfen. :)

Sie können auch eine Sicherung der Datenbank wiederherstellen, um Daten zu melden oder in ein Data Warehouse zu laden.

1
Olle Johansson

Verwenden Sie READ_UNCOMMITTED in Situationen, in denen sich die Quelle höchstwahrscheinlich nicht ändert.

  • Beim Lesen von historischen Daten. Beispielsweise einige Bereitstellungsprotokolle, die vor zwei Tagen stattgefunden haben.
  • Beim erneuten Lesen von Metadaten. z.B. metadatenbasierte Anwendung.

Verwenden Sie READ_UNCOMMITTED nicht, wenn Sie wissen, dass sich die Quelle während des Abrufvorgangs ändern kann.

1
neo