本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「もっと危機的なトランザクションログ関連トラブルの対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:1年以上安定稼働しているシステムでオンライン処理を実行していたところ、ある日の夕方、急にオンライン処理でエラーが発生した。
エラーログを確認するとトランザクションログの拡張が失敗していたので、トラブル事例18の緊急対処方法を参考に、トランザクションログのバックアップを実施したが状況は変わらず、復旧できない。
原因が分からず、どうしようもないので、システムを再起動して再度トランザクションログのバックアップを取得したところ、緊急事態はひとまず回避できた。
しかし、根本的な対策としてトラブル事例18の原因として挙げられていたバックアップジョブも後で確認したが通常通り動作しており、根本原因はやはり分からない。また、システムを再起動したことで、他の業務も全面停止するまでのトラブルとなってしまったため、技術的な原因だけでなく、ビジネス的観点での根本原因の追究や対策の立案が求められている。
障害発生直後のエラーログを確認すると、確かにトランザクションログの拡張エラーが出ていました(図19-1)(図19-2)。
ただしトラブル事例18とは違い、今回はバックアップジョブが起動していなかったという、単なるバックアップ運用体制のミスが原因ではありません。
図19-1のsys.databasesでの出力結果には、log_reuse_wait_desc列にログを再利用できない理由が記述されます。その値が「NOTHING」ならば「(問題は)なし」ですが、対象とするデータベース「TESTDB」の値は「LOG_BACKUP」と記述されていました。
続いて、緊急対処としてトランザクションログのバックアップを実施した直後のsys.databasesの出力結果を確認します(図19-3)。
ここでは、log_reuse_wait列に着目します。log_reuse_wait列には、「前回のチェックポイントの時点で、トランザクションログ領域の再利用が待機中であるか否か」のステータスが示されます(*1)。値は、障害発生直後の「2」ではなく、「4」に変わっていました。
トランザクションログバックアップを1度行った後のlog_reuse_wait列の値「4」は、「アクティブなトランザクションがまだ存在している」状況を示しています。
これはどんな状況でしょう。トランザクションログは変更履歴を記録するに当たり、BEGIN TRANからEND TRANまでを1つの処理としてシーケンシャルに記録していきます。END TRANが記録されるまでは、閉じられていないトランザクションがまだあると見なし、記録を開始した仮想ログを切り捨てません。つまり、トランザクションログを「循環的に再利用できない状態」となっているわけです。
そして、2回目/再起動後のトランザクションログバックアップが成功した理由は、インスタンスの再起動によって、トランザクションログバックアップを阻害していたトランザクションが強制終了されたためです。
Copyright © ITmedia, Inc. All Rights Reserved.