SQL2005 LOG Datei und Spiegelung

[Fips 10]

Hallo zusammen.

 

Ich habe folgendes Problem.

 

Bisher hatte ich eine 1,8 GB Datenbank und eine nur einpaar MB große log datei ldf.

Nun läuft die Datenbank auf 2 Servern als Spiegel mit dem Ergebnis das die Datenbankdatei immernoch 1,8 GB groß ist und die log Datei ldf nun nach 2 Wochen bereits 4 GB übersteigt. Ich sichere aber jeden Tag die Datenbank und das Transaktionsprotokoll.

 

Vorher stand die Datenbank auch im Modus Einfach und nun im Modus Vollständig. Aber da es sich um eine Spiegelung handelt kann ich die Datenbanken nicht in den Modus Einfach mehr stellen.

 

Hat da jemand eine Idee. Im Forum habe ich schon viele Einträge betreffend großer Log Dateien gefunden aber ich komme gerade damit nicht weiter.

 

MfG Fips

[NilsK 2.785]

Moin,

 

da das Mirroring auf dem Log Shipping beruht, kann das Log natürlich nicht laufend abgeschnitten werden. Das Recovery Model muss also "Full" sein.

 

Je nachdem, was in deiner Datenbank passiert, kann es durchaus sein, dass die Logdatei auf 4 GB anwächst. Sie wird ja linear beschrieben und nicht automatisch verkleinert - es kann also sein, dass die Datei zwar 4 GB belegt, real aber wesentlich weniger drinsteht (weil es z.B. zwischendurch mal einen Import oder eine Massenänderung gegeben hat).

 

Sicherst du das Transaktionsprotokoll über die SQL-Backupschnittstelle (also per BACUP LOG bzw. über einen geeigneten Agenten)? Dann wird es auch gekürzt, aber die Datei bleibt halt gleich groß.

 

Um die Datei zu verkleinern, kannst du ein DBCC SHRINKFILE absetzen (siehe Onlinehilfe) - das kann mehrfach erforderlich sein, weil möglicherweise der aktive Protokollteil zufällig gerade am Dateiende steht und dadurch keine Verkleinerung möglich ist.

 

Gruß, Nils

[Fips 10]

Das Backup der Datenbanken erfolgt über einen Wartungsauftrag.

Er zeigt mir auch an wenn ich auf Datei verkleinern gehe da von den 4 GB 3,8GB frei sind aber er gibt diese nicht an das system zurück.

 

Automatisch verkleinern steht auf true und dann ist das Backup normal wieder. bei einer anderen Datenbank hat er den freien Speicher auch wieder freigegeben.

 

Gruß Fips und danke schonmal.

[NilsK 2.785]

Moin,

 

Das Backup der Datenbanken erfolgt über einen Wartungsauftrag.

 

hm ... bevor man nichts macht, ist ein Wartungsvertrag besser. Allgemein stehe ich damit etwas auf Kriegsfuß, weil viel Unsinn drin vorkonfiguriert ist.

 

Er zeigt mir auch an wenn ich auf Datei verkleinern gehe da von den 4 GB 3,8GB frei sind aber er gibt diese nicht an das system zurück.

 

Nein, wie ich schon schrieb, wird das nicht automatisch getan.

 

Automatisch verkleinern steht auf true

 

Manipulationen der Dateien würde ich nicht automatisch vornehmen lassen. Zumal du damit der Fragmentierung Vorschub leistet: Die eine Automatik verkleinert die Datei, damit die andere sie beim nächsten Insert wieder vergrößert ...

 

bei einer anderen Datenbank hat er den freien Speicher auch wieder freigegeben.

 

Automatisch aus dem Log? Wusste gar nicht, dass die Automatik das macht. Aber wenn es bei der jetzigen DB nicht klappt, hast du wahrscheinlich die Pointer-Problematik. Versuch die Verkleinerung einfach nach ein paar Tagen noch mal.

 

Gruß, Nils

[phoenixcp 10]

Um die Datei zu verkleinern, kannst du ein DBCC SHRINKFILE absetzen (siehe Onlinehilfe) - das kann mehrfach erforderlich sein, weil möglicherweise der aktive Protokollteil zufällig gerade am Dateiende steht und dadurch keine Verkleinerung möglich ist.

Wobei hier der Erfolg ein wenig vom Versionsstand der SQL Server Engine abhängig ist. Bis Versionsstand 9.0.3200 (SQL 2005 + SP 2 + CUMULATIVER FIX KB941450) gab es scheinbar ein Problem beim freigeben von Speicherplatz durch den Shrinkprocessor.

Ab Versionsstand 9.0.3215 (SQL 2005 + SP 2 + CUMULATIVER FIX KB943656 (SRP 5)) funktioniert das dann wieder besser.

[Fips 10]

Okay dann werde ich mal ein paar Tage das beobachten.

 

Danke erstmal.

 

Gruß Fips