Benutzer mit den meisten Antworten
Transaktionsprotokolle werden nach dem Backup mit Backup Exec nicht gekürzt

Frage
-
Sehr geehrte Damen und Herren,
mit Backup Exec 2016 sichere ich 4 Datenbanken SQL Server 2012 (SP4). Alle Datenbanken sind im Wiederherstellungsmodus "Vollständig". Ich sichere einmal am Tag komplett (03:00) und alle 4 Stunden (von 06.00 - 18:00) die Transaktionslogs.Im Backup Exec SQL Server Agent ist Transaktionsprotokoll sichern und kürzen eingestellt.
Leider werden sehr oft die Transaktionslogs nach dem Sichern nicht gekürzt und die Speicher laufen voll.
Selbst ein manuelles DBCC SHRINKFILE verkleinert das Protokoll nicht. Ich muss die Datenbank immer erst in den Wiederherstellungsmodus "einfach" bringen, dann das Protokoll kürzen und wieder auf "Vollständig" zurück stellen.Das mache ich nun schon ca. 4 Jahre so.
Das kann doch aber keine Dauerlösung sein.
Ist jemanden das Problem bekannt? Was ist die Ursache? Gibt es eine Lösung dafür?Das gleicher Verhalten hatte ich übrigens unter SQL Server 2008R2 auch schon.
Ich hatte eigentlich gehofft, dass das Problem mit dem Update auf 2012 verschwindet.
So langsam nervt mich das und es sollte eine Lösung her.
Antworten
-
Hallo,
Damit hast du deine Erklärung. Der Index Rebuild geht vollständig ins Transaktionslog. Wenn du den Index Rebuild machen willst wird deine Log Datei immer auf diese Größe wachsen. Dann musst du die Logs so groß lassen weil sie ja sowieso immer auf diese Größe springen werden.
Ich würde dir die Wartungsskripte von Ola Hallengren empfehlen. Die prüfen vorweg ob ein Rebuild notwendig ist und vermindern so das Transaktionsvolumen im Log.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 08:57
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
Hallo,
Damit hast du deine Erklärung. Der Index Rebuild geht vollständig ins Transaktionslog. Wenn du den Index Rebuild machen willst wird deine Log Datei immer auf diese Größe wachsen. Dann musst du die Logs so groß lassen weil sie ja sowieso immer auf diese Größe springen werden.
Ich würde dir die Wartungsskripte von Ola Hallengren empfehlen. Die prüfen vorweg ob ein Rebuild notwendig ist und vermindern so das Transaktionsvolumen im Log.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
Hallo,
dann ist aber immer noch unklar, warum die Logfiles sich dann nicht verkleinern lassen.
Das sollte dann doch auf jeden Fall nach dem Indexrebuild funktionieren. Kann man das irgendwie abfragen, welche Transaktion da noch offen ist und anscheinend dir Verkleinerung blockiert?
Vielen Dank für die Wartungsskripte, schaue ich mir auf jeden Fall an!
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
Da hast du glaube ich was falsch verstanden. Bei einer Log Sicherung wird der Inhalt der Log Datei gesichert. Wenn du nur 5 MB Datenvolumen in der Datei vom 100 GB hast, dann werden auch nur 5 MB und etwas Beiwerk gesichert. Du sicherst hier nicht die physische Datei sondern nur den tatsächlichen Transaktionsinhalt welcher seit der letzten Sicherung angefallen ist. Je häufiger du sicherst desto kleiner werden deine Log Sicherungen. Wenn du dir die TRN Dateien ansiehst werden diese in der Regel deutlich kleiner sein als die Transaktionslog Datei.
Es sei denn du hast irgendein unfähiges Drittanbietertool im Einsatz welches zu dumm ist eine richtige Sicherung zu machen und statt dessen einen VSS Sicherung der Log Datei macht.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 10:10
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 10:40
Alle Antworten
-
Hallo
Sichere das Log deutlich öfter. Mindestens einmal die Stunde und auch rund um die Uhr.
Ein Backup leert das Log ohne die Datei zu verkleinern. Es macht keinen Sinn das Log ständig zu verkleinern. Wenn es immer wächst dann sicherst du zu selten oder deine Vorgabe ist viel zu klein gewählt für das Transaktionsvolumen.
Wenn es nicht geleert wird, dann hast du noch offene Transaktionen welche verhindern, dass die Logs geleert werden können. Hast du mal geprüft wie alte deine älteste Transaktion ist?
Wie Groß ist denn das Transaktionslog und wie sind die Wachstumseinstellungen für das LOG?
Was meinst du genau mit "Backup Exec"? Hast du einen Wartungsplan oder ein Backup Skript? Poste doch mal ein Bild oder den Skript Text hier.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 07:59
-
Hallo Benjamin,
danke für Deine Antwort
>Sichere das Log deutlich öfter. Mindestens einmal die Stunde und auch rund um die Uhr.
Ok ich werde das ausprobieren.
ich habe im Moment folgende Einstellungen:
Anfangsgröße 500 MB -> Erweiterung 100 MB bis 2097152 MB beschränkt.
Im Normalfall ist die größe des Logs je nach Datenbank so zwischen 2 und 3 GB.
Im Problemfall wachsen die Logs bis auf 25 GB sind aber eigentlich leer.
>Wenn es nicht geleert wird, dann hast du noch offene Transaktionen, welche verhindern, dass die Logs >geleert werden können.
Ich kann mir nicht vorstellen, dass es noch offene Transaktionen geben soll. Kann man das irgendwie ermitteln und den Verursacher herausfinden?
-
Hallo
ist dieses extreme Wachstum regelmäßig zu bestimmten Zeiten? Oder gibt es zum Beispiel Nachts irgendwelche geplanten Aufgaben wie Index Wartung oder andere ETL Prozesse die viele Daten laden/verändern?
Wie Groß ist denn die eigentliche Datenbank die zum dem Transaktionslog gehört.
Führe mal das folgende Skript aus und poste das Ergebnis
/*============================================================================ File: 001 - A06 - System Environment - SQL Agent Job Information.sql Summary: This script gives you an overview of the current value of the PLE Date: June 2015 Session: Analysis of a Microsoft SQL Server SQL Server Version: 2008 / 2012 / 2014 ------------------------------------------------------------------------------ Written by Uwe Ricken, db Berater GmbH This script is intended only as a supplement to demos and lectures given by Uwe Ricken. THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. ============================================================================*/ USE master; GO-- Get SQL Server Agent jobs and Category information (Query 4) (SQL Server Agent Jobs) SELECT sj.name AS [JobName], sj.[description] AS [JobDescription], SUSER_SNAME(sj.owner_sid) AS [JobOwner], sj.date_created, sj.[enabled], sj.notify_email_operator_id, sc.name AS [CategoryName] FROM msdb.dbo.sysjobs AS sj INNER JOIN msdb.dbo.syscategories AS sc ON (sj.category_id = sc.category_id) ORDER BY sj.name OPTION (RECOMPILE); GO
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012 -
Hallo
ist dieses extreme Wachstum regelmäßig zu bestimmten Zeiten? Oder gibt es zum Beispiel Nachts irgendwelche geplanten Aufgaben wie Index Wartung oder andere ETL Prozesse die viele Daten laden/verändern?
Ja, jeden 2. Tag werden Nachts die Statistiken erneuert und die Indexe neu erstellt.
Ist vielleicht ein bisschen oft, schafft aber eine gute Perfomance.
Die Datenbanken ansich sind 6, 27, 32 und 56 GB groß.
-
Hallo,
Damit hast du deine Erklärung. Der Index Rebuild geht vollständig ins Transaktionslog. Wenn du den Index Rebuild machen willst wird deine Log Datei immer auf diese Größe wachsen. Dann musst du die Logs so groß lassen weil sie ja sowieso immer auf diese Größe springen werden.
Ich würde dir die Wartungsskripte von Ola Hallengren empfehlen. Die prüfen vorweg ob ein Rebuild notwendig ist und vermindern so das Transaktionsvolumen im Log.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 08:57
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
Hallo,
Damit hast du deine Erklärung. Der Index Rebuild geht vollständig ins Transaktionslog. Wenn du den Index Rebuild machen willst wird deine Log Datei immer auf diese Größe wachsen. Dann musst du die Logs so groß lassen weil sie ja sowieso immer auf diese Größe springen werden.
Ich würde dir die Wartungsskripte von Ola Hallengren empfehlen. Die prüfen vorweg ob ein Rebuild notwendig ist und vermindern so das Transaktionsvolumen im Log.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
Hallo,
dann ist aber immer noch unklar, warum die Logfiles sich dann nicht verkleinern lassen.
Das sollte dann doch auf jeden Fall nach dem Indexrebuild funktionieren. Kann man das irgendwie abfragen, welche Transaktion da noch offen ist und anscheinend dir Verkleinerung blockiert?
Vielen Dank für die Wartungsskripte, schaue ich mir auf jeden Fall an!
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
-
Man kann das Transaktionslog nur dann verkleinern wenn der aktive Teil des Transaktionslog gerade am Anfang der Log Datei ist. Wenn die Daten noch am Ende der Datei stehen, kann man das Log nicht verkleinert werden.
https://technet.microsoft.com/en-us/library/ms179355(v=sql.105).aspx
Indem du das Wiederhstellungsmodell auf Simple stellst werden die vorhandenen Log Einträge verworfen und das Log ist frei zum verkleinern. Dadurch verlierst du aber jede Möglichkeit der Point-in-Time Recovery
Zudem würde ich in deinem Fall das Log nicht verkleinern, da es ja sowieso durch den Rebuild wachsen muss. Und eine Log Sicherung wird niemals das Log als Datei verkleinern. Die Große bleibt immer gleich.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 09:53
-
Man kann das Transaktionslog nur dann verkleinern wenn der aktive Teil des Transaktionslog gerade am Anfang der Log Datei ist. Wenn die Daten noch am Ende der Datei stehen, kann man das Log nicht verkleinert werden.
https://technet.microsoft.com/en-us/library/ms179355(v=sql.105).aspx
Zudem würde ich in deinem Fall das Log nicht verkleinern, da es ja sowieso durch den Rebuild wachsen muss. Und eine Log Sicherung wird niemals das Log als Datei verkleinern. Die Große bleibt immer gleich.
Ok verstanden. Das Problem was sich mir dann stellt ist, dass ich dann stündlich bei der Sicherung der Logfiles 100 GB Daten über das Netz ziehen muss. Das ist auch der Hauptgrund, warum ich die Dateien überhaupt verkleinern möchte.
Sollte man das dann in Kauf nehmen?
-
Da hast du glaube ich was falsch verstanden. Bei einer Log Sicherung wird der Inhalt der Log Datei gesichert. Wenn du nur 5 MB Datenvolumen in der Datei vom 100 GB hast, dann werden auch nur 5 MB und etwas Beiwerk gesichert. Du sicherst hier nicht die physische Datei sondern nur den tatsächlichen Transaktionsinhalt welcher seit der letzten Sicherung angefallen ist. Je häufiger du sicherst desto kleiner werden deine Log Sicherungen. Wenn du dir die TRN Dateien ansiehst werden diese in der Regel deutlich kleiner sein als die Transaktionslog Datei.
Es sei denn du hast irgendein unfähiges Drittanbietertool im Einsatz welches zu dumm ist eine richtige Sicherung zu machen und statt dessen einen VSS Sicherung der Log Datei macht.
Benjamin Hoch
MCSE: Data Platform & Data Management and Analytics
MCSA: SQL Server 2012/2014 & 2016 DB Administration
MCSA: Windows Server 2012
- Bearbeitet Benjamin.Hoch Montag, 18. Dezember 2017 10:10
- Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 10:40
-
Da hast du glaube ich was falsch verstanden. Bei einer Log Sicherung wird der Inhalt der Log Datei gesichert. Wenn du nur 5 MB Datenvolumen in der Datei vom 100 GB hast, dann werden auch nur 5 MB und etwas Beiwerk gesichert. Du sicherst hier nicht die physische Datei sondern nur den tatsächlichen Transaktionsinhalt welcher seit der letzten Sicherung angefallen ist. Je häufiger du sicherst desto kleiner werden deine Log Sicherungen. Wenn du dir die TRN Dateien ansiehst werden diese in der Regel deutlich kleiner sein als die Transaktionslog Datei.
Es sei denn du hast irgendein unfähiges Drittanbietertool im Einsatz welches zu dumm ist eine richtige Sicherung zu machen und statt dessen einen VSS Sicherung der Log Datei macht
Du hast Recht, das habe ich wirklich falsch verstanden. Asche auf mein Haupt.
Ich benutze den BackupExec SQL Server Agent. Leider ist die Sicherung nicht wirklich transparent, da man die Sicherungsdateien nicht zu Gesicht bekommt.
Aber anhand der Datenmenge im Sicherungsprotokoll konnte ich Deine Ausführung von Oben nachvollziehen. Es wird wirklich immer nur der Transaktionsinhalt gesichert. Nach dem Rebuild der Indexe waren das mal 13 GB, sonst sind es immer wesentlich weniger Daten.
Gut das habe ich jetzt verstanden, also macht es wirklich keinen Sinn die Logdateien ständig zu verkleinern.
Jetzt ägere ich mich, dass ich erst so spät bei Euch nachgefragt habe.
Vielen Dank!
- Bearbeitet Bl0ckS1z3 Montag, 18. Dezember 2017 10:41