もっと危機的なトランザクションログの拡張エラーが発生した（ファイル管理トラブル）：SQL Serverトラブルシューティング（26）（1/2 ページ）

連載バックナンバー

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

トラブル 19（カテゴリー：ファイル管理）：もっと危機的なトランザクションログの拡張エラーが発生した

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

トラブルの原因を探る

　障害発生直後のエラーログを確認すると、確かにトランザクションログの拡張エラーが出ていました（図19-1）（図19-2）。

図19-1　障害発生直後に取得したsys.databasesでの出力結果

図19-2　障害発生時に出力されていたエラーログ

　ただしトラブル事例18とは違い、今回はバックアップジョブが起動していなかったという、単なるバックアップ運用体制のミスが原因ではありません。

　図19-1のsys.databasesでの出力結果には、log_reuse_wait_desc列にログを再利用できない理由が記述されます。その値が「NOTHING」ならば「（問題は）なし」ですが、対象とするデータベース「TESTDB」の値は「LOG_BACKUP」と記述されていました。

　続いて、緊急対処としてトランザクションログのバックアップを実施した直後のsys.databasesの出力結果を確認します（図19-3）。

図19-3　トランザクションログのバックアップを行った後に取得したsys.databasesでの出力結果

　ここでは、log_reuse_wait列に着目します。log_reuse_wait列には、「前回のチェックポイントの時点で、トランザクションログ領域の再利用が待機中であるか否か」のステータスが示されます（*1）。値は、障害発生直後の「2」ではなく、「4」に変わっていました。

sys.databasesのlog_reuse_wait列に関するステータス例（出典：Microsoft Developer Network）

　トランザクションログバックアップを1度行った後のlog_reuse_wait列の値「4」は、「アクティブなトランザクションがまだ存在している」状況を示しています。

　これはどんな状況でしょう。トランザクションログは変更履歴を記録するに当たり、BEGIN TRANからEND TRANまでを1つの処理としてシーケンシャルに記録していきます。END TRANが記録されるまでは、閉じられていないトランザクションがまだあると見なし、記録を開始した仮想ログを切り捨てません。つまり、トランザクションログを「循環的に再利用できない状態」となっているわけです。

　そして、2回目／再起動後のトランザクションログバックアップが成功した理由は、インスタンスの再起動によって、トランザクションログバックアップを阻害していたトランザクションが強制終了されたためです。