none
Warum kann ein LOGFile das auf SIMPLE steht auf über 300 GB anwachsen ?? RRS feed

  • Frage

  • Hallo;
    ich habe gesternen einen Server entdeckt dessen Logfile auf SIMPLE steht und trotzdem mitlerweile 326 GB belegt.

    Hat dafür jemand eine Erklärung wie das zustande kommen kann.

    Das Growing ist unlimited aber trotzdem sollte doch das Logfile nicht anwachsen. Jetzt kann ich es auch nicht mehr shrinken !!!
    Habe es schon auf FULL umgestellt, ein DB Backup und dann ein LOG Backup durchgeführt, trotzdem KEIN Shrink des Physikalischen FIles möglich.

    Danke
    Markus

    Mittwoch, 24. August 2011 08:39

Antworten

  • Hallo Markus,

    das erklärt warum Dein Log File so groß gewurden ist. Es wurde eine Replikation eingerichtet, jedoch war nirgends ein Abonnement der die Daten abgerufen hat, so das diese in Problem damit gelöst.Daten nie comitet wurden.

    Unter dem Punkt Replikation kann m SQL Server Managment Studio diese wieder deaktiviert werden. Vermutlich ist Dein Problem damit gelöst.

     


    Gruß Falk
    Falk Krahl
    • Als Antwort markiert Markus Mistler Donnerstag, 25. August 2011 13:55
    Donnerstag, 25. August 2011 10:12
  • Vielen Dank für eure Hilfe,

    Zum System es ist ein SQL2005 SP2 unter Win 2003.
    Das Logfile wurde nicht so groß angelegt und mit einem DBCC OPENTRAN sehe ich auch, dass die DB wohl für Replikation eingerichtet ist.

    Allerdings weis niemand wohin, woher oder warum ?

    Das ist der Ausdruck von dbcc opentran:
    Transaction information for database 'MicrosoftIdentityIntegrationServer'.

    Replicated Transaction Information:
            Oldest distributed LSN     : (0:0:0)
            Oldest non-distributed LSN : (10818625:608:1)
    DBCC execution completed.
    If DBCC printed error messages, contact your system administrator.

    Wie kann ich denn nun herausfinden wohin bzw. wer mit dieser DB repliziert wird ?

    Danke
    Markus

    • Als Antwort markiert Markus Mistler Donnerstag, 25. August 2011 13:55
    Donnerstag, 25. August 2011 08:06

Alle Antworten

  • Hallo Markus,

    es gibt einige Dinge die dazu führen können das das Protokoll auch im Simple Recovery-Modell wachsen kann:

    Eine langlebige Transaktion - Das Protokoll kann nicht gelöscht werden, bis die Transaktion das Commit bzw. Rollback bekommt. Du kannst mit DBCC OPENTRAN Dir anzeigen lassen, was die älteste aktive Transaktion ist.

    Transaktionsreplikation - Das Protokoll kann solange nicht gelöscht werden, solange der Log-Leser Job diese nicht gelesen hat und die Transaktion committed hat.

    Es gab auch einen Fehler in SQL 2000 SP4, der verhinderte das Checkpoints aus dem Clearing richtig behandelt wurden. siehe Link

    Nähere Informationen um was für einen SQL Server es sich handelt, wären also sehr hilfreich. Meine Vermutung ist jedoch der 1. Punkt, das es sich ume eine langlebige Transaktion handelt. Ggf. wäre auch noch interressant ob das Log-File auch voll belegt ist, oder ob der größte Teil leer ist.

     


    Gruß Falk
    Falk Krahl

    Mittwoch, 24. August 2011 11:14
  • ... dessen Logfile auf SIMPLE steht und trotzdem mitlerweile 326 GB belegt.
    Hat dafür jemand eine Erklärung wie das zustande kommen kann.

    Hallo Markus,
    Falk hat ja schon die wichtigsten Punkte & Gründe aufgeführt.
    Auch bei Recovery-Model = Simple kann das Log File groß werden, nämlich so groß wie es für alle aktuellen - aktiven Transaktionen nötigt ist.
    Der Unterschied zwischen Simple und Full ist, das bei Simple sofort nach Abschluß der Transaktion der Platz wieder frei gegeben wird, während es bei Full erst nach einem (bis zweitem) Log Backup erfolgt.
    So oder so, das Log File bleibt danach erst mal so groß, wie sie ist; weshalb sollte sich auch verkleinern.
    Wenn sich das Log File nicht verkleinern lässt, kann das 2 (und mehr) Gründe haben:
    1. Das Log File wurde gleich mit dieser Größe angelegt; wenn bei dem Statement unten size = max_size ist, dann ist das der Fall und dann kannst Du die Datei auch nicht weiter verkleinern, ohne das Du es nicht vorher umkonfigurierst.
    SELECT name, size, max_size, growth
    FROM sys.database_files
    WHERE [type] = 1;
    

    Das macht man z.B. bei DWH, wo regelmäßig große Datenmengen hinzu kommen und die eben entsprechen Log benötigen; häufiges automatisches vergrößern wäre da eine Performanzbremse.

    2. Wie Falk schon schrieb, gibt es noch nicht abgeschlossene Transaktionen, weshalb die VLFs nicht freigegeben wurden.
    Das kannst Du einfach über sys.databases (http://msdn.microsoft.com/de-de/library/ms178534.aspx) prüfen, ob es noch aktive Transaktionen oder andere Gründe gibt, die das Log belegen:
    SELECT [name]
       ,[database_id]
       ,[log_reuse_wait]
       ,[log_reuse_wait_desc]
     FROM [sys].[databases]
    

    Eine statistische Übersicht für alle DB-Logs gibt es mit dem Befehl:
    DBCC SqlPerf(LogSpace);
    

    dort findest Du auch den von erwähnten verwendeten Platz des Log bzw. was frei ist.
    Mit der undokumentierten Funktion
    DBCC LogInfo
    

    ausgeführt auf der jeweilgen Datenbank, kannst Du Dir die Detail-Informationen zu den VLF anzeigen lassen; alles mit Status = 2 ist nicht "reuseable".

    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
    Mittwoch, 24. August 2011 13:36
  • Vielen Dank für eure Hilfe,

    Zum System es ist ein SQL2005 SP2 unter Win 2003.
    Das Logfile wurde nicht so groß angelegt und mit einem DBCC OPENTRAN sehe ich auch, dass die DB wohl für Replikation eingerichtet ist.

    Allerdings weis niemand wohin, woher oder warum ?

    Das ist der Ausdruck von dbcc opentran:
    Transaction information for database 'MicrosoftIdentityIntegrationServer'.

    Replicated Transaction Information:
            Oldest distributed LSN     : (0:0:0)
            Oldest non-distributed LSN : (10818625:608:1)
    DBCC execution completed.
    If DBCC printed error messages, contact your system administrator.

    Wie kann ich denn nun herausfinden wohin bzw. wer mit dieser DB repliziert wird ?

    Danke
    Markus

    • Als Antwort markiert Markus Mistler Donnerstag, 25. August 2011 13:55
    Donnerstag, 25. August 2011 08:06
  • Hallo Markus,

    das erklärt warum Dein Log File so groß gewurden ist. Es wurde eine Replikation eingerichtet, jedoch war nirgends ein Abonnement der die Daten abgerufen hat, so das diese in Problem damit gelöst.Daten nie comitet wurden.

    Unter dem Punkt Replikation kann m SQL Server Managment Studio diese wieder deaktiviert werden. Vermutlich ist Dein Problem damit gelöst.

     


    Gruß Falk
    Falk Krahl
    • Als Antwort markiert Markus Mistler Donnerstag, 25. August 2011 13:55
    Donnerstag, 25. August 2011 10:12
  • Danke.

    ich vermute auch dass es das ist.

    Da sind 2 Replikationen eingetragen. Jetzt muss ich nur noch klären ob ein von diesen überhaupt noch benötigt wird.

    Vielen Dank für eure Hilfe. Ich melde mich wenn ich das Logfile shrinken konnte.

    Gruß
    Markus

    Donnerstag, 25. August 2011 10:23
  • Tjsa unter der REPLIKATION war tatsächlich ein Partner eingestellt,
    das hat ein Kollege von mir getan.
    Anscheinend war aber damit irgend etwas nicht in ordnung, denn ich glaube nicht, dass wenn die Replikation eingeschaltet ist, das Logfile NIE mehr kleiner gemacht werden kann.

    Deswegen vermute ich der Kollege hat was falsches Eingestellt. Er wusste auch nicht mehr warum er dies getan hat.

    Somit haben wir die Replikation gelöscht und einen Checkpoint gesetzt und schon konnten wir auch shrinken.

    Habe jetzt 5 GB gewählt. Wird aber wohl nicht mehr so groß. Aber egal...... wir haben ja jetzt Platz.

    Vielen Dank nochmals und Gruß
    Markus

    Donnerstag, 25. August 2011 13:58