「ログファイルが破損」して復旧しなくなった（起動トラブル）：SQL Serverトラブルシューティング（16）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「復旧処理に必要なログファイルが破損し、復旧しなくなった場合の対処方法」を解説します。

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

連載バックナンバー

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

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

トラブル 11（カテゴリー：起動）：「ログファイルが破損」して復旧しなくなった

目次

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

　「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」と「エラー824」が記録されていた（図11-1）。

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

　エラー3414とエラー824は、第15回「データベースが“未確認／SUSPECT”状態となり、アクセスできなくなった」でも遭遇したエラーのため、同様にデータベースを緊急（EMERGENCY）モードに変更して、データベースの一貫性確認ツールのDBCC CHECKDBを実行してみたが、データファイルの一貫性エラーは検出されなかった。

目次に戻る

トラブルの原因を探る

　今回もエラー824が発生しているので、SQL Serverの正常な動作に必要な構成ファイルが破損してしまった状況は第15回で紹介した事例と同じです。しかし、データベースの一貫性確認ツールのCHECKDBでチェックしても、データファイルの一貫性エラーは検出されませんでした。

　図11-1のエラーメッセージを再度確認してください。「SQL Serverで、一貫性に基づいた論理 I/O エラーが検出されました: (bad checksum)。このエラーは、ファイル 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\DBNAME_log.ldf'（略）のread 中に発生しました」とあります。エラーの検出されたファイルの拡張子が「ldf」であることから、破損したのはデータファイルではなく「トランザクションログファイル」のようです。トランザクションログファイルとは、データベースシステムがデータの整合性を保つための「復旧処理」に必要となる、「データの変更内容が記録されている」重要なファイルです。ちなみに、データファイルの拡張子は「mdf」です。

　トランザクションログファイルもデータファイルと同様に、チェックサムを使ってファイルの整合性を確認しています。ただし、トランザクションログファイルが破損していたとしても、データファイル内のオブジェクトの整合性には影響がないことから、CHECKDBコマンドではエラーとして検出されないのです。

目次に戻る

解決方法

　この解決には、アプリケーションとしての整合性を保つために、有効なバックアップからリストアして復旧します。リストアの手順は、第14回「ユーザーデータベースが破損して起動しない」で解説していますので、併せてご覧ください。

　もしバックアップがない場合は、第15回の「解決方法」を参考にしながら、以下のようにALTER DATABASEコマンド、repair_allow_data_lossオプションを使用したCHECKDBコマンド、CHECKCONSTRAINTSコマンドを実行して、「トランザクションログファイルを再作成」します。

ALTER DATABASE DBNAME SET SINGLE_USER
GO
DBCC CHECKDB (‘DBNAME’, REPAIR_ALLOW_DATA_LOSS)
GO
DBCC CHECKCONSTRAINTS (‘DBNAME’)
GO
 
（表示メッセージ）警告: データベース 'DBNAME' のログが再構築されました。トランザクションの一貫性は失われました。RESTORE チェーンが壊れ、サーバーが以前のログ ファイルのコンテキストを保持しなくなったので、以前のログ ファイルについて把握しておく必要があります。DBCC CHECKDB を実行して物理的な一貫性を検証してください。データベースは dbo 専用モードに設定されました。データベースが使用可能な状態になったら、データベース オプションを再設定し、余分なログ ファイルを削除してください。

　なお、トランザクションログを再作成すると、さまざまな設定情報も変更されるので注意してください。例えば、トランザクションログファイルのサイズや拡張サイズなどが既定値に戻ります。データベースの復旧モデルは「単純復旧モデル」になります。アプリケーションとしての整合性確認に加えて、データベースの設定も併せて確認し、必要に応じて再設定をしてください。

　全ての確認と再設定が終わったら、ALTER DATABASEコマンドを使用して、データベースの動作モードを「マルチユーザーモード」に変更します。「オンライン」になれば復旧は完了です。

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

「トランザクションログファイルが破損して起動しない」場合の解決手順

1. エラーログを確認して、破損しているデータベースを確認
2. データファイルの破損でなければ、トランザクションログファイルの破損と推測される。有効なバックアップがあれば、バックアップからリストアする
3. バックアップを使用できない場合は、r「epair_allow_data_loss修復オプション」を使用した「DBCC CHECKDB」コマンドを実行し、トランザクションログを再作成する
4. アプリケーションとしての整合性を確認する
5. データベースの設定を確認し、必要に応じて再設定する

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

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

筆者紹介

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

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

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

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