none
Transaktionsprotokolle werden nach dem Backup mit Backup Exec nicht gekürzt RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    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.

    Montag, 18. Dezember 2017 07:48
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    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.

    https://ola.hallengren.com/

    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
    Montag, 18. Dezember 2017 08:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Kann man das irgendwie ermitteln und den Verursacher herausfinden?

    Das kannst Du mit grundsätzlich erst mal mit dieser Abfrage prüfen:

    select name, log_reuse_wait_desc
from sys.databases

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
    Montag, 18. Dezember 2017 09:34
    |
  • Question
    Anmelden
    0
    Anmelden

    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.

    https://ola.hallengren.com/

    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
    Montag, 18. Dezember 2017 09:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Kann man das irgendwie ermitteln und den Verursacher herausfinden?

    Das kannst Du mit grundsätzlich erst mal mit dieser Abfrage prüfen:

    select name, log_reuse_wait_desc
from sys.databases

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Hallo Olaf,

    Ok, super probier ich gleich mal aus....

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
    Montag, 18. Dezember 2017 09:39
    |
  • Question
    Anmelden
    0
    Anmelden

    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
    Montag, 18. Dezember 2017 10:08
    |
  • Question
    Anmelden
    0
    Anmelden
    Seit SQL Server 2008 R2 kann man auch in der Standard Edition Backup Komprimierung verwenden, das spart auch Platz.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 11:21
    Montag, 18. Dezember 2017 10:57
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    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



    Montag, 18. Dezember 2017 07:55
    |
  • Question
    Anmelden
    0
    Anmelden

    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?

    Montag, 18. Dezember 2017 08:04
    |
  • Question
    Anmelden
    0
    Anmelden

    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

    Montag, 18. Dezember 2017 08:13
    |
  • Question
    Anmelden
    0
    Anmelden

    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ß.

    Montag, 18. Dezember 2017 08:24
    |
  • Question
    Anmelden
    0
    Anmelden

    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.

    https://ola.hallengren.com/

    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
    Montag, 18. Dezember 2017 08:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Kann man das irgendwie ermitteln und den Verursacher herausfinden?

    Das kannst Du mit grundsätzlich erst mal mit dieser Abfrage prüfen:

    select name, log_reuse_wait_desc
from sys.databases

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
    Montag, 18. Dezember 2017 09:34
    |
  • Question
    Anmelden
    0
    Anmelden

    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.

    https://ola.hallengren.com/

    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
    Montag, 18. Dezember 2017 09:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Kann man das irgendwie ermitteln und den Verursacher herausfinden?

    Das kannst Du mit grundsätzlich erst mal mit dieser Abfrage prüfen:

    select name, log_reuse_wait_desc
from sys.databases

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Hallo Olaf,

    Ok, super probier ich gleich mal aus....

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 09:39
    Montag, 18. Dezember 2017 09:39
    |
  • Question
    Anmelden
    0
    Anmelden

    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


    Montag, 18. Dezember 2017 09:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Was bedeutet der Status LOG_BACKUP?

    Montag, 18. Dezember 2017 09:52
    |
  • Question
    Anmelden
    0
    Anmelden

    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?

    Montag, 18. Dezember 2017 10:03
    |
  • Question
    Anmelden
    0
    Anmelden

    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
    Montag, 18. Dezember 2017 10:08
    |
  • Question
    Anmelden
    0
    Anmelden

    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
    Montag, 18. Dezember 2017 10:40
    |
  • Question
    Anmelden
    0
    Anmelden
    Seit SQL Server 2008 R2 kann man auch in der Standard Edition Backup Komprimierung verwenden, das spart auch Platz.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert Bl0ckS1z3 Montag, 18. Dezember 2017 11:21
    Montag, 18. Dezember 2017 10:57
    |