Sie werden vom Server automatisch gehandhabt. Allerdings können die Sperrmechanismen auch kontrolliert werden; hierfür gibt es drei mögliche Ansätze. Das Sperrverhalten kann über ein sauberes Design (Anwendungs- und Datenbankdesign, Normalisierung, Indizes), Timeouts und Verwendung von Isolationsstufen kontrolliert werden.

• Design: Das Design der Anwendung und der Datenbank ist einer derjenigen Schritte in der Softwareentwicklung, die das Anwendungsverhalten wesentlich beeinflussen. Zum Beispiel sollte beim Datenbankdesign darauf geachtet werden, welche Daten innerhalb einer Tabelle von welchen Anwendungen beziehungsweise Endbenutzern geändert werden. So werden höchstwahrscheinlich in einer Produktdaten-Tabelle die Spalten image und amount von verschiedenen Rollen (z.B. Marketing und Sales) gepflegt, die sich gegenseitig – unnötigerweise – beim Zugriff behindern. Das Design der Datenbank kann zu einem großen Anteil zum Verhindern von Sperren beitragen.
• Timeouts: Ein weiteres Werkzeug zur Kontrolle von Sperren sind Timeouts. Anwender hassen es, auf eine Anwendung warten zu müssen, aber sie hassen es noch mehr, wenn eine Anwendung „einfriert“. Wenn also für bestimmte Tabellen oder Spalten hohen Zugriffsraten und damit eine hohe Anzahl an Sperren zu erwarten sind, dann können für entsprechende SQL-Abfragen Timeouts definiert werden. Selbstverständlich muss die Anwendung dann entsprechend im UI darauf reagieren: ein „Bitte versuchen Sie es später erneut“ ist auf jeden Fall besser als ein 6.
• Isolationsstufen: Eine dritte Möglichkeit zur Beeinflussung des Sperrverhaltens ist die Nutzung von Isolationsstufen.

Im SQL Server kann der Typ der Sperre in Form des folgenden Befehls geändert werden:

Set Transaction Isolation Level

Die folgenden Level können eingestellt werden:

SET TRANSACTION ISOLATION LEVEL

 { READ UNCOMMITTED

 | READ COMMITTED

 | REPEATABLE READ

 | SNAPSHOT

 | SERIALIZABLE

 }

[ ; ]

Prinzipiell kann zu einem Zeitpunkt genau ein Level eingestellt werden, der so lange Gültigkeit hat, wie die Verbindung (connection ) besteht, oder bis zur nächsten Änderung des Levels. In diesem Zusammenhang erlaubt der Isolationslevel READ UNCOMMIITED so genannte „dirty reads“. Dabei können mit einer Query Daten gelesen werden, die innerhalb einer anderen Transaktion zwar bereits manipuliert, jedoch noch nicht commited sind. Intern führt dies beim SQL Server unter anderem dazu, dass weniger Sperren gehalten werden müssen, wodurch sich ebenfalls das Verhalten im Hinblick auf das Ausweiten von Sperren ändern kann. Eine vollständige Beschreibung der Isolation Level bietet Microsoft auf dieser Website . (Jörg M. Freiberger/am)