連載
» 2017年06月26日 05時00分 UPDATE

SQL Serverトラブルシューティング(52):すぐに終了するはずの処理が、急に「いつまでたっても」終わらなくなった(パフォーマンストラブル) (1/2)

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ある処理が終わらない場合の発生例と対処方法」を解説します。

[椎名武史,ユニアデックス株式会社]

連載バックナンバー

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

トラブル 39(カテゴリー:処理遅延):「いつまでたっても」終わらない処理がある

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

トラブルの実例:普段はすぐに終了するはずの処理が、急に「いつまでたっても」終わらなくなった。

 処理をいったんキャンセルして再実行してみたが、やはり正常に完了しない。SQL Serverのパフォーマンスログを確認したところ、処理そのものの負荷は高くはなく、むしろ、ほとんど使用されていなかった。

 続いてDMVで「dm_exec_requests」を確認したところ、ステータスは「suspended」になっており、wait_typeは「LCK_M_IS」と出力されていた。

トラブルの原因を探る

 パフォーマンスログの確認後、SQL Serverの内部動作を調査するツール「DMV(Dynamic Management View)」で実行した「dm_exec_requests」のステータスが「suspended(停止)」となっていました。これは、何らかの要因によって処理が中断された状態を示しています。

 また、wait_typeが「LCK〜」で始まっている値は、「ロック待ち」が発生していることを示しています。ロックはトランザクションの一貫性などを確保するために使われる、データベースシステムに必須の機能です。処理の内容によって「Sロック」や「Xロック」などのロックモードを使い、システムは同時実行性と一貫性などを担保しつつ、処理を進めるようになっています。

 では、このロックはどんな状況で発生しているのでしょう。DMVで「dm_tran_locks(*1)」を実行すると、各トランザクションが要求しているロックの状況を確認できます(図1)。

photo 図1 DMVで「dm_tran_locks」を実行したところ、session_id「52」が従業員テーブルのISロックを要求したが、「ロック待ち」となっていた

 図1では、session_id「52」のセッションがデータベースに対する「Sロック」と、従業員テーブルに対する「ISロック」を要求していますが、そのうち従業員テーブルのリクエストステータスは「WAIT」で、ロック待ちになっています。

 同じ従業員テーブルに対してのロック要求を確認すると、session_id「51」のセッションが「Xロック」を要求して「確保済み(ロック済み)」になっています。つまり、session_id「52」は、session_id「51」が従業員テーブルに対してXロックを保持しているために、ロックの互換性(*2)がないISロックを確保できなかったことが分かりました。


       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。