データベースが「未確認／SUSPECT」状態となり、アクセスできなくなった（起動トラブル）：SQL Serverトラブルシューティング（15）（2/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「データベースが“未確認”の状態となり、アクセスできなくなった場合の対処方法」を解説します。

[椎名武史，ユニアデックス株式会社]

解決方法

　このトラブルは、拡張子「mdf」のファイル＝データファイルの破損が原因であることが分かりました。データファイルの破損は、「データベースのバックアップからリストアする」ことで解決できます。完全復旧モデルを利用している場合のリストア手順は、第14回「ユーザーデータベースが破損して起動しない」で解説していますので、併せてご覧ください。

　今回はこの他に、「有効なバックアップがない」あるいは「バックアップを使えない」事情があるときの対処方法を解説します。もし有効なバックアップがなかったとしても、現在のファイルから一部だけでも修復できないかを試みることができます。

　ここでは、出力されたエラー824に記載されていた、データベースの一貫性確認ツールである「DBCC CHECKDB」を使います（*2）。データベースが「未確認」の状態のままではコマンドを実行できないので、事前準備として、固定サーバーロールで「sysadmin」の権限を持つメンバーが、ALTER DATABASEコマンド（*3）で対象のデータベースを「緊急（EMERGENCY）」モードに変更します。その後、CHECKDBコマンドを実行します。

*2：（参考）「DBCC CHECKDB」について（Microsoft Deveroper Network）

*3：（参考）「ALTER DATABASEのSETオプション」について（Microsoft Deveroper Network）

　CHECKDBコマンドを実行すると、以下のような一貫性確認の結果が表示されます。

CHECKDB により、データベース 'DBNAME' に 0 個のアロケーション エラーと 4 個の一貫性エラーが見つかりました。
repair_allow_data_loss は DBCC CHECKDB (DBNAME) で見つかったエラーの最小修復レベルです。

　データベースに一貫性の問題が発生していた場合は、一貫性を修復するための「最小修復レベル」が合わせて表示されます。

　最小修復レベルがrepair_rebuildならばデータが失われることなく修復できます。しかし、上記の例のようにrepair_allow_data_lossだった場合は、修復処理を行うと一部のデータが失われてしまう可能性があります。

　残念ながら、失われてしまうデータが何かを確認する方法はなく、設定されている制約が崩れてしまう可能性もあります（このような事態にならないよう「普段からバックアップを正しく取る体制を整える」ことを強くお勧めします）。

　データベースの修復は、ALTER DATABASEコマンドでデータベースを「シングルユーザー」モードに変更してから、修復オプションを使用したCHECKDBコマンドを実行します。

ALTER DATABASE DBNAME SET SINGLE_USER
GO
DBCC CHECKDB (‘DBNAME’, REPAIR_ALLOW_DATA_LOSS)
GO

　その後、修復状況を確認するために、再度一貫性を確認するCHECKDBコマンドと、制約を確認するCHECKCONSTRAINTSコマンドを実行します。

DBCC CHECKDB (‘DBNAME’)
GO
DBCC CHECKCONSTRAINTS (‘DBNAME’)
GO

　これでエラーが見つからなければ、データベースとしての一貫性が戻ったことになります。データベースの動作モードを「マルチユーザーモード」に変更して、「オンライン」にします。

ALTER DATABASE DBNAME SET MULTI_USER
GO
ALTER DATABASE DBNAME SET ONLINE
GO

　これでデータベースとしての一貫性は修復されました。ただし、アプリケーションとしての一貫性は保証されていません。こちらも別途、忘れずに手動で確認してください。

　なお、障害発生時の切り分けとして「デタッチ」「アタッチ」を使用してオンラインになるかを試す手段もあります。しかし、今回のようにデータベースが破損している状況では、絶対に実行しないでください。デタッチは成功しますが、アタッチに失敗する可能性が大だからです。デタッチ状態ではCHECKDBコマンドを実行できないので、修復させる手段が完全になくなってしまいます（*4）。

*4：（参考）「Database Detach and Attach」について（Microsoft Deveroper Network）

「データベースが未確認状態となり、アクセスできなくなった」場合の解決手順

1. エラーログを確認して破損しているデータベースを確認
2. データファイルが破損していたら、バックアップからリストアを試みる
3. バックアップを使用できない場合は、「DBCC CHECKDB」を実行し、破損状況と最小復旧レベルを確認する
4. 修復オプション付きでDBCC CHECKDBを実行する
5. DBCC CHECKDBとDBCC CHECKCONSTRAINTSを実行し、一貫性エラーを解消する。解消できたら、アプリケーションとしての整合性も確認する

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

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

筆者紹介

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

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

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

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