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

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「ユーザーデータベースが破損して起動しなくなった場合の対処方法」を解説します。

[内ヶ島暢之，ユニアデックス株式会社]

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

→この他の起動トラブルの実例を見る

トラブル 09（カテゴリー：起動）：ユーザーデータベースが破損して起動しない

目次

• トラブルの実例
• トラブルの原因
• 解決方法

　前回のmasterデータベースに起因した起動トラブルに続いて、今回は「ユーザーデータベース」に起因する起動障害について紹介します。

トラブルの実例：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が“今のところ”業務に大きな影響を与えていないとしても、決して放置してはいけません。もし管理領域も壊れていたならば破損がさらに広がってしまいます。早期の対処を推奨します。

「ユーザデータベースが破損して起動しない」場合の解決手順

1. エラーログを確認して破損しているデータベースを確認する
2. データベースバックアップのリストアを行い、データベースを復旧する
3. DBCC CHECKDB、アプリケーションの動作確認を通じて整合性確認を行う

→この他のトラブルの実例を見る

（コラム）実務の現場から

　筆者は10年以上データベースサポートの仕事をしていますが、これまでに何度かデータベースの破損が業務に大きく影響を及ぼしてしまったケースに遭遇しました。

　中には……バックアップさえ取られていないケースもありました。この復旧には大変な労力を要しました。このケースでは、運よく数日前に開発システムへデータを移動したばかりだったので、まずそれを戻して、差分は紙の注文書をデータ化する力業で復旧させたのです。

　そのようなことが起こらないよう、バックアップを取ることはもちろんですが、それに加えて、普段から「バックアップが正しく取得されていることを確認」するルーティンを設けることを強くお勧めします。

　実は、取得したバックアップが本当に有効であるかを確認するには、「実際にリストアしてみる」しかありません。できれば運用の中に、本番系から開発系へのデータベース移動を組み込んで、「バックアップの有効性を確認する仕組み」も取り入れていただきたいと思います。

　この「バックアップを採取していなかったとき」のトラブルシューティングについては、別の回で紹介したいと思います。

本トラブルシューティングの対応バージョン：SQL Server 全バージョン

筆者紹介

内ヶ島 暢之（うちがしま のぶゆき）

ユニアデックス株式会社所属。Microsoft MVP Data Platform（2011〜 ）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を行っていた。2016年4月よりIoTビジネス開発の担当となり、新しい仕事に奮闘中。ストレッチをして柔らかい身体を手に入れるのが当面の目標。

椎名 武史（しいな たけし）

ユニアデックス株式会社所属。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。