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

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

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

連載バックナンバー

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

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

トラブル 10（カテゴリー：起動）：「データベースが未確認状態」となりアクセスできなくなった

目次

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

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの実例：ビルの法定停電時にSQL Serverの事前シャットダウンを忘却しており、強制的に電源が落ちてしまった。

　マシンを起動したところSQL Serverのサービスは正常に起動したが、ユーザーアプリケーションからSQL Serverのデータベースへ接続しようとすると「メッセージ 926、レベル 14、状態 1、行 1 データベース 'DBNAME' を開けません。このデータベースは、復旧により問題ありと設定されています。詳細については、SQL Server エラー ログを参照してください」というエラーが表示され、データベースへアクセスできなくなった。

　WindowsイベントビューアーでWindows ログの「Application」の項目を確認すると、「エラー3414」が記録されていた（図10-1）。

図10-1　「エラー3414」を、Windowsイベントビューアーで確認

目次に戻る

トラブルの原因を探る

　SQL Serverの管理ツール「SQL Server Management Studio（以下、SSMS）」で状況を確認します。オブジェクト エクスプローラーを見たところ、対象のデータベースが「未確認」の状態になっていました（図10-2）。

図10-2　SSMSで確認すると、データベースが「未確認」の状態になっていた

　エラー3414には、「復元中にエラーが発生したので、データベース 'DBNAME' (11:0) は再開されません。復元エラーを診断して修正するか、既知の適切なバックアップから復元してください」と表示されています。また、その直前の「エラー824」に、「SQL Serverで、一貫性に基づいた論理I/O エラーが検出されました。このエラーは、ファイル 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\DBNAME.mdf'（略）のread 中に発生しました。（略）このエラー状態は深刻で、データベースの整合性を損なう可能性があるので、すぐに解決する必要があります。完全なデータベース一貫性確認（DBCC CHECKDB）を実行してください」とありました（図10-3）。かなり深刻なエラーのようです。

図10-3　「エラー824」も発生していた

　ちなみに、エラー824は第14回「ユーザーデータベースが破損して起動しない」でも遭遇したエラーです。データベースの復旧処理中にエラー824などの問題が発生すると、事象発生までのデータベースの整合性を保つために、「データベースを未確認の状態」に変更してユーザーからのアクセスを制限します。参考までに、SSMSで表示された「未確認」のステータスは、英語版では「SUSPECT」と表記されます（*1）。

*1：（参考）データベースの状態について（Microsoft Deveroper Network）

目次に戻る