ich habe hier ein Problem, dass ich mir nicht erklären kann. Seit dem 01.02.2010 werden anscheiend die LOGs auf den SQL-Servern nicht mehr auto. gekürzt. An diesem Tage wurde "nur" ein IE8 Patch installiert, nichts SQL relevantes.
Das SQL Studio zeigt mir schön wann die letzte Datenbank- bzw Logsicherung war, allerdings werden die LOGs nicht abgeschnitten. Ich kann natürlich händisch rangehen, aber das ist ja keine Lösung.
Soweit ich weiß, wurde an den SQL nicht gemacht bis auf das IE-Patch. Gesichert wird mit BackupExec, da wurde kein Patch installiert, davon abgesehen schneidet ja nicht BackupExec die LOGs ab sondern der SQL-Server, BE markiert nur die LOGs zum abschneiden.
Hat jemand einen Einfall, was hier schief laufen könnte.
BackupExec-Logs sind grün, deshalb habe ich den Anwuchs der LOG-Files auch gar nicht bemerkt.
Event-Log für o.g. DB (LOG-Backup):
Das Protokoll wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), Erste LSN: 508:11530:1, Letzte LSN: 508:15399:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'DB1_00__8f98ee60_a19b_4bd3_830d_8a66235d5033_'}). Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.
Event-Log für o.g. DB (Full-Backup):
Der E/A-Vorgang für die DB1-Datenbank hängt. Es ist keine Benutzeraktion erforderlich. Wenn der E/A-Vorgang jedoch nicht umgehend fortgesetzt wird, sollten Sie die Sicherung möglicherweise abbrechen.
gefolgt von:
Der E/A-Vorgang für die DB1-Datenbank wurde fortgesetzt. Es ist keine Benutzeraktion erforderlich.
gefolgt von:
Die Datenbank wurde gesichert. Datenbank: DB1, Erstellungsdatum(-zeit): 2009/09/09(15:54:14), gesicherte Seiten: 1, Erste LSN: 508:11231:101, Letzte LSN: 508:11274:1, Anzahl der Sicherungsgeräte: 1, Geräteinformationen: (FILE=1, TYPE=VIRTUAL_DEVICE: {'BE_SQLAgent-DB1__30d4e15d_4b5e_40dd_997a_fe31fe33e7ac_'}).
sieht doch erst mal alles grün aus. Warum bist du denn der Ansicht, dass die Logs nicht abgeschnitten werden? Wenn es um das Anwachsen der Log-Dateien geht: Das ist normal, die verkleinern sich nicht von selbst (anders als bei Exchange!). Das Log wird immer sequenziell geschrieben, und erst wenn das Log abgeschnitten wurde (per Backup oder per Truncate), fängt SQL Server innerhalb der bestehenden Datei wieder am Anfang an.
Ich bin der Meinung, dass die LOGs sehr groß wurden, da auf beiden Server die LDF-Datei das Datum 01.02.2010 trug und auf einem Server 25 GB auf eine anderen 100 GB groß war.
Ich war der Meinung, dass SQL, ähnlich dem EX-Backup die LOGS auto. abschneidet.
Habe den Artikel noch nicht studiert, wenn ich den gelesen habe und noch Fragen habe, dann werde ich mich noch einmal hier melden.
die Logs können auch durchaus sehr groß werden, wenn viele Transaktionen laufen. Das können z.B. Imports sein, das Löschen großer Datenmengen oder auch Wiederholtes Ändern derselben Daten. Jede Transaktion muss SQL Server einzeln protokollieren.
Daher sollte man in Produktionsumgebungen auch a) die Loggröße überwachen und b) einen Task einrichten, der die Notbremse ziehen kann, indem er ab einem Schwellwert das Protokoll abschneidet und direkt danach eine Vollsicherung ausführt.
Wann das Log abgeschnitten wird, ist eindeutig bekannt: Beim Log-Backup. Punkt. Eine große Logdatei macht den Server nicht langsamer, denn er muss ohnehin alle Transaktionen protokollieren, darüber hinaus wird das Log sequenziell geschrieben. Schlechtes Log-Management kann den Server aber durchaus bremsen - etwa falsche Einstellungen zur Dateigröße, die dann ständige Vergrößerung erfordern bzw. Fragmentierung erzeugen.
Das "Notbremse-Skript" ist eigentlich simpel: Man erzeuge im SQL Agent einen Auftrag, der die Loggröße oder den freien Plattenplatz überwacht und bei Überschreiten einer Schwelle zwei Kommandos ausführt: 1. Abschneiden des Logs, 2. Full Backup der Datenbank.
Wenn man mit kritischen Datenbanken operiert, sollte man selbet Know-how dazu aufbauen oder sich extern unterstützen lassen. Eure Firmenwagen lasst ihr ja sicher auch warten.