6
SQL 2008 R2: Log-File Shrink
Moin,
unser Consultant sagte uns, dass die Log-Files auf unseren SQL-Server nicht verkleinert werden, wenn wir Backups machen.
Das ist leider so, da es (lt. Hersteller unserer Backuplösung) keine SQL-API gibt, die Block-basierte Backups unterstützt.
Nun wollte ich ein Skript erstellen, welches das manuell macht. Bin über Maintenance gegangen, weil das an sich für mich passend klang und habe dort einen neuen Maintenance Plan erstellt.
Dort habe ich je ein "Execute T-SQL Statement Task" erstellt für die jeweiligen Datenbanken:
Wenn ich dies dann ausführe, bekomme ich zwar kein Fehler, aber es passiert auch nicht wirklich was. Die Dateigröße verändert sich nicht.
Falsch gemacht? Muss ich das woanders einstellen?
Gruß
Jimpiet
unser Consultant sagte uns, dass die Log-Files auf unseren SQL-Server nicht verkleinert werden, wenn wir Backups machen.
Das ist leider so, da es (lt. Hersteller unserer Backuplösung) keine SQL-API gibt, die Block-basierte Backups unterstützt.
Nun wollte ich ein Skript erstellen, welches das manuell macht. Bin über Maintenance gegangen, weil das an sich für mich passend klang und habe dort einen neuen Maintenance Plan erstellt.
Dort habe ich je ein "Execute T-SQL Statement Task" erstellt für die jeweiligen Datenbanken:
USE WSS_Content;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE WSS_Content
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (WSS_Content_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE WSS_Content
SET RECOVERY FULL;
GOWenn ich dies dann ausführe, bekomme ich zwar kein Fehler, aber es passiert auch nicht wirklich was. Die Dateigröße verändert sich nicht.
Falsch gemacht? Muss ich das woanders einstellen?
Gruß
Jimpiet
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 245102
Url: https://administrator.de/forum/sql-2008-r2-log-file-shrink-245102.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
für mal das ganze manuell aus ohne Taskplaner
aber mal ganz unabhängig davon. Beim SQL sollte man meiner Meinung nach zusätzlich zu der externen Backup Software die SQL Interne Sicherung verwenden.
Bei mir läuft stündlich eine Transaktionslog Sicherung und 2x Täglich eine Vollsicherung.
für mal das ganze manuell aus ohne Taskplaner
aber mal ganz unabhängig davon. Beim SQL sollte man meiner Meinung nach zusätzlich zu der externen Backup Software die SQL Interne Sicherung verwenden.
Bei mir läuft stündlich eine Transaktionslog Sicherung und 2x Täglich eine Vollsicherung.
Hallo,
Hat der auch einen Namen bzw. das Produkt einen?
In welchen Wiederherstellungsmodus laufen deine SQL Instanzen?
Für den Anfang mal hier Lesen
http://technet.microsoft.com/de-de/library/ms178037(v=sql.105).aspx
http://help.fogcreek.com/8686/how-to-shrink-sql-server-transaction-logs
Gruß,
Peter
Hat der auch einen Namen bzw. das Produkt einen?
In welchen Wiederherstellungsmodus laufen deine SQL Instanzen?
keine SQL-API gibt, die Block-basierte Backup unterstützt.
?!? Was willst du uns damit sagen? Ob Dateibasierend oder Blockbasierend, ist nicht der Auslöser, und vollkommen wurscht. Wichtig ist ob diese überhaupt SQL Aware ist und und und.Bin über Maintenance gegangen,
Erzeuge dort eine Sicherungsjob und alles wird gut, allerdings wie schon gefragt "Was ist dein Wiederherstellungsmodus der einzelnen Instanzen?" Tipp: Simple sollte reichen.-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (WSS_Content_Log, 1);
Sind denn alle Voraussetzungen für ein Shrinkfile gegeben?DBCC SHRINKFILE (WSS_Content_Log, 1);
Für den Anfang mal hier Lesen
http://technet.microsoft.com/de-de/library/ms178037(v=sql.105).aspx
http://help.fogcreek.com/8686/how-to-shrink-sql-server-transaction-logs
Gruß,
Peter
N'Abend.
Ein Logfile einer SQL-Datenbank zu shrinken ist ziemlich unsinnig, wenn das Wiederherstellungsmodell der Datenbank nicht auf "EInfach" steht; steht dort "Vollständig", wird das Logfile immer wieder anwachsen, daher ist das einfach nur Resourcenverschwendung.
Plane über die Maintenance eine Transaktionsprotokoll-Sicherung, dadurch werden die Einträge im Logfiles ins Backup geschrieben und aus dem Log gelöscht; dadurch wird zwar die Datei nicht kleiner, aber sie wächst auch nicht mehr wirklich an (bzw. nur sehr langsam, immer angenommen, die Nutzung der Datenbank verändert sich nicht drastisch).
Cheers,
jsysde
Ein Logfile einer SQL-Datenbank zu shrinken ist ziemlich unsinnig, wenn das Wiederherstellungsmodell der Datenbank nicht auf "EInfach" steht; steht dort "Vollständig", wird das Logfile immer wieder anwachsen, daher ist das einfach nur Resourcenverschwendung.
Plane über die Maintenance eine Transaktionsprotokoll-Sicherung, dadurch werden die Einträge im Logfiles ins Backup geschrieben und aus dem Log gelöscht; dadurch wird zwar die Datei nicht kleiner, aber sie wächst auch nicht mehr wirklich an (bzw. nur sehr langsam, immer angenommen, die Nutzung der Datenbank verändert sich nicht drastisch).
Cheers,
jsysde
@wiesi200:
Manuell funktioniert das tatsächlich ohne Probleme
@Pjordorf:
Es handelt sich bei der Backup-Lösung um Catalogic DPX (ehemals Syncsort).
Voraussetzungen sind ja erfüllt, da es, manuell ausgeführt, funktioniert.
@jsysde:
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die "Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu verlieren.
Manuell funktioniert das tatsächlich ohne Probleme
@Pjordorf:
Es handelt sich bei der Backup-Lösung um Catalogic DPX (ehemals Syncsort).
Voraussetzungen sind ja erfüllt, da es, manuell ausgeführt, funktioniert.
@jsysde:
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die "Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu verlieren.
Zitat von @JimPiet:
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die
"Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu
verlieren.
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die
"Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu
verlieren.
Dann solltest du aber für den "Worst-Case" einen vernünftigen Wartungsplan mit mehreren Sicherungen einrichten und nicht den "Blödsinn" mit Shrink File.
N'Abend.
Habe ja auch nirgendwo das Gegenteil behauptet, diente nur zur Erklärung, warum das Shrinken eines Logfiles blödsinnig ist.
Cheers,
jsysde
@jsysde:
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die
"Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu
verlieren.
Da es sich bei dem System um den Forefront Identity Manger handelt und dieser einmal täglich gesichert wird, halte ich die
"Full" Option besser geeignet, als möglicherweise (im Worst-Case) einen kompletten Tag des Datenbestandes zu
verlieren.
Habe ja auch nirgendwo das Gegenteil behauptet, diente nur zur Erklärung, warum das Shrinken eines Logfiles blödsinnig ist.
Cheers,
jsysde
