Jump to content

SQL 2005 53GB ldf Datei


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Geschrieben

Hallo,

 

es ist auf dem SQL 2005 unter Verwaltung -> Wartungspläne einen Plan zur Sicherung des Transaktionslogs erstellt.

Ich ging immer davon aus, dass die ldf-Datei dann automatisch verkleinert wird?

Was mache ich falsch, bzw. wie kriege ich die ldf Datei denn kleiner?

 

Danke für HIlfe

Sebastian

Geschrieben

Moin,

 

kurze Ergänzung: Das Verkleinern der Datei würde ich nur machen, wenn es nötig ist. Wächst z.B. im Normalbetrieb die Logdatei sowieso wieder stark an, dann sollte man sie besser gleich groß lassen. Ist sie hingegen bereits klein, dann sollte man sie auch nicht per automatischem Task verkleinern.

 

Gruß, Nils

Geschrieben

Danke für Deine Antwort, nur leider komme ich da nicht ganz zurecht.

Wo und wie kann ich denn jetzt den Task zum shrinken der Logs einbauen?

Ich muss dazu sagen, dass ich den SQL Server nicht aufgesetzt habe und ich diesen so übernommen habe.

 

Danke und Grüße

Sebastian

post-51863-1356738985122_thumb.jpg

post-51863-13567389851419_thumb.jpg

Geschrieben

Ok, aber könnte der Zugriff auf SQL nicht schneller gehen wenn die Log Datei kleiner ist?

Wieviel größer darf die denn z.B. in einer Woche werden?

Und wie sieht es mit dem wiederherstellen aus, wenn ich vorher ein Backup gemacht habe und ich das Logfile dann verkleinere?

 

Grüße

Sebastian

Geschrieben
Ok, aber könnte der Zugriff auf SQL nicht schneller gehen wenn die Log Datei kleiner ist?

Sicher. Könnte nicht nur, er wird.

Wieviel größer darf die denn z.B. in einer Woche werden?

Das lässt sich so nicht beantworten. Das hängt ganz klar von der Art und Anzahl der Transaktionen auf deinem System ab.

Und wie sieht es mit dem wiederherstellen aus, wenn ich vorher ein Backup gemacht habe und ich das Logfile dann verkleinere?

Dafür hast du ja dann das Backup, oder? Grundlegende Backup und Restore-Szenarieren für den SQL Server sind dir bekannt? Wenn nein: Backing Up and Restoring Databases in SQL Server

 

Das Verkleinern der Datei würde ich nur machen, wenn es nötig ist. Wächst z.B. im Normalbetrieb die Logdatei sowieso wieder stark an, dann sollte man sie besser gleich groß lassen. Ist sie hingegen bereits klein, dann sollte man sie auch nicht per automatischem Task verkleinern.

Hier kann ich Nils leider nicht zustimmen, aber hieran scheiden sich immer wieder die Geister. :). Die Vergrößerung des Transaktionslog im laufenden Betrieb hängt sehr stark von Art und Anzahl der Transaktionen ab. Häufen sich bestimmte Peaks in Transaktionszahlen immer wieder mal, dann wird es unregelmäßig große Anstiege geben. Je nachdem ob das zutrifft oder nicht, würde ich das Transaktionslog immer im Rahmen des Wartungsplans mit verkleinern (übrigens in deinem zweiten Bild der Task direkt unter dem markierten, den einfach hinter den Backup-Task hängen ;) ). Zudem würde ich aber die initiale Größe des Transaktionslog auf einen gewissen Wert voreinstellen, so das die Datei zwar ggf. nach einem Backup leer ist, aber recht performant neu befüllt werden kann, weil der Platz auf den Platten bereit allokiert ist.

 

Gruß

Carsten

Geschrieben

Moin,

 

Sicher. Könnte nicht nur, er wird.

 

äh - nö. Zumindest nicht pauschal. Warum sollte er? Die Datei wird sequenziell beschrieben. Wenn sie nicht astronomische Größen annimmt, sollte das Ansteuern des Ansatzpunktes innerhalb der Datei nicht großartig unterschiedlich sein.

 

Das lässt sich so nicht beantworten. Das hängt ganz klar von der Art und Anzahl der Transaktionen auf deinem System ab.

 

Yepp.

 

Je nachdem ob das zutrifft oder nicht, würde ich das Transaktionslog immer im Rahmen des Wartungsplans mit verkleinern

 

Das kann nach hinten losgehen. Verkleinerst du eine große Datei, gibt SQL Server den Platz ans Dateisystem zurück, das ihn nach Gutdünken nutzt. Muss SQL Server nun neuen Platz allokieren, dann fordert er diesen beim Dateisystem an. Bei häufiger Vergrößerung und Verkleinerung leistet man so schnell der Fragmentierung Vorschub, was sich deutlich auf die Performance auswirken kann.

 

Zudem würde ich aber die initiale Größe des Transaktionslog auf einen gewissen Wert voreinstellen, so das die Datei zwar ggf. nach einem Backup leer ist, aber recht performant neu befüllt werden kann, weil der Platz auf den Platten bereit allokiert ist.

 

Was meiner Argumentation entspricht, warum ich nicht pauschal verkleinern würde. ;)

 

Gruß, Nils

Geschrieben

Guten Morgen und vielen Dank für die Antworten.

 

Ich habe nun beschlossen die Datenbank inkl. Logs erst mal nicht anzurühren und sie erst mal nur beobachten.

Bei diesem beobachten ist mir jetzt aufgefallen, dass die Sicherung der Transaktionslogs alle zwei Stunden immer ein neues *.trn File erstellt. Die neuen Files sind alle kleiner als das erste erstellte File und auch haben auch alle unterschiedliche Größen.

 

Grüße

Sebastian

Geschrieben

Moin,

 

stimmt ist erst mal eine Feststellung :D

Ich wollte aber eigentlich fragen, ob das so in Ordnung ist wenn jetzt bei jeder Sicherung ein neues File erstellt wird. Oder könnte ich ältere Backup Transaktionslogs einfach löschen?

 

Grüße

Sebastian

Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...