SQL Serverデータベースは時折「In Recovery」モードに入ることがあり、これはデータベース管理者を驚かせることがよくあります。この状態は再起動、データベースの復元、または予期しないシャットダウン中に発生し、SQL Serverがデータの整合性を維持するために不完全なトランザクションをリプレイまたは取り消すために発生します。このプロセスは通常自動的に行われますが、予想以上に時間がかかることがあります。または行き詰まっているように見えることがあり、管理者はどのように対処すべきかわからなくなることがあります。
この問題に遭遇した場合は心配しないでください。この記事では、裏側で起こっていることを理解し、どのように対処すべきかを教えてくれます。以下は学べる内容の概要です:
- 「In Recovery」モードの意味 — データベースがこの状態に入る理由と、SQL Serverが裏で何を行っているか。
- リカバリの3段階 — リカバリ中にSQL Serverがフォローする解析、リドゥ、アンドゥの段階を明確に分解したもの。
- 遅延の一般的な原因 — 大きなトランザクションログから過剰な仮想ログファイル(VLF)まで、プロセスを遅らせている可能性のある要因を見てみましょう。
- オンラインに戻る方法 — 待つことからSQL修復ツールを使用するまで、データベースを一貫した状態に復元するための実用的な手順を学びます。
- 高度な支援を求めるタイミング — リカバリプロセスが停滞して進展がない場合の対処方法。
このガイドを終えると、SQL Serverのリカバリプロセスとデータベースをできるだけ早くオンラインに戻すために使用できるツールについての堅実な理解が得られるでしょう。
SQL Serverにおける「In Recovery」モードの理解
SQL Serverが再起動するか、データベースがバックアップから復元されると、データの整合性を維持するために「回復中」モードに入ります。このフェーズでは、SQL Serverは不完全なトランザクションを再実行または取り消してデータの破損を防ぎ、トランザクションの一貫性を確保します。
SQL Serverが再起動した後、データベースは「回復中」モードに移行します。また、SQL Serverデータベースが起動時やバックアップから復元時に回復状態であるのを確認することもあります。
図1 – SQLデータベース「回復中」モード
データベースの「回復中」状態は、データベースが回復プロセスを実行しており、プロセスが完了すると自動的にオンラインになることを意味します。しかし、回復が遅く、データベースが回復状態に留まっている場合があります。データベースファイルのサイズに応じて、SQLデータベースは3つの回復フェーズを経るため、まだ回復状態である可能性があります。
SQLデータベース回復の3つのフェーズ
通常、SQL Serverが再起動されるときにデータベースが適切にシャットダウンされないと、クラッシュ回復が行われ、DBが一貫性を保つことが保証されます。SQL DBが経る必要のある回復の3つのフェーズがあります:
フェーズ1:分析
このフェーズは、”最後のチェックポイントからトランザクションログの最後まで”を開始します。これにより、クラッシュ時の汚れたページをすべて特定するのに役立つ ‘Dirty Page Table’ (DPT) テーブルが作成されます。また、SQL Serverが停止したときに未確定のトランザクションを特定するための ‘Active Transaction Table’ (ATT) テーブルも作成されます。
フェーズ2: Redo
このフェーズでは、SQL Server はチェックポイントの後およびクラッシュの前に起こったすべての変更をロールフォワードします。基本的に、redo フェーズでは、確定されているがまだ SQL データファイル (.mdf/.ldf) に書き込まれていないトランザクションすべてがロールフォワードする必要があります。
フェーズ3: Undo
データベースの復旧時に未確定のトランザクションがあれば、それらは一貫した状態にするために Undo フェーズでロールバックする必要があります。
データベースがリカバリモードで停止した場合の対処方法
SQL Server エラーログを確認して、データベース内で最初に見つかるメッセージが次のように見えるかを確認してください:
Starting up database ‘DatabaseName’
これは、DB ファイルがオープンされ、リカバリプロセスが開始されていることを意味します。しばらくすると、SQL Server がリカバリの3つのフェーズを実行しているのを見ることができます。データベースのバックアップとリストア方法についてのガイダンスが必要な場合は、Azure SQL データベースのバックアップとリストアガイドを参照してください。
データベースリカバリのフェーズ1は以下の通りです:
Recovery of database ‘DatabaseName’ (9) is 0% complete (approximately 95 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
Recovery of database ‘DatabaseName’ (9) is 3% complete (approximately 90 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
フェーズ1の完了後、SQL Serverはフェーズ2および3のリカバリーを行います:
Recovery of database ‘DatabaseName’ (9) is 5% complete (approximately 85 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required…
Recovery of database ‘DatabaseName’ (9) is 95% complete (approximately 40 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
Phase 3 of 3. This is an informational message only. No user action is required.
フェーズ2および3が完了すると、次のようなものが表示されます:
3807 transactions rolled forward in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
0 transactions rolled back in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery completed for database DatabaseName (database ID 9) in 30 second(s) (analysis 1289 ms, redo 29343 ms, undo 72 ms.) This is an informational message only. No user action is required.
エラーログでは、「ユーザーアクションは不要です」というメッセージに注意してください。これは、データベースがリカバリ状態にあることを示しています。ただし、リカバリには予想以上に時間がかかる場合があり、データベースがリカバリモードのまま停止することがあります。
SQLデータベースが「リカバリ中」にスタックする理由
以下は、SQLデータベースがリカバリモードでスタックする原因です:
- 長時間実行中のトランザクションがロールバックしています
- トランザクションログファイルのサイズが巨大です
- DBトランザクションログ内に仮想ログファイル(VLF)が多すぎます
- SQL Serverにバグがあり、現在は修正されています。
データベースを一貫した状態に戻すためにできることは?
回避策1:データベースのリカバリが完了するのを待つ
データベースをオンラインに戻す最も明白な解決策は、忍耐強くリカバリプロセスが完了するのを待つことです。これには数時間または数日かかることがあります。SQL Server 2008または2008 R2のDBでリカバリに予想以上に時間がかかる場合は、Microsoftの修正プログラムを適用すると役立つかもしれません。
注意: データベースを一貫した状態でオンラインにするためにRESTOREコマンドを実行しないでください。SQL Serverはすでに同じタスクを実行しようとしています。また、‘RESTORE with..Recovery’を実行すると、データベースが再度同じ手順を踏むことになります。
回避策 2: 専門的なSQLデータベース修復ツールを使用する
回復が完了したがデータベースを一貫した状態に戻せない場合、専門のSQL修復ツールを使用することで、データベースを元の状態に復元できるかもしれません。
- Stellar Repair for MS SQL — 壊れたまたは失敗した後にSQLデータベースを元の状態に復元するのを助ける専門的なツールです。
- ApexSQL Recover — このツールは、削除された、切り捨てられた、または壊れたSQL Serverデータベースデータを回復します。
- dbForge SQL Complete — 主にIDE拡張ですが、有用なエラーハンドリングとトラブルシューティング機能を提供します。
- Redgate SQL Data Recovery — Redgateは、データ回復機能を含む一連のSQL Serverツールを提供しています。
- SysTools SQL Recovery Tool — 壊れたまたは損傷したSQLデータベースファイル(.MDFおよび.NDF)を回復し、使用可能な状態に戻すことで知られています。
- Kernel for SQL Database Recovery — このツールは、SQL Serverデータベースを破損や予期しないシャットダウンから回復および復元できます。
- Aryson SQL Database Recovery — SQL Server内のMDFおよびNDFファイルを修復および復元できる別のツールです。
結論
この記事では、SQLデータベースが「In Recovery」モードに陥った場合の意味、リカバリの3つの重要な段階(分析、リドゥ、アンドゥ)、およびデータベースをオンラインに戻すための方法について取り上げました。大規模なトランザクションログから仮想ログファイル(VLF)が多すぎるまで、様々な原因についても議論しました。
SQLデータベースがまだリカバリモードに陥っている場合は、忍耐が重要であることを覚えておいてください。リカバリプロセスを再起動させるRESTOREコマンドの実行は避けてください。手動での介入が失敗する深刻な問題の場合は、専門のSQLデータベース修復ツールを使用してデータを復元することを検討してください。
このガイドが役立つと思われる場合は、チームと共有するか、SQLリカバリの経験に関するコメントを残してください。
Source:
https://dzone.com/articles/resolving-sql-database-stuck-in-recovery-mode