ユーザーデータベースが破損して起動しない（起動トラブル）：SQL Serverトラブルシューティング（14）

トラブルの実例：SQL Serverを運用している中で、突然アプリケーションにエラーが発生するようになってしまった。SQL Serverの管理ツールである「SQL Server Management Studio」で確認したエラー番号は「エラー824」（図9-1）。同じエラーをエラーログでも確認できた。

　そこで、夜間のメンテナンス時間に再起動を行ったが、それ以降、ユーザーデータベースに全く接続できなくなってしまった。

図9-1　「エラー824」を、SQL Server Management Studioで確認

トラブルの原因を探る

　エラー824は、「SQL Serverのデータが破損している」「データに不整合がある」ときに示されます。SQL Serverは8KBの「ページ」という単位でデータを保存しています。このページ内のチェックサムと実際のデータを付き合わせて、不整合があるとエラー824が出力されます。

　また、再起動を行っても現象が解消せず、むしろ悪化していることを考えると、この障害はメモリ上のみで発生した破損ではなく、ディスクに保存されているユーザーデータベースのデータそのものが破損してしまったことが分かります。

解決方法

　ユーザーデータベースが破損してしまったら、あらかじめ取得してあったデータベースのバックアップからリストアします。完全復旧モデルを利用している場合の手順は以下の通りです。

1. データベースの「現在のトランザクションログ」のバックアップを取得する
2. 全てのユーザーセッションを切断し、接続しないように調整する
3. データベースのリストアをWITH NORECOVERYオプション付きで実行する
4. 保存してあるトランザクションログのリストアをWITH NORECOVERYオプション付きで実行する
5. （1）で取得したトランザクションログのリストアをWITH RECOVERYオプション付きで実行する
6. データアクセスを確認する

図9-2　データベースリストアツールの画面。「WITH NORECOVERY」の指定は、後続のリストアがあることを示す。一方、「WITH RECOVERY」は「これでデータベースの復旧を終了する」ことを示すオプションとなる

　データアクセスの確認には、アプリケーションの動作確認の他に、SQL Serverの機能を使って全体的に問題がないかを確認する「DBCC CHECKDB」を使います。DBCC CHECKDBを実行し、問題がないことを確認することでリストアしたデータベースの整合性が保証されたことになります（図9-3）。

図9-3　DBCC CHECKDBを実行し、不整合エラーのないことを確認する

　ちなみに、データ不整合エラーであるエラー824は、破損箇所へSQL Serverがアクセスしてはじめて発覚します。そのため、その時点で破損しているのが1カ所だけとは限りません。データベースの他の箇所が壊れている可能性もあります。

　エラー824が“今のところ”業務に大きな影響を与えていないとしても、決して放置してはいけません。もし管理領域も壊れていたならば破損がさらに広がってしまいます。早期の対処を推奨します。