Ein Transaktionsprotokoll auf einem SQL Server-Computer wächst unerwartet oder wird voll

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 317375 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
317375 A transaction log grows unexpectedly or becomes full on a computer that is running SQL Server
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

In SQL Server 7.0, SQL Server 2000 und SQL Server 2005 können Transaktionsprotokoll-Dateien mit der Einstellung "Automatische Vergrößerung" automatisch wachsen.

Typischerweise stabilisiert sich die Größe der Transaktionsprotokoll-Datei, wenn sie die maximale Anzahl an Transaktionen aufnehmen kann, die zwischen Kürzungen des Transaktionsprotokolls ausgeführt werden können, die entweder durch Prüfpunkte oder durch das Erstellen von Sicherungskopien des Transaktionsprotokolls ausgelöst werden.

In bestimmten Situationen kann das Transaktionsprotokoll jedoch so umfangreich werden, dass der dafür vorgesehene Speicherplatz nahezu oder ganz erschöpft ist. In der Regel wird Ihnen die folgende Fehlermeldung angezeigt, wenn eine Transaktionsprotokoll-Datei den gesamten verfügbaren Speicherplatz ausfüllt und nicht mehr vergrößert werden kann:
Fehler: 9002, Schweregrad: 17, Status: 2
Die Protokolldatei für die '%.*ls'-Datenbank ist voll.
Bei der Verwendung von SQL Server 2005 wird eine Fehlermeldung etwa folgenden Inhalts angezeigt:
Fehler 9002, Schweregrad: 17, Status: 2
Die Protokolldatei für die '%.*ls'-Datenbank ist voll. Die log_reuse_wait_desc-Spalte von 'sys.databases' enthält Informationen dazu, warum Protokollspeicherplatz nicht erneut verwendet werden kann.
Zusätzlich zu dieser Fehlermeldung markiert SQL Server Datenbanken unter Umständen aufgrund des nicht ausreichenden Speicherplatzes für eine Erweiterung des Transaktionsprotokolls als fehlerverdächtig. Weitere Informationen zur Problembehandlung in dieser Situation finden Sie unter dem Thema "Insufficient Disk Space" (Unzureichender Speicherplatz) in der Onlinedokumentation zu SQL Server.

Außerdem kann eine Vergrößerung des Transaktionsprotokolls zu folgenden Situationen führen:
  • Zu einer sehr umfangreichen Transaktionsprotokoll-Datei
  • Transaktionen können fehlschlagen und es kann ein Rollback dieser Transaktionen gestartet werden.
  • Die vollständige Ausführung von Transaktionen nimmt viel Zeit in Anspruch.
  • Es können Leistungsprobleme auftreten.
  • Es können Blockierungen auftreten.

Ursachen

Aus den folgenden Gründen oder in den folgenden Szenarios kann es zu einer Vergrößerung des Transaktionsprotokolls kommen: Hinweis: In SQL Server 2005 können Sie die Spalten log_reuse_wait und log_reuse_wait_desc in der Katalogansicht "sys.databases" überprüfen, um die Ursachen für die folgenden Probleme zu ermitteln:
  • Der Transaktionsprotokoll-Speicher kann nicht wieder verwendet werden
  • Das Transaktionsprotokoll kann nicht abgeschnitten werden

Nicht übergebene Transaktionen

Explizite Transaktionen werden nicht übergeben, wenn Sie keinen expliziten COMMIT- oder ROLLBACK-Befehl ausgeben. Dies ist am häufigsten dann der Fall, wenn eine Anwendung einen CANCEL- oder Transact SQL KILL-Befehl ohne den entsprechenden ROLLBACK-Befehl ausgibt. Die Transaktion wird zwar abgebrochen, es findet jedoch kein Rollback statt; SQL Server kann daher alle danach aufgerufenen Transaktionen nicht mehr verkürzen, weil die abgebrochene Transaktion noch immer geöffnet ist. Sie können den Verweis "DBCC OPENTRAN Transact-SQL" verwenden, um zu überprüfen, ob es in einer Datenbank zu einem bestimmten Zeitpunkt eine aktive Transaktion gibt. Weitere Informationen zu diesem speziellen Szenario finden Sie im folgenden Artikel der Microsoft Knowledge Base:
295108 Unvollständige Transaktion kann beanspruchen, große Anzahl der Sperren und große Anzahl der CASE Blockierung
171224 INF: grundlegend, wie das TransactSQL Befehlsworks BEENDET
Weitere Informationen finden Sie auch unter dem Thema "DBCC OPENTRAN" in der SQL Server-Onlinedokumentation.

Fälle, in denen es zu nicht übergebenen Transaktionen kommen kann:
  • Ein Anwendungsdesign, das davon ausgeht, dass alle Fehler ein Rollback auslösen.
  • Ein Anwendungsdesign, das das Verhalten von SQL Server bei einem Rollback zu benannten Transaktionen oder speziell geschachtelten benannten Transaktionen nicht angemessen berücksichtigt. Wenn Sie versuchen, ein Rollback zu einer Transaktion mit dem Namensbestandteil "Inner" durchzuführen, wird die folgende Fehlermeldung angezeigt:
    Server: Meldung 6401, Ebene 16, Status 1, Zeile 13 Ein Rollback für "InnerTran" kann nicht ausgeführt werden. Keine Transaktion und kein Sicherungspunkt dieses Namens wurde gefunden.
    Nachdem SQL Server diese Fehlermeldung generiert hat, setzt es die Verarbeitung mit der nächsten Anweisung fort. Es handelt sich hierbei um ein beabsichtigtes Verhalten. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation unter den Themen "Nested Transactions" (Geschachtelte Transaktionen) oder "Inside SQL Server" (SQL Server von innen betrachtet).

    Microsoft empfiehlt, bei der Entwicklung Ihrer Anwendung die folgenden Faktoren zu berücksichtigen:
    • Öffnen Sie nur eine Transaktionseinheit (ziehen Sie die Möglichkeit in Betracht, dass Ihre Transaktionseinheiten durch einen anderen Prozess aufgerufen werden).
    • Überprüfen Sie @@TRANCOUNT, bevor Sie COMMIT, ROLLBACK, RETURN oder ähnliche Befehle bzw. Anweisungen ausgeben.
    • Gehen Sie beim Schreiben Ihres Codes von der Annahme aus, dass eine andere Einheit "@@TRANCOUNT" Uhren Code möglicherweise "verschachtelt", und planen Sie ein Rollback für die äußere @@TRANCOUNT für den Fall ein, dass ein Fehler auftritt.
    • Überprüfen Sie die Sicherungspunkt- und Markierungsoptionen für Transaktionen. (Diese heben keine Sperren auf!)
    • Führen Sie umfangreiche und vollständige Testläufe durch.
  • Eine Anwendung, die Eingriffe von Seiten des Benutzers innerhalb von Transaktionen zulässt. Dies hat zur Folge, dass die Transaktion für lange Zeit offen bleibt, was wiederum zu Blockierungen und einer Vergrößerung des Transaktionsprotokolls führt, weil die offene Transaktion nicht abgeschnitten werden kann und dem Protokoll nach der offenen Transaktion weitere Transaktionen hinzugefügt werden.
  • Eine Anwendung, die @@TRANCOUNT nicht überprüft, um sicherzustellen, dass es keine offenen Transaktionen gibt.
  • Netzwerkfehler oder sonstige Fehler, bei denen die Verbindung der Clientanwendung zu SQL Server getrennt wird, ohne dass SQL Server darüber informiert wird.
  • Verbindungs-Pooling. Nachdem Arbeitsthreads erstellt wurden, verwendet SQL Server diese wieder, wenn sie keine Verbindung bedienen. Falls eine Benutzerverbindung eine Transaktion startet, diese Verbindung vor der Übergabe oder dem Rollback der Transaktion getrennt wird und eine weitere Verbindung danach den gleichen Thread verwendet, bleibt die vorherige Transaktion offen. In dieser Situation kommt es zu Sperren der vorherigen Transaktion, die offen bleiben. Dadurch wird die Verkürzung übergebener Transaktionen im Protokoll verhindert, was zu sehr großen Protokolldateien führt. Weitere Informationen zu dem Thema Verbindungs-Pooling finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    164221 INFO: Aktivieren des Verbindungsspoolings in einer ODBC-Anwendung

Extrem umfangreiche Transaktionen

Protokolleinträge in Transaktionsprotokoll-Dateien werden Transaktion für Transaktion abgeschnitten. Bei einer sehr umfangreichen Transaktion werden diese Transaktion und alle nach ihr gestarteten Transaktionen erst dann aus dem Transaktionsprotokoll entfernt, wenn die umfangreiche Transaktion abgeschlossen ist. Dies kann zu sehr großen Protokolldateien führen. Ab einer bestimmten Transaktionsgröße kann die Protokolldatei den gesamten verfügbaren Speicherplatz einnehmen und eine Fehlermeldung des Typs "Transaktionsprotokoll ist voll" auslösen, wie zum Beispiel den Fehler 9002. Weitere Informationen zur Vorgehensweise bei diesem Typ von Fehlermeldung finden Sie im nachstehenden Abschnitt "Weitere Informationen". Außerdem erfordert es viel Zeit und SQL Server-Verwaltungsaufwand, ein Rollback für umfangreiche Transaktionen durchzuführen.

Operationen: DBCC DBREINDEX und CREATE INDEX

Aufgrund von Änderungen des Wiederherstellungsmodells in SQL Server 2000 kann das Transaktionsprotokoll im Vergleich zu dem von SQL Server 7.0 in einem äquivalenten Wiederherstellungsmodus unter Verwendung von SELECT INTO oder BULK COPY und deaktivierter Option "Trunc. Log on chkpt." erheblich stärker anwachsen, wenn Sie den vollständigen Wiederherstellungsmodus verwenden und DBCC DBREINDEX ausführen.

Die Größe des Transaktionsprotokolls nach der Operation DBREINDEX kann zwar zum Problem werden, bei dieser Vorgehensweise ist die Leistung in Bezug auf die Wiederherstellung des Protokolls jedoch besser.

Während der Wiederherstellung von Sicherungskopien des Transaktionsprotokolls

Dies wird in den folgenden Artikeln der Microsoft Knowledge Base beschrieben:
232196 INF: erscheint Protokollspeicherplatz, der verwandt wird, zu nach dem Wiederherstellen aus Sicherung Sie wachsen

Wenn Sie SQL Server 2000 darauf konfigurieren, den Modus "Massenprotokolliert" zu verwenden und die Anweisung BULK COPY oder SELECT INTO ausgeben, wird jeder geänderte Block markiert und eine Sicherungskopie dieses Blocks erstellt, wenn Sie eine Sicherungskopie des Transaktionsprotokolls erstellen. Dadurch haben Sie zwar die Möglichkeit, Sicherungskopien von Transaktionsprotokollen zu erstellen und auch nach Massenvorgängen eine wegen Fehlern notwendig werdende Wiederherstellung durchzuführen, dies führt jedoch auch zu einer Vergrößerung der Transaktionsprotokolle. In SQL Server 7.0 gibt es dieses Feature nicht. SQL Server 7.0 protokolliert nur, welche Blöcke geändert werden, nicht jedoch die eigentlichen Blöcke. Die Protokollierung beansprucht daher in SQL Server 2000 wesentlich mehr Speicherplatz als in SQL Server 7.0 im Modus "Massenprotokolliert", jedoch weniger als im vollständigen Wiederherstellungsmodus.

Clientanwendungen verarbeiten nicht alle Ergebnisse

Wenn Sie eine Abfrage an SQL Server senden und die Ergebnisse nicht sofort verarbeiten, halten Sie möglicherweise Sperren aufrecht und reduzieren die Parallelität auf Ihrem Server.

Nehmen Sie beispielsweise an, dass Sie eine Abfrage senden, die Zeilen aus zwei Seiten erfordert, um Ihren Resultset zu füllen. SQL Server analysiert und kompiliert die Abfrage und führt sie dann aus. Dies bedeutet, dass gemeinsam verwendete Sperren für die zwei Seiten verhängt werden, welche die Zeilen enthalten, die Sie für Ihre Abfrage benötigen. Nehmen Sie zudem an, dass nicht alle Zeilen in ein SQL Server-TDS-Paket passen (die Methode zur Kommunikation zwischen Server und Client). TDS-Pakete werden gefüllt und an den Client gesendet. Falls alle Zeilen aus der ersten Seite in das TDS-Paket passen, hebt SQL Server die gemeinsam verwendete Sperre für diese Seite auf, behält die gemeinsam verwendete Sperre für die zweite Seite jedoch bei. SQL Server wartet dann darauf, dass der Client weitere Daten abfragt (beispielsweise mithilfe von DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults oder FetchLast/FetchFirst).

Dies bedeutet, dass die gemeinsam verwendete Sperre aufrechterhalten wird, bis der Client die restlichen Daten anfordert. Andere Prozesse, die Daten aus dieser zweiten Seite anfordern, werden in diesem Fall möglicherweise blockiert.

Für Abfragen tritt eine Zeitüberschreitung ein, bevor die Vergrößerung des Transaktionsprotokolls abgeschlossen ist, und Ihnen werden unzutreffende Meldungen angezeigt, die besagen, dass das Protokoll voll ist

In dieser Situation wird Ihnen eine Meldung zu fehlendem Speicherplatz angezeigt, obwohl noch ausreichend Speicherplatz zur Verfügung steht.

Diese Situation ist in SQL Server 7.0 und SQL Server 2000 nicht identisch.

Eine Abfrage kann eine automatische Vergrößerung des Transaktionsprotokolls verursachen, wenn das Transaktionsprotokoll nahezu voll ist. Dies kann zusätzlichen Zeitaufwand zur Folge haben und bewirken, dass eine Abfrage gestoppt wird oder für diese Abfrage eine Zeitüberschreitung eintritt. SQL Server 7.0 gibt in diesem Fall den Fehler 9002 zurück. In SQL Server 2000 tritt dieses Problem nicht auf.

Wenn Sie in SQL Server 2000 die Option Automatisch verkleinern für eine Datenbank aktiviert haben, gibt es eine extrem kurze Zeitspanne, während der eine automatische Vergrößerung des Transaktionsprotokolls versucht wird. Dieser Versuch schlägt jedoch fehl, weil gleichzeitig die Funktion Automatisch verkleinern ausgeführt wird. Auch dieses Verhalten kann die Ursache für unzutreffende Meldungen zu Fehler 9002 sein.

In der Regel wird für die automatische Vergrößerung von Transaktionsprotokoll-Dateien nur wenig Zeit benötigt. Unter den folgenden Umständen kann dies aber länger als gewöhnlich dauern:
  • Zu kleine Schrittweite für die automatische Vergrößerung.
  • Der Server arbeitet aus bestimmten Gründen nur langsam.
  • Die Festplattenlaufwerke sind nicht schnell genug.

Nicht replizierte Transaktionen

Das Transaktionsprotokoll der Datenbank Verleger kann größer werden, wenn Sie die Replikation einsetzen. Transaktionen, die sich auf die replizierten Objekte auswirken, werden als für die Replikation bestimmt gekennzeichnet. Diese Transaktionen, wie zum Beispiel nicht übergebene Transaktionen, werden nach dem Prüfpunkt oder dem Erstellen einer Sicherungskopie des Transaktionsprotokolls erst dann gelöscht, wenn der Task "Protokollleser" die Transaktionen in die Verteilungsdatenbank kopiert und die Kennzeichnung beseitigt. Falls ein Problem in Bezug auf den Task "Protokollleser" das Auslesen dieser Transaktionen aus der Datenbank Verleger verhindert, kann sich das Transaktionsprotokoll weiter vergrößern, weil die Anzahl der nicht replizierten Transaktionen zunimmt. Sie können den Verweis DBCC OPENTRAN Transact-SQL verwenden, um die älteste nicht replizierte Transaktion zu identifizieren.

Weitere Informationen zur Problembehandlung bei nicht replizierten Transaktionen finden Sie unter den Themen "sp_replcounters" und "sp_repldone" in der SQL Server-Onlinedokumentation.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
306769 UPDATE: Transaktionsprotokoll der publizierten Snapshot-Datenbank kann nicht abgeschnitten werden
240039 UPDATE: DBCC OPENTRAN meldet Replikationsinformation nicht
198514 BUG: Wiederherstellen auf Server läßt Transaktion im Protokoll

Weitere Informationen

Das Transaktionsprotokoll einer Datenbank wird als Satz virtueller Protokolldateien (VLFs) verwaltet, dessen Größe von SQL Server intern auf der Basis der Gesamtgröße der Protokolldatei und der zur Vergrößerung des Protokolls verwendeten Schrittweite bestimmt wird. Ein Protokoll wird immer um ganze VLFs vergrößert und kann nur bis zum Ende einer VLF komprimiert werden. Eine VLF kann sich in einem der folgenden Zustände befinden: Aktiv, wiederherstellbar und wiederverwendbar.
  • AKTIV: Der aktive Bereich des Protokolls beginnt bei der kleinsten LSN (Log Sequence Number), die eine aktive (nicht übergebene) Transaktion repräsentiert. Der aktive Bereich des Protokolls endet bei der zuletzt geschriebenen LSN. Alle VLFs, die einen Teil des aktiven Protokolls beinhalten, gelten als aktive VLFs. (Nicht genutzter Speicher im physischen Protokoll ist kein Bestandteil einer VLF.)
  • WIEDERHERSTELLBAR: Der Bereich des Protokolls vor der ältesten aktiven Transaktion wird nur benötigt, um für Wiederherstellungszwecke über eine Folge von Sicherungskopien des Protokolls verfügen zu können.
  • WIEDERVERWENDBAR: Wenn Sie keine Sicherungskopien des Transaktionsprotokolls gespeichert oder bereits eine Sicherungskopie des Protokolls erstellt haben, verwendet SQL Server die VLFs vor der ältesten aktiven Transaktion wieder.
Wenn SQL Server das Ende der physischen Protokolldatei erreicht, wird dieser Speicherplatz in der physischen Datei durch das Auslösen der Operation CIRCLING BACK von SQL Server wiederverwendet. SQL Server recycelt also den Speicherplatz in der Protokolldatei, der nicht mehr für Wiederherstellungs- oder Sicherungszwecke benötigt wird. Wird eine Folge von Sicherungskopien des Protokolls gespeichert, kann der Bereich des Protokolls vor der kleinsten LSN erst dann überschrieben werden, wenn Sie diese Protokolldatensätze sichern oder abschneiden. Wenn Sie die Sicherungskopie des Protokolls erstellt haben, kann SQL Server wieder an den Anfang dieser Datei gehen. Nachdem SQL Server wieder damit begonnen hat, Protokolldatensätze in einen früheren Bereich des Protokolls zu schreiben, erstreckt sich der wiederverwendbare Bereich des Protokolls vom Ende des logischen Protokolls bis zum aktiven Bereich des Protokolls.

Weitere Informationen finden Sie in der SQL Server 2000-Onlinedokumentation unter "Transaction Log Physical Architecture" (Physische Architektur des Transaktionsprotokolls). Außerdem finden Sie ein anschauliches Diagramm und eine eingehende Erläuterung zu diesem Thema auf Seite 190 von "Inside SQL Server 7.0" (Soukup, Ron. Inside Microsoft SQL Server 7.0, Microsoft Press, 1999) sowie auf den Seiten 182 bis 186 von "Inside SQL Server 2000" (Delaney, Kalen. Inside Microsoft SQL Server 2000, Microsoft Press, 2000). SQL Server 7.0- und SQL Server 2000-Datenbanken können automatisch vergrößert oder verkleinert werden. Mithilfe dieser Optionen können Sie Ihr Transaktionsprotokoll entweder komprimieren oder erweitern.

Weitere Informationen zu den möglichen Auswirkungen dieser Optionen auf Ihren Server finden Sie im folgenden Artikel der Microsoft Knowledge Base:
315512 INF: Überlegungen für Vergrößerungs- in SQL Server und Autoshrink-Konfiguration in SQL Server
Es gibt einen Unterschied zwischen dem Verkürzen oder Abschneiden und dem Komprimieren einer Transaktionsprotokoll-Datei. Wenn SQL Server eine Transaktionsprotokoll-Datei abschneidet, bedeutet dies, dass Inhalte dieser Datei (zum Beispiel die übergebenen Transaktionen) gelöscht werden. Wenn Sie die Größe der Datei im Hinblick auf den verwendeten Speicherplatz betrachten (zum Beispiel mit dem Windows Explorer oder indem Sie den Befehl dir verwenden), stellen Sie fest, dass die Größe unverändert bleibt. Der Speicherplatz in der LDF-Datei kann jetzt jedoch wieder für neue Transaktionen verwendet werden. Nur wenn SQL Server die Transaktionsprotokoll-Datei verkleinert, sehen Sie wirklich eine Veränderung in Bezug auf die physische Größe der Protokolldatei.

Weitere Informationen dazu, wie Sie Transaktionsprotokolle verkleinern können, finden Sie im folgenden Artikel der Microsoft Knowledge Base:
256650 INF: SO WIRD'S GEMACHT: Verkleinern des SQL Server 7.0-Transaktionsprotokolls
272318 INF: Verkleinern des Transaktionsprotokolls in SQL Server 2000 mit DBCC SHRINKFILE
Weitere Informationen zur Verwendung des Transaktionsprotokolls in SQL Server 6.5 finden Sie im folgenden Artikel der Microsoft Knowledge Base:
110139 INF: Gründe für das Anwachsen des SQL-Transaktionsprotokolls

Eigenschaften

Artikel-ID: 317375 - Geändert am: Freitag, 12. Juli 2013 - Version: 6.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
Keywords: 
kbsqlsetup kbinfo KB317375
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com