10
Datenbanken Transaction Logs laufen voll
Guten Morgen in die Runde,
ich spring mal wieder von Kriegsschauplatz zu Kriegsschauplatz. =)
Server: W2k12R2
Problemkinder:
Transaction Log File 1 = 109GB
Transaction Log File 2 = 41GB
Die restlichen 7 Transaction Log Files in Summe = 16GB
Wenn ich das richtig recherchiert habe ist das Truncate für das beräumen der Transaction Logfiles zuständig?
Das Backup funktioniert bis auf das bereinigen der Transaction Logs.
Hat einer eine zündende Idee?
VG
ich spring mal wieder von Kriegsschauplatz zu Kriegsschauplatz. =)
Server: W2k12R2
Problemkinder:
Transaction Log File 1 = 109GB
Transaction Log File 2 = 41GB
Die restlichen 7 Transaction Log Files in Summe = 16GB
Backup-SqlDatabase -DatabaseObject $_ -BackupFile $aPath$($_.NAME)_ldf.bak -BackupAction Log -LogTruncationType Truncate -CompressionOption On -InitializeWenn ich das richtig recherchiert habe ist das Truncate für das beräumen der Transaction Logfiles zuständig?
Das Backup funktioniert bis auf das bereinigen der Transaction Logs.
Hat einer eine zündende Idee?
VG
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 369533
Url: https://administrator.de/contentid/369533
Printed on: April 19, 2024 at 12:04 o'clock
10 Comments
Latest comment
Schonmal danke für den Link. (der kam hier bereits via Google vorbei =))
Im Trockentest läuft auch das Backup durch mit folgendem Log:
Die Zeile aus dem Ausgangspost oben ist immer der Transaction Zweig.
Das gesicherte Transactionlog CMDB_ldf.bak hat nur 31GB statt 109GB als ldf.
Warum bereinigt er das ldf nicht?
VG
Im Trockentest läuft auch das Backup durch mit folgendem Log:
08:33:22_4464060 | INF | Backup-Mode: BB
08:33:34_6951942 | TRY | Versuche Datenbank CMDB zu sichern.
08:34:01_5788989 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\CMDB_mdf.bak
08:34:01_5798989 | TRY | Versuche Transaction-Log CMDB zu sichern
08:41:30_3014154 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\CMDB_ldf.bak
08:41:30_3114123 | TRY | Versuche Datenbank ConfigDB zu sichern.
08:41:32_8695909 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\ConfigDB_mdf.bak
08:41:32_8705911 | TRY | Versuche Transaction-Log ConfigDB zu sichern
08:41:35_0937465 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\ConfigDB_ldf.bak
08:41:35_1037498 | TRY | Versuche Datenbank DiscoveryConfig zu sichern.
08:41:35_6507862 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\DiscoveryConfig_mdf.bak
08:41:35_6517855 | TRY | Versuche Transaction-Log DiscoveryConfig zu sichern
08:41:35_7157903 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\DiscoveryConfig_ldf.bak
08:41:35_7257908 | TRY | Versuche Datenbank LM_Recognition zu sichern.
08:41:43_1003103 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LM_Recognition_mdf.bak
08:41:43_1013077 | TRY | Versuche Transaction-Log LM_Recognition zu sichern
08:44:49_2373607 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LM_Recognition_ldf.bak
08:44:49_2433632 | TRY | Versuche Datenbank LMAsset zu sichern.
08:44:51_5175228 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMAsset_mdf.bak
08:44:51_5185232 | TRY | Versuche Transaction-Log LMAsset zu sichern
08:45:06_5565711 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMAsset_ldf.bak
08:45:06_5795742 | TRY | Versuche Datenbank LMContract zu sichern.
08:45:07_2966270 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMContract_mdf.bak
08:45:07_2976263 | TRY | Versuche Transaction-Log LMContract zu sichern
08:45:12_2149748 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMContract_ldf.bak
08:45:12_2279836 | TRY | Versuche Datenbank LMCore zu sichern.
08:45:12_8750215 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMCore_mdf.bak
08:45:12_8760176 | TRY | Versuche Transaction-Log LMCore zu sichern
08:45:20_4305459 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMCore_ldf.bak
08:45:20_4365469 | TRY | Versuche Datenbank LMCore_SessionState zu sichern.
08:45:21_0335889 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMCore_SessionState_mdf.bak
08:45:21_0345888 | TRY | Versuche Transaction-Log LMCore_SessionState zu sichern
08:45:46_1303485 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMCore_SessionState_ldf.bak
08:45:46_1363548 | TRY | Versuche Datenbank LMCore_TempDB zu sichern.
08:45:47_0234112 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMCore_TempDB_mdf.bak
08:45:47_0244115 | TRY | Versuche Transaction-Log LMCore_TempDB zu sichern
08:46:03_1865440 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMCore_TempDB_ldf.bak
08:46:03_1925447 | TRY | Versuche Datenbank LMLicence zu sichern.
08:46:06_3587670 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\LMLicence_mdf.bak
08:46:06_3597673 | TRY | Versuche Transaction-Log LMLicence zu sichern
08:46:13_8832950 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\LMLicence_ldf.bak
08:46:13_8892959 | TRY | Versuche Datenbank SM zu sichern.
08:48:26_2685762 | SUX | Datenbank wurde erfolgreich gesichert: G:\Backup.test\SM_mdf.bak
08:48:26_2695773 | TRY | Versuche Transaction-Log SM zu sichern
08:56:05_4727745 | SUX | Transaction-Log wurde erfolgreich gesichert: G:\Backup.test\SM_ldf.bak
Errorcode Datenbankbackups: 0Die Zeile aus dem Ausgangspost oben ist immer der Transaction Zweig.
Das gesicherte Transactionlog CMDB_ldf.bak hat nur 31GB statt 109GB als ldf.
Warum bereinigt er das ldf nicht?
VG
Hallo H41mSh1C0R,
prüfe mal ob die Log DB freien Platz hat.
dbcc sqlperf(logspace)
wenn ja, kannst du mittels:
USE [Deine_DB]
GO
DBCC SHRINKFILE (N'Deine_DB_log' , 10, TRUNCATEONLY)
GO
die Datei verkleinern.
Für das SQL Backup ist Hallogrens Script sehr hilfreich.
Update:
Wenn dein Log zu groß wird, solltest du das Transaktionslog in kürzeren Abständen sichern und verkleinern.
Ich habe das bei einer speziellen DB auf 30min stehen.
grüße vom it-frosch
prüfe mal ob die Log DB freien Platz hat.
dbcc sqlperf(logspace)
wenn ja, kannst du mittels:
USE [Deine_DB]
GO
DBCC SHRINKFILE (N'Deine_DB_log' , 10, TRUNCATEONLY)
GO
die Datei verkleinern.
Für das SQL Backup ist Hallogrens Script sehr hilfreich.
Update:
Wenn dein Log zu groß wird, solltest du das Transaktionslog in kürzeren Abständen sichern und verkleinern.
Ich habe das bei einer speziellen DB auf 30min stehen.
grüße vom it-frosch
Hallo IT-Frosch,
die Prüfung ergab das die Nutzung bei 9% der 109GB liegt.
Wenn ich das Shrinkfile versuche bekomme ich die Meldung
"Cannot shrink log file 2 (CMDB_log) because the logical log file located at the end of the file is in use."
*grad am googlen warum*
VG
die Prüfung ergab das die Nutzung bei 9% der 109GB liegt.
Wenn ich das Shrinkfile versuche bekomme ich die Meldung
"Cannot shrink log file 2 (CMDB_log) because the logical log file located at the end of the file is in use."
*grad am googlen warum*
VG
Hallo H41mSh1C0R,
du musst beim Shrink die id des Logfiles mit angeben.
Quelle:
https://stackoverflow.com/questions/7193445/dbcc-shrinkfile-on-log-file- ...
grüße vom it-frosch
du musst beim Shrink die id des Logfiles mit angeben.
Quelle:
https://stackoverflow.com/questions/7193445/dbcc-shrinkfile-on-log-file- ...
grüße vom it-frosch
Hallo,
ich glaub du hast da einen Denkfehler. Ein truncate bedeutet das er den Speicher im Transaktionslog bereinigt, nicht aber die Datei selbst verkleinert. Im Produktiv betrieb "schleift" sich irgendwann mal eine entsprechende Dateigröße ein. Es ist eher kontraproduktiv diese ständig tatsächlich zu verkleinern.
Grüße
ich glaub du hast da einen Denkfehler. Ein truncate bedeutet das er den Speicher im Transaktionslog bereinigt, nicht aber die Datei selbst verkleinert. Im Produktiv betrieb "schleift" sich irgendwann mal eine entsprechende Dateigröße ein. Es ist eher kontraproduktiv diese ständig tatsächlich zu verkleinern.
Grüße
Hi,
na immer muss die ja nicht verkleinert werden, aber wenn die 109GB nur zu 9% benutzt wird lohnt es jetzt auf jeden Fall, da die Storage Truppe mir hier sonst den Hahn abdrehen, wenn ich alle Nase lang um die Ecke komm ich hätte gern hier und da noch 20GB extra.
Ich bin erstmal dran das Shrinken/Umstellen auf Simple hinzubekommen. Noch mag es nicht, Stichwort "morroring session or availability group".
VG
na immer muss die ja nicht verkleinert werden, aber wenn die 109GB nur zu 9% benutzt wird lohnt es jetzt auf jeden Fall, da die Storage Truppe mir hier sonst den Hahn abdrehen, wenn ich alle Nase lang um die Ecke komm ich hätte gern hier und da noch 20GB extra.
Ich bin erstmal dran das Shrinken/Umstellen auf Simple hinzubekommen. Noch mag es nicht, Stichwort "morroring session or availability group".
VG
Das Shrinken hat funktioniert, nachdem ich den Mirror entfernt hatte.
Allerdings lässt sich nun der Mirror nicht mehr aufbauen.
Muss ich das Shrinken auf dem Mirror Server ebenfalls machen und dann den Mirror wieder herstellen?
VG
EDIT:
Laut Netz Backup ziehen, den auf dem Mirrorserver einspielen, dann den Mirror aufbauen.
Aber wie soll man verhindern das in den 15minuten keine neuen Transaktionslogs generiert werden?
Allerdings lässt sich nun der Mirror nicht mehr aufbauen.
Muss ich das Shrinken auf dem Mirror Server ebenfalls machen und dann den Mirror wieder herstellen?
VG
EDIT:
Laut Netz Backup ziehen, den auf dem Mirrorserver einspielen, dann den Mirror aufbauen.
Aber wie soll man verhindern das in den 15minuten keine neuen Transaktionslogs generiert werden?
Wenn das Wiederherstellungsmodell auf simple/einfach steht wird keines erzeugt.
