本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ロックされたわけではないのに終わらない処理がある場合の確認方法と対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:これまで問題がなかったのに、急に処理が遅くなった。
SQL Serverのパフォーマンスログを確認すると、普段の傾向とは多少異なる部分はあったが、それが明らかなボトルネックになるほどではなく、他の処理にも影響は及ぼしてはいなかった。
まずは前回のトラブル事例と同様に、SQL Serverの内部動作を調査するツール「DMV(Dynamic Management View)」で「dm_exec_requests」のステータスを確認します。ステータスは「running(実行中)」でした。前回のトラブル事例では、処理が中断された「suspended(停止)」のステータスとなってしまい、ロック待ちが発生していたことが原因でしたが、今回は状況が違います。
今回のトラブル事例では、SQL Serverの「クエリストア」機能を事前に有効にしたシステムでトラブルシューティングを行います。クエリストアは、実行された処理時間や実行プランを保存し、確認できるSQL Server 2016から実装された新機能です。以前のバージョンでもそれらの情報を取得する方法はありましたが、クエリストアによって「より簡単」に情報を取得できるようになりました。
クエリストアは既定では無効になっているので、システムをSQL Server 2016に刷新したならば、この機能も有効にしておくことをお勧めします。設定は、「データベースのプロパティ」→ページの選択で「クエリストア」を選ぶ→操作モード(要求)を、オフから「読み取り、書き込み」に変更すると機能が有効になります(図1)。
クエリストアでは「その後に実行したクエリの処理状況」を収集できます。クエリストアで収集した結果は、データベースを展開した中の「クエリストア」メニューから確認できます。今回は、クエリストアの「リソースを消費するクエリの上位」を展開して、その状況を探ります(図2)(図3)。
表示されたクエリの中から「合計実行時間が長いクエリ」を探ると、プランID「8」とプランID「10」、2つのプランがリストアップされました(図3の右上のグラフ)。このグラフの縦軸は実行時間を示していますが、それぞれ実行時間がかなり違うことを確認できます。つまりこのシステムでは、『これまでは、処理時間の短いプランID「10」で実行されていたクエリが、何らかの理由でプランID「8」に変更された』ために、処理時間が長くなったことが分かりました。
Copyright © ITmedia, Inc. All Rights Reserved.