使用頻度の高いデータベースで 4 分ごとにネットワーク パスへのデータベースの完全バックアップをセットアップした顧客がいます。お客様には、それを行わず、代わりにトランザクション バックアップを行うことを強くお勧めします。
しかし、この方法でフル バックアップを実行すると、どのような問題が発生する可能性があるのでしょうか? それ以外は、バックアップの実行中にデータベースが頻繁に使用されるため、バックアップに正しいデータが含まれることはありません。そして、サーバーの負荷。
この顧客との間で SQL 関連の問題 (webservice<-sqlconnection->sql) がいくつかありましたが、このバックアップ シナリオが問題の一部であるかどうかを技術的に知りたいですか?
もちろん、テスト中にバックアップを停止し、イベントログなどを調べて、これを調査し始めます。しかし、直接誰かが「NOOO、これはXをロックしてYをスローし、悪い」などと言うことができるかどうかに興味があります. ;)
それが小規模なデータベースであり、おそらくそうであると推測している場合、少し余分な負荷がかかる以外に害はないでしょうが、データを失わないようにする必要がある場合は、毎日完全バックアップを実行する必要があります。フル バックアップの代わりに数分ごとにログ バックアップを行い、スタンバイ サーバーにログを配布するか、ミラーリングをセットアップします。
冗長性のために 2 番目の MSSQL サーバーを実行できますか? RAIDミラーに両方のサーバーがありますか？
または、Red Gateなどを使用して 5 分ごとにデータをバックアップすることもできます。そして、その非常に速い!!! 多くの圧縮/暗号化があります。10 分ごとに 100 万レコードのデータベースをバックアップしました。問題はありません！
4 分ごとにデータベースをバックアップする理由をクライアントに尋ねなければなりません。
MSSQL の「バックアップ モード」に相当するものにデータ ファイルを配置している限り、バックアップは有効なはずですが、これはバックアップを実行する方法として非常に影響が大きいように思えます。「1 時間ごとの完全バックアップ、ログベースのバックアップを継続的に行う」だけでも、大きな改善になります。
もちろん、これはデータベースのサイズに大きく依存します。5 ～ 10 メガのデータベースの場合、オーバーヘッドは逆になる可能性がありますが、それはありそうにありません。
これは小さなデータベースだと思いますが、4分のウィンドウを超えると、データベースを停止できます。2番目のバックアップが開始され、処理と以前のバックアップの両方がさらに遅くなり、3番目のバックアップが開始されるのを待ちます...