Legen Sie die Größe der Protokolldatei nach dem Verkleinern von SQL Server 2008 R2 manuell fest

Ich werde ein etwas unfreiwilliger DBA bei der Arbeit und brauche wirklich Hilfe bei etwas.

Wir haben eine 40-GB-Datenbank im vollständigen Wiederherstellungsmodus, keine konfigurierte Protokollsicherung und eine riesige Protokolldatei mit 84 GB. Mein bisheriger Plan, um diese Situation zu beheben, besteht darin, eine vollständige Protokollsicherung für die Datenbank durchzuführen, die Protokolldatei zu verkleinern und einen Wartungsplan zu erstellen, um jede Nacht eine Protokollsicherung mit der Datenbanksicherung durchzuführen, um die Kontrolle zu behalten.

Mein Problem ist, dass ich nicht möchte, dass die Protokolldatei auf nichts verkleinert wird und der erste Morgen am Montag ständig wächst. Ich habe eine grobe Schätzung, wie die Datei aussehen soll (ca. 20% der Datenbank), und möchte diese von Anfang an festlegen, um so viel zusammenhängenden Speicherplatz wie möglich zu gewährleisten. Handelt es sich nur um das Ändern der "Anfangsgröße" unter Datenbankeigenschaften -> Dateien? Ich würde auch vermuten, dass die Datenbank offline sein muss, damit dies geschieht?

Danke im Voraus

Schrumpfen Sie einfach auf die Ihrer Meinung nach optimale Größe. Verwenden Sie nicht die Benutzeroberfläche, sondern tun Sie dies einfach. Nehmen wir an, 200 MB sind Ihre optimale Größe:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);

Wenn Sie nur einmal am Tag eine Protokollsicherung durchführen möchten und nicht an einer Wiederherstellung zu einem bestimmten Zeitpunkt interessiert sind, sollten Sie zu einem einfachen Wiederherstellungsmodell wechseln. Dies bedeutet, dass Protokollsicherungen nicht erforderlich (tatsächlich unmöglich) sind, der Inhalt des Protokolls sich jedoch selbst verwaltet.

Wenn Sie möchten, dass Protokollsicherungen sinnvoll sind, planen Sie nicht, nachts eine vollständige Sicherung und anschließend eine einzelne Protokollsicherung durchzuführen. Dies hält Sie im vollständigen Wiederherstellungsmodell, lässt das Protokoll sehr hart arbeiten und kauft Ihnen nichts. Wenn Sie also zu einem bestimmten Zeitpunkt eine Wiederherstellung wünschen, führen Sie Protokollsicherungen häufiger mit einer Geschwindigkeit durch, die Ihrer Datenverlusttoleranz entspricht. Wenn Sie nie mehr als 15 Minuten Daten verlieren möchten, führen Sie alle 15 Minuten eine Protokollsicherung durch.

Ihre Dateiverwaltung kann vollständig online sein. Sie haben zwei Pfade, abhängig davon, ob Sie Ihre Protokollinformationen für Wiederherstellungszwecke aufbewahren müssen:

Wiederherstellung zum Zeitpunkt nicht erforderlich

1. Konvertieren Sie die Datenbank in die SIMPLEWiederherstellung. Führen Sie einen Prüfpunkt aus, um Transaktionen auf die Festplatte zu schreiben.
2. Reduzieren Sie das Protokoll.
3. Ändern Sie die Größe des Protokolls auf die entsprechende Größe.

Ich empfehle außerdem, einen festen Wachstumsbetrag und ein unbegrenztes Wachstum festzulegen (um Ihr Protokoll besser verwalten zu können). Beachten Sie, dass die feste Wachstumsmenge sehr stark von der Menge abhängt. Ich würde empfehlen, zunächst 1-2 GB zu verwenden, je nachdem, wie viel Wachstum das Protokoll erwarten kann. Im Idealfall wächst Ihr Protokoll nicht stark, daher sollte dies keine großen Auswirkungen haben. Wenn Ihr Protokoll regelmäßig wächst, müssen Sie möglicherweise Ihre Größe überprüfen.

Erreicht mit:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Zeitpunkt der Wiederherstellung erforderlich

Das größte Problem besteht darin, dass Sie Ihre Protokolldatei nicht über Ihr derzeit aktives VLF-Segment hinaus verkleinern können. Um dies zu sehen, können Sie DBCC LOGINFOim Datenbankkontext verwenden. Jedes Segment mit dem Status = 2 ist aktiv. Um aktive Segmente zu löschen, müssen Sie eine Transaktionsprotokollsicherung ausführen, wenn derzeit keine Transaktionen in diesem Segment aktiv sind. Ihre Schritte sind:

1. Führen Sie eine Transaktionsprotokollsicherung durch.
2. Verkleinern Sie Ihre Datei. (Idealerweise reduzieren, aber wenn Ihre Datenbank aktiv ist, ist dies schwierig).
3. Wiederholen Sie die Schritte 1 und 2, bis Ihr Protokoll eine geeignete Größe hat, idealerweise so klein wie möglich.
4. Ändern Sie die Größe des Protokolls auf die entsprechende Größe.

Erreicht mit:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Einige zusätzliche Ressourcen, um zu verstehen, was hier vor sich geht:

• SQL Server-Wiederherstellungsmodelle

• Kimberly Tripps T-Log-Empfehlungen

• Datenbankprüfpunkte

Nein, die Datenbank muss nicht offline sein, um das Protokoll zu verkleinern. Und ich werde sagen, dass dies wahrscheinlich einer der wenigen Fälle ist, in denen das Verkleinern des Protokolls eine gute Idee ist. Sie könnten die anfängliche Größe festlegen, aber es wäre einfacher, die Verkleinerung durchzuführen und sie anzuweisen, auf eine bestimmte Größe zu verkleinern.

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

Sie können dies auch tun, indem Sie die GUI verwenden und das zweite Optionsfeld und das Kontrollkästchen verwenden, das angibt, wie groß das Protokoll am Ende sein soll. Sie können zur GUI gelangen, indem Sie im Objekt-Explorer in SSMS mit der rechten Maustaste auf die Datenbank klicken und Aufgaben, Verkleinern und Dateien auswählen.

In Ergänzung zu Aarons Antwort zum einfachen Modus können Sie zwei (oder mehr) differenzielle Sicherungen pro Tag planen, um so das Datenverlustfenster Ihres Datenbankbetriebs zu verringern und gleichzeitig den EINFACHEN Modus beizubehalten.