バックアップには、おそらく xp_sqlmaint を使用する必要があります。古いバックアップを削除する便利な機能があり、適切なログ ファイルが作成されます。次のような方法で呼び出すことができます。 "[BackupArchive]" -BkUpMedia DISK [BakExpirationSchedule]''
([角括弧] を適切な値に置き換えます)。
また、バックアップのために、トランザクション ログのバックアップが必要になる場合があります。次のようなもの: IF DATABASEPROPERTYEX((SELECT db_name(dbid) FROM master..sysprocesses WHERE spid=@@SPID), ''Recovery'') <> ''SIMPLE'' EXECUTE master.dbo.xp_sqlmaint N'' -S " [ServerName]" [ServerLogonDetails] -D [DatabaseName] -Rpt "[BackupArchive]\BackupLog_TRN.txt" [RptExpirationSchedule] -BkUpLog "[BackupArchive]" -BkExt TRN -BkUpMedia DISK [BakExpirationSchedule]''
使用している実際のコマンドをデータベース テーブル (コマンドごとに 1 行) に保存し、何らかのテンプレート置換スキームを使用して構成可能な値を処理することをお勧めします。これにより、新しいコードをデプロイする必要なく、コマンドを簡単に変更できます。
復元するには、内部 SQL サーバー以外のすべての接続を切断する必要があります。基本的に、「exec sp_who」の結果と、dbname で一致し、ステータスが「background」ではない行、および「SIGNAL HANDLER」、「LOCK MONITOR」、「LAZY WRITER」のいずれでもない cmd を取得します。 、「LOG WRITER」、「CHECKPOINT SLEEP」は、spid を「kill」します (例: ExecuteNonQuery("kill 1283"))。
KILL コマンドからの例外をトラップして無視する必要があります。それらについてあなたができることは何もありません。既存の接続が原因で復元を続行できない場合は、エラーが発生します。
接続を強制終了する際の危険の 1 つは、ADO の接続プールです (Windows アプリよりも asp.net アプリの方が多い)。ADO は、接続プールからフェッチされた接続が有効であると想定します...そして、強制終了された接続にはうまく反応しません。その接続で発生する次の操作は失敗します。エラーを思い出せません...その特定のエラーだけをトラップして処理できるかもしれません...また、3.5でも接続プールをフラッシュできると思います(したがって...エラーをトラップし、接続プールをフラッシュします、接続を開き、コマンドを再試行してください...醜いですが、実行できる可能性があります)。