Cursorparallelität (Datenbankmodul)

Microsoft SQL Server 2005 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.

Hinweis:
Wenn in SQL Server 2000 und SQL Server 7.0 die zugrunde liegende Tabelle eine timestamp-Spalte aufweist, wird OPTIMISTIC WITH ROW VERSIONING selbst dann verwendet, wenn OPTIMISTIC WITH VALUES angegeben wurde. Wenn OPTIMISTIC WITH ROW VERSIONING angegeben wurde und die Tabelle keine Timestamps aufweist, wird OPTIMISTIC WITH VALUES 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.

Hinweis:
Bei 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 gemeinsam verwendete 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:
In SQL Server 2005 werden Scrollsperren nur für keysetgesteuerte und dynamische Cursor unterstützt.

*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.

Siehe auch

Andere Ressourcen

DECLARE CURSOR (Transact-SQL)
Cursor Concurrency (ODBC)

Hilfe und Informationen

Informationsquellen für SQL Server 2005