web-dev-qa-db-ja.com

SPステートメントの完了から取得された時間がRPC完了と大きく異なる場合のクエリのパフォーマンス

XEイベントからデータを収集したときに、以下のクエリのパフォーマンスを理解できません。

クエリ

DECLARE @Importdate DATETIME = ISNULL ((

SELECT ImportDatetime
FROM
Customertable
where CustomerID = 1
and OrderID =1 
) , '01/01/2000')

ステートメントのこの部分は1行だけを返します

SP statement completedは40秒を示します

RPC Completed上記のステートメントの場合64秒

RPCがこのような大きな違いを示す理由と、この問題を探す場所を理解するのに助けが必要ですか？そのように報告されたNWの問題はありませんが、ここで何が示され、上記のように単純なクエリはその実行時間に対して高いようです

アドバイスをお願いします

sql-serversql-server-2014query-performanceextended-events
2
BeginnerDBA

まず、次のように述べます。

はい、これはストアドプロシージャのステートメントの一部です。

これはストアドプロシージャの唯一のステートメントですか？テストすれば不可能ではありませんが、そうでなければ、変数を設定してそれを使用したり、他のことをしたりしないストアドプロシージャがあると、奇妙に思えます。では、ストアドプロシージャの他のステートメントについてはどうでしょうか。すべての時間を考慮したことがありますか？

  1. RPC:Starting —プロシージャを実行するためのリモートプロシージャコール（つまり、アドホッククエリバッチではありません）
  2. SP:Starting —ストアドプロシージャが開始します（キャッシュにない場合、コンパイルに時間がかかります）
  3. 1つ以上のセット：
    1. SP:StmtStarting
    2. SP:StmtCompleted
  4. SP:Completed
  5. RPC:Completed

レイテンシを確認する場合は、必ずEndTimeをキャプチャして、次の値を比較してください。

  • 最後のSP:StmtCompletedおよびSP:Completed
  • SP:CompletedおよびRPC:Completed
  • 返される結果行が多い場合や、呼び出し側のアプリがそれらを十分に速く消費していない場合、そのmightは、最終的なSP:StmtCompletedとSP:Completedの間の予想される時間差よりも大きく表示されます。

さもないと：

  • コンパイル時間可能性がありますSP:StartingのEndTimeと最初のSP:StmtStartingのStartTimeの間の差。
  • このプロシージャには他にどのようなステートメントがあり、期間は何ですか？

次に、私たちは本当にここで数秒について話しますか？ 2つのSELECT（または類似の）述部が与えられた単一の列のINTに40秒か？インデックスがなくても、alotの競合がないか、テーブルに数十億行あるか、またはそのようなものでない限り、そのようなクエリは40秒のかなり前に返されると思います。間違った数で割った可能性はありますか？ 1000000で除算する必要があると思います。これらの数値が正しければ、その単純なSELECTが40秒かかるのは、他の何が残りの24秒を占めるのかよりも、もっと心配になります。

1
Solomon Rutzky

一般的に言えば rpc_completedにはネットワーク時間が含まれますが、sp_statement_completedには含まれません 。クエリは1行しか返さないため、これはクエリの場合によくあることです。

そのため、ネットワーク経由でクライアントにデータを送信するために余分な時間が費やされていることが1つの説明です。

このクエリの待機統計を測定して、違いを説明するASYNC_NETWORK_IO待機が24秒あることを確認できます。

サーバーにSSMSがインストールされている場合は、リモートデスクトップからサーバーにクエリを実行できます。ネットワークの待機時間はほとんどありません。この場合、このステートメントのこれら2つのイベントの時間にはほとんど違いがありません。

1
Josh Darnell