本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ある処理が終わらない場合の発生例と対処方法」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
「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)。
図1では、session_id「52」のセッションがデータベースに対する「Sロック」と、従業員テーブルに対する「ISロック」を要求していますが、そのうち従業員テーブルのリクエストステータスは「WAIT」で、ロック待ちになっています。
同じ従業員テーブルに対してのロック要求を確認すると、session_id「51」のセッションが「Xロック」を要求して「確保済み(ロック済み)」になっています。つまり、session_id「52」は、session_id「51」が従業員テーブルに対してXロックを保持しているために、ロックの互換性(*2)がないISロックを確保できなかったことが分かりました。
参考リンク *2:ロックの互換性(Microsoft Developer Network)
Copyright © ITmedia, Inc. All Rights Reserved.