none
Transaktionslog verkleinern bei Wiederherstellungsmodell 'Einfach' RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    das Thema ist sicher schon oft behandelt worden und ich habe auch sehr viele Blogartikel zu dem Thema gefunden. Jedoch bin ich kein Experte in Sachen SQL Server/Datenbanken allgemein. Deswegen wollte ich euch bitten, mir einmal unter die Arme zu greifen. :)

    Die Situation ist folgende. Ich arbeite mit einer Software für das betriebswirtschaftliche Controlling. Man kann in der Software "Dateien" anlegen, die dann aber eigentlich im SQL Server als Datenbank angelegt werden. Ich habe also viele Datenbanken mit demselben Schema, jedoch mit unterschiedlichen Daten. Einige Funktionen der Software verursachen, dass das Transaktionsprotokoll ziemlich stark anwächst. Bspw. kann eine 1GB große Datenbank auch schon mal ein 15GB Transaktionsprotokoll bekommen. Das verbraucht natürlich unglaublich viel Platz auf meinem Computer. Die Datenbanken sind alle im Wiederherstellungsmodell "Einfach" und wenn man in der Software eine Dachensicherung starte, bekommt man ein Full Backup von der Datenbank als .bak Datei.

    Ich habe bisher immer im Management Studio die Datenbank verkleinert. Nun habe ich aber gelesen, dass das sehr der Performance schadet, wenn man das macht, weil dann die Indizes fragmentiert sind. Ich möchte aber auch nicht so viel Platz auf meinem Computer verbrauchen, weil das Transaktionsprotokoll an sich ja leer ist. Nur die Datei ist halt noch so groß. Wenn ich dann im SSMS die Verkleinerung anstoße, wird das Protokoll auch im nu wieder wenige 100kb klein.

    Meine Frage ist also, wie ich hier am besten vorgehen kann. Kann ich weiterhin die Datenbank verkleinern und dann die Indizes neu erstellen? Wäre das okay? Oder sollte ich im SSMS einfach nur die Datei für das Transaktionsprotokoll verkleinern? Schadet das er Performance?

    Vielen Dank für eure Hilfe

    Alex

    Sonntag, 16. November 2014 18:10
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Alex,
    ich habe da verschiedene Richtlinien:
    1.) Generell sollte die LDF-Datei nicht größer als 2 GB sein. (Ist eher für die anderen DBs auf dem Server gedacht)
    2.) Generell sollte die LDF-Datei nicht größer als 500 MB sein. Für einzelne Datenbanken sind hier Ausnahmen für die Ziele explizit eingetragen.
    3.) Log File Growth für kleine Datenbanken. Setze das Wachstum für kleine LDFs auf 5 MB. Kleine Datenbanken sind über eine Bedingung mit <= 51200 KB definiert.
    4.) Log File Growth für andere Datenbanken. Setze das Wachstum für LDFs auf 50 MB. Datenbanken sind über eine Bedingung mit > 51200 KB definiert.
    5.) Seitenüberprüfung. Diese Regel überprüft, ob die PAGE_VERIFY-Datenbankoption auf CHECKSUM festgelegt ist. Wenn CHECKSUM für die PAGE_VERIFY-Datenbankoption angegeben wird, berechnet SQL Server Database Engine (Datenbankmodul) beim Schreiben der Seite auf den Datenträger eine Prüfsumme des Inhalts der gesamten Seite und speichert den Wert im Seitenkopf. Wenn die Seite vom Datenträger gelesen wird, wird die Prüfsumme erneut berechnet und mit dem im Seitenkopf gespeicherten Prüfsummenwert verglichen. Dadurch wird ein hohes Maß an Integrität der Datendateien bereitgestellt. http://technet.microsoft.com/de-de/library/ms190249.aspx

    Leider setzt die Software ständig die Seitenüberprüfung zurück, so dass man sich den Punkt eigentlich schenken kann. Die Entwickler wissen es mittlerweile und werden es ggf. in einer zukünftigen Version ändern.

    Ein Index Rebuild baut die Indizes neu auf und bringt Dir auch Deine Daten wieder in die richtige Reihenfolge, wenn sie fragmentiert sein sollten. Das bläht natürlich das Log und ggf. auch die Datenbank-Datei auf. Das Log kannst Du immer ohne Performance-Verlust kleiner machen. Das kostet dann aber Zeit, wenn es zu klein ist und regelmäßig wieder vergrößert werden soll. Hier also die automatischen Vergrößerungen im Auge behalten und gegen 0 optimieren.

    Zur internen Verwaltung der LDFs und ihre Auswirkungen auf den Serverneustart habe ich hier einiges zusammen getragen:
    http://www.insidesql.org/blogs/cmu/sql_server/schon-mal-von-vlfs-gehoert

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 18. November 2014 07:59
    |
    Beantworter

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Nun habe ich aber gelesen, dass das sehr der Performance schadet, wenn man das macht, weil dann die Indizes fragmentiert sind.

    Hallo Alex,

    das stimmt, tritt aber nur auf, wenn man die Datendatei (MDF/NDF) verkleinert, nicht beim Verkleinern der TransactionLog Datei. Das sollte man zwar auch nicht unbedingt machen, den wenn der Platz benötigt wird, muss die Datei jedesmal vergrößert werden, das dauert jedesmal seine Zeit und ist somit der Performanz abträglich.

    Wichtig ist hier einen vernünftigen Vergößerungsfaktor für die Datenbankdateien zu haben. Der Default ist leider ein unsinniger Faktor von 10% für die Log Dateien, d.h. ist die Log Datei bereits 15 GB groß, wächst sie beim nächsten man 1,5 GB und das dauert dann wirklick lange. Besser ist hier ein fester Wert von z.B. 200 MB. 

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Sonntag, 16. November 2014 20:11
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Alex!
    Ich glaube die Software kenne ich. Bei uns läuft auch im Bereich Controlling so ein Teil, was Unmengen an Datenbanken produziert und das Transaktionslog immer grottig konfiguriert.
    Ich habe mit der Richtlinienbasierten Verwaltung einigermaßen Ordnung in das Chaos gebracht:
    http://msdn.microsoft.com/de-de/library/bb510667.aspx

    Nach der initialen Befüllung ist das Log erst mal sehr groß. Ich shrinke dass dann immer wieder auf sinnvolle Werte, wobei ich auch die Vergrößerung bereits wie von Olaf angeregt auf feste Werte (z. b. 200 MB) einstelle. Zumindest das bleibt erhalten. Einmal im Monat checke ich dann den ganzen Server.

    Leider wird z. B. auch die Seitenüberprüfung immer wieder auf "Torn Page Detection" geändert, auch wenn ich sie auf "Checksum" geändert habe.
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Montag, 17. November 2014 08:09
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christoph,

    das klingt ja schon mal nicht schlecht. Was genau hast du denn mit der richtlinienbasierten Verwaltung gemacht? Nur das Thema mit der Seitenüberprüfung?

    Was ist denn mit den Datenbanken, die ich schon ein paar Mal komplett verkleinert habe? Kann ich die durch deinen Index Rebuild wieder zu alter Performance bringen?

    Montag, 17. November 2014 15:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Alex,
    ich habe da verschiedene Richtlinien:
    1.) Generell sollte die LDF-Datei nicht größer als 2 GB sein. (Ist eher für die anderen DBs auf dem Server gedacht)
    2.) Generell sollte die LDF-Datei nicht größer als 500 MB sein. Für einzelne Datenbanken sind hier Ausnahmen für die Ziele explizit eingetragen.
    3.) Log File Growth für kleine Datenbanken. Setze das Wachstum für kleine LDFs auf 5 MB. Kleine Datenbanken sind über eine Bedingung mit <= 51200 KB definiert.
    4.) Log File Growth für andere Datenbanken. Setze das Wachstum für LDFs auf 50 MB. Datenbanken sind über eine Bedingung mit > 51200 KB definiert.
    5.) Seitenüberprüfung. Diese Regel überprüft, ob die PAGE_VERIFY-Datenbankoption auf CHECKSUM festgelegt ist. Wenn CHECKSUM für die PAGE_VERIFY-Datenbankoption angegeben wird, berechnet SQL Server Database Engine (Datenbankmodul) beim Schreiben der Seite auf den Datenträger eine Prüfsumme des Inhalts der gesamten Seite und speichert den Wert im Seitenkopf. Wenn die Seite vom Datenträger gelesen wird, wird die Prüfsumme erneut berechnet und mit dem im Seitenkopf gespeicherten Prüfsummenwert verglichen. Dadurch wird ein hohes Maß an Integrität der Datendateien bereitgestellt. http://technet.microsoft.com/de-de/library/ms190249.aspx

    Leider setzt die Software ständig die Seitenüberprüfung zurück, so dass man sich den Punkt eigentlich schenken kann. Die Entwickler wissen es mittlerweile und werden es ggf. in einer zukünftigen Version ändern.

    Ein Index Rebuild baut die Indizes neu auf und bringt Dir auch Deine Daten wieder in die richtige Reihenfolge, wenn sie fragmentiert sein sollten. Das bläht natürlich das Log und ggf. auch die Datenbank-Datei auf. Das Log kannst Du immer ohne Performance-Verlust kleiner machen. Das kostet dann aber Zeit, wenn es zu klein ist und regelmäßig wieder vergrößert werden soll. Hier also die automatischen Vergrößerungen im Auge behalten und gegen 0 optimieren.

    Zur internen Verwaltung der LDFs und ihre Auswirkungen auf den Serverneustart habe ich hier einiges zusammen getragen:
    http://www.insidesql.org/blogs/cmu/sql_server/schon-mal-von-vlfs-gehoert

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Dienstag, 18. November 2014 07:59
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden
    Klasse! Danke für eure Antworten.
    Dienstag, 18. November 2014 17:52
    |