Die Datenbank wird immer im Wiederherstellungsmodus gestartet


11

Bei jedem Neustart meines Servers befindet sich die Datenbank immer im Wiederherstellungsmodus und es dauert ungefähr 20 Minuten, bis sie sich normal verhält. Dies passiert immer und nur, wenn ich den Server neu starte, also habe ich ein paar Fragen ...

  1. Mir wurde gesagt, dass dies durch eine große Protokolldatei verursacht werden könnte? Könnte das richtig sein? Wenn nicht, was könnten dann die anderen Ursachen sein?
  2. Ich muss den Speicherplatz der Protokolldatei verringern, um Wiederherstellungen zu verhindern. Was ist besser: schrumpfen oder abschneiden?
  3. Wie kann ich eine Protokolldatei / Datenbank verkleinern oder kürzen, um die Größe zu verringern? Wie ist die Syntax?

Ich verwende derzeit Microsoft SQL Server 2008.


Neigen Sie dazu, große Transaktionen im Flug zu haben, wenn Sie herunterfahren? Auf was ist das Wiederherstellungsintervall eingestellt?
Martin Smith

20 Minuten vor dem Neustart des Servers werden keine Aktionen ausgeführt.

Wie oft fängst du wieder an? Wie oft sichern Sie die Datenbank? Ich frage mich, warum Sie den Server regelmäßig neu starten. Um vollständig zu sein, können Sie bei Bedarf manuell eine Datenbank überprüfen (wodurch das Protokoll gelöscht wird).
Lynn Langit

"Um vollständig zu sein, können Sie bei Bedarf manuell eine Datenbank überprüfen (wodurch das Protokoll gelöscht wird)." Wie geht das? und wenn Sie "Protokoll löschen" sagen, meinen Sie damit, das Protokoll nicht zu verwenden oder einfach zu löschen?

Nicht genug Information. Wiederherstellungsmodell? Verwenden Sie Funktionen wie Spiegelung oder Replikation? Größe der Datenbank und der beteiligten Dateien? Hat behandeln die Datenbank keine großen Transaktionen?
Jon Seigel

Antworten:


6

Ich habe das gleiche Problem und glaube, ich habe es behoben, aber ich konnte es nicht vollständig testen, um es zu bestätigen.

Ich glaube, die Probleme hängen mit der Anzahl der VLFs zusammen, die Sie in Ihrer Protokolldatei haben, und nicht mit ihrer Größe. Wenn Sie eine große Protokolldatei haben, ist es wahrscheinlich, dass sie durch automatische Wachstumsereignisse organisch gewachsen ist und dass es sich nicht um ein beabsichtigtes geplantes Wachstum handelt. In diesem Fall befinden sich möglicherweise Tausende von VLFs in Protokolldateien.

Hier ist eine Abfrage, um zu sehen, wie viele VLFs Sie haben, die ich von hier aus verwendet habe :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Eine weitere Erklärung der VLFs finden Sie unter diesem Link .

Ich glaube, das Problem ist, dass SQL Server bei so vielen VLFs lange braucht, um ihren Status zu beurteilen und dann die Datenbank aus der Wiederherstellung zu bringen. Wenn Sie Ihre Protokolldatei auf die kleinstmögliche Größe verkleinern, häufig auf die Größe des ersten VLF, der in der Protokolldatei erstellt wurde, können Sie sie sofort absichtlich wieder vergrößern und dadurch die richtige Anzahl von VLFs erstellen lassen (etwas weniger als) 16).

Sobald dies abgeschlossen ist, können Sie sicher feststellen, dass Ihre Datenbank viel schneller wiederhergestellt wird.

Ich hatte keine Gelegenheit, ein Failover unserer Produktionsinstanzen zu testen, nachdem ich unsere eigenen VLF-Probleme behoben hatte. Daher wäre ich sehr gespannt, ob Sie bestätigen können, dass dies die Hauptursache des Problems ist. Experimentell habe ich gesehen, dass die Zeit, die für die Wiederherstellung in unserer Staging-Umgebung benötigt wird, aufgrund dieser Tatsache drastisch reduziert wurde. Hoffentlich ist es das.



2

Aus diesem MSDN- Artikel :

Lang laufende nicht festgeschriebene Transaktionen verlängern die Wiederherstellungszeit für alle Arten von Prüfpunkten.

Es wird im Allgemeinen nicht empfohlen, eine DBCC-Schrumpfdatei in Produktionsdatenbanken auszuführen. Auch das Verhalten beim Abschneiden von Protokollen wurde von früheren Versionen auf 2008 geändert (danke @Edward) - laut diesem Blog :

Das Sicherungsprotokoll mit trucate_only wird in SQL 2008 nicht mehr unterstützt. Wenn sich Ihre Datenbank in einem Massenprotokoll oder einem vollständigen Wiederherstellungsmodell befindet, planen Sie die T-Protokoll-Sicherung in regelmäßigen Abständen und Ihr T-Protokoll bleibt in Form.

Ich werde noch einmal erwähnen, wie oft Sie die Datenbank sichern? In der Regel "verwalten" regelmäßige Sicherungen die Protokollgröße am besten.


0

Das Reduzieren der Größe des Online-Transaktionsprotokolls kann das Problem beheben, dh das Online-Schalten der Datenbank beschleunigen. Sie sollten jedoch vorher über die Notfallwiederherstellung nachdenken. Beachten Sie, dass Sie im Simple Recovery-Modell zu einem bestimmten Zeitpunkt keine Wiederherstellung durchführen können. Wenn Sie sich jedoch im vollständigen Wiederherstellungsmodell befinden, können Sie die Größe des Online-Transaktionsprotokolls am besten beibehalten, indem Sie regelmäßig eine Transaktionsprotokollsicherung erstellen (planen).

Durch das Abschneiden des Transaktionsprotokolls wird kein physischer Festplattenspeicher freigegeben, sondern der SQL Server kann diesen Speicherplatz nur für Transaktionen wiederverwenden, die seit dem letzten CHEKPOINT (seit der letzten Sicherung des Transaktionsprotokolls) aufgetreten sind.

Wenn Sie die Datenbank verkleinern, reduzieren Sie die Größe der Dateien. So verkleinern Sie die MyDB-Datenbank um 15 Prozent:

DBCC SHRINKDATABASE (MyDB, 15); GEHEN

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.