© best_vector/Shutterstock.com
Windows Developer
Sperrverhalten von Shared Locks unter verschiedenen ISO-Isolationsstufen

Betreten verboten

Um konsistente Daten zu liefern, verwendet Microsoft SQL Server als Standard ein pessimistisches Modell zur Sperrung von Datensätzen. Dieser Artikel beleuchtet die Fragestellung, welche Sperrmechanismen zu diesem Zwecke bei SELECT-Statements zum Einsatz kommen.

Uwe Ricken


Das pessimistische Sperrverhalten wird angewendet, um das ACID-Prinzip durchzusetzen: bei einer unteilbaren (atomicity), konsistenten (consistency), isolierten (isolation), dauerhaften (durability) Transaktion werden Ressourcen so lange vor Änderungen geschützt, wie sie bearbeitet werden. Dieses Verfahren stellt sicher, dass Datensätze zwar gleichzeitig von zwei Anwendern gelesen, aber nicht gleichzeitig von ihnen bearbeitet werden können. Während eine Ressource gelesen wird, kann sie nicht von einer zweiten Transaktion bearbeitet werden, Gleiches gilt auch in umgekehrter Form. Während innerhalb einer Transaktion Datensätze geändert werden, können sie – abhängig von der Isolationsstufe – nicht gelesen werden. Dieser Artikel beschäftigt sich mit den lesenden Sperren (SELECT) und zeigt im Detail, wie Ressourcen unter verschiedenen ISO-Isolationsstufen gelesen und wieder freigegeben werden.

Testumgebung

Alle auszuführenden Tests verwenden einen Heap [1], der 1 000 Datensätze beinhaltet. Die Tabelle aus Listing 1 hat somit ebenfalls 1 000 Datensätze und besitzt keinen Index. Für unsere Tests mit unterschiedlichen ISO-Isolationsstufen reicht dieses einfache Modell aus.

Listing 1-- Erstellen der DemotabelleCREATE TABLE dbo.Customer( Id INT NOT NULL IDENTITY(1,1), Name CHAR(100) NOT NULL, Ort CHAR(100) NOT NULL);GO -- Füllen der Demotabelle mit 1 000 DatensätzenDECLARE @i INT = 1;WHILE @i

Protokollierung mit Microsoft SQL Server Profiler

Für die benötigte Protokollierung ist der Microsoft SQL Server Profiler ausreichend, und er bietet für diesen Artikel verbesserte lesbare Ergebnisse.

Warum eine dedizierte Protokollierung? Bei einigen ISO-Isolationsstufen besteht das Problem von Shared Locks darin, dass man sie nicht „sichtbar“ machen kann, indem man eine dedizierte Transaktion beginnt. Eine Kontrolle der gesetzten Sperren ist daher sehr schwierig und nur während der Ausführung des Befehls in einer SQL-Server-Profiler-Sitzung oder mit Extended Events möglich.

Konfiguration der SQL-Server-Profiler-Sitzung: Während der Ausführung der SQL-Abfragen müssen der Beginn [SQL:StmtStarting] und die Beendigung [SQL:StmtCompleted] der Befehlsausführung protokolliert werden. Weiterhin wird aufgezeichnet, wann eine Objektsperre gesetzt wird [Lock:Acquired] und wann die zuvor gesetzte Sperre wieder aufgehoben wird [Lock:R...

Windows Developer
Sperrverhalten von Shared Locks unter verschiedenen ISO-Isolationsstufen

Betreten verboten

Um konsistente Daten zu liefern, verwendet Microsoft SQL Server als Standard ein pessimistisches Modell zur Sperrung von Datensätzen. Dieser Artikel beleuchtet die Fragestellung, welche Sperrmechanismen zu diesem Zwecke bei SELECT-Statements zum Einsatz kommen.

Uwe Ricken


Das pessimistische Sperrverhalten wird angewendet, um das ACID-Prinzip durchzusetzen: bei einer unteilbaren (atomicity), konsistenten (consistency), isolierten (isolation), dauerhaften (durability) Transaktion werden Ressourcen so lange vor Änderungen geschützt, wie sie bearbeitet werden. Dieses Verfahren stellt sicher, dass Datensätze zwar gleichzeitig von zwei Anwendern gelesen, aber nicht gleichzeitig von ihnen bearbeitet werden können. Während eine Ressource gelesen wird, kann sie nicht von einer zweiten Transaktion bearbeitet werden, Gleiches gilt auch in umgekehrter Form. Während innerhalb einer Transaktion Datensätze geändert werden, können sie – abhängig von der Isolationsstufe – nicht gelesen werden. Dieser Artikel beschäftigt sich mit den lesenden Sperren (SELECT) und zeigt im Detail, wie Ressourcen unter verschiedenen ISO-Isolationsstufen gelesen und wieder freigegeben werden.

Testumgebung

Alle auszuführenden Tests verwenden einen Heap [1], der 1 000 Datensätze beinhaltet. Die Tabelle aus Listing 1 hat somit ebenfalls 1 000 Datensätze und besitzt keinen Index. Für unsere Tests mit unterschiedlichen ISO-Isolationsstufen reicht dieses einfache Modell aus.

Listing 1-- Erstellen der DemotabelleCREATE TABLE dbo.Customer( Id INT NOT NULL IDENTITY(1,1), Name CHAR(100) NOT NULL, Ort CHAR(100) NOT NULL);GO -- Füllen der Demotabelle mit 1 000 DatensätzenDECLARE @i INT = 1;WHILE @i

Protokollierung mit Microsoft SQL Server Profiler

Für die benötigte Protokollierung ist der Microsoft SQL Server Profiler ausreichend, und er bietet für diesen Artikel verbesserte lesbare Ergebnisse.

Warum eine dedizierte Protokollierung? Bei einigen ISO-Isolationsstufen besteht das Problem von Shared Locks darin, dass man sie nicht „sichtbar“ machen kann, indem man eine dedizierte Transaktion beginnt. Eine Kontrolle der gesetzten Sperren ist daher sehr schwierig und nur während der Ausführung des Befehls in einer SQL-Server-Profiler-Sitzung oder mit Extended Events möglich.

Konfiguration der SQL-Server-Profiler-Sitzung: Während der Ausführung der SQL-Abfragen müssen der Beginn [SQL:StmtStarting] und die Beendigung [SQL:StmtCompleted] der Befehlsausführung protokolliert werden. Weiterhin wird aufgezeichnet, wann eine Objektsperre gesetzt wird [Lock:Acquired] und wann die zuvor gesetzte Sperre wieder aufgehoben wird [Lock:R...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang