none
Backup-issue RRS feed

  • Allgemeine Diskussion

  • Hi Forum,
    I've created on a SQL 2008 EE 64-bit SQL-Server a BackupJob.
    The Job should backup all user-DBs.
    The Job looks like:
    DECLARE @name VARCHAR(100) -- database name for the path
    DECLARE @path VARCHAR(256) -- path for backup files  
    DECLARE @fileName VARCHAR(256) -- filename for backup  
     
    -- specify database backup directory
    SET @path = 'S:\Fullbackup\UserDB\'  
     
    DECLARE db_cursor CURSOR FOR  
    SELECT name 
    FROM master.dbo.sysdatabases 
    WHERE name NOT IN ('master','model', 'msdb','tempdb', 'AdminDB')  
     
    OPEN db_cursor   
    FETCH NEXT FROM db_cursor INTO @name   
     
    WHILE @@FETCH_STATUS = 0   
    BEGIN  
           SET @fileName = @path + @name + '_' + 'FULL' + '.BAK' 
           BACKUP DATABASE @name TO DISK = @fileName with init, skip 
           FETCH NEXT FROM db_cursor INTO @name   
    END   
     
    CLOSE db_cursor   
    DEALLOCATE db_cursor
    There are 6 DBs to backup, one quite big (5TB).
    In the Job-History is the Job as sucessful marked. But only 1 DB was backuped (the big one) and the backup file would correctly saved.
    Unfortunately I can't do a restore to test the backup file.
    Since the rest 5 DBs were not backuped, I've read the message in the JOb-History und found:
     Processed 12159856 pages for database 'MyDB', 
     file 'MyDB_1' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 11999704 pages  for database 'MyDB', 
     file 'MyDB_2' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 12159920 pages for database 'MyDB', 
     file 'MyDB_3' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 12159808 pages for database 'MyDB', 
    .......
    .......
    file 'MyDB_33' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 12159680 pages for database 'MyDB', 
     file 'MyDB_34' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 12158352 pages for database 'MyDB', 
     file 'MyDB_35' on file 1. [SQLSTATE 01000] (Message 4035)  Processed 15...  The step succeeded.
    The big DB has 50 *.NDF-Files, the history message says about file nr. 35 and nothing more??
    Is there something wrong?
    Thanks for your help
    P.

    Montag, 22. Juli 2013 09:52

Alle Antworten

  • Hallo P.!

    Da Du sonst auf deutsch fragst, antworte ich mal auf deutsch.

    Die Job-History ist ziemlich begrenzt, so dass Du nur einen Bruchteil der Informationen sehen wirst, aber in der Backup-History solltest Du alles zu den Sicherungen sehen und in der Regel steht es auch im Errorlog des Servers.

    Hast Du das Skript mal mit dem Debugger laufen lassen, oder im Management Studio?


    Einen schönen Tag noch,
    Christoph Muthmann
    Microsoft SQL Server MVP - Blog

    Dienstag, 23. Juli 2013 11:32
    Beantworter
  • Hallo Purclot,

    ich würde auch sagen, da fehlt schlicht ein Teil der Meldung, der Teil zwischen "Processed 15... the step succeeded", den normalerweise gibt es eine zusammenfassende Meldung am Ende, wei

    Processed 184 pages for database 'TestDB', file 'TestDB' on file 1.
    Processed 8 pages for database 'TestDB', file 'TestDB_GenutzteFG' on file 1.
    Processed 8 pages for database 'TestDB', file 'TestDB_LeereFG' on file 1.
    100 percent processed.
    Processed 1 pages for database 'TestDB', file 'TestDB_log' on file 1.
    BACKUP DATABASE successfully processed 201 pages in 0.051 seconds (30.790 MB/sec).


    Olaf Helper

    Blog Xing

    Dienstag, 23. Juli 2013 12:27
  • Either translate your post or post your question again on the English Forums.


    Raul, das hatte er sozusagen auch, genauer gesagt hatte er es zunächst in Deutsch ins en-US Forum "SQL Database Engine" gepostet, von woher ich es dann hierher verschoben hatte. Kurz darauf hatte er es dann ins Englische übersetzt; schlechtes Timing.

    Olaf Helper

    Blog Xing

    Mittwoch, 24. Juli 2013 12:31
  • Hallo Christoph, hallo Olaf,

    danke für Euere Antworten.

    1. in der Log-Datei ist tatsächlich die Meldung komplett, daher der erste Punkt ist erledigt.
    2. da die eine DB ca. 6TB groß ist, kann ich den Job aus Zeitgründen (das Fullbackup allein von der großen DB dauert Stunden) nicht mit Debugger überwachen. Wenn ich anstatt den Job starten, das Kommando mit dem 'print' ausgebe sieht alles gut aus (der Backupbefehl, Pfade usw). Schliesslich wird der ganze Job mit Erfolg beendet, gäbe es Fehler im Cursor usw.,  würde der Job doch nicht laufen?
    Es ist als ob eine DB aus dem Cursor, die der Reihe nach gesichert werden soll, zu dem Zeitpunkt nicht erreichbar (aus welchem Grund auch immer) wäre. Es ist aber definitiv nicht der Fall, und  auch wenn doch, würde doch der Job mit einer Fehlermeldung beendet...

    Somit stehe ich weiterhin auf dem Schlauch...

    P.

    Mittwoch, 24. Juli 2013 19:27
  • Hallo Purclot,

    Ich kann ich Deinem Script kein Problem/Fehler sehen, das sollte eigentlich das tun, was angedacht ist. Kleine Anmerkung: Die System View dbo.sysdatabases ist veraltet und abgekündigt, Du solltest besser sys.databases verwenden.

    Hast Du das Backup File schon überprüft, ob es in Ordnung ist? Einen Restore Test musst Du dafür nicht umbedingt machen (wegen der Größe), es gibt auch ein paar Validierungsfunktionen für den Restore:

    - RESTORE FILELISTONLY (Transact-SQL)
    - RESTORE HEADERONLY (Transact-SQL)
    - RESTORE VERIFYONLY (Transact-SQL)


    Olaf Helper

    Blog Xing

    Donnerstag, 25. Juli 2013 06:45
  • Hallo Olaf,

    danke für den Hinweis mit sys.databases.
    Das Backup von der großen DB scheint in ordnung zu sein (vorher mit den 3 Restore-Befehlen von oben getestet).
    Das einzige Problem ist, dass die kleineren DBs, die mit-gesichert werden sollen, nicht gesichert werden.
    Soll heissen: der Backupjob läuft im Cursor und offensichtlich nach dem Backup von der großen DB bricht den Job ab, zeigt aber keine Fehler in der Log-Datei.

    P.

    Donnerstag, 25. Juli 2013 07:27
  • Momentan kann ich auch nur raten; richtig überprüfen kannst Du es nur vor Ort.

    Eine Idee ist noch, das einer der Datenbank-Namen ein Zeichen enhält, das nicht in Dateinamen erlaubt ist, wie ein Doppelpunkt oder Slash, was zum Problem führt, weil der Datenbankname im Backup-Filenamen enthalten; weit hergeholt, aber potentiell möglich.

    Ändere Dein Script mal so, dass das Backup Statement nur ausgegeben, aber nicht ausgeführt wird; kannst Du die Statement dann manuell ausführen? Die große DB, die ja funktioniert, kannst Du auslassen:

    DECLARE @name VARCHAR(100) -- database name for the path
    DECLARE @path VARCHAR(256) -- path for backup files  
    DECLARE @fileName VARCHAR(256) -- filename for backup  
     
    -- specify database backup directory
    SET @path = 'S:\Fullbackup\UserDB\'  
     
    DECLARE db_cursor CURSOR FOR  
        SELECT name 
        FROM master.dbo.sysdatabases 
        WHERE name NOT IN ('master','model', 'msdb','tempdb', 'AdminDB')  
     
    OPEN db_cursor   
    FETCH NEXT FROM db_cursor INTO @name   
     
    WHILE @@FETCH_STATUS = 0   
    BEGIN  
           SET @fileName = @path + @name + '_' + 'FULL' + '.BAK';
           
           PRINT 'BACKUP DATABASE ' + QUOTENAME(@name) + ' TO DISK = ' + @fileName + ' with init, skip';       
           FETCH NEXT FROM db_cursor INTO @name;
    END   
    
    CLOSE db_cursor;
    DEALLOCATE db_cursor;


    Olaf Helper

    Blog Xing

    Donnerstag, 25. Juli 2013 07:42
  • Hallo Olaf,

    ja, wenn ich die Backupbefehle nur herausgebe, kann ich die DBs einwandfrei sichern.
    So wie ich irgendwo weit oben geschrieben habe, tritt der Fehle nicht immer vor, soll heissen: manchmal werden alle DBs gesichert, manchmal nur die eine, große. Leider an solchen Tagen, an denen nur die große DB gesichert wird, gibt es in der LOG-Datei keinen Hinweis auf einen Fehler, der Job endet mit Erfolg, der kein Erfolg ist...

    P.

    Donnerstag, 25. Juli 2013 08:56
  • Hallo Purclot,

    jede erfolgreiche Sicherung wird auch immer im Windows EventLog sowie im SQL Server ErrorLog protokolliert; findest Du an den Tagen, wo es nicht komplett gelaufen ist, Einträge zu erfolgreichen/fehlgeschlagenen Sicherungen?


    Olaf Helper

    Blog Xing

    Donnerstag, 25. Juli 2013 16:58
  • Hallo Olaf,

    ja, die LOG-Dateien sehen gut aus:

    Database backed up. Database: T_Conf, creation date(time): 2013/06/23(14:41:42), pages dumped: 47679, first LSN: 154264:197:57, last LSN: 154274:18118:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'K:\Fullbackup\UserDB\Satz1\T_Conf_FULL.BAK'}). This is an informational message only. No user action is required.

    Keine Fehler usw. Das Problem ist, das hier eben außer der DB: T_Conf noch zus. 5 DBs mitgesichert werden sollten!

    Gruß P.

    Montag, 29. Juli 2013 11:13