原因不明の処理遅延が「不定期」に発生する（パフォーマンストラブル）：SQL Serverトラブルシューティング（49）（2/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は原因の追及が難しい、「不定期に処理遅延が発生する場合の対処例」を解説します。

[内ヶ島暢之，ユニアデックス株式会社]

解決方法

　今回の例では、トランザクションログの拡張処理が原因で遅延が発生していることを突き止めました。

　トランザクションログが拡張されるということは、「データベースを更新する量に対してログファイルのサイズが足りていない」ことを意味します。そのためにこのシステムでは、「トランザクションログファイルを現設定値よりも大きくする」ことが解決方法になります（図3）。

図3　ログファイルの初期サイズと拡張サイズの設定画面。ちなみに拡張を「割合指定」にすると、拡張されるたびにどんどん最大サイズが大きくなっていきます（預金の複利計算と同じです）

　併せて、バッチプログラムを見直したところ、「拡張されたログファイルを、当初想定のサイズに縮小する（元のサイズに戻す）コマンド」が記述されていました。日中に処理状況に応じて拡張されたログファイルは、夜中のバッチ処理によってサイズが元に戻されていたのです。本事例のシステムでは、運用が進んだことによって、既にトランザクションログファイルの初期設定値が適切でないことが分かっています。このコマンドを停止し、その代わりにログファイルのサイズを監視する処理を追加することによって、不定期に起きていた遅延がスッと解消され、その根本対策も実施できました。

　ちなみに「ファイル拡張に伴う遅延トラブル」は、ログファイルだけでなく、データファイルも同様に発生します。SQL Serverがファイルの拡張を行う場合、この拡張処理が終わるまでそのファイルへアクセスをロックするので、他の処理が「待ち」の状態になります。例えば、バッチ処理で「大量データを更新する」「大量のデータをロードする」「データの洗い替えをする」などの処理でも同様のトラブルが発生する可能性があります。

　このトラブル事例は、ログファイルサイズは設計段階から拡張サイズも含めて深く検討しておくこと、そして運用においてもファイルサイズの定点観測が必要なことをあらためて思い出させてくれます。運用においては、まず「監視するフロー」を設けることをお勧めします。併せて、「特に大きなデータの入れ替え」などが発生する際には、「データファイルやログファイルも設定し直すフロー」もセットにして実施する体制にすると、トラブル発生率はグッと下がると思います。

目次に戻る

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

筆者紹介

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

ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP Data Platform（2011〜）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、2016年現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。

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

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