none
Schnell wachsendes Backup

    Frage

  • Hallo an alle,

    ich habe folgendes Problem.
    Ich habe eine Email von unserem Backupbeauftragten bekommen wo folgendes Problem geschildert wird:

    Seit dem 11.08. das CIC Backup doppelt so groß ist (über 800 GB) und dem entsprechend auch doppelt so lange läuft.Die IC-DB hatte am 10.08. eine Größe von 305 GB und wuchs vorher auch recht beschaulich auf diese Größe (ca. 2 GB/Woche). Am 11.08. hatte sie plötzlich eine Größe von 672 GB! Mehr als doppelt so viel, wie am Vortag. Seit dem kommen mal 18 GB /Tag oder auch nur 2 GB/Tag dazu, einmal waren es plötzlich 45 GB weniger. Das Backup braucht nun mittlerweile wieder über 12 Stunden.

    Kann mir vielleicht einer verraten wie das möglich sein kann?
    Es wird ein Vollbackup erstellt.

    Ich habe am 9.8.2013 einige Jobs neu erstellt. Unter anderem Rebuild Indexes. Kann es daran liegen, dass das auf einmal passiert? Ich kann mir das nämlich nicht vorstellen. Wie kann ich das beheben?

    Zudem habe ich noch eine Fragen. Wir wollen unseren produktiven Server downgraden von SQL Server 2008 R2 Enerprise auf SQL Server 2008 R2 Standard.
    Wie gehe ich da am besten vor? Ich habe einen Post gelesen, wie das funktionieren könnte.

    downgrade sql server

    Hat das schon wer von euch gemacht? Ich habe LEIDER nicht sehr große Erfahrung damit. Ich habe so etwas noch nie gemacht, weshalb ich ziemliche Bauchschmerzen habe.

    Vielen Dank




    • Bearbeitet BCCsql Donnerstag, 22. August 2013 08:39
    Donnerstag, 22. August 2013 06:05

Antworten

  • Hallo,

    Ich hätte besser ein Script geposten, wo die Größen gleich in GB umgerechnet werden; so musste ich etwas malen.

    Also, file_size der Datenbank ist zu beden Zeitpunkten gleich (360 GB), das Backup um 01:53 aber doppelt so groß, um 23:00 noch um 20% größer.

    Das Fullbackup enthält auch Teile des Transaktionsprotokoll und da Du schriebst, vorher ein Index Rebuild zu machen, wird das Trans-Log stark anwachsen und somit auch die Vollsicherung. Ich nehme an, ihr führt den Tage über regelmäßig Log Sicherungen durch, wodurch das 2te Backup um 23:00 entsprechend kleiner ist als zuvor.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 08:40
  • Kann mir vielleicht einer verraten wie das möglich sein kann?
    Es wird ein Vollbackup erstellt.

    Hallo,

    ich kenne den Workload der Datenbank nicht, von daher kann ich nicht konkret sagen, wie das möglich sein kann. Es kann aber durchaus möglich sein, das viele Daten geladen und/oder gelöscht werden.

    Ein Index Rebuild vergrößert die Datenbank-Datei durchaus, da Platz benötigt wird, um die Daten und Index Seiten umzustrukturieren. Gesichert werden aber nur die belegten Seiten, nicht die leeren, von daher sollte es das Backup nicht vergrößern.
    Was definitv dadurch vergrößert wird, ist das Transaction Log File und somit natürlich auch die Log Sicherung.

    Über die Backuphistorie kannst Du nachprüfen, wie groß die gesicherten Daten je Tag sind, also Beispiel Anfrage kannst Du diese verwenden: Database size growth as a list
    Du musst nur die Aggregation auf Jahr/Monat raus nehmen. Oder ganz vereinfacht:

    SELECT TOP 100 BS.database_name,
                   BS.backup_size,
                   BF.logical_name,
                   BF.file_size
    FROM msdb.dbo.backupset as BS
         INNER JOIN 
         msdb.dbo.backupfile AS BF 
            ON BS.backup_set_id = BF.backup_set_id 
    WHERE BF.file_type = 'D' 
    ORDER BY BS.backup_start_date DESC

    Zum Downgrade: Zunächst solltest Du Klären, ob Enterprise Features verwendet werden, wie Partitioning, CDC etc.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    • Bearbeitet Olaf HelperMVP Donnerstag, 22. August 2013 06:55 Script hinzugefügt
    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 06:51
  • Mir fällt gerade der Backup Name auf; einmal sichert ihr per I3_IC (kenne ich nicht) und einmal per Symantec Backup Exec!?!

    "D" ist die Vollsicherung der Datendaten, "L" ist die Logsicherung.

    Ändere mal die Abfrage so ab:

    SELECT TOP 100 
           BS.database_name,
           BS.backup_start_date,
           BS.backup_finish_date,
           BF.file_type,
           BF.logical_name,
           BS.backup_size / 1048576 AS SetSizeGB,       
           BF.backup_size / 1048576 AS BackupSizeGB,
           BF.file_size / 1048576 AS BFSizeGB
    FROM msdb.dbo.backupset as BS
         INNER JOIN 
         msdb.dbo.backupfile AS BF 
            ON BS.backup_set_id = BF.backup_set_id
               AND BF.file_type = BS.type
    --falls man filtern will: WHERE BS.type = 'L'
    ORDER BY BS.backup_start_date DESC


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 10:08
  • Die Abfrage der SKU liefert die Werte für die aktuelle Datenbank; wenn sie auf allen Daten nichts zurück liefert, dann kannst Du problemlos migrieren.

    Wenn ich mir so ein Tageszyklus ansehe

    dann hast Du mit dem Maintenance Plan / SQL Server Sicherung einen guten Durchsatz, 420 GB in 48 min ist doch passable. Dein Log File ist wirklich sehr groß, doppelt so groß wie die Datenbankdatei; das wundert.

    Dann sieht es so aus, als würde mit Symantec Backup Daten und Log in einem sichern; zumindest der Größe nach. Und der Durchsatz ist nicht so gut, für die gleiche Menge 9 Stunden gegenüber 1,5 Stunden.

    Machst Du den Index Rebuild etwa täglich? Wöchentlich würde normalerweise vollkommen reichen. Du kannst es ja heute mal aussetzen, um zu sehen wie dann die Backup Größen & Zeiten sind.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 11:29

Alle Antworten

  • Kann mir vielleicht einer verraten wie das möglich sein kann?
    Es wird ein Vollbackup erstellt.

    Hallo,

    ich kenne den Workload der Datenbank nicht, von daher kann ich nicht konkret sagen, wie das möglich sein kann. Es kann aber durchaus möglich sein, das viele Daten geladen und/oder gelöscht werden.

    Ein Index Rebuild vergrößert die Datenbank-Datei durchaus, da Platz benötigt wird, um die Daten und Index Seiten umzustrukturieren. Gesichert werden aber nur die belegten Seiten, nicht die leeren, von daher sollte es das Backup nicht vergrößern.
    Was definitv dadurch vergrößert wird, ist das Transaction Log File und somit natürlich auch die Log Sicherung.

    Über die Backuphistorie kannst Du nachprüfen, wie groß die gesicherten Daten je Tag sind, also Beispiel Anfrage kannst Du diese verwenden: Database size growth as a list
    Du musst nur die Aggregation auf Jahr/Monat raus nehmen. Oder ganz vereinfacht:

    SELECT TOP 100 BS.database_name,
                   BS.backup_size,
                   BF.logical_name,
                   BF.file_size
    FROM msdb.dbo.backupset as BS
         INNER JOIN 
         msdb.dbo.backupfile AS BF 
            ON BS.backup_set_id = BF.backup_set_id 
    WHERE BF.file_type = 'D' 
    ORDER BY BS.backup_start_date DESC

    Zum Downgrade: Zunächst solltest Du Klären, ob Enterprise Features verwendet werden, wie Partitioning, CDC etc.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    • Bearbeitet Olaf HelperMVP Donnerstag, 22. August 2013 06:55 Script hinzugefügt
    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 06:51
  • Es werden keine Enterprise features verwendet. Ich habe das mit

    SELECT * FROM sys.dm_db_persisted_sku_fearures

    und die ist leer.
    Heißt das, dass keine Enterprise features genutzt werden? Falls ja, dann werden keine genutzt.

    Ich habe mal die Abfrage ausgeführt, die du mir da gegeben hast

    SELECT TOP 100 BS.database_name,
                   BS.backup_size,
                   BF.logical_name,
                   BF.file_size,
                   BS.backup_start_date,
                   BS.backup_finish_date
    FROM msdb.dbo.backupset as BS
         INNER JOIN 
         msdb.dbo.backupfile AS BF 
            ON BS.backup_set_id = BF.backup_set_id 
    WHERE BF.file_type = 'D' 
    ORDER BY BS.backup_start_date DESC

    anderes Ergebnis

    -- Transact-SQL script to analyse the database size growth using backup history. 
    DECLARE @endDate datetime, @months smallint; 
    SET @endDate = GetDate();  -- Include in the statistic all backups from today 
    SET @months = 6;           -- back to the last 6 months. 
     
    ;WITH HIST AS 
       (SELECT BS.database_name AS DatabaseName 
              ,YEAR(BS.backup_start_date) * 100 
               + MONTH(BS.backup_start_date) AS YearMonth 
              ,CONVERT(numeric(10, 1), MIN(BF.file_size / 1048576.0)) AS MinSizeMB 
              ,CONVERT(numeric(10, 1), MAX(BF.file_size / 1048576.0)) AS MaxSizeMB 
              ,CONVERT(numeric(10, 1), AVG(BF.file_size / 1048576.0)) AS AvgSizeMB 
        FROM msdb.dbo.backupset as BS 
             INNER JOIN 
             msdb.dbo.backupfile AS BF 
                 ON BS.backup_set_id = BF.backup_set_id 
        WHERE NOT BS.database_name IN 
                  ('master', 'msdb', 'model', 'tempdb') 
              AND BF.file_type = 'D' 
              AND BS.backup_start_date BETWEEN DATEADD(mm, - @months, @endDate) AND @endDate 
        GROUP BY BS.database_name 
                ,YEAR(BS.backup_start_date) 
                ,MONTH(BS.backup_start_date)) 
    SELECT MAIN.DatabaseName 
          ,MAIN.YearMonth 
          ,MAIN.MinSizeMB 
          ,MAIN.MaxSizeMB 
          ,MAIN.AvgSizeMB 
          ,MAIN.AvgSizeMB  
           - (SELECT TOP 1 SUB.AvgSizeMB 
              FROM HIST AS SUB 
              WHERE SUB.DatabaseName = MAIN.DatabaseName 
                    AND SUB.YearMonth < MAIN.YearMonth 
              ORDER BY SUB.YearMonth DESC) AS GrowthMB 
    FROM HIST AS MAIN 
    ORDER BY MAIN.DatabaseName 
            ,MAIN.YearMonth

    Ergebnis

    Wie kommt es zu solchen Ergebnissen, wie kann ich das ändern, dass das nicht so lange dauert????

    Donnerstag, 22. August 2013 07:47
  • Hallo,

    Ich hätte besser ein Script geposten, wo die Größen gleich in GB umgerechnet werden; so musste ich etwas malen.

    Also, file_size der Datenbank ist zu beden Zeitpunkten gleich (360 GB), das Backup um 01:53 aber doppelt so groß, um 23:00 noch um 20% größer.

    Das Fullbackup enthält auch Teile des Transaktionsprotokoll und da Du schriebst, vorher ein Index Rebuild zu machen, wird das Trans-Log stark anwachsen und somit auch die Vollsicherung. Ich nehme an, ihr führt den Tage über regelmäßig Log Sicherungen durch, wodurch das 2te Backup um 23:00 entsprechend kleiner ist als zuvor.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 08:40
  • Wie schon angedeutet, kann es mit einem zeitgleich laufenden Index Rebuild liegen. Auch wenn die hohe Differenz überrascht.

    Generell würde ich empfehlen, mit Backup Compression zu arbeiten. Das geht schneller und komprimiert natürlich auch schlicht die Menge. - Das Differenz-Problem wird dadurch natürlich nicht gelöst.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Donnerstag, 22. August 2013 08:47
  • Ich verstehe das nicht.

    Wenn ich die Abfrage: WHERE BF.file_type ='D' mache bekomme ich das vorher gepostete Ergebnis.

    Ändere ich das ab: WHERE BF.file_type ='L' bekomme ich andere Ergebnisse.

    Ich suche nur nach einer Erklärung wie ich das lösen kann. Ich kann den zeitpunkt ändern für das Index rebuild. Verzweiflung macht sich breit.

    Donnerstag, 22. August 2013 09:03
  • Mir fällt gerade der Backup Name auf; einmal sichert ihr per I3_IC (kenne ich nicht) und einmal per Symantec Backup Exec!?!

    "D" ist die Vollsicherung der Datendaten, "L" ist die Logsicherung.

    Ändere mal die Abfrage so ab:

    SELECT TOP 100 
           BS.database_name,
           BS.backup_start_date,
           BS.backup_finish_date,
           BF.file_type,
           BF.logical_name,
           BS.backup_size / 1048576 AS SetSizeGB,       
           BF.backup_size / 1048576 AS BackupSizeGB,
           BF.file_size / 1048576 AS BFSizeGB
    FROM msdb.dbo.backupset as BS
         INNER JOIN 
         msdb.dbo.backupfile AS BF 
            ON BS.backup_set_id = BF.backup_set_id
               AND BF.file_type = BS.type
    --falls man filtern will: WHERE BS.type = 'L'
    ORDER BY BS.backup_start_date DESC


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 10:08
  • Zuerst wird via Maintenance Plan ein Vollbackup von der Datenbank gemacht.
    Danach ein Transaction Log Backup via Maintenance Plan. (SQL Server Management Studio).

    und später einmal wird das über Symantec Backup Exec gesichert.

    Ich habe mal die Abfrage ausgeführt. Hier das Ergebnis:




    Hier nochmal meine andere Frage. Kann ich das downgrade durchführen?

    Es werden keine Enterprise features verwendet. Ich habe das mit

    SELECT * FROM sys.dm_db_persisted_sku_fearures

    und die ist leer.
    Heißt das, dass keine Enterprise features genutzt werden?




    • Als Antwort markiert BCCsql Freitag, 23. August 2013 05:27
    • Tag als Antwort aufgehoben BCCsql Freitag, 23. August 2013 05:28
    Donnerstag, 22. August 2013 10:18
  • Die Abfrage der SKU liefert die Werte für die aktuelle Datenbank; wenn sie auf allen Daten nichts zurück liefert, dann kannst Du problemlos migrieren.

    Wenn ich mir so ein Tageszyklus ansehe

    dann hast Du mit dem Maintenance Plan / SQL Server Sicherung einen guten Durchsatz, 420 GB in 48 min ist doch passable. Dein Log File ist wirklich sehr groß, doppelt so groß wie die Datenbankdatei; das wundert.

    Dann sieht es so aus, als würde mit Symantec Backup Daten und Log in einem sichern; zumindest der Größe nach. Und der Durchsatz ist nicht so gut, für die gleiche Menge 9 Stunden gegenüber 1,5 Stunden.

    Machst Du den Index Rebuild etwa täglich? Wöchentlich würde normalerweise vollkommen reichen. Du kannst es ja heute mal aussetzen, um zu sehen wie dann die Backup Größen & Zeiten sind.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Als Antwort markiert BCCsql Donnerstag, 22. August 2013 11:55
    Donnerstag, 22. August 2013 11:29
  • Die Abfrage der SKU liefert die Werte für die aktuelle Datenbank; wenn sie auf allen Daten nichts zurück liefert, dann kannst Du problemlos migrieren.

     - Es werden bei dieser Abfrage doch nur die Systemdatenbanken abgefragt? Auf jeden Fall sind sie leer.

    Den Index Rebuild lief täglich ja, laut Hersteller sollte ich das mal eine Woche täglich laufen lassen, damit die Indexe mal "aufgehübscht" werden.

    Ich habe das jetzt geändert. Es soll wöchentlich jetzt gemacht werden. Morgen werden wir ja dann sehen, ob sich da etwas getan hat.

    Vielen Dank erstmal :)

    Donnerstag, 22. August 2013 11:54
  •  - Es werden bei dieser Abfrage doch nur die Systemdatenbanken abgefragt? Auf jeden Fall sind sie leer.

    Den Index Rebuild lief täglich ja, laut Hersteller sollte ich das mal eine Woche täglich laufen lassen, damit die Indexe mal "aufgehübscht" werden.

    Njein, es gibt Enterprise Features auf Server und auf Datenbank-Level, z.B. Partitioning und diese Info musst Du je Datenbank abfragen.

    Also, wenn erst mal ein Index Rebuild lief, geht es nicht mehr hübscher, auch nicht wenn man es x-mal innerhalb einer Woche laufen lässt; Neu ist Neu.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 22. August 2013 12:07
  • ...

    Also, wenn erst mal ein Index Rebuild lief, geht es nicht mehr hübscher, auch nicht wenn man es x-mal innerhalb einer Woche laufen lässt; Neu ist Neu.


    ...

    Wenn der Index Rebuild NICHT WÄHREND des Backups läuft, kommt das auch nicht ins Full Backup.

    Die vorab "gerebuildeten" Indexe an sich sind ja eher sogar kleiner/komprimmierter als die noch fragmentierten, auf jeden Fall nicht größer bloß weil sie rebuildet wurden.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Donnerstag, 22. August 2013 12:11

  • Njein, es gibt Enterprise Features auf Server und auf Datenbank-Level, z.B. Partitioning und diese Info musst Du je Datenbank abfragen.


    wie frage ich das ab auf server basis? und je datenbank? wie lauten, da die befehle?
    Donnerstag, 22. August 2013 19:27

  • Njein, es gibt Enterprise Features auf Server und auf Datenbank-Level, z.B. Partitioning und diese Info musst Du je Datenbank abfragen.


    wie frage ich das ab auf server basis? und je datenbank? wie lauten, da die befehle?

    Die Abfrage

    SELECT * FROM sys.dm_db_persisted_sku_features

    muss einfach im Kontext der jeweiligen Datenbank ausgeführt werden und liefert dann Features in der jeweiligen Datenbank, die Enterprise Level sind.-

    Letztlich prüft die die folgenden Aspekte:

    • Compression.

    • Partitioning.

    • TransparentDataEncryption.

    • ChangeCapture.

    Auditing z.B. prüft sie nicht. Ergo sollte man nochmal selber nachprüfen, was noch so benötigt werden könnte. - Die Liste der Features ist hier online: msdn.microsoft.com/de-de/library/cc645993.aspx

    Für den "Server" als solches gibt es eine solche Abfrage nicht. Die Engine spielt für die Datenbank keine direkte Rolle. Das nach einem Downgrade gewisse Performance- oder Hochverfügbarkeitsfeatures nicht mehr so oder anders funktionieren, ist der einzelnen Datenbank egal.

    Dafür gibt es meines Wissens auch keine Sicht zur bequemen Übersicht.


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Donnerstag, 22. August 2013 19:56
  • Für den "Server" als solches gibt es eine solche Abfrage nicht.


    Die Info sollte man aber vermutlich bekommen, wenn man die Abfrage auf der "master" Datenbank ausführt; bin mir aber nicht sicher und kann es gerade nicht ausprobieren, in der Doku steht auch nichts dazu, aber irgendwo muss der SQL Server sich ja auch merken, dass das Feature aktiv ist.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 23. August 2013 02:18
  • Ich möchte nur berichten, dass das Downgrade ohne Probleme abgelaufen ist. :) Das mit der Backup Größe überprüfe ich sobald ich auf Arbeit bin. 

    Vielen Dank für die tolle Hilfe und Unterstützung. :)

    Freitag, 23. August 2013 05:27
  • Für den "Server" als solches gibt es eine solche Abfrage nicht.


    Die Info sollte man aber vermutlich bekommen, wenn man die Abfrage auf der "master" Datenbank ausführt; bin mir aber nicht sicher und kann es gerade nicht ausprobieren, in der Doku steht auch nichts dazu, aber irgendwo muss der SQL Server sich ja auch merken, dass das Feature aktiv ist.
    ..

    Nein, dem ist eben nicht so, sonst hätte ich das schon geschrieben ;-)

    Und nein, er "merkt" es sich auch nirgendwo speziell als "Enterprise Feature aktiv" - der "downgrade" ist ja auch eher ein "fresh install", und nimmt darauf keine Rücksicht.
    Hat ja alles geklappt :)


    Andreas Wolter | Microsoft Certified Master SQL Server
    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com

    Freitag, 23. August 2013 08:37