{"id":832,"date":"2007-12-05T19:17:20","date_gmt":"2007-12-05T18:17:20","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2007\/12\/05\/allgemein\/blockierungen-bei-updates-auf-unterschiedlichen-datensaetzen"},"modified":"2007-12-05T21:35:38","modified_gmt":"2007-12-05T20:35:38","slug":"blockierungen-bei-updates-auf-unterschiedlichen-datensaetzen","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2007\/12\/05\/allgemein\/blockierungen-bei-updates-auf-unterschiedlichen-datensaetzen","title":{"rendered":"Blockierungen bei Updates auf unterschiedlichen Datensätzen"},"content":{"rendered":"

Die Frage<\/a> lautete:<\/p>\n

Auf Verbindung 1 wird in einer etwas längeren Transaktion (ja, macht man nicht, aber nur mal angenommen..) der Datensatz mit ID "0815\u2033 geändert.<\/p>\n

Auf Verbindung 2 wird jetzt ein UPDATE-Befehl auf den Datensatz mit der ID "4711\u2033 abgesetzt (\u2026 WHERE ID = 4711).<\/p>\n

Geht der UPDATE auf der Verbindung 2 glatt durch oder wird er von Verbindung 1 blockiert?<\/p><\/blockquote>\n

Das kommt darauf an….<\/p>\n

Tabelle ohne Index<\/strong><\/p>\n

Gehen wir mal davon aus, die Tabelle ist ein Heap, also eine Tabelle ohne Clustered Index, außerdem sind gar keine Indexes darauf. Dann muss der SQL-Server wohl oder übel einen Table-Scan durchführen um die betroffenen Sätze zu finden. Dazu liest er jeden Satz durch. Auf den gerade untersuchten Satz wird eine Update-Sperre (U) gesetzt. Ist der Datensatz betroffen, dann wird sie ein eine Exklusiv-Sperre (X) umgewandelt, sonst sofort wieder freigegeben.<\/p>\n

Wegen des Table-Scan versucht Verbindung 2 auch den Satz mit ID 0815 zu lesen (er liest alle Sätze der Tabelle). Der ist schon gesperrt, daher wird die Verbindung blockiert<\/strong>. Der zweite muss warten und versteht nicht warum… \ud83d\ude09<\/p>\n

Der SQL-Server-2005 verwendet hier übrigens Satz-Sperren, während der 2000er generell beim Table-Scan Seitensperren verwendete. In den anderen unten genannten Fällen verhalten sich die Systeme gleich.<\/p>\n

Tabelle mit Index<\/strong><\/p>\n

Hat die Tabelle einen Index auf dem Suchfeld (hier ID), dann sieht es anders aus. Sowohl bei einem Clustered-Index als auch einem normalen Index kann der SQL-Server den Datensatz direkt mittels Index-Seek anspringen. <\/p>\n

Daher tritt hier keine Blockierung<\/strong> auf.<\/p>\n

Tabelle mit Index, Suche über zwei Felder<\/strong><\/p>\n

Angenommen wir filtern nicht über die ID, sondern über zwei Felder, z.B. Kundennummer und laufende-Nummer (… WHERE KDNR=4711 AND LFDNR=10). Nur auf einem davon ist ein Index: Auf der Kundennummer liegt ein nicht-eindeutiger Index, pro Kundennummer kann es zig laufende Nummern geben.<\/p>\n

Dann macht der SQL-Server zwar einen Index-Seek auf alle Sätze mit KDNR=4711, aber er muss für alle potentiell betroffenen Sätze nachsehen, welchen Wert LFDNR hat. Daher wird auch hier eine Blockierung auftreten<\/strong>, wenn zufällig ein anderer Satz mit der gleichen Kundennummer schon exklusiv gesperrt ist.<\/p>\n

Resümee<\/strong><\/p>\n

Ob es bei zwei UPDATEs auf unterschiedlichen Datensätzen zu einer Blockierung kommt oder nicht, hängt ganz allein vom Zugriffsplan des "Zweiten" ab. Der Nutzen der richtigen Indexe kann gar nicht hoch genug bewertet werden.<\/p>\n

Und wie schon Cato sagte: Transaktionen müssen immer so kurz wie möglich sein.<\/p>\n

Ausschlussklauseln<\/strong><\/p>\n