本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「トランザクションログ関連トラブルの対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:データベース移行プロジェクトでさまざまなテストを実施し、大きな問題は発生しなかった。ようやくテスト系の設定から本番系の設定に切り替え、新システムを稼働。1週間後、開発システムにデータを移行するためにバックアップを行った。
その数日後、ユーザーアプリケーションにエラーが発生し、アプリケーションが全面動作停止状態となった。再起動を行うも、状況は変わらなかった。
エラーログを確認すると、トランザクションログの拡張エラーが出ていました(図18-1)。
このエラーは、トランザクションログが肥大化し、ドライブの容量の上限に達するなどの要因によって、これ以上トランザクションログへ書き込みができなくなったときに発生します。また、再起動を行っても本情報はクリアされず、状況は変わらないので、エラーがそのまま発生し続けてしまいます。
今回のトラブルは、何らかの理由で「トランザクションログのバックアップが実行されなかったこと」が原因と推測されます。
完全復旧モデルでは、最初にデータベースの完全バックアップを採取するまで、トランザクションログの動作は単純復旧モデルと同じ動きをします。トランザクションログのバックアップを取っていない段階ならば、内部でログは切り捨てられます。つまり、ドライブの容量が枯渇するまでトランザクションログが肥大化してしまうことはありません。
しかし今回の場合は、データ移行のためにデータベースバックアップを行っています。ここが落とし穴でした。データベースバックアップを取ったことによって、トランザクションログのバックアップも行わなければ、ログを切り捨てられない状態に変わりました。その後もログバックアップが実行されなければ、仮想ログのステータスは「全て使用中」のままとなります。ドライブの空き容量がある限り、トランザクションログファイルは空き領域を確保するために拡張し続けます。最終的に、ドライブの容量がなくなった=拡張できなくなったのでエラーとなってしまったことになります。
なお、トランザクションログに書き込みができない状態では、SQLなどのDML(Data Manipulation Language:データ操作言語)文によるデータ更新ができないだけでなく、領域確保情報などの内部動作に伴うログ書き込みもできません。このために、インスタンス全体の動作、そしてサービス全体に影響を及ぼす大きなトラブルになってしまうのです。
Copyright © ITmedia, Inc. All Rights Reserved.