it-swarm.com.de

Transaktionsprotokoll aufgrund von log_backup voll

Ich teste, wie bestimmte Vorgänge unter verschiedenen Wiederherstellungsmodellen protokolliert werden. Nachfolgend sind die Schritte aufgeführt, die ich bisher ausgeführt habe

1.Erstellen Sie die Datenbank im vollständigen Wiederherstellungsmodell
2. Backup erstellen
3.Erstellen Sie eine Tabelle und fügen Sie 10 Millionen Datensätze ein
4. Führen Sie eine Protokollsicherung durch, überprüfen Sie VLF count und sehen Sie den Prozentsatz des freien Protokollspeicherplatzes
5. Führen Sie jetzt eine Indexwiederherstellung durch und sehen Sie sich die mit der Funktion fn_dblog generierten Datensätze an

6. Jetzt habe ich auf das Bulk-Recovery-Modell umgestellt
7.Erstellen Sie ein Backup
8. Erstellte eine Protokollsicherung
9. hat eine Indexwiederherstellung durchgeführt

Seltsamerweise schlägt die Indexwiederherstellung mit dem folgenden Fehler fehl.

Die Anweisung wurde beendet. Meldung 9002, Ebene 17, Status 2, Zeile 1 Das Transaktionsprotokoll für die Datenbank 'Bulklogging' ist aufgrund von 'LOG_BACKUP' voll.

das stimmt eigentlich nicht

Das automatische Wachstum des 1.log-Speicherplatzes ist nicht eingeschränkt

Autogrwoth setting

2. Platz auf dem Speicherort der Protokolldatei

space on drive where log file is stored

Kann mir jemand helfen zu verstehen, warum ich über dem Fehler stehe, obwohl Platz vorhanden ist und das automatische Wachstum nicht eingeschränkt ist

hinzufügen eines Bildes mit Indexgröße.

Das Problem wurde behoben, aber nicht sicher, wie diese Änderung den Unterschied ausmachte. Alle Hinweise wären sehr willkommen.

Kommentar sagt zwei lange - also hier posten ...

ich habe den Index erneut ausgeschrieben, nachdem ich das Wiederherstellungsmodell geändert hatte, und dann hat es funktioniert. Darüber hinaus wurde der geskriptete Index vor und nach genau gleich geblieben, nur die Sitzung wurde geändert. Aber ich bin nicht sicher, wie dies funktioniert hat.

Vorher:

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Nachher: ​​

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

Update zum Schließen dieser Frage:
Ich verwende Fn_dblog, um Protokolldatensätze zu überprüfen. Dies scheint einen versteckten Fehler zu haben, wie beschrieben hier , der mein Protokollwachstum beeinflussen kann.

Edit 15.08.13: Vorsicht - Jonathan hat gerade von einem Kundensystem erfahren, das dies ausgiebig nutzt, dass jedes Mal, wenn fn_dump_dblog aufgerufen wird, ein neuer versteckter SQLOS-Scheduler und bis zu drei Threads erstellt werden, die nicht verschwinden (und nicht verschwinden) wiederverwendet werden), bis ein Server neu gestartet wird. Es ist ein Fehler, den das SQL-Team beheben wird, sobald wir sie darauf aufmerksam gemacht haben. Mit Vorsicht verwenden.

Bearbeiten 15.05.15: Es wurde in SQL Server 2012 SP2 + und SQL Server 2014 behoben. Das Update wird nicht früher zurückportiert.

enter image description here

7
TheGameiswar

Dieser Fehler tritt auf, weil das Transaktionsprotokoll aufgrund von LOG_BACKUP voll wird. Daher können Sie für diese Datenbank keine Aktion ausführen. In diesem Fall löst das SQL Server-Datenbankmodul einen 9002-Fehler aus.

In diesem Fall müssen Sie tun

  • Erstellen Sie eine vollständige Datenbanksicherung.
  • Verkleinern Sie die Protokolldatei, um die physische Dateigröße zu verringern.
  • Erstellen Sie ein LOG_BACKUP.
  • Erstellen Sie einen LOG_BACKUP-Wartungsplan, um häufig Sicherungsprotokolle zu erstellen.

Hinweis: Der Verkleinerungsvorgang wirkt sich auf die SQL Server-Leistung während der Ausführung des Verkleinerungsbefehls aus. Dies führt auch zu einer Indexfragmentierung und kann die Leistung von Abfragen verlangsamen, die einen Bereich des Index durchsuchen.

Es wird daher empfohlen, vor der Inbetriebnahme einen LOG_BACKUP-Wartungsplan vorzubereiten, um die Protokolldatei häufig zu sichern und den Verkleinerungsvorgang in der Produktion zu vermeiden.

Weitere Informationen finden Sie unter Das Transaktionsprotokoll für die Datenbank "SharePoint_Config" ist aufgrund von LOG_BACKUP voll.

Hoffe das hilft dir

Ich bin heute mit einer meiner Produktionsdatenbanken auf dieses Problem gestoßen. Ich habe es behoben, indem ich der Datenbank eine zweite Protokolldatei hinzugefügt habe. Ich konnte keine vollständige Sicherung durchführen oder die Protokolldatei nicht wie oben beschrieben verkleinern, da beim Versuch das LOG_BACKUP Fehlermeldung. Ich habe auch versucht, die Protokolldatei zu erweitern, aber auch dies hat den gleichen Fehler generiert. Am Ende machte das Hinzufügen einer zweiten kleineren Protokolldatei die Datenbank wieder verwendbar. Danach konnte ich die Datenbank sichern und die Größe des ursprünglichen Protokolls ändern.

0
Mr.Brownstone