Bildnachweis:Alexander Baxevanis Aktualisiert am 23. April 2015
Letztes Jahr habe ich eine Reihe von Beiträgen zusammengestellt, die darauf abzielen, einen detaillierten Blick auf Parallelität, die ACID-Eigenschaften von Anweisungen und Transaktionen und jede der wichtigsten Isolationsstufen in SQL Server zu werfen. Jetzt habe ich die Serie mit einem abschließenden Beitrag zum wahrscheinlich am häufigsten absichtlich verwendeten Isolationslevel abgeschlossen:Read Uncommitted ("NOLOCK").
| Die ACID-Eigenschaften von Kontoauszügen und Transaktionen |
| Die serialisierbare Isolationsstufe |
| Die Isolationsstufe für wiederholbares Lesen |
| Die Read Committed-Isolationsstufe |
| Festgeschriebene Snapshot-Isolation lesen |
| Datenänderungen unter Read Committed Snapshot Isolation |
| Die SNAPSHOT-Isolationsstufe |
| Die Read Uncommitted-Isolationsstufe |
Da Sie sich auf die letzte Folge geduldet haben, kann ich Ihnen etwas anderes Hintergrundlesen/Beobachten von ungebundenem Lesen anbieten:
- Lubor Kollar :Zuvor festgeschriebene Zeilen könnten übersehen werden, wenn der NOLOCK-Hinweis verwendet wird
- Aaron Bertrand:Schlechte Angewohnheiten:NOLOCK überall platzieren
- Craig Freedman:Abfragefehler bei Read Uncommitted
- Aaron Bertrand :Vermeiden Sie die Verwendung von NOLOCK in SQL Server UPDATE- und DELETE-Anweisungen
- David Lean :SQL Server NOLOCK Hint &andere schlechte Ideen
- Sunil Agarwal :Concurrency Series:Warum werde ich blockiert, wenn ich die Isolationsstufe „Read Uncommitted“ oder den NOLOCK-Hinweis verwende?
- Tony Rogerson :Timebomb – The Consistency Problem with NOLOCK / READ UNCOMMITTED (und ein Follow-up)
