none
LOG Datei zu groß RRS feed

  • Frage

  • Hallo,

     

    ich habe bei einer MSSQL 2000 das Problem, dass eine Anwendung, die auf die SQL Datenbank zugreift nicht mehr funktioniert.

    Ich habe herausgefunden, das die LOG Datei 350GB groß ist (NEIN, kein schreibfehler, wirklich 350 GB).

    Wenn ich versuche den EnterpriseManager zu starten, bleibt er hängen und nichts geht mehr.

    Wie kann ich jetzt die LOG Datei wieder verkleinern und auf welche Größe, wenn die DB ca. 51 GB hat ????

     

    Danke und Beste Grüße

    Matthias

    Donnerstag, 25. August 2011 07:56

Alle Antworten

  • Hallo Matthias,

    welches Wiederherstellungsmodell verwendest Du? Wird die Datenbank regelmäßig gesichert?

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
    Donnerstag, 25. August 2011 08:24
    Moderator
  • Hallo Matthias,

    verwende besser den Query Analyzer, der hat nicht so viel Overhead.
    Als Anmeldekonto solltest Du vorzugsweise ein Konto nehmen, dass die Datenbank nicht als Standard verwendet.

    Möglich ist das die Protokolldatei nicht mehr vergrößert werden kann:
    Ein Transaktionsprotokoll auf einem SQL Server-Computer wächst unerwartet oder wird voll.

    Als Notmaßnahme kannst Du das Protokoll abschneiden und verkleinern wie beschrieben in:
    INF: Verkleinern des Transaktionsprotokolls in SQL Server 2000 mit DBCC SHRINKFILE

    Danach ist eine vollständige Sicherung der Datenbank anzuraten.

    Danach solltest Du den Grund für die übermäßige Größe ermitteln.
    Wird das Protokoll regelmäßig (in kurzen Abständen) gesichert?
    Wenn nein, sollte  der Wiederherstellungsmodus auf einfach eingestellt sein
    oder aber eine Protokollsicherung als Auftrag eingerichtet werden.

    Gruß Elmar

    • Als Antwort vorgeschlagen Falk Krahl Freitag, 26. August 2011 18:59
    Donnerstag, 25. August 2011 08:27
  • Hallo Elmar, Hallo Stefan,

     

    in meinem Wartungsplan habe ich eine Sicherung der DB und des LOG Vollsicherung eingetragen und das wird immer um 1 Uhr Nachts ausgefeührt.

    Ich kontrolliere immer die größe der Sicherung, die jedoch immer bei 51GB liegt ?!?!?!

    Hab auch schon versucht, die Sicherung von einem anderen Tag Wiederherzustellen, jedoch der gleiche Mist....sorry :)

    Die Rücksicherung dauert in diesem Fall fast zwei Tage:(

    Wenn ich des geschafft habe, die DB bzw. das LOG zu verkleinern, dann werd ich mich nochmals melden zu Fehlersuche.

    Aber vorerst mal vielen vielen lieben Danke !!!!!

     

    Gruß Matthias

    Donnerstag, 25. August 2011 08:34
  • Hallo Matthias,

    es macht IMO keinen Sinn, LOG und DATA gemeinsam zu EINER Zeit zu sichern. Der Grund für das Recovery Model FULL besteht darin, daß man gesicherte Transaktionen bis zu einem bestimmten Zeitpunkt wieder herstellen kann. Wenn dann also die Logsicherung um 21:00 gemacht wird, dann habt Ihr definitiv die Arbeit von einem ganzen Tag verloren:

    - 21:00 Uhr Logsicherung

    - 22:00 Uhr Vollsicherung

    Was passiert nun, wenn euch um 18:00 Uhr die DB abraucht?

    - Pech gehabt, da nur das letzte FULL-Backup vorliegt (von 22:00 Uhr des Vortages)

    Besser ist es, eine Logsicherung stündlich (oder bei hoher Transaktionslast 15 - 30 Minutenintervalle) durchzuführen.

    So, das nur mal als "Basics"...

    Nun noch mal zu Deinem Problem...

    Wie Elmar bereits asusgeführt hat, sollte ev. mal das Recoverymodell der DB auf SIMPLE gestellt werden. Starte dazu den Query Analyzer; achte darauf, daß Du einen Account verwendest, der sysadmin oder owner der DB ist.

    Im Query Analyzer gibst Du dann die folgenden Befehle ein:

     

    USE Master
    GO
    
    -- Sicherung Deiner Datenbank
    BACKUP DATABASE [YourDatabase] TO DISK = 'Backuppfad_und_datei.bak' WITH STATS, INIT
    GO
    
    -- Recoverymodell auf Simple stellen
    ALTER DATABASE [YourDatabase] SET RECOVERY SIMPLE
    GO
    
    -- Logfile verkleinern auf 100 MB
    USE [YourDatabase]
    GO
    
    DBCC SHRINKFILE (Name_Von_Log, 100) WITH NO_INFOMSGS
    

    Danach solltest Du mal das Sicherungskonzept überdenken. Wenn Du den Recoverymode auf SIMPLE läßt, brauchst Du keine LOG-Sicherung mehr machen; würde dann eh einen Fehler generieren.

     


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITS Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    Sonntag, 28. August 2011 11:07
  • Hallo @All,

    ich habs jetzt hin bekommen. Danke.

    Ich habe mein Backup Konzept auch noch einmal überdacht und jetzt wird in der Nacht ein Backup der DB gemacht und alle 2h eine Sicherung des Transaktionsfiles im Modus: Vollständig. Jetzt wird das Log höchstens 10 MB groß :)

     

    Ich danke an dieser Stelle allen beteiligten!

     

    Beste Grüße

    Matthias

    Mittwoch, 31. August 2011 16:40
  • Hallo,

    ich habe ein ähnliches Problem.

    Eine meiner Datenbanken ist ca. 4GB groß,

    das Logfile hat inzwischen 12 GB und hat weniger als 10% freien Platz, der Modus steht aus Simple.

    Hat jemand ne Idee, was da schief läuft?

    So langsam geht mir der Plattenplatz aus.

    Gruß

    cheapy

    Dienstag, 17. April 2012 09:17
  • Hallo cheapy,

    prüf mal, was Dir für die Datenbank die Spalte log_reuse_wait_desc liefert:

    SELECT name, log_reuse_wait_desc
    FROM sys.databases
    ORDER BY name


    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing

    Dienstag, 17. April 2012 10:57
  • hast Du offene Transaktionen die das Logfile fuellen, da sie ja nicht automatisch aus dem Logfile geloescht werden koennen:

    select * from master.dbo.sysprocesses where open_tran > 0
    

    Dienstag, 17. April 2012 17:05
  • Hallo,

    mittlerweile brennt das Problem wieder.

    Für die problematische DB liefert mir die Spalte log_reuse_wait_desc die Information REPLICATION.

    Für diese DB ist eine Snapshot Replication definiert, die ca. 100 Tabellen sowie einige Stroed Procedures, Functions und Views beinhaltet.

    Nur hab ich leider keine Idee, wie ich nun an die Ursache des Problems ran komme.

    Ich habe noch eine zweite Replikation für eine andere DB auf dem Server, die allerdings nur 5 Tabellen beinhaltet, hier gibt es keinerlei Probleme.

    Hat jemand ne Idee, wie ich dem Problem auf die Spur kommen kann? In den Server-Logdateien ist auch nichts auffälliges zu finden.

    Gruß

    cheapy

    Montag, 7. Mai 2012 08:03
  • Hallo,

    dieser Select bringt kein Ergebnis.

    select * from master.dbo.sysprocesses where open_tran > 0

    Gruß

    cheapy


    Montag, 7. Mai 2012 08:04