Nur independent DBH!
|
Standardwert:
STD | |
STD | Ein gelesener Satz (siehe „Sperrgranulat“) ist bis zum Lesen des nächsten Satzes SHARED (siehe „Sperrschärfe“) gesperrt, ein geänderter Satz ist bis zum Transaktionsende EXCLUSIVE gesperrt. |
SHARED | |
Wie bei STD, mit einer Ausnahme: | |
EXCLUSIVE | |
Ein gelesener Satz wird bei einer UPDATE-Verarbeitung bis zum Transaktionsende EXCLUSIVE gesperrt. | |
Sperrgranulat: | |
Gesperrt ist immer die ganze Seite, auf welcher der Satz liegt. | |
Sperrschärfe: | |
SHARED: EXCLUSIVE: | |
Verarbeitungstyp: | |
Unter der Voraussetzung, dass auf einem Realm prinzipiell Änderungen zulässig sind (Datenbank mit UPDATE zugeschaltet, kein explizites Abschalten (DAL) oder implizites Abschalten (Fehlerbehandlung) oder Sperren von Realms oder Datenbanken, keine durch BPRIVACY gesetzte Realm-Sperre), ist im SQL-Fall der Verarbeitungstyp immer UPDATE, im Nicht-SQL-Fall genau dann, falls READY-USAGE-MODE=UPDATE. |
Der Parameter bezieht sich auf alle Datenbanken, die an der Session teilnehmen.
PP LOCK=SHARED sollten Sie angeben, wenn Sie die DML-Anweisung KEEP nutzen, um Daten wiederholt lesen zu können und nicht zum Zwecke der Serialisierung gegenüber anderen Transaktionen.
PP LOCK=EXCLUSIVE kann durch eine Reduzierung der parallelen Verarbeitung zu kürzeren Pfadlängen und selteneren Deadlocks führen. PP LOCK=EXCLUSIVE sollten Sie nur angeben, wenn für alle UPDATE-Transaktionen Folgendes gilt:
Alle gelesenen Sätze werden auch geändert.
Es gibt keine sequenziell laufenden Suchfragen (FIND-7).
Vor jedem Zugriff auf den Membersatz eines nicht-singulären Sets wird der Ownersatz gelesen und verändert.
Wenn eine dieser Voraussetzungen fehlt, kann es dazu führen, dass die Parallelität vermindert wird oder die erhoffte Einsparung der Pfadlänge nicht zu Stande kommt. Dann sollten Sie durch Performance-Vergleich überprüfen, ob der Einsatz von PP LOCK=EXCLUSIVE sinnvoll ist.