3

SQL Server 2008 R2 に、何百万ものファイルが varbinary BLOB として格納されているデータベースがあります。先週、次のことを行うプロセスを設定しました。

  1. いくつかの Entity Framework コードを使用して、BLOB を持つ行 (エンティティ) を取得します。
  2. BLOB ストリームをオブジェクト ストアにコピーします。
  3. ストアからの新しいオブジェクト ID を使用して、データベース内のエンティティを更新します。

これを常に実行している 30 のスレッドがあり、このプロセスにはまだ数日かかります。数日前、データベース ログ ファイルがいっぱいになりました。このプロセスが原因であるに違いありません。このデータベースではポイント イン タイム バックアップは重要ではないと判断し、単純復旧モデルを使用するようにデータベースを設定しました。それから昨日、ログファイルがいっぱいになったというエラーがプロセスから再び表示されました! シンプルモードでこれはどのように可能ですか?! これが起こらないようにするために私にできることはありますか？ログ ファイルを監視すると、SQL Server は 7% までいっぱいになり、その後ゼロに切り詰めるので、非常に混乱しています。完全バックアップが始まると、ログファイルがチェックされずに大きくなり始めるようです...

4

2 に答える 2

3

単純復旧モードでも、SQL Server は、ACID 準拠を維持し、ロールバック (または特定の災害復旧シナリオでは「ロールフォワード」) を許可するために、ログ ファイルを作成します。そのため、少なくとも一度に受け取る可能性のあるトランザクションを処理するのに十分なスペースが必要です。そうでない場合は、自動拡張するか、エラーが発生します。

実際問題として、いくつかのオプションがあります。最も簡単な方法は、トランザクションを処理するのに十分なスペースを与えることです。もう 1 つは、トランザクションをより少ないトランザクションに分割することです。Simple Recovery では、トランザクションが完全にコミットされてファイナライズされると、そのスペースを再利用できるようになるためです。

明確にするための編集とコメントへの対応: SQL Server は、明示的なトランザクションが呼び出されなくても、ほぼすべてのアクション (いくつかの例外がありますが、ここでは重要ではありません) を暗黙的なトランザクションに配置します。したがって、100 万行を挿入するコマンドを実行すると、その挿入に対する暗黙的なトランザクションが発生し、単純な復旧モードであっても、トランザクションが完全にコミットされて完了するまで、これらの 100 万行すべてがトランザクション ログに影響を与えます。スペースをより速く解放したい場合は、コードを書き直して、1 つのステートメントで 100 万行を挿入する代わりに、10 ステートメントでそれぞれ 10 万行を挿入するようにします。

あなたの質問からは、完全バックアップ中にのみ成長していることは明らかではありませんでしたが、はい、バックアッププロセスは、実行中にログ内のスペースを解放する能力に影響を与えます. これは、完全バックアップにはログ ファイルのデータも含まれるため、サーバーはバックアップ プロセス中に情報が利用可能であることを確認する必要があるためです。In Recoveryに関連する議論があります。

通常、スケジュールされたバックアップを延期するのは非常に気が進まないのですが、この特定のシナリオではそれが役立つ場合があります。また、トランザクションをより小さな断片に分割することが、最終的には進むべき道かもしれません.

于 2012-12-26T17:32:38.033 に答える
0

完全バックアップが始まると、ログファイルがチェックされずに大きくなり始めるようです...

つまり、完全バックアップを行っている間だけ大きくなりますか? フル バックアップには、すべてのデータ ページと、バックアップ手順中に生成された一連のログ レコードが含まれているため、これは理にかなっています。

そのため、バックアップの実行中は、おそらくログを切り捨てることはできません。これは私の側の（教育を受けた）推測であることに注意してください。

これは、sys.databases.log_reuse_wait_desc の値を見ることで確認できます。

于 2012-12-26T18:12:04.653 に答える