none
不定期でクエリが時間切れになりましたが発生します RRS feed

  • 質問

  • お世話になっております。

    <サーバ>

    OS:Windows2012R2

    DB:SQLServer2014(SP無)

    <クライアント>

    Windows8.1

    の環境で半年前より月1回か2回不定期で

    「クエリが時間切れになりました」

    というエラーが発生します。クライアントアプリからODBCでSQLServerに接続しておりコマンドタイムアウトを3分に設定しています。

    クエリタイムアウト後、再度アプリを実行すると当該の処理が1秒かからず処理が完了するのですが原因特定の方法などご教示いただけないでしょうか。

    よろしくお願いします。


    2018年12月3日 6:50

回答

  • 経験上、ハブが壊れかけている場合、そのようなことがありました。通常、1秒かからず終わるクエリが、同じ条件で3分かかっても終わらないことは考えにくいので、ハードやネットワークの不具合を確認した方が良いかもしれません。

    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    2018年12月3日 7:15
  • ブロッキングの可能性は考えられませんでしょうか?

    同じテーブルを更新しているバッチ処理がある等、なんらかの処理にブロックされている可能性があります。

    「クエリが時間切れになりました」が発生するクエリがSELECTしかしておらず、かつダーティリードを許可するものであれば、
    クエリの先頭に
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
    この一行を足すだけでブロッキングが解消できる可能性が高いです。

    心当たりがあれば一度お試しください。

    2018年12月3日 23:59
  • トレースフラグで検証された件、了解しました。あとは、動的管理ビュー(DMV)を使ってみる等でしょうか・・・

    SQLServer: 動的管理ビュー(DMV)を使ってみよう / DMVを使ったパフォーマンス評価とトラブルシューティング
    https://qiita.com/maaaaaaaa/items/dc98081effcbf290a8ed


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    2018年12月19日 2:37
  • DMVは動的ですから、今実行していることの調査になります。
    #発行されたSQLはある程度記録されていますので、そのようなものなど必ずしも今現在だけの情報しか取れないというわけではありません。

    私が上で紹介したページにトラブルシューティングが載っています。私が説明するにしても同じことの繰り返しになります。トラブルシューティングは原因を特定するためのものですから、机上ではできず、実践でしかできません。まずは上記の記事を足掛かりにチャレンジしてみて下さい。チャレンジしていく中で力が付いてきますし、これまで気づかなかったことに気づくこともあります。このようなデバッグ的なことはご自分で行うしか解決方法が無いのです。何が原因なのかは回答する側には確かめる手段が無いのですから。

    また、ブロックキング等、SQL Server Mangement Studioの利用状況モニターでも確認することができます。

    SQL Server 2008 で「利用状況モニタ」ツールでロック待ちのプロセスをリストアップする(ロックの監視)
    http://d.hatena.ne.jp/matu_tak/20091114/1258151357

    ロックに関してあまりご存知ない場合は、以下の記事などが参考になると思います。以下の記事ではロック状態を取得するクエリも紹介されています。

    SQL Serverで「デッドロック」を回避する
    http://www.atmarkit.co.jp/ait/articles/0304/11/news003.html

    ところで、ロックを起こすようなクエリを発行しているようなところの心当たりはないのでしょうか? 不適切な分離レベルを用いているとか、一つの処理において複数のトランザクションが発生しているとか、そういった部分はないのでしょうか?
    問題となっている削除クエリは単純ですし、そのクエリだけで発生するようですし、次に実行すると瞬時に終わることからパラメータースニッフィングでもないようですし、やはりその削除クエリ時のブロッキングの発生を調べた方が良い気がします。
    タイムアウトを再現させることができるのであれば、上記で紹介したツールを使うとブロッキングが原因ということがすぐにわかるのですが・・・


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!


    2018年12月20日 1:17

すべての返信

  • 経験上、ハブが壊れかけている場合、そのようなことがありました。通常、1秒かからず終わるクエリが、同じ条件で3分かかっても終わらないことは考えにくいので、ハードやネットワークの不具合を確認した方が良いかもしれません。

    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    2018年12月3日 7:15
  • trapemiya様

    ご回答ありがとうございます。

    ハードやネットワークの不具合を確認してみます。

    2018年12月3日 7:25
  • ブロッキングの可能性は考えられませんでしょうか?

    同じテーブルを更新しているバッチ処理がある等、なんらかの処理にブロックされている可能性があります。

    「クエリが時間切れになりました」が発生するクエリがSELECTしかしておらず、かつダーティリードを許可するものであれば、
    クエリの先頭に
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
    この一行を足すだけでブロッキングが解消できる可能性が高いです。

    心当たりがあれば一度お試しください。

    2018年12月3日 23:59
  • お世話になっております。

    前回投稿させて頂いてから再度、「クエリが時間切れになりました」エラーが発生しました。

    今回はネットワーク障害の可能性、ブッキングの可能性を疑い、以下のサイトを参考に

    SQLServerのトレースログを出力するようにしました。

    https://www.projectgroup.info/tips/SQLServer/MSSQL_00000008.html

    トレースログにはクライアントから発行したSQL文が発行されていたため、ネットワーク障害の可能性は無いかと考えております。

    またブロッキングも確認されませんでした。

    SQL文は

    DELETE FROM テーブル名 WHERE  フィールド1 =AAA AND フィールド2 > BBB

    という削除クエリになっております。

    フィールド1,2ともINDEXを作っておりSSMSで実行プランを確認するとINDEX SEEKとなっています。

    フィールド2 > BBB を 

    フィールド2 BETWEEN BBB AND ZZZ

    に変更してみようか、

    SQLServerのSPを適用してみようかと考えております。

    アドバイスをいただけますでしょうか。

    よろしくお願いします。


    2018年12月19日 1:43
  • トレースフラグで検証された件、了解しました。あとは、動的管理ビュー(DMV)を使ってみる等でしょうか・・・

    SQLServer: 動的管理ビュー(DMV)を使ってみよう / DMVを使ったパフォーマンス評価とトラブルシューティング
    https://qiita.com/maaaaaaaa/items/dc98081effcbf290a8ed


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    2018年12月19日 2:37
  • trapemiya のアバター

    trapemiyaさん

    trapemiya のアバター

    いつも回答ありがとうございます。

    DMVのご紹介ありがとうございます。クエリを変更前と変更後で比較する場合に改善するかどうか判断するために使用するというツールになるのでしょうか。勉強不足で申し訳ございませんがご教示頂くと幸いです。

    2018年12月20日 0:06
  • DMVは動的ですから、今実行していることの調査になります。
    #発行されたSQLはある程度記録されていますので、そのようなものなど必ずしも今現在だけの情報しか取れないというわけではありません。

    私が上で紹介したページにトラブルシューティングが載っています。私が説明するにしても同じことの繰り返しになります。トラブルシューティングは原因を特定するためのものですから、机上ではできず、実践でしかできません。まずは上記の記事を足掛かりにチャレンジしてみて下さい。チャレンジしていく中で力が付いてきますし、これまで気づかなかったことに気づくこともあります。このようなデバッグ的なことはご自分で行うしか解決方法が無いのです。何が原因なのかは回答する側には確かめる手段が無いのですから。

    また、ブロックキング等、SQL Server Mangement Studioの利用状況モニターでも確認することができます。

    SQL Server 2008 で「利用状況モニタ」ツールでロック待ちのプロセスをリストアップする(ロックの監視)
    http://d.hatena.ne.jp/matu_tak/20091114/1258151357

    ロックに関してあまりご存知ない場合は、以下の記事などが参考になると思います。以下の記事ではロック状態を取得するクエリも紹介されています。

    SQL Serverで「デッドロック」を回避する
    http://www.atmarkit.co.jp/ait/articles/0304/11/news003.html

    ところで、ロックを起こすようなクエリを発行しているようなところの心当たりはないのでしょうか? 不適切な分離レベルを用いているとか、一つの処理において複数のトランザクションが発生しているとか、そういった部分はないのでしょうか?
    問題となっている削除クエリは単純ですし、そのクエリだけで発生するようですし、次に実行すると瞬時に終わることからパラメータースニッフィングでもないようですし、やはりその削除クエリ時のブロッキングの発生を調べた方が良い気がします。
    タイムアウトを再現させることができるのであれば、上記で紹介したツールを使うとブロッキングが原因ということがすぐにわかるのですが・・・


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!


    2018年12月20日 1:17