Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Sperrprotokoll festlegen (LOCK)

&pagelevel(3)&pagelevel

Nur independent DBH!

PP LOCK={STD | SHARED | EXCLUSIVE}

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.
Eine Sperre, die durch die DML-Anweisung KEEP gesetzt wurde, ist bis zur DML-Anweisung FREE bei einer RETRIEVAL-Verarbeitung SHARED und bei einer UPDATE-Verarbeitung EXCLUSIVE.

SHARED


Wie bei STD, mit einer Ausnahme:
Eine Sperre, die durch die DML-Anweisung KEEP gesetzt wurde, ist immer SHARED.

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:
Sperre gegen Ändern seitens einer fremden Transaktion

EXCLUSIVE:
Sperren gegen Lesen und Ändern seitens einer fremden Transaktion

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.