Hallo DP-Gemeinde.
Ich kapiere eine Sache nicht im MSSQL von M$. (Ob das in dieses Board gehört ... bitte verschieben, wenn nötig)

Der MSSQL-Server legt neben der MDF-Datei ein Transaktions-Log-File an. Okay. Das kenne ich.
Allerdings wird dieses LogFile immer großer.

Es ist doch aber ein Transaktions-Log, in dem alle Änderungen an der DB geloggt werden, richtig?
Wenn man die DB Offline schaltet, oder auch wenn man ein Backup startet, sollten doch alle Transaktionen in die MDF übernommen werden. Und zwar so, dass alle Transaktionen endgültig sind und somit das Log-File eigentlich nichts mehr beinhalten sollte.

Wieso ist dann das Log-File immernoch (bei meinen Kunden) doppelt so groß, wie die eigentliche MDF?
Ich rede hier vom 65 GB MDF gegen 118 GB Log-File (ursprünglich 238 GB), und ich kriege diese Log-File nicht kleiner.

Ich habe schon einige Webseiten durchgelesen, denn Sinn und Aufbau des Log-File reingezogen und u.a. mit DBCC SHRINKFILE rumhandiert, es ändert sich nichts. Es wird nicht kleiner.
In meinem Verständnis sollte doch dieses Log-File irgendwann mal gegen 0 MB tendieren, wenn alle Transaktionen in der MDF eingearbeitet sind, oder nicht?

Ich lasse die MDF- und LOG-Files jedes Wochenende auf einem RDX-Laufwerk (500GB) sichern. Aber so langsam wird diese Platte zu klein (kommen ja auch noch andere Sachen drauf), wenn da ein 238 GB Logfile mitgesichert werden muß.

Wie händelt Ihr das? Oder , wo liegt mein Denk-Fehler?

Deine Sicherung ist nicht richtig eingestellt.
Ich bin hier keine DB-Admin-Spezialist, aber auch das Transaktions-Log sollte mit "Shrink-Option" gesichert werden

https://www.mssqltips.com/sqlservert...ansaction-log/


[OT]65 GB Nutzdaten zu 118 GB Log-Daten ist ja gar nix.
Ich hatte schon 2 GB Nutzdaten zu 500 GB Log-Daten[/OT]

Danke Bernhard,

Über die SSMS-Gui hatte ich das schon probiert. So habe ich das LOG von 238GB auf 118GB runter bekommen.
Das Log-File direkt mit DBCC SHRINKFILE zu verkleinern, auf die Idee bin ich garnicht gekommen. Bin auch nicht davon ausgegangen, dass das überhaupt funktioniert.
Tut es aber. Cool! 1 MB groß.

Interessanter Weise, konnte ich das Log-File auch "einfach" umbenennen/löschen.
- Shrinken im SSMS
- DB "ausklinken"
- im Filesystem das Log-File umbenennen
- im SSMS die DB wieder anhängen (Fehlermeldung, dass das Log-File fehlt, akzeptieren) und ein neues Log-File festlegen
Der MSSQL stört sich nicht daran.

Lässt man das Shrinken weg, kriegt man die DB i.a.R. nicht mehr hoch.
Wenn man dann das Log-File bereits gelöscht hat, hat man Probleme. Dann hilft nur noch das Backup.

Wenn sich doch aber das Log-File so einfach auf 1 MB shrinken lässt, wieso tut es dann das SSMS nicht?

'n bissl mulmig is mir schon dabei
Mal schaun, ob die Kunden-DB noch läuft und wie lange

Hier hast du eine gute Zusammenfassung zu dem Thema:
https://blog.atwork.at/post/2011/03/...tabase-is-full

Und Best Practice dazu:
https://www.insidesql.org/blogs/fran...fuer-log-files

Wenn das Recovery model auf "FULL" für die Datenbank steht, dann bleibt der Platz in der LOG reserviert, bis eine Sicherung durchgeführt wurde. Dann bleibt die Datei zwar gleich groß, der Platz in der Datei wird aber wieder genutzt. Mit Shrink kann dann eine gesicherte Datei auch wieder verkleinert werden.

Wenn das Recovery model auf "SIMPLE" steht, dann wird Datei nur genutzt so lange Transaktionen laufen. Wird die Datei größer durch eine große Transaktion, behält die Datei die Größe, allerdings kann nach den Transaktion der Platz direkt wieder genutzt werden.

Ach ja, es gibt einen kleinen Bug in machen SQL-Servern.
Da lässt sich die Datei nicht (mehr) Shrinken, weil er sagt, dass die Datei bereits geshrinkt wird, obwohl kein Shrink läuft. In dem Fall dann einfach die Datei 1 MByte größer machen und dann erneut Shrinken.