Cursorparallelität (Datenbankmodul)
Microsoft SQL Server unterstützt vier Parallelitätsoptionen für Servercursor:
READ_ONLY
OPTIMISTIC WITH VALUES
OPTIMISTIC WITH ROW VERSIONING
SCROLL LOCKS
READ_ONLY
Positionierte Aktualisierungen über den Cursor sind nicht zulässig; es werden keine Sperren für die Zeilen aufrechterhalten, aus denen das Resultset besteht.OPTIMISTIC WITH VALUES
Die Steuerung durch vollständige Parallelität ist ein Standardbestandteil der Theorie für die Transaktionssteuerung. Die Steuerung durch vollständige Parallelität wird in Situationen verwendet, in denen nur eine geringe Chance besteht, dass ein anderer Benutzer oder Prozess eine Zeile im Zeitraum zwischen dem Öffnen eines Cursors und dem Aktualisieren der Zeile bearbeiten könnte. Wird ein Cursor mit dieser Option geöffnet, werden keine Sperren für die zugrunde liegenden Zeilen aufrechterhalten; dadurch kann der Durchsatz maximiert werden. Wenn der Benutzer versucht, eine Zeile zu ändern, werden die aktuellen Werte in der Zeile mit den Werten verglichen, die beim letzten Abrufvorgang abgerufen wurden. Wenn sich Werte geändert haben, erkennt der Server, dass die Zeile bereits von einem anderen Benutzer oder Prozess aktualisiert wurde, und gibt einen Fehler zurück. Wenn die Werte identisch sind, führt der Server die Änderung aus.Durch Auswahl dieser Parallelitätsoption wird der Benutzer oder Programmierer gezwungen, selbst mit dem gelegentlich auftretenden Fehler umzugehen, der darauf hinweist, dass die Zeile von einem anderen Benutzer geändert wurde. Eine Anwendung, die diesen Fehler empfängt, aktualisiert in der Regel den Cursor, ruft die neuen Werte ab und lässt dann den Benutzer entscheiden, ob die Änderung für die neuen Werte ausgeführt werden soll. In SQL Server Version 6.5 oder früher werden die Spalten text, ntext und image nicht für Parallelitätsvergleiche verwendet.
OPTIMISTIC WITH ROW VERSIONING
Diese Steuerungsoption für die vollständige Parallelität basiert auf der Zeilenversionsverwaltung. Bei der Zeilenversionsverwaltung muss die zugrunde liegende Tabelle über einen Versionsbezeichner verfügen, über den der Server ermitteln kann, ob die Zeile nach dem Lesen in den Cursor geändert wurde. In SQL Server wird diese Funktion durch den timestamp-Datentyp bereitgestellt. Hierbei handelt es sich um eine binäre Zahl, die die relative Reihenfolge von Änderungen in einer Datenbank angibt. Jede Datenbank verfügt über einen globalen aktuellen timestamp-Wert, nämlich **@@**DBTS. Bei jeder Änderung einer Zeile mit einer timestamp-Spalte speichert SQL Server den aktuellen **@@**DBTS-Wert in der timestamp-Spalte und inkrementiert anschließend **@@**DBTS. Wenn eine Tabelle über eine timestamp-Spalte verfügt, werden die Timestamps auf die Zeilenebene übernommen. Der Server kann dann den aktuellen timestamp-Wert einer Zeile mit dem timestamp-Wert vergleichen, der beim letzten Abrufen der Zeile gespeichert wurde, und so ermitteln, ob die Zeile aktualisiert wurde. Hierbei muss der Server nicht die Werte in allen Spalten vergleichen, nur die timestamp-Spalte. Wenn eine Anwendung die vollständige Parallelität mit Zeilenversionsverwaltung für eine Tabelle anfordert, die keine timestamp-Spalte aufweist, verwendet der Cursor standardmäßig die auf Werten basierende Steuerung für die vollständige Parallelität..gif "Hinweis")
HinweisBei Cursorn, die über Remotedatenquellen geöffnet wurden, sind Aktualisierungen über den Cursor nicht möglich, wenn die Remotequelle keine timestamp-Spalte enthält.
SCROLL LOCKS
Bei dieser Option wird die Steuerung für die eingeschränkte Parallelität implementiert, bei der die Anwendung versucht, die zugrunde liegenden Datenbankzeilen zu genau dem Zeitpunkt zu sperren, zu dem sie in das Resultset des Cursors eingelesen werden. Wenn Servercursor verwendet werden, wird auf der Zeile beim Einlesen in den Cursor eine Aktualisierungssperre platziert. Wenn der Cursor innerhalb einer Transaktion geöffnet wird, wird die Transaktionsaktualisierungssperre aufrechterhalten, bis entweder ein Commit oder ein Rollback für die Transaktion ausgeführt wird. Die Cursorsperre wird beim nächsten Abrufen einer Zeile aufgehoben. Wenn der Cursor außerhalb einer Transaktion geöffnet wurde, wird die Sperre beim nächsten Abrufen einer Zeile aufgehoben. Deshalb sollte ein Cursor immer dann in einer Transaktion geöffnet werden, wenn der Benutzer die Steuerung für die eingeschränkte Parallelität in vollem Umfang wünscht. Durch eine Aktualisierungssperre wird verhindert, dass andere Tasks eine Aktualisierungssperre oder exklusive Sperre abrufen, die wiederum verhindert, dass andere Tasks die Zeile aktualisieren. Eine Aktualisierungssperre blockiert jedoch keine freigegebene Sperre; somit verhindert sie nicht, dass andere Tasks die Zeile lesen, es sei denn, der zweite Task fordert ebenfalls einen Lesevorgang mit einer Aktualisierungssperre an.
Scroll Locks
Diese Cursorparallelitätsoptionen generieren möglicherweise Scrollsperren, abhängig von den in der SELECT-Anweisung der Cursordefinition angegebenen Sperrhinweisen. Scrollsperren werden bei einem Abrufvorgang für jede Zeile abgerufen und bis zum nächsten Abrufen oder Schließen des Cursors aufrechterhalten, je nachdem, welches Ereignis zuerst auftritt. Beim nächsten Abrufvorgang ruft der Server Scrollsperren für die Zeilen im neuen Abrufvorgang ab und gibt dann die Scrollsperren für die Zeilen im vorhergehenden Abrufvorgang frei. Scrollsperren hängen nicht von Transaktionssperren ab und können Commit- oder Rollbackvorgänge überdauern. Wenn die Option für das Schließen der Cursor bei einem Commitvorgang deaktiviert ist, werden offene Cursor durch COMMIT nicht geschlossen, und Scrollsperren werden über den Commitvorgang hinaus aufrechterhalten, um die Isolation der abgerufenen Daten zu erhalten.
Der Typ der abgerufenen Scrollsperren hängt von der Cursorparallelitätsoption und den Sperrhinweisen in der SELECT-Anweisung des Cursors ab.
| Hinweis |
|---|
Scrollsperren werden nur für keysetgesteuerte und dynamische Cursor unterstützt. |
Sperrhinweise |
Schreibgeschützt |
Vollständig mit Werten |
Vollständig mit Zeilenversionsverwaltung |
Sperren |
|---|---|---|---|---|
Keine Hinweise |
- |
- |
- |
Aktualisieren |
NOLOCK* |
- |
- |
- |
- |
HOLDLOCK |
- |
- |
- |
Aktualisieren |
UPDLOCK |
- |
- |
- |
Aktualisieren |
TABLOCKX |
- |
- |
- |
Aktualisieren |
Alle sonstigen |
- |
- |
- |
Aktualisieren |
*Durch Angeben des NOLOCK-Hinweises wird die Tabelle, für die der Hinweis angegeben ist, durch den Cursor schreibgeschützt.
Angeben der Cursorparallelitätsoptionen
Die Parallelitätsoptionen werden in jeder Cursorumgebung unterschiedlich angegeben:
Transact-SQL-Cursor
Geben Sie die Schlüsselwörter READ_ONLY, SCROLL_LOCK und OPTIMISTIC für die DECLARE CURSOR-Anweisung an. Durch das Schlüsselwort OPTIMISTIC wird die vollständige Parallelität mit Zeilenversionsverwaltung angegeben. Transact-SQL-Cursor unterstützen die OPTIMISTIC WITH VALUES-Parallelitätsoption nicht.
ADO-Anwendungen
Geben Sie adLockReadOnly, adLockPessimistic, adLockOptimistic oder adLockBatchOptimistic in der LockType-Eigenschaft eines Recordset-Objekts an.
ODBC-Anwendungen
Legen Sie das SQL_ATTR_CONCURRENCY-Anweisungsattribut auf SQL_CONCUR_READ_ONLY, SQL_CONCUR_ROWVER, SQL_CONCUR_VALUES oder SQL_CONCUR_LOCK fest.