In einem Data Warehouse-Szenario gibt es einen Nachteil bei der Verwendung von WITH (NOLOCK)

Question

Ich habe eine Kimball-Stil DW (Fakten und Dimensionen in Sternmodellen - keine spät ankommenden Fakten Zeilen oder Spalten, keine Spalten in Dimensionen außer Verfall als ändern Teil der sich langsam ändernden Dimensionen des Typs 2) mit umfangreicher täglicher Verarbeitung zum Einfügen und Aktualisieren von Zeilen (an neuen Daten) und monatlichen und täglichen Berichtsprozessen. Die Fakttabellen sind durch die Daten für die einfache Rollback alter Daten partitioniert.

Ich verstehe die WITH(NOLOCK) uncommitted auszulesenden Daten führen kann, weiß ich nicht aber auch alle Sperren erstellen möchten, die die ETL-Prozesse zu versagen oder zu blockieren verursachen würde. Wenn wir vom DW lesen, lesen wir in allen Fällen von Faktentabellen für ein Datum, das sich nicht ändert (die Faktentabellen sind nach Datum partitioniert), und für Dimensionstabellen, für die keine Attribute für die Fakten geändert werden sie sind verbunden mit.

Also - gibt es irgendwelche Nachteile? - vielleicht in den Ausführungsplänen oder in der Operation von solchen SELECT -nur Abfragen, die parallel von den gleichen Tabellen laufen.

Answer 1

Solange es keine no-update Daten gibt, ist es kein Schaden, aber ich würde mich wundern, wenn es auch viel Nutzen ist. Ich würde sagen, es ist einen Versuch wert. Das Schlimmste, was passieren wird, ist, dass Sie unvollständige und/oder inkonsistente Daten erhalten, wenn Sie sich in der Mitte einer Batch-Einfügung befinden, aber Sie können entscheiden, ob das irgendetwas Nützliches ungültig macht.

Answer 2

Ja. Ihr SQL wird viel weniger lesbar sein. Sie werden unweigerlich einige NOLOCK-Hinweise verpassen, weil SQL SELECT-Befehle, die die NOLOCK-Strategie verwenden, es überallhin mitnehmen müssen.

You can get the same thing by setting the isolation level

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Am Ende erhalten Sie eine 10% Leistungssteigerung (sorry, ich bin zu faul, um den Artikel für sie zu sehen, aber es ist da draußen)

I‘ d sagen, ein 10% Gewinn ist es nicht wert, Lesbarkeit zu reduzieren.

Answer 3

Wenn es möglich ist, die gesamte Datenbank schreibgeschützt zu machen, dann ist dies eine bessere Option. Sie erhalten Lese-Nicht-Commit-Leistung, ohne Ihren gesamten Code ändern zu müssen.

ALTER DATABASE adventureworks SET read_only 

Answer 4

Dies ist, was Sie wahrscheinlich benötigen:

`ALTER DATABASE Adventure SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATENBANK AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION ON; `

Dann gehen Sie vor und

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

in Ihren Abfragen verwenden. Nach BOL:

Das Verhalten von READ COMMITTED auf der Einstellung der READ_COMMITTED_SNAPSHOT Datenbankoption ab:

Wenn READ_COMMITTED_SNAPSHOT auf OFF (Standardeinstellung) gesetzt ist, verwendet die Database Engine gemeinsame Sperren andere Transaktionen zu verhindern, Modifizieren Zeilen, während die aktuelle Transaktion eine Leseoperation ausführt.Die gemeinsam genutzten Sperren blockieren auch, dass die Anweisung Zeilen liest, die von anderen Transaktionen geändert wurden, bis die andere Transaktion abgeschlossen ist. Der freigegebene Sperrtyp bestimmt, wann er freigegeben wird. Zeilensperren werden freigegeben, bevor die nächste Zeile verarbeitet wird. Seitensperren werden freigegeben, wenn die nächste Seite gelesen wird, und Tabellensperren werden freigegeben, wenn die Anweisung abgeschlossen ist.

Wenn READ_COMMITTED_SNAPSHOT auf ON festgelegt ist, verwendet das Datenbankmodul die Zeilenversionsverwaltung, um jede Anweisung mit einem transaktionskonsistenten Snapshot der Daten zu versehen, wie sie am Anfang der Anweisung vorhanden waren. Sperren werden nicht verwendet, um die Daten vor Aktualisierungen durch andere Transaktionen zu schützen.

Hoffe diese Hilfe. Raj

Answer 5

Haben Sie darüber nachgedacht, eine DATABASE SNAPSHOT Ihres DW zu erstellen und Ihre Berichte daraus zu erstellen?

Answer 6

NOLOCK führt einen "schmutzigen Lesevorgang" durch (unanständig LESEN UNKOMMITTIERT macht dasselbe wie NOLOCK). Wenn die Datenbank während des Lesens aktualisiert wird, besteht die Gefahr, dass inkonsistente Daten zurückgegeben werden. Die einzige Option besteht darin, entweder das Sperren und damit das Blockieren zu akzeptieren oder eine der beiden neuen Isolationsstufen zu wählen, die in SQL 2005 ab discussed here angeboten werden.