SQL Azureでブロッキングしているクエリを探す

Finding Blocking Queries in SQL Azure – SQL Azure Team Blog – Site Home – MSDN Blogsを簡単に翻訳し紹介したエントリーです。

遅かったり、長い間実行しているクエリは、過度のリソース消費を伴い、クエリのブロッキングの原因となります。つまり、パフォーマンス劣化につながります。ブロッキングの意味は、SQL ServerとSQL Azureで違いはありません。ブロッキングは、ロックによる同時実行制御を行うリレーショナル データベース マネージメントシステムでは避けることができない特徴です。

以下のクエリは、合計時間が長かったり、ほかのクエリにブロッキングされたりして、実行時間が長いクエリのトップ10を表示します。

SELECT TOP 10 r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as st
WHERE r.blocking_session_id = 0 
    and r.session_id in 
    (SELECT distinct(blocking_session_id)
         FROM sys.dm_exec_requests)
GROUP BY r.session_id, r.plan_handle,
    r.sql_handle, r.request_id,
    r.start_time, r.status,
    r.command, r.database_id,
    r.user_id, r.wait_type,
    r.wait_time, r.last_wait_type,
    r.wait_resource, r.total_elapsed_time,
    r.cpu_time, r.transaction_isolation_level,
    r.row_count, st.text
ORDER BY r.total_elapsed_time desc

ブロッキングの原因は、残念なアプリケーション仕様であったり、残念な実行計画や、インデックスの不足が、ブロッキングの原因となりえます。

 

ブロッキングを理解する

 

SQL Azure上で、一つ目の接続が特定のリソースを共有ロックし、2つ目の接続が同じリソースに共有ロックと矛盾するロックを取得しようとした時にブロッキングが発生します。通常、最初の接続(共有ロック)がリソースをロックしている時間はとても短い時間です。ロックを解放したとき、二つ目の接続は、リソースにロックをかけ、プロセスを続けます。これは普通の動作で、頻繁に発生することでパフォーマンスへの影響はほとんどありません。

トランザクションの続行時間が長くなり、クエリがロックをかけ続けていると、ほかのクエリのパフォーマンスに影響が出ます。クエリがトランザクションを実行しておらず、(かつ、ロックヒント文を使用していない)場合、SELECT分はデータを読み取っている間だけ共有ロックを取得します。INSERTやUPDATEやDELETE分は、実行が終了するまでロックを取得しつづけることで、一貫性とロールバックを行うことができます。

クエリの種類や、トランザクションの分離レベルやロックヒントの使用有無などによって、クエリのロック時間や動きが変わります。詳細については、MSDNを参照してください。

まとめ

 

短くて速くて単純なクエリを多用することがブロッキングの減少につながります。長く大きなトランザクションは、ちいさな塊にし、トランザクション量を減らし、効率のいいSQLを書くようにすることがパフォーマンス観点状重要になります。一つの残念な遅いクエリがブロックすると、ほかの早いクエリまでもが遅くなってしまい全体としてパフォーマンスが劣化してしまいます。