jimpiet
Goto Top

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:

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;
GO

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

Content-ID: 245102

Url: https://administrator.de/contentid/245102

Ausgedruckt am: 22.11.2024 um 13:11 Uhr

wiesi200
wiesi200 30.07.2014 um 17:36:44 Uhr
Goto Top
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.
Pjordorf
Pjordorf 30.07.2014 um 18:54:44 Uhr
Goto Top
Hallo,

Zitat von @JimPiet:
(lt. Hersteller unserer Backuplösung)
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?

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
jsysde
jsysde 30.07.2014 um 22:01:36 Uhr
Goto Top
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
JimPiet
JimPiet 31.07.2014 um 08:22:22 Uhr
Goto Top
@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.
wiesi200
wiesi200 31.07.2014 um 09:58:43 Uhr
Goto Top
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.

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.
jsysde
jsysde 31.07.2014 um 18:49:36 Uhr
Goto Top
N'Abend.
@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.

Habe ja auch nirgendwo das Gegenteil behauptet, diente nur zur Erklärung, warum das Shrinken eines Logfiles blödsinnig ist.

Cheers,
jsysde