次の方法で共有


SQL Server での復旧のパフォーマンスについて

復旧のパフォーマンスは、バックアップの復元後の復旧ではなく、主にクラッシュ後の復旧に重点を置いて検討します。ただし、バックアップからの復元後の復旧でも最適化を行うことはできます。

復旧にかかる時間は、最後のチェックポイント以後に行われた処理の量と、データが失われた時点でアクティブなすべてのトランザクションによって既に行われていた処理の量によって決まります。SQL Server では、recovery interval という構成オプションを使用して、SQL Server でデータベースを復旧するのに必要な概算最大時間をデータベースごとに分単位で設定します。この recovery interval の設定により、チェックポイントの頻度が制御されます。短いトランザクションを使用するオンライン トランザクション処理 (OLTP) システムでは、recovery interval の設定が復旧にかかる時間を決定する主な要因になります。

インストール後、SQL Server によって recovery interval がゼロ (0) に設定されます。recovery interval の設定を既定値から変更していない場合、実行時間の長いトランザクションが存在しなければ、各データベースの復旧は約 1 分以内に完了します。復元したデータを復旧するとき、データの損失時に実行時間の長いトランザクションがアクティブになっていた場合は、このようなトランザクションのロールバックにかかる時間によって復旧時間が決まります。ただし、SQL Server 2005 以降のバージョンでは、クラッシュ後の復旧処理やデータベース ミラーリング フェールオーバーの最中でもデータベースを使用できます。この機能を "高速復旧" といいます。

recovery interval の値がゼロ (0) に設定されていて、ロールバックが必要な実行時間の長いトランザクションが存在しないにもかかわらず、データベースあたりの復旧時間が毎回 1 分を大幅に超える場合は、ご購入元に問い合わせて復旧のパフォーマンスに関する問題を解決することを検討してください。

復旧により、データベースの仮想ログ ファイルに基づいて進行状況が報告されます。復旧では、復旧の開始時点から最新のチェックポイントまでログが分析され、スキャンされます。分析フェーズに基づき、復旧中に読み取られるログの量が推定されます。この推定値と実際に読み取ったログの量を比較して、復旧の進行状況が報告されます。

recovery interval の設定を既定値から変更すると、完了するまでに何倍もの時間をかけて復旧が行われます。たとえば、recovery interval の値を 10 に変更すると、recovery interval が既定値のゼロ (0) である場合の約 10 倍の時間がかかるようになります。

SQL Server の起動に要する時間を短縮するためにログ領域を増やす場合は、小さな領域を何度も追加するのではなく、できる限り大きな領域を確保してください。小さなログ領域の数が増えると、その初期化に時間がかかります。

復元操作後に復旧すると、実行時間の長いトランザクションが終了した場合は、サーバーでロールバック プロセスが終了します。実行時間の長いトランザクションのロールバック中にサーバー プロセスを終了すると、次の復旧を行うのに長い時間が必要になります。ロールバック プロセスにかかる時間の長さに不安を感じたら、システム管理者に依頼してサーバーでロールバックが進行していることを確認してください。

実行時間の長いトランザクションの実行中にサーバーがクラッシュした場合、SQL Server によって復旧処理が開始されます。この場合、元に戻すフェーズの間データベースを使用できるので、復旧速度が速くなります。

完全復旧モデルに基づいてバックアップからデータを復元するときに復旧時間を削減する方法については、「データベース復元時の復旧時間の短縮」を参照してください。