Transaktionsprotokollpflege beim Wechsel zu Simple Recovery


9

Hintergrund:

Ich habe kürzlich mehr als 50 SQL Server mit mehr als 450 Datenbanken geerbt. Die nächtlichen Backups sind ungefähr 8 TB groß und wir verbrauchen natürlich mehr Speicherplatz als wir möchten. Alle Datenbanken sind auf VOLLSTÄNDIGE Wiederherstellung eingestellt, und die Transaktionsprotokolle wurden nie gesichert. Ich habe alle SQL Server durchgesehen und solche mit niedriger Priorität identifiziert, die nur eine nächtliche Sicherung benötigen und bei denen ein Tag mit Datenverlust akzeptabel ist.

Frage:

Ich schalte viele Datenbanken mit niedriger Priorität von in den SIMPLEWiederherstellungsmodus um FULL. Werden die vorhandenen Transaktionsprotokolle abgeschnitten (wenn Prüfpunkte erstellt werden)? Einige der vorhandenen Transaktionsprotokolle haben eine Größe von 50 bis 100 GB. Was ist der beste Ansatz, um zu bestimmen, auf was ich sie verkleinern soll, um vorwärts zu kommen? Ich möchte sie offensichtlich nicht so groß halten. Oder werden sie im Laufe der Zeit von selbst schrumpfen (ich glaube nicht, dass sie es tun werden)?

Antworten:


2

Bevor von einem Wechsel FULLzu SIMPLEWiederherstellungsmodell, fragen Sie sich , wie viele Daten Sie leisten zu verlieren. Für die Datenbanken, in denen Sie im Katastrophenfall die letzte Datenbanksicherung wiederherstellen können, SIMPLEsollte dies in Ordnung sein. Wenn dies nicht der Fall ist, bleiben Sie bei FULL.

Führen Sie die LDFfolgenden Schritte von Kimberly Tripp aus, um die Datei auf eine möglichst kleine Größe zu verkleinern : 8 Schritte zur Verbesserung des Transaktionsprotokolldurchsatzes

  1. Warten Sie auf die Zeit, in der die Datenbank nur wenig aktiv ist

  2. In SSMS ausführen:

    DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)
  3. Ändern Sie die Größe der Transaktionsprotokolldatei:

    ALTER DATABASE db_name
    MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

1
Ich würde SHRINK- Protokolldateien nicht empfehlen, da dies zu einer VLF-Fragmentierung führt und die gesamte Datenbankauslastung angehalten wird, während das Protokoll wächst, da die Transaktionsprotokolldatei keine sofortige Initialisierung verwenden kann .
Kin Shah

9

Ich wechsle viele Datenbanken vom VOLLSTÄNDIGEN Wiederherstellungsmodus in den EINFACHEN Wiederherstellungsmodus (T-Logs und Wiederherstellung zu einem bestimmten Zeitpunkt sind nicht erforderlich). Werden die vorhandenen Transaktionsprotokolle abgeschnitten (wenn Prüfpunkte erstellt werden)?

In einem einfachen Wiederherstellungsmodell gibt das Datenbankmodul automatische Prüfpunkte aus und seine Häufigkeit wird durch das Wiederherstellungsintervall (erweiterte Serverkonfigurationseinstellung) oder wenn das Protokoll zu 70% voll wird, bestimmt.

Sofern keine lang laufenden Transaktionen auftreten, die das Abschneiden des Protokolls verzögern, schneidet ein automatischer Prüfpunkt den nicht verwendeten Teil des T-Protokolls ab.

Einige der vorhandenen Transaktionsprotokolle haben eine Größe von 50 bis 100 GB. Dies ist der beste Ansatz, um zu bestimmen, auf was ich sie verkleinern soll, um vorwärts zu kommen. Ich möchte sie offensichtlich nicht so groß halten.

Wenn Sie das Datenbankwiederherstellungsmodell für Datenbanken mit 50 bis 100 GB T-Protokollen auf VOLL gesetzt haben, müssen Sie häufige T-Protokoll-Sicherungen durchführen. Denken Sie daran, dass im Modell für die vollständige Wiederherstellung nach dem Einrichten einer Protokollsicherungskette selbst die automatischen Prüfpunkte nicht dazu führen, dass das Protokoll abgeschnitten wird.

Als letzten Ausweg können Sie die Protokolldatei abschneiden, sofort eine vollständige Sicherung erstellen und dann mit der Erstellung von T-Protokoll-Sicherungen beginnen, damit Sie im Katastrophenfall zu einem bestimmten Zeitpunkt eine Wiederherstellung durchführen können.

Oder werden sie im Laufe der Zeit von selbst schrumpfen (ich glaube nicht, dass sie es tun werden)?

Wie @TomTom hervorhob, handelt es sich um eine manuelle Operation.

Nachlesen :


2

Viele der Fragen können von uns nicht beantwortet werden. Wie lang ist ein Stück Schnur?

Einige der vorhandenen Transaktionsprotokolle haben eine Größe von 50 bis 100 GB. Dies ist der beste Ansatz, um zu bestimmen, auf was ich sie verkleinern soll, um vorwärts zu kommen.

Solange sie sein müssen. Ich schlage vor, nicht zu schrumpfen. Trunacate Protokolle, kommen Sie in einer Woche zurück und sehen Sie, wie viel Speicherplatz verwendet wird, dann entscheiden Sie. Aber DU musst diesen beantworten.

Die nächtlichen Backups haben ungefähr 8 TB und natürlich verbrauchen wir mehr Speicherplatz als wir möchten.

Warum also einfach machen? Ich meine, ernsthaft.

Alle Datenbanken sind auf VOLLSTÄNDIGE Wiederherstellung eingestellt, und die Transaktionsprotokolle wurden nie gesichert.

Eine kleine Logik wird Ihnen sagen, dass wenn Sie sie EINMAL abschneiden, Sie wahrscheinlich ohnehin VIEL weniger Speicherplatz zum Sichern verwenden werden. Das Ergebnis kann sein, dass Sie sie gut im vollständigen Wiederherstellungsmodus halten können. Probieren Sie das zuerst aus. Wenn sie nur ein geringes Volumen usw. haben, werden die Protokollsicherungen in Zukunft viel kleiner sein.

Ich habe alle SQL Server durchgesehen und diejenigen mit NIEDRIGER Priorität identifiziert, die nur eine nächtliche Sicherung benötigen, und Datenverluste im Wert von mehreren Tagen im Katastrophenfall sind kein Problem (Faxdatenbanken und ähnliches).

Ja. Das ist so lange, bis Sie vor Gericht landen und Ihren Arsch bekommen, weil Sie keine kritischen rechtlichen Dokumente haben. Wissen Sie, dass die Faxprotokolle möglicherweise Teil dessen sind, was Sie jahrelang als geschäftsrelevante Informationen aufbewahren müssen? So ist es in meiner Gerichtsbarkeit (10 Jahre). Wenn Sie eine U-Aktiengesellschaft sind, kann es ähnlich überrascht sein (SOX). Wenn Sie dies nicht tun, ist es vor Gericht SEHR schlecht, wenn Sie nachweisen möchten, dass Sie kein Fax erhalten haben. Oder habe einen geschickt. Es interessiert niemanden, ob dies monatlich passiert ist und Sie neuere Protokolle haben - Sie erfüllen die gesetzlichen Anforderungen nicht. Stellen Sie sicher, dass dies von einer SEHR hohen Person abgemeldet wird, da Ihr nicht kritisches Unternehmen möglicherweise Ihr Grund für die Entlassung ist.

Oder werden sie im Laufe der Zeit von selbst schrumpfen (ich glaube nicht, dass sie es tun werden)?

Und das sollten sie nicht tun. Die Größenänderung von Protokollen ist eine manuelle Operation, mit Ausnahme von Datenbanken mit geringem Volumen.


Danke für die Rückmeldung. Ich stimme dem ersten Punkt zu und werde sie im Auge behalten. Stellen Sie sie auf einfach ein, damit Sie sich nicht um die Protokollpflege kümmern müssen. und wir müssen sie nicht behalten. In der vollständigen Wiederherstellung zu bleiben und Protokollsicherungen zu erstellen (auch wenn diese klein sind), ist immer noch zusätzlicher Speicherplatz, den wir nicht haben. Die Bezeichnung von SQL-Servern mit niedriger Priorität war eine Geschäftsentscheidung, die über mir getroffen wurde.
BamBamBeano
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.