Informationen zum Auswählen eines Cursortyps
Die Auswahl eines Cursortyps hängt von verschiedenen Variablen, einschließlich der folgenden, ab:
Der Größe des Resultsets.
Dem Prozentsatz der Daten, die vermutlich benötigt werden.
Der Leistung des Öffnens eines Cursors.
Dem Bedarf an Cursorvorgänge, wie z. B. Scrollen oder positionierte Aktualisierungen.
Dem Maß an Sichtbarkeit für Datenänderungen, die von anderen Benutzern ausgeführt werden.
Die Standardeinstellungen sind für ein kleines Resultset akzeptabel, sofern keine Aktualisierung erfolgt, doch eignet sich ein dynamischer Cursor für ein großes Resultset besser, bei dem es wahrscheinlich ist, dass ein Benutzer eine Antwort findet, bevor viele Zeilen abgerufen werden müssen.
Wenn die abzurufenden Daten alle auf einmal verwendet werden und es keinen Bedarf für positionierte Aktualisierungen oder Scrolling gibt, werden Standardresultsets empfohlen. Bei SQL Server entfällt die Einschränkung, welche verhindert hat, dass mehrere ausstehende Standardresultsets möglich sind, wenn das MARS-Feature (Multiple Active Result Sets) verwendet wird.
Regeln für das Auswählen eines Cursortyps
Einige einfache Regeln, die bei der Auswahl eines Cursortyps beachtet werden sollten, sind folgende:
Verwenden Sie möglichst Standardresultsets. Wenn Scrolling benötigt wird, kann es effizienter sein, ein kleines Resultset auf dem Client zwischenzuspeichern und durch den Cache zu scrollen, statt den Server aufzufordern, einen Cursor zu implementieren.
Verwenden Sie die Standardeinstellungen, wenn Sie ein gesamtes Resultset für den Client abrufen, wie etwa beim Erstellen eines Berichts. Standardresultsets stellen die schnellste Möglichkeit dar, Daten an den Client zu übertragen.
Standardresultsets können nicht verwendet werden, wenn die Anwendung positionierte Aktualisierungen verwendet.
Standardresultsets müssen bei allen Transact-SQL-Anweisungen oder Batches mit Transact-SQL-Anweisungen verwendet werden, die mehrere Resultsets generieren.
Dynamische Cursor können schneller als statische Cursor oder keysetgesteuerte Cursor geöffnet werden. Interne temporäre Arbeitstabellen müssen erstellt werden, wenn statische oder keysetgesteuerte Cursor geöffnet werden, sind jedoch für dynamische Cursor nicht erforderlich.
Bei Verknüpfungen können keysetgesteuerte und statische Cursor schneller als dynamische Cursor sein.
Keysetgesteuerte oder statische Cursor müssen dann verwendet werden, wenn Sie absolute Abrufvorgänge ausführen möchten.
Durch statische und keysetgesteuerte Cursor wird die Nutzung von tempdb erhöht. Statische Servercursor erstellen den gesamten Cursor in tempdb; keysetgesteuerte Cursor hingegen erstellen das Keyset in tempdb.
Falls ein Cursor während eines Rollbackvorgangs geöffnet gehalten werden muss, verwenden Sie einen synchronen statischen Cursor und legen CURSOR_CLOSE_ON_COMMIT auf OFF fest.
Jeder Aufruf einer API-Abruffunktion oder -methode löst einen Roundtrip zum Server aus, wenn Servercursor verwendet werden. Anwendungen sollten diese Roundtrips durch das Verwenden von Blockcursorn mit einer ausreichend großen Anzahl von Zeilen minimieren, die bei jedem Abrufvorgang zurückgegeben werden.