KB2455009 – FIX: Leistungseinbußen beim Wiederherstellen einer Datenbank, wenn im Transaktionsprotokoll SQL Server 2005, in SQL Server 2008 oder in SQL Server 2008 R2 viele VLFs vorhanden sind

Problembeschreibung

Stellen Sie sich folgendes Szenario vor:

Sie installieren Microsoft SQL Server 2005, Microsoft SQL Server 2008 oder Microsoft SQL Server 2008 R2 auf einem Computer.
Mindestens eine der Datenbanken ist im vollständigen oder massenprotokollierten Wiederherstellungsmodell enthalten.
Die anfängliche Größe einer Transaktionsprotokolldatei für die Datenbank ist klein. Die Transaktionsdatei wird jedoch größer.
Das automatische Wachstum der Transaktionsprotokolldatei ist auf eine kleine Größe konfiguriert. Beispielsweise wird das automatische Wachstum auf ein Megabyte oder auf ein Prozent konfiguriert. Oder Sie erhöhen die Transaktionsprotokolldatei mit einem kleinen manuellen Wachstum.
Die Transaktionsprotokolldatei wächst um das kleine Wachstum. Nach einer Weile ist die Transaktionsprotokolldatei groß.

Beispielsweise wächst die Transaktionsprotokolldatei von hundert Megabyte auf zehn Gigabyte. Die Transaktionsprotokolldatei wächst in jedem Wachstum um ein Megabyte.

In diesem Szenario können die folgenden Probleme auftreten:

Die Datenbankwiederherstellung ist langsam, wenn die Datenbank gestartet wird, wenn eine große Menge an Wiederherstellungsaufwand vorliegt.

Beispielsweise steht eine Transaktion für einen langen Zeitraum aus. Oder viele Transaktionen, die klein sind, werden nicht zugesichert, wenn die SQL Server heruntergefahren oder neu gestartet wird. In diesem Fall erhalten Sie möglicherweise einen Fehler für eine lange geschätzte Wiederherstellungszeit in der Analysephase, in der Rückgängig-Phase oder in der Redo-Phase. Der Fehler sieht wie folgt aus und wird in der Fehlerprotokolldatei SQL Server 2005 protokolliert:

Die Analyse der Datenbank "mydatabase" (7) ist zu 0% abgeschlossen (ca. 1234 Sekunden verbleiben). Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.
Die Datenbankwiederherstellung ist langsam, wenn eine vollständige Datenbanksicherungsdatei und eine zusätzliche Transaktionsprotokollsequenz wiederhergestellt werden, wenn die Datenbank online gestellt wird.

Hinweis Um die Datenbank während des Wiederherstellungsvorgangs online zu stellen, verwenden Sie die WITH RECOVERY-Syntax oder die WITH STANDBY = <-Optionen> Syntax.
Die Wiederherstellung der Datenbankspiegelung ist auf einem Partnerserver im Spiegelungspaar langsam.
Der Fortschritt des Protokolllese-Agents für die Transaktionsreplikation ist für die folgenden Vorgänge langsam:
- Das Transaktionsprotokoll einer Herausgeberdatenbank wird analysiert.
- Ein Befehl wird einer Verteilungsdatenbank hinzugefügt.
- Die Transaktionen werden repliziert.
Eine langsame Leistung tritt auf, wenn eine Datenbankmomentaufnahme erstellt wird, wenn viele Transaktionen protokolliert werden oder die Transaktionsprotokolle lange aktiv bleiben. Dieses Problem tritt auf, weil die Momentaufnahme die Wiederherstellung ausführen muss und die Transaktionsprotokolle zurückgesetzt werden müssen.
Eine langsame Leistung tritt auf, wenn Sie die DBCC CHECKDB-Syntax verwenden, um eine ausgeblendete Datenbankmomentaufnahme zu erstellen, die die Datenbankmomentaufnahme vollständig wiederherstellen muss, um die Konsistenzüberprüfungen auszuführen.

Ursache

Diese Probleme treten auf, da die virtuellen Protokolldateien (Virtual Log Files, VLFs) in einer Transaktionsprotokolldatei möglicherweise eine langsame Leistung verursachen, wenn SQL Server diese VLFs während der folgenden Vorgänge durchsucht:

Datenbankwiederherstellung
Datenbankspiegelung
Datenbankmomentaufnahme
Aktivitäten des Datenbanktransaktionsreplikationsprotokolllesers

Wenn eine Transaktionsprotokolldatei für eine Datenbank bei extremen Wachstumsbedingungen in kleinen Schritten vergrößert wird, sind Tausende bis Hunderttausende von VLFs in einem einzigen Satz von Transaktionsprotokolldateien (LDF) vorhanden. Durch das große Protokollwachstum in großen Schritten werden jedoch nur mehrere VLFs im Vergleich erstellt. Beispielsweise können mehrere weniger als 100 VLFs sein.

Hinweis Die VLFs sind die Divisionen oder Segmente, die intern von SQL Server in der Transaktionsprotokolldatei verwendet werden.

Lösung

Informationen zum kumulativen Update

SQL Server 2008 R2

Der Fix für dieses Problem wurde erstmals im kumulativen Update 6 veröffentlicht. Weitere Informationen zum Abrufen dieses kumulativen Updatepakets für SQL Server 2008 R2 erhalten Sie, indem Sie auf die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

2489376 Kumulatives Updatepaket 6 für SQL Server 2008 R2 Hinweis Da die Builds kumulativ sind, enthält jede neue Fix-Version alle Hotfixes und alle Sicherheitsupdates, die im vorherigen SQL Server 2008 R2 Fix Release enthalten waren. Es wird empfohlen, die neueste Fixversion anzuwenden, die diesen Hotfix enthält. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

981356 Die SQL Server 2008 R2-Builds, die nach SQL Server 2008 R2 veröffentlicht wurden

SQL Server 2008 Service Pack 1

Der Fix für dieses Problem wurde erstmals im kumulativen Update 12 für SQL Server 2008 Service Pack 1 veröffentlicht.

Hinweis Da die Builds kumulativ sind, enthält jede neue Fixversion alle Hotfixes und alle Sicherheitsfixes, die im vorherigen SQL Server 2008-Fix-Release enthalten waren. Microsoft empfiehlt, die neueste Fixversion anzuwenden, die diesen Hotfix enthält. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

970365 Die SQL Server 2008-Builds, die nach der Veröffentlichung von Microsoft SQL Server 2008-Hotfixes für SQL Server 2008 Service Pack 1 veröffentlicht wurden, werden für bestimmte SQL Server Service Packs erstellt. Sie müssen einen SQL Server 2008 Service Pack 1-Hotfix auf eine Installation von SQL Server 2008 Service Pack 1 anwenden. Standardmäßig ist jeder Hotfix, der in einem SQL Server Service Pack bereitgestellt wird, im nächsten SQL Server Service Pack enthalten.

SQL Server 2008 Service Pack 2

Der Fix für dieses Problem wurde erstmals im kumulativen Update 2 für SQL Server 2008 Service Pack 2 veröffentlicht.

Hinweis Da die Builds kumulativ sind, enthält jede neue Fixversion alle Hotfixes und alle Sicherheitsfixes, die im vorherigen SQL Server 2008-Fix-Release enthalten waren. Microsoft empfiehlt, die neueste Fixversion anzuwenden, die diesen Hotfix enthält. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

2402659 Die SQL Server 2008-Builds, die nach der Veröffentlichung von Microsoft SQL Server 2008-Hotfixes für SQL Server 2008 Service Pack 2 veröffentlicht wurden, werden für bestimmte SQL Server Service Packs erstellt. Sie müssen einen SQL Server 2008 Service Pack 2-Hotfix auf eine Installation von SQL Server 2008 Service Pack 2 anwenden. Standardmäßig ist jeder Hotfix, der in einem SQL Server Service Pack bereitgestellt wird, im nächsten SQL Server Service Pack enthalten.

SQL Server 2005 Service Pack 3

Der Fix für dieses Problem wurde erstmals im kumulativen Update 13 für SQL Server 2005 Service Pack 3 veröffentlicht.

Hinweis Da die Builds kumulativ sind, enthält jede neue Fixversion alle Hotfixes und alle Sicherheitsfixes, die im vorherigen SQL Server 2005-Fix-Release enthalten waren. Microsoft empfiehlt, die neueste Fixversion anzuwenden, die diesen Hotfix enthält. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

960598 Die SQL Server 2005-Builds, die nach der Veröffentlichung von Microsoft SQL Server 2005-Hotfixes für SQL Server 2005 Service Pack 3 veröffentlicht wurden, werden für bestimmte SQL Server Service Packs erstellt. Sie müssen einen SQL Server 2005 Service Pack 3-Hotfix auf eine Installation von SQL Server 2005 Service Pack 3 anwenden. Standardmäßig ist jeder Hotfix, der in einem SQL Server Service Pack bereitgestellt wird, im nächsten SQL Server Service Pack enthalten.

SQL Server 2005 Service Pack 4

Der Fix für dieses Problem wurde erstmals im kumulativen Update 1 für SQL Server 2005 Service Pack 4 veröffentlicht.

Hinweis Da die Builds kumulativ sind, enthält jede neue Fixversion alle Hotfixes und alle Sicherheitsfixes, die im vorherigen SQL Server 2005-Fix-Release enthalten waren. Microsoft empfiehlt, die neueste Fixversion anzuwenden, die diesen Hotfix enthält.

Sie müssen einen SQL Server 2005 Service Pack 4-Hotfix auf eine Installation von SQL Server 2005 Service Pack 4 anwenden. Standardmäßig ist jeder Hotfix, der in einem SQL Server Service Pack bereitgestellt wird, im nächsten SQL Server Service Pack enthalten.

Status

Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.

Problemumgehung

Installieren Sie diesen Hotfix, und starten Sie SQL Server kann die Wiederherstellungsleistung verbessern. Beispielsweise kann die Leistung für die folgenden Vorgänge verbessert werden, nachdem Sie diesen Hotfix installiert und SQL Server neu gestartet haben:

Datenbankwiederherstellung
Datenbankspiegelung
Datenbankmomentaufnahme
Aktivitäten des Datenbanktransaktionsreplikationsprotokolllesers

Wenn Sie diesen Hotfix nicht installieren können, können Sie die folgenden Problemumgehungen ausführen, um ein vorhandenes Problem zu vermeiden und ein zukünftiges Auftreten zu verhindern.

Beheben eines vorhandenen Problems

Warten Sie, bis der Wiederherstellungs- oder Wiederherstellungsvorgang abgeschlossen ist

. Wenn Sie über eine nicht wiederhergestellte Datenbank verfügen, bei der die Leistung beim Wiederherstellen oder Wiederherstellen der Datenbank langsam ist, müssen Sie möglicherweise warten, bis der Wiederherstellungs- oder Wiederherstellungsvorgang abgeschlossen ist. Beispielsweise wird der Offlinestatus oder der Wiederherstellungsstatus in SQL Server Management Studio (SSMS) für eine nicht wiederhergestellte Datenbank angezeigt. Das Beenden SQL Server bietet in der Regel keine Erleichterung für eine langsame Wiederherstellung und kann mehr Zeit in Anspruch nehmen, um dieselbe Wiederherstellungsanalysephase, Wiederholen-Phase oder Rückgängig-Phase zu wiederholen.
Vermeiden Sie das Wiederherstellen der Transaktionsprotokollsequenz, die Tausende von VLFs

enthält. Wenn beim Wiederherstellen und Wiederherstellen einer Datenbank mithilfe einer Sicherungsdatei die langsame Leistung auftritt, können Sie vermeiden, die Transaktionsprotokollsequenzen wiederherzustellen, die Tausende von VLFs enthalten. Um die Sicherungsdatei mit den meisten aufgezeichneten virtuellen Protokolldateien zu identifizieren, verwenden Sie die folgende Anweisung, um die Spalten "FirstLSN " und " LastLSN" in den Protokolldateien anzuzeigen:
HEADERONLY FROM DISK='C:\folder\file.trn'

WIEDERHERSTELLEN Sie können die Wiederherstellung der Protokolldateien vermeiden. Alternativ können Sie die STOP AT-Anweisung in den RESTORE-Befehlen verwenden, um die stark fragmentierten Teile der Transaktionsprotokolle zu vermeiden. Wenn Sie die Protokollsequenzen während eines Fehlerwiederherstellungsszenarios nicht vollständig bis zum neuesten Zeitpunkt wiederherstellen, tritt in Der Datenbank SQL Server Datenverlust auf. Dieser Datenverlust tritt auf, da nicht alle Transaktionen beibehalten werden. Daher gibt es eine Geschäftliche Kompromissentscheidung. Sie können ein stark fragmentiertes Transaktionsprotokoll vollständig wiederherstellen. Dieser Vorgang kann jedoch viele Stunden dauern. Oder Sie können die STOP AT-Anweisung in der Wiederherstellung verwenden, um die Wiederherstellung vor dem stark fragmentierten Teil des Protokolls zu beenden. Alle fehlenden Transaktionen, die Sie weglassen, gehen jedoch verloren.

Hinweis: Ohne installation dieses Hotfix gibt es in der Regel keinen sicheren Rückgriff auf beschleunigte Wiederherstellung, nachdem Sie SQL Server neu gestartet haben. SQL Server muss die Liste der VLFs suchen, um die Protokolldateien zu analysieren, abgeschlossene Transaktionen zu wiederholen und dann unvollständige Transaktionen rückgängig zu machen, um die Wiederherstellung abzuschließen, um die Datenbank sicher online zu stellen. Sie können Transaktionen während der Wiederherstellung nicht sicher überspringen.

Verhindern eines zukünftigen Auftretens

Festlegen des automatischen Zuwachsschritts der Datenbank auf eine entsprechende Größe

Wenn die Größe des automatischen Vergrößerungsschritts zu klein ist, gibt es viele virtuelle Protokolldateien (Virtual Log Files, VLFs), und sie können in SQL Server eine langsame Leistung feststellen. Wenn die Größe des automatisch wachsenden Inkrements zu groß ist, müssen Abfragen, die die Transaktionsprotokolle automatisch vergrößern, möglicherweise lange warten, bis ein Wachstum abgeschlossen ist. Daher kann in SQL Server ein Timeoutfehler auftreten. Um diese Probleme zu umgehen, können Sie die Größe des automatischen Zuwachsens für Ihre Datenbank auf eine entsprechende Größe festlegen.
Beseitigen Sie die große Anzahl von VLFs, und verwenden Sie ein manuelles Wachstum

Wenn sich viele VLFs im Transaktionsprotokoll befinden, verringern Sie die Größe des Transaktionsprotokolls, und erhöhen Sie es vor dem Spitzengeschäft, um die Nachfrage mithilfe eines manuellen Wachstums zu decken. Beispielsweise erhöht sich das Transaktionsprotokoll in einem großen Schritt oder in einem einzigen manuellen Wachstum wieder auf eine angemessene durchschnittliche Größe. Daher erreicht die Größe des Transaktionsprotokolls eine Spitzenkapazität, und die Protokollsicherungsdateien werden häufig und regelmäßig geplant. Darüber hinaus kann das Transaktionsprotokoll abgeschnitten werden, und die VLFs für das Transaktionsprotokoll können in einem Zyklus wiederverwendet werden.
Manuelles Verkleinern und Vergrößern des Transaktionsprotokolls

Um ein Protokoll mit zu vielen VLFs zu korrigieren, führen Sie die folgenden Schritte aus, um das Protokoll zu verkleinern und manuell zu vergrößern:
1. Wenn sich die Datenbank in einem vollständigen oder massenprotokollierten Wiederherstellungsmodell befindet, müssen Sie das Transaktionsprotokoll sichern, damit die aktiven VLFs abgeschnitten und wiederverwendet werden können. BACKUP LOG databasename TO DISK='C:\folder\log_backupfile.trn'
  Weitere Informationen zum Sichern der Transaktionsprotokolldatei mithilfe von SSMS finden Sie auf der folgenden Microsoft Developer Network (MSDN)-Website:
  
  Sichern der Transaktionsprotokolldatei mithilfe von SSMSWeitere Informationen zum Sichern der Transaktionsprotokolldatei mithilfe von Transact-SQL-Anweisungen finden Sie auf der folgenden MSDN-Website:
  
  Sichern der Transaktionsprotokolldatei mithilfe von Transact-SQL-Anweisungen
2. Führen Sie eine der folgenden Anweisungen aus, um den logischen Namen der Transaktionsprotokolldatei zu ermitteln.
  Anweisung 1
  exec sp_helpfile Anweisung 2
  select * from sys.sysfiles To reduce the size of the transaction log file to the desired size, use the following code:DBCC SHRINKFILE(transactionloglogicalfilename, TRUNCATEONLY)
3. Sie können die Größe der Transaktionsprotokolldatei auf eine entsprechende Größe erhöhen. Es wird empfohlen, die Größe der Transaktionsprotokolldatei auf die maximale normale Größe zu erhöhen. Daher wird das automatische Wachstum vermieden. Um die Größe des Transaktionsprotokolls festzulegen, verwenden Sie die Seite "Datenbankeigenschaften" in SSMS, oder verwenden Sie die folgende ALTER DATABASE-Syntax:MODIFY FILE ( NAME = transactionloglogicalfilenae, SIZE=newtotalsize MB)
  Weitere Informationen zum Vergrößern einer Datenbank in SSMS finden Sie auf der folgenden MSDN-Website:
  
  So erhöhen Sie die Größe einer Datenbank in SSMSWeitere Informationen zur ALTER DATABASE MODIFY FILE-Syntax finden Sie auf der folgenden MSDN-Website:
  
  Allgemeine Informationen zur ALTER DATABASE MODIFY FILE-Syntax

Weitere Informationen

Sie können die Anzahl der VLF-Segmente überprüfen, indem Sie die SQL-Fehlerprotokolldatei überprüfen und dann die Protokollsequenznummer (Log Sequence Number, LSN) in jeder Transaktionsprotokollsicherungsdatei suchen. Die ersten Ziffern vor dem Doppelpunktsymbol in den LSNs entsprechen der Nummer des LSN.

Beispielsweise ist die erste Zahl in der ersten Informationsnachricht für den LSN 1. Die erste Zahl in der zweiten Informationsnachricht für den LSN ist jedoch 100001. In diesem Szenario gibt es 100.000 VLFs, die zwischen dem Zeitpunkt der ersten Informationsnachricht und der zweiten Informationsnachricht verwendet werden. Daher sieht das protokollierte fragmentierte Transaktionsprotokoll mit vielen virtuellen Protokolldateien (Virtual Log Files, VLFs) wie folgt aus:

{Das Protokoll wurde gesichert. Datenbank: mydbname, Erstellungsdatum(Uhrzeit): 08.07.2010(12:36:46), erster LSN: 1:5068:70, letzter LSN: 1:5108:1, Anzahl der Speicherabbildgeräte: 1, Geräteinformationen: (FILE=1, TYPE=DISK: {'C:\folder\logbackup1.trn'}). Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

Protokoll wurde gesichert. Datenbank: mydbname, Erstellungsdatum(Uhrzeit): 08.07.2010(15:36:46), erster LSN: 100001:5108:1, letzter LSN: 100002:5108:1, Anzahl der Speicherabbildgeräte: 1, Geräteinformationen: (FILE=2, TYPE=DISK: {'C:\folder\logbackup2.trn'}). Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.}

Die folgende Tabelle enthält weitere Informationen zu den Produkten oder Tools, die automatisch auf die Bedingung überprüfen, die im Abschnitt "Symptome" in Ihrer Instanz von SQL Server und in den Versionen von SQL Server beschrieben wird, für die die Regel ausgewertet wird.

Regelsoftware	Regeltitel	Regelbeschreibung	Produktversionen, für die die Regel ausgewertet wird
System Center Advisor	SQL Server mit Transaktionsreplikation kann die Leistung des Log Reader-Agents aufgrund der Größe des Transaktionsprotokolls oder der Anzahl von VLF beeinträchtigt werden.	In diesem SQL Server Instanzratgeber die Transaktionsreplikation des Anwesenheitsstatus mit einer deutlich höheren Anzahl von VLFs oder TLOG erkannt. Die Leistung des Log Reader-Agents wird durch die Größe des Transaktionsprotokolls oder die Anzahl von VLF negativ beeinflusst. Verringern Sie die Transaktionsprotokollgröße und die Anzahl von VLF, um die Leistung des Log Reader-Agents zu verbessern.	SQL Server 2008 SQL Server 2008 R2 SQL Server 2012

Informationsquellen

Weitere Informationen zur physischen Architektur des Transaktionsprotokolls finden Sie auf der folgenden MSDN-Website:

Allgemeine Informationen zur physischen Architektur des Transaktionsprotokolls

Weitere Informationen zu Protokollsequenznummern (Log Sequence Numbers, LSN) finden Sie auf der folgenden MSDN-Website:

Allgemeine Informationen zu Protokollsequenznummern

Weitere Informationen zum Fehler 1413 beim Starten der Datenbankspiegelung finden Sie auf der folgenden MSDN-Website:

Allgemeine Informationen zum Fehler 1413 beim Starten

der Datenbankspiegelung Weitere Informationen dazu, wie sich eine Protokolldateistruktur auf die Wiederherstellungszeit der Datenbank auswirken kann, finden Sie auf der folgenden MSDN-Website:

Wie sich eine Protokolldateistruktur auf die Datenbankwiederherstellungszeit

auswirken kann Weitere Informationen zum Transaktionsprotokoll VLFs finden Sie auf der folgenden MSDN-Website:

Allgemeine Informationen zur Transaktionsprotokolldatei

Weitere Informationen zum Erstellen einer Datenbankmomentaufnahme finden Sie auf der folgenden MSDN-Website:

Erstellen einer DatenbankmomentaufnahmeWeitere Informationen zum inkrementellen Wartungsmodell für SQL Server erhalten Sie, indem Sie auf die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

935897 Ein inkrementelles Wartungsmodell ist vom SQL Server-Team verfügbar, um Hotfixes für gemeldete Probleme bereitzustellen. Weitere Informationen zum Benennungsschema für SQL Server Updates finden Sie in der Microsoft Knowledge Base:

822499Neues Benennungsschema für Microsoft SQL Server SoftwareupdatepaketeFür weitere Informationen zur Softwareupdateterminologie klicken Sie auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

824684 Erläuterung von Standardbegriffen bei Microsoft-Softwareupdates