データベース復旧時間の問題
SQL Serverが意図せず停止してしまった際に（サーバーダウンなどによって）、大量の更新操作（バッチ処理でのデータ投入処理など）が行われていた場合、SQL Serverを再起動してもデータベースの状態が「復旧中」となり長時間使用できなくなることがあります。これはデータベースをSQL Serverが停止する直前の状態に戻すための復旧処理が行われていることに起因しています。
データベースに対して実行された更新操作が、個々のトランザクションの観点から整合性のとれた状態にもどるまで、ユーザーがデータベースを使用することを許可しません。
SQL Serverや他の多くのデータベース管理システム（IBM Db2 など）は、ARIES（Algorithms for Recovery and Isolation Exploiting Semantics）と呼ばれるデータベース復旧アルゴリズムをもとに設計されています。
ARIESは、トランザクションログの先行書き込み（WAL: Write Ahead Logging）や、データベース復旧時に実行される再実行（Redo）／ロールバック（Undo）などによって構成される、データベース復旧時の整合性確保のためのアルゴリズムです。
ARIESにおける再実行やロールバックはトランザクションログをもとに実行されます。それはトランザクションログに記録された更新情報を元に、データベースに対して再実行やロールバックの処理が逐次的に実行されることを意味します。つまり、適用しなければならないトランザクションログの数が多ければ多いほど、対処に必要な時間が増えてしまいます。
例えば、数十億件のデータ投入を一つのトランザクションで実行中にSQL Serverがダウンしてしまった場合を考えてみましょう。SQL Serverが再起動されると、未完了でとなってしまったデータ投入処理を、記録されたトランザクションログを辿りながら取り消す膨大な量のロールバック処理が行われることになります。
その復旧に必要となる時間は、データベースのデータやトランザクションログを配置しているディスクのIO速度や帯域に大きく依存します。実際に発生した類似する状況では、12時間もの長期間にわたってデータベースの復旧が行われ続け、その間ユーザーはデータベースへのアクセスができませんでした。
