Gemeinsamen Zugriff für Anwendungen verbessern, die unvollständige Ergebnisse tolerieren

Sie können die Option SKIP LOCKED DATA verwenden, um gesperrte Zeilen zu überspringen, um den gemeinsamen Zugriff von Anwendungen und Transaktionen zu verbessern, die unvollständige Ergebnisse tolerieren können.

Es ist wichtig zu verstehen, wie die Klausel SKIP LOCKED DATA bei Anweisungen SELECT, SELECT INTO, UPDATE mit Suche oder DELETE mit Suche verwendet werden soll. Die Verwendung der neuen Klausel kann sich erheblich auf das Abfrageergebnis auswirken, da möglicherweise alle qualifizierten Zeilen nicht zurückgegeben werden. Bitte beachten Sie jedoch, dass Db2 möglicherweise Verfahren zur Sperrenvermeidung verwendet, wie zum Beispiel 'Aktuell festgeschrieben' und das Auswerten nicht festgeschriebener Daten, um bestimmte Sperren zu vermeiden, und die Daten möglicherweise nicht überspringt, auch wenn sie gesperrt sind.

Bei Verwendung der neuen Funktion sollte ein sorgfältiges Anwendungsdesign verwendet werden, um den gewünschten Geschäftsanforderungen möglichst genau gerecht zu werden. Möglicherweise erwarten Sie weniger präzise Informationen im Gegenzug für eine schnelle Verfügbarkeit des Abfrageergebnisses ohne Blockierungen durch Sperren.

In allen Fällen gibt Db2 mit SKIP LOCKED DATA die genauesten Daten zurück, ohne auf Sperren zu warten. Wenn es erforderlich ist, auf gesperrte Daten zuzugreifen, um die Abfrage zu beantworten, überspringt Db2 gesperrte Daten und stellt Teilergebnisse (oder Werte, die aus Teilergebnissen abgeleitet sind) zur Verfügung. Wenn keine Daten zur Beantwortung der Abfrage gesperrt werden müssen, überspringt Db2 die Daten auch dann nicht, wenn sie gesperrt sind. Die folgenden Beispiele veranschaulichen zwei solcher Szenarios.

Szenario 1: SKIP LOCKED DATA überspringt Zeilen aufgrund der Semantik für aktuell festgeschriebene Daten nicht

Erstellen Sie eine Tabelle TI wie folgt:

CREATE TABLE T1
 (C1 INTEGER,
  C2 VARCHAR(30))

Füllen Sie die Tabelle T1 mit Werten wie folgt:

Tabelle 1.
C1	C2
1	AAAAAAAA
2	BBBBBBBB
3	CCCCCCCC
4	DDDDDDDD
5	EEEEEEEE

Tabelle 2.
Sitzung 1	Sitzung 2
`db2 +c "update T1 set C2='new value from session1' where C1 <= 3"` Sitzung 1 erhält eine X-Sperre für die Zeilen 1, 2 und 3
	`db2 +c "select * from TQ where C1 >= 3 SKIP LOCKED DATA"` Sitzung 2 (CS-Isolation) muss Zeile 3 lesen. Da sie im X-Modus von Sitzung 1 gesperrt wird, vermeidet Sitzung 2 die Sperrung mit der Semantik für aktuell festgeschriebene Lesevorgänge. Sie erhält aktuell festgeschriebene Daten von Zeile 3 von Member 2. Sitzung 2 überspringt Zeile 3 nicht. Die Ergebnismenge gibt 3 Zeilen zurück: C1 C2 3 CCCCCCCC 4 DDDDDDDD 5 EEEEEEEE

Hinweis: CUR_COMMIT gilt nicht für SELECT-Anweisungen, wenn FOR UPDATE oder RS-Isolation verwendet wird. Wenn SKIP LOCKED verwendet wird, überspringen solche Abfragen, ebenso wie UPDATE und DELETE mit Suche, Zeilen statt auf eine Sperre zu warten, wenn ein Sperrenkonflikt vorliegt.

Szenario 2: SKIP LOCKED DATA überspringt Zeilen aufgrund der Sperrenvermeidung nicht

Erstellen Sie eine Tabelle TI wie folgt:

CREATE TABLE T1
 (C1 INT,
  C2 CHAR );

CREATE INDEX IX1 ON T1(C2);

INSERT INTO T1 VALUES (1, 'AAAA');
INSERT INTO T1 VALUES (2, 'BBBB');
INSERT INTO T1 VALUES (3, 'CCCC');
INSERT INTO T1 VALUES (4, 'DDDD');

Tabelle 3.
Sitzung 1	Sitzung 2
`db2 +c "UPDATE T1 SET C1 = 99 WHERE C1 < 3"` Sitzung 1 erhält eine X-Sperre für die Zeilen 1 und 2
	`db2 +c "select count(*) from T1 where c2 >= 'AAAA' SKIP LOCKED DATA`" SELECT verwendet eine reine Indexsuche. Alle Daten auf der entsprechenden Indexseite werden festgeschrieben und UPDATE in Sitzung 1 hat keine Auswirkungen auf die Indexseite. Dadurch vermeidet Db2 Sperren. SELECT überspringt keine Zeilen und gibt 4 zurück.