none
DRINGEND! Transaction Log voll! Database down. RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Leute,

    ich brauche dringend mal eure Hilfe. Ich bin ratlos dies bezüglich.

    Am Montag hatten wir in der Firma einen total Ausfall. Unsere Telefonanlage hat keine Calls mehr in die Telefondatenbank geschrieben, weil das Transaction Log voll war.

    Zum Verständnis:
    Die Datenbank (Telefonanlage) 13_IC wird gespiegelt, um ein Backup für ein möglichen Failover zu haben.

    Die Telefonanlage kann bei einem Ausfall der Datenbank in seinen Cache schreiben( so genannte PMQ Files), diese kann er eine Weile im Cache behalten/zurück halten, aber irgendwann werden auch diese Files voll und muss dann in die Datenbank schreiben. Bei dem Versuch die Daten in die Datenbank zu schreiben ist diese Fehlermeldung gekommen.

    (The transaction log for database 'I3_IC' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases) Das steht im EventLog des Servers.

    SELECT log_reuse_wait_desc FROM sys.databases where name = 'I3_IC'

    Ergebnis
    log_resuse_wait_desc
    LOG_BACKUP

    Am 22.09.2013 um 2:45 Uhr (jeden Samstag) läuft ein Index rebuild.
    SQL Version 2008 R2 Standard läuft bei uns.(zur Info, also Offline Rebuild)
    Dieser Job ist am 22.09.2013 das erste mal abgebrochen, seit der Job läuft (am 09.08.2013 eingerichtet, seitdem läuft er jeden Samstag).

    Kann es sein das er beim Abbruch der Neuindexierung denn allokierten Speicher nicht wieder frei gegeben hat? Und am Montag, den 23.09.2013 um 4:14 Uhr es nun zu Eklat gekommen ist?

    Zudem kam noch dazu das am 23.09.2013 um 2:00 Uhr das Transaction Log Backup gestartet ist. Kann diese Konstellation dazu führen das die Database connection nicht established ist? 

    Ergo: Rebuild Indexes (Offline), Transaction log Backup, Custom querys und Schreibversuche der Telefonanlage.

    Kann dieses Bildnis dazu geführt haben das die DB einfach blockiert hat?
    Am Freitag war die .ldf noch 10 GB groß. Auf unserer Partition sind 488 GB groß. Und die war voll.

    1. Nachdem wir wussten, dass das Transaction Log voll ist, haben wir nachgesehen was der Grund war.
    Die Befehle waren nicht commited. Somit konnte durch das Backup des Transaction Logs nicht verkleinert werden.
    2. Also haben wir die Spiegelung entfernt und danach wurden die Befehle commited. Uhd damit war es auch möglich das Transaction Log zu verkleinern.

    Jedoch sind die Daten vom 23.09.2013 von 4:00 Uhr - 10:00 Uhr verloren.

    Aber wie kann das passieren? Hat jemand eine plausible Erklärung?

    Vielen vielen Dank

    P.S. Entschuldigt für das Durcheinander. :( Hoffe ihr könnt meinem Problem folgen.



    • Bearbeitet BCCsql Mittwoch, 25. September 2013 09:50
    Mittwoch, 25. September 2013 09:34
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    ...
    Das Transaction Log Backup läuft einmal täglich als SQL Server Job.  Und dann nochmal täglich per Symantec Backup-Exec.

    ...

    Das klingt schon etwas "chaotisch". Warum mischt man 2 Backup Techniken? Und beides für die Logs?

    Für eine kritische Umgebung wäre mir persönlich so eine Kombination zu heikel - wenn man sie mal benötigt, muss man gleich an noch mehr denken als sonst erforderlich.

    - aber das nur Nebenbei.

    Für eine seriöse Aussage zu dem genauen Grund für das Problem, haben wir nicht genug Informationen hier. Da müsste man schon etwas mehr zeit hineinstecken und sich alles ganz genau ansehen. Vielleicht helfen die bisherigen Informationen samt dem internen Wissen und Log-Auswertungen aus.

    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Mittwoch, 25. September 2013 11:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Nimm am besten einen Wartungsplan, dann bist Du die Sorge los.

    Siehe hierzu auch: Sichern und Wiederherstellen von Datenbanken

    Die Backups sind ziemlich sicher nicht schuld dran, sondern eher zu selten gelaufen um das aus dem Ruder laufen zu verhindern. Bedenke aber auch, dass Du in der Nacht beim Rebuild sehr viel Platz für Deine Backups gebraucht hättest.

    Hast Du mittlerweile mal die Uhrzeiten des Wachstums ermittelt und mit den Jobs abgeglichen?

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Mittwoch, 25. September 2013 11:59
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden
    Das Vergrößern von Log Files kannst Du über die Performance Counter ermitteln, ein Basis Script dazu findest Du hier: Log Growth Rate

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 26. September 2013 05:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Alternativ geht es über die GUI:

    - Rechte Maustaste auf die Datenbank

    - Berichte -> Standardberichte -> Datenträgerverwendung

    - Dort dann "Ereignisse zur automatischen Vergrößerung/Verkleinerung für Daten-Protokolldateien" aufklappen

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Donnerstag, 26. September 2013 06:03
    |
    Beantworter

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden

    Wie groß ist die Datenbank bei 10 GB LDF?

    Wie oft läuft das Transaction Log Backup? Bei uns ist dies alle 20 Minuten der Fall.

    Der Rebuild verursacht natürlich einigen Traffic, welcher nicht unbedingt für alle Tabellen notwendig ist. Hast Du einen Überblick über die Fragmentierung der Tabellen vor dem Rebuild? Wie wäre ein Reorganize jede Nacht? Oder direkt intelligente Skripte nutzen, die in Abhängigkeit von der Fragmentierung aktiv werden? Schau auch mal bei Ola Hallengren nach.

    Im Bericht der Datenträgerverwendung kannst du sehen, zu welchen Zeitpunkten genau die Vergrößerung erfolgte.

    Wie ist die Vergrößerung eingestellt? 10 Prozent wäre eher ungünstig. Siehe hierzu auch: Schon mal von VLFs gehört?

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Mittwoch, 25. September 2013 10:24
    |
    Beantworter
  • Question
    Anmelden
    1
    Anmelden

    Entschuldige, das ich mir in dem leichten Durccheinander jetzt mal nur einen Punkt herauspicke.

    (Tipp: eine chronologische Aufstellung ist hilfreich)

    Das das Log beim Index Rebuild mindestens intern, und wenn es nicht langt auch extern wächst, ist denke ich klar. Wenn es mittendrinnen zum Abbruch kommt, muss natürlich auch das Rollback protokolliert werden.

    Und wie bereits richtig erkannt, wird das Log nicht truncated, wenn der Spiegel nicht mitzieht. (Warum das wiederum der Fall war, das ist hieraus nicht erkennbar)

    Das Daten "einfach so" verlorengehen, ist nicht möglich. Anstelle eines Commit lief dann für diese "fehlenden Daten" sicherlich ebenfalls ein Rollback. Genaueres kann ich hierzu ad hoc nicht sagen nach diesen Angaben.

    Um soetwas zu vermeiden, helfen sicherlich Christoph's Hinweise.

    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Mittwoch, 25. September 2013 11:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Die Datenbank ist 352 GB groß.
    Das Transaction Log Backup läuft einmal täglich als SQL Server Job.  Und dann nochmal täglich per Symantec Backup-Exec.
    Nein leider hatte ich mir keinen Überblick über die Fragmentierung der Tabellen vor dem Rebuild gemacht.
    Ich habe den Job erstmal deaktiviert und muss mir erstmal im Klaren werden, ob DAS überhaupt der Auslöser war. Falls ja, dann muss ich mir natürlich etwas anderes überlegen.

    Mein Chef brauch von mir halt ne klare Aussage, wie das zustande kommen konnte.

    Was die Vergrößerung angeht:


    • Bearbeitet BCCsql Mittwoch, 25. September 2013 11:08
    Mittwoch, 25. September 2013 11:05
    |
  • Question
    Anmelden
    1
    Anmelden

    ...
    Das Transaction Log Backup läuft einmal täglich als SQL Server Job.  Und dann nochmal täglich per Symantec Backup-Exec.

    ...

    Das klingt schon etwas "chaotisch". Warum mischt man 2 Backup Techniken? Und beides für die Logs?

    Für eine kritische Umgebung wäre mir persönlich so eine Kombination zu heikel - wenn man sie mal benötigt, muss man gleich an noch mehr denken als sonst erforderlich.

    - aber das nur Nebenbei.

    Für eine seriöse Aussage zu dem genauen Grund für das Problem, haben wir nicht genug Informationen hier. Da müsste man schon etwas mehr zeit hineinstecken und sich alles ganz genau ansehen. Vielleicht helfen die bisherigen Informationen samt dem internen Wissen und Log-Auswertungen aus.

    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Mittwoch, 25. September 2013 11:20
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich finde die Idee gut das Transaction Log Backup alle 15 Minuten oder so zu machen.

    Nur suche ich schon ne Weile im Netz nach einem Befehl, der mir die Transaction Log Backups dynamisch benennt. Wenn dann möchte ich auch alle 15 Minuten Backups behalten, bis sie am nächsten Tag von dem dann aktuellen Backup überschrieben werden.
    Beispiel:
    BACKUP LOG [I3_IC] TO  DISK = N'E:\I3_IC_Log .bak' ........usw.

    E:\I3_IC_Log 00:00 .bak
    E:\I3_IC_Log 00:15 .bak
    E:\I3_IC_Log 00:30 .bak
    usw.
    usw.
    Kann mir da jemand den Befehl nennen, das er die Zeit da übernimmt?

    Das Problem ist denke ich weniger das Backup'n. Sondern eher der Verlauf, wie es zu diesem Ausfall kam.
    KÖNNTE es denn rein theoretisch möglich sein, dass diese Kombination dazu führte?

    Mittwoch, 25. September 2013 11:33
    |
  • Question
    Anmelden
    1
    Anmelden

    Ich denke, das geht am Sinn vom Transaction Log vorbei. Einmal täglich würde ich eher eine differentielle Sicherung sehen. Zwei konkurrierende Systeme machen auch keine Freude. Alle 20 Minuten auf Platte sichern und abends dann als File-Backup mit Symantec abziehen.

    Wie gesagt, im Bericht über die Datenträgerverwendung siehst Du die Zeitpunkte der Vergrößerung und kannst damit evtl. andere Aktionen ausschließen.

    Da Du eine Standard Edition verwendest, kannst Du ja nur synchron spiegeln und damit kann auch der Platz auf dem Mirror-Server die limitierende Größe sein.

    Ansonsten beachte die Hinweise von Andreas.

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Mittwoch, 25. September 2013 11:35
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Nimm am besten einen Wartungsplan, dann bist Du die Sorge los.

    Siehe hierzu auch: Sichern und Wiederherstellen von Datenbanken

    Die Backups sind ziemlich sicher nicht schuld dran, sondern eher zu selten gelaufen um das aus dem Ruder laufen zu verhindern. Bedenke aber auch, dass Du in der Nacht beim Rebuild sehr viel Platz für Deine Backups gebraucht hättest.

    Hast Du mittlerweile mal die Uhrzeiten des Wachstums ermittelt und mit den Jobs abgeglichen?

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Mittwoch, 25. September 2013 11:59
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hast Du mittlerweile mal die Uhrzeiten des Wachstums ermittelt und mit den Jobs abgeglichen?


    Wie mache ich das?
    Mittwoch, 25. September 2013 13:55
    |
  • Question
    Anmelden
    0
    Anmelden
    Das Vergrößern von Log Files kannst Du über die Performance Counter ermitteln, ein Basis Script dazu findest Du hier: Log Growth Rate

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 26. September 2013 05:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Alternativ geht es über die GUI:

    - Rechte Maustaste auf die Datenbank

    - Berichte -> Standardberichte -> Datenträgerverwendung

    - Dort dann "Ereignisse zur automatischen Vergrößerung/Verkleinerung für Daten-Protokolldateien" aufklappen

    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Donnerstag, 26. September 2013 06:03
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    haben die Beiträge weitergeholfen?

    Gruss,
    Raul

    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Freitag, 27. September 2013 06:48
    |