10

Management Studio で実行されているクエリが中断される原因は何ですか?

  1. テーブル (1,100 万行) から単純な上位 60000 を選択すると、結果が 1 ～ 2 秒以内に返されます。
  2. クエリを上位 70000 に変更すると、結果に最大 40 分かかります。

別の関連する問題を少し検索したところ、DBCC FREEPROCCACHE を使用して修正する人に出会いました。

  1. DBCC FREEPROCCACHE を実行してから、70000 のクエリをやり直したところ、うまくいったようです。

ただし、問題は別のクエリでも発生します。

  1. 90000 まで増やしたり、[Right->Open Table] を使用してテーブルを開こうとすると、約 8000 レコードを取得して停止します。

テーブルを開くときにアクティビティ ログを確認すると、セッションが「Async_Network_IO」の待機タイプで中断されていることが示されます。90000 の選択を実行しているセッションのステータスは「スリープ中」です。これは、45 分で返された上記の選択 70000 クエリと同じステータスです。ステータスが「スリープ中」と表示され、「実行可能」に変化していないように見えるのは奇妙です（アクティビティモニターが30秒ごとに更新されます）。

その他の注意事項：

  • Open Table と select 90000 の両方を同時に実行していません。すべてのクエリは一度に 1 つずつ実行されます。
  • 32 ビット SQL Server 2005 SP2 CU9 を実行しています。SP3 へのアップグレードを試みましたが、インストールに失敗しました。このアップグレードを試みる前に、問題が発生していました。
  • サーバーのセットアップはアクティブ/アクティブ クラスターであり、どちらかのノードで問題が発生し、もう一方のインスタンスにはこの問題はありません。
  • この同じサーバー インスタンスに約 20 の他のデータベースがありますが、この 1 つの DB だけで問題が発生しています。
  • このデータベースはかなり大きくなります。現在、76756.19MB です。データファイルは11,513MB。
  • リモート デスクトップを使用してサーバー ボックスにローカルでログインしています。
4

2 に答える 2

10

待機の種類 "Async_Network_IO" は、SQL Server のネットワーク バッファーがいっぱいであるため、クライアントが結果セットを取得するのを待機していることを意味します。あなたのクライアントがタイムリーにデータを取得していない理由はわかりません。

もう 1 つのケースは、SQL Server がリモート テーブルに対してクエリを実行しているときに、リンク サーバーで発生する可能性があります。この場合、SQL Server はリモート サーバーが応答するのを待機しています。

注目に値するのはウイルス スキャナです。ネットワーク接続を監視している場合、時々遅延が発生することがあります。多くの場合、すべての CPU を占有していることから明らかです。

于 2009-08-25T19:00:28.070 に答える
2

一時停止とは、リソースを待機していて、リソースを取得すると再開することを意味します。引き戻しているサイズから判断すると、OLAPタイプのクエリを使用しているようです。

次のことを試してください。

  1. NOLOCKを使用するか、クエリの先頭でトランザクション分離レベルを設定します
  2. 実行プランを確認し、クエリをより効率的に調整します
于 2009-08-25T19:04:10.137 に答える