Thomas Bandt

Über mich | Kontakt | Archiv

SQL Server: Logfile effektiv killen

Über Shrinkfile hatte ich ja schon einmal geschrieben, allerdings hat das in einem späteren Fall leider auch nichts gebracht - die Platte war voll, das Logfile riesig.

Was 100% funktioniert, ist das hier:

dbcc shrinkfile(xyz_log, 2)
backup log xyz with truncate_only
dbcc shrinkfile(xyz_log, 2)

Danach bleibt kaum mehr was über. xyz steht für den Namen der Datenbank, xyz_log für den Namen des verwendeten Logfiles.

Kommentare

  1. GENiALi schrieb am Mittwoch, 18. April 2007 14:40:00 Uhr:

    Wieder einmal ein riesen Dank an dich. Genau zum richtigen Zeitpunkt ein ensprechendes Posting. :-)
    Sensationell.
  2. Herbert Held schrieb am Donnerstag, 19. April 2007 11:56:00 Uhr:

    Das Problem kenn ich. Mir hat dieser Link geholfen http://www.insidesql.de/beitraege/administration/alle_benutzerdatenbanken_auf_einmal_verkleinern.html

    Dieses Script hab ich auf die Logfiles angepasst und im Sql Server-Agent als Auftrag gesetzt.

    Aber warum gibt du dbcc shrinkfile(xyz_log, 2)
    2 mal an? Halte den ersten für überflüssig!
  3. Hans Pickelmann schrieb am Samstag, 21. April 2007 01:04:00 Uhr:

    Weiß nicht ob dies auf einem Produktivsystem bei dem das Transaction-Protokol ja seine Bestimmung haben wird so sinnvoll ist. Den mit der im SQL-Server 2005 schon als obsolet markierten Funktion und in der nächsten Version von SQL Server nicht mehr unterstützten Funktion "truncate_only" schmeißt du dieses Log-File aus der Sicherungsprotokollkette. Und das "hardcore shrinken" ist auch nicht die feine Art mit der DB umzugehen.
    Warum es im ersten Artikel von dir nicht den gewünschten Erfolg brachte wird wohl daran liegen, dass im Logfile zu wenig „inaktiv“ markierte Einträge vorhanden waren als neue hinzu kamen und somit das File immer weiter gewachsen ist. Hier hätte normalerweise ein Backup des Logfiles wieder genügend Einträge „freigegeben“.

    Ich bin dazu übergegangen die DB lieber etwas größer zu lassen und kein Verkleinern und Abschneiden an ihr vorzunehmen... also nur ein regelmäßiges (kann auch stündlich sein) normales Backup der Log-Datei und des Weiteren in gewissen Abständen ein Vollbackup der DB.
    Hat bei mir den Effekt, dass die jeweilige Größe der DB bzw. des Logfiles nahezu konstant bleibt und die Indizes nicht immer wieder "rebuilded" werden müssen bzw. durchs shrinken fragmentieren was sich dann wiederum übel auf die Performance der DB auswirken kann.


« Zurück  |  Weiter »