スケジュールされたバックアップタスクは、常にジョブが成功したと言っているにもかかわらず、常にすべてのデータベースをバックアップするわけではありません

SQL 2008で、ストアドプロシージャを実行してすべてのデータベースをバックアップするジョブがあります。これは、SQLサーバーエージェントジョブを介して毎日実行されます。

それは毎日成功して終了しますが、いくつかのデータベースはいくつかのデータベースをバックアップした後にのみ成功して終了します。毎回異なる数のデータベースを使用できます。ほとんどの場合、すべてのデータベースが正常にバックアップされますが、場合によっては2つのバックアップが正常に実行され、場合によっては5などもバックアップされます。

ジョブ履歴、イベントビューアー、またはSQLサーバーログにエラーが表示されません。

フォルダは拡張可能なストレージボリューム上のフォルダへの「ジャンクション」ですが、ローカルディスクへのバックアップが行われています。

OSは、SQL Server 2008 Webエディション64ビットを実行しているWindows 2003 64ビットで、VMware ESXi 5ホスト上で実行されている仮想マシンです。

ストアドプロシージャ：

ALTER PROCEDURE [dbo].[backup_all_databases] 
@path VARCHAR(255)='c:\backups\'

AS

DECLARE @name VARCHAR(50) -- database name  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name 
DECLARE @dbIsReadOnly sql_variant -- is database read_only?
DECLARE @dbIsOffline sql_variant -- is database offline?

DECLARE db_cursor CURSOR FOR  
SELECT name 
FROM master.dbo.sysdatabases 
WHERE name NOT IN ('tempdb')
AND version > 0 AND version IS NOT NULL

OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   

WHILE @@FETCH_STATUS = 0   
BEGIN   
SET @fileName = @path + @name + '.bak'

SET @dbIsReadOnly = (SELECT DATABASEPROPERTY(@name, 'IsReadOnly')) -- 1 = Read Only
SET @dbIsOffline = (SELECT DATABASEPROPERTY(@name, 'IsOffline')) -- 1 = Offline

IF (@dbIsReadOnly = 0 OR @dbIsReadOnly IS NULL) AND @dbIsOffline =0
BEGIN
    BACKUP DATABASE @name TO DISK = @fileName  WITH INIT
    WAITFOR DELAY '00:00:20'
END

FETCH NEXT FROM db_cursor INTO @name 
END   

CLOSE db_cursor   
DEALLOCATE db_cursor

何か提案してください？

エラーを処理してログに記録するために、TRY / CATCHブロックを追加します。DBは、シングルユーザーでも、復元されたものでも、何でもかまいません。

これがないと、エラーがログに記録されない方法でステートメントが異常終了する可能性があります（ステートメント、バッチ、スコープ、接続など）

TRY / CATCHを使用すると、コンパイルエラーまたは接続中止エラー以外のすべてがログに記録されますか？しかし、私はこれが事実であることを疑います。

また、sysdatabasesを置き換えるsys.databasesを使用して、さらにフラグを読み取ります。

-- declares etc

BEGIN TRY

    DECLARE db_cursor CURSOR FOR  
    SELECT name, state, user_access
    FROM sys.databases 
    WHERE name NOT IN ('tempdb')

    OPEN db_cursor   
    FETCH NEXT FROM db_cursor INTO @name, @state, @user_access

    WHILE @@FETCH_STATUS = 0   
    BEGIN   

        SET @fileName = @path + @name + '.bak'
        IF @state = 0 AND user_access = 0
        BEGIN
            BEGIN TRY
                BACKUP DATABASE @name TO DISK = @fileName  WITH INIT
            END TRY
            BEGIN CATCH
                -- log but do not rethrow so loop continues
            END CATCH
            WAITFOR DELAY '00:00:20'
        END
        ELSE
           --log user and/or state issues

        FETCH NEXT FROM db_cursor INTO @name 
    END   

    CLOSE db_cursor   
    DEALLOCATE db_cursor

END TRY
BEGIN CATCH
  -- some useful stuff here
END CATCH

「backup」コマンドの後でエラーを確認し、検出されたエラーについて独自のメールを送信します。

これにより、何が起こっているかを確認するための開始点が提供され、ジョブの問題が解決されるまで、すべての問題を警告することが保証されます。

カーソルで注文してください。SQLでデータが返される順序を選択できるようにすると、sys.databasesへのカーソルに「問題」があることがわかりました。名前順で十分です。

バックアップは、テープへのバックアップ、またはバックアップファイルをコピーまたはアクセスする他のプロセスと同時に実行されていますか？もしそうなら、私はそれが使用中であるためにファイルを上書きすることに失敗しているに違いないと思います。複数のバックアップコピーの余地がある場合は、プロシージャを変更して、出力ファイルに日付スタンプを追加できますが、その後、クリーンアップルーチンが必要になります。

SQL Server 2005の導入により、sysdatabasesおよびsys.databasesを介したカーソルループが変更されたように見えたため、信頼性が低く、この動作の変更はsp_foreachdbでも確認できました。

カーソルの種類を変更することで改善が見られた（早送りだったと思います）が、最終的にはOla Hallengrenのバックアップおよびメンテナンスソリューションなどのソリューションに切り替えました。バックアップなどの重要なほとんどのことと同様に、これらの潜在的なソリューションを使用していても、データベースが確実にバックアップされるように、すべてのデータベースをクロスチェックする必要があります。

カーソルタイプ：http : //msdn.microsoft.com/en-us/library/ms378405(v=SQL.90).aspx

Olaのメンテナンスソリューション：http : //ola.hallengren.com/

特に大きなDBをバックアップしているときに、同じ問題が発生しました。

@@fetch_statusGLOBAL変数であるため、ユーザーのカーソルとは別のカーソルによって変更（0に設定）される可能性があります。私は次のように（疑似コードで）解決しました：

create a temp table with dbNames
select top 1 in a variable (use order by)
while variable is null
do your thing

set variable = null
delete top 1(use order by)
select top 1 in a variable (use order by)
loop

私はこの問題を理解しようとしましたが、ユーザーが解決策を投稿したことが何度もあり、カーソル宣言を鈍くすると、機能し始めます。だから私はそれをテストしました、そしてそれはあなたがカーソル宣言が静的であり、それが機能し始めることを確認するだけです。

失敗するのは-サーバーレベルのカーソルしきい値設定を確認します--1として構成されている場合、つまり、カーソルキーセットのデータを読み取ろうとすると、すべてのカーソルが同期的に読み込まれ、すべてのカーソルが同期されます。同時に読んでください。この値を0に変更すると、SQLサーバーに単純な単語で非同期入力を行うように指示します。キーセットがまだ入力されている間にカーソルがレコードをフェッチできるため、サーバーレベルでこの変更を行った後、使用しているデータベースを見落とすことはありません。カーソル。

解決策：カーソルを静的に宣言するか、サーバーレベルの設定「カーソルのしきい値」を-1から0に変更します。

ありがとう、Gaurav Mishra | シニアDBA