0

[データベース管理者サイトからの相互投稿で、ここでより良い牽引力が得られることを期待しています。いずれかのサイトを適宜更新します。]

SQL Server 2005 (SP2) に、次のような単一のクエリを含むストアド プロシージャがあります (わかりやすくするために簡略化しています)。

SELECT * FROM OPENQUERY(MYODBC, 'SELECT * FROM MyTable WHERE Option = ''Y'' ')
OPTION (MAXDOP 1) 

この proc が実行されると (そして 1 回だけ実行されると)、プランが sys.dm_exec_query_stats に表示され、「total_worker_time」の値が高くなります (例: 34762.196 ミリ秒)。これは経過時間に近いです。ただし、SQL Management Studio の統計では、予想どおり (6828 ミリ秒など) はるかに低い CPU 時間が示されています。通信相手のサーバーが遅いため、クエリが返されるまでに時間がかかりますが、多くの行は返されません。

私は、SQL Server 2005 の並列クエリが奇数の CPU 時間を示す可能性があるという問題を認識しています。そのため、クエリ ヒントを使用して並列処理をオフにしようとしました (ただし、実際には何もなかったとは思いません)。場合)。

CPU 使用率の 2 つの見方が異なる可能性があるという事実を説明する方法がわかりません。また、どちらが正確であるかもわかりません (CPU 使用率の方が高い数値である可能性があると考える理由は他にもありますが、測りにくい)。誰か私にステアをくれませんか?

UPDATE : 問題は OPENQUERY にあると想定していたので、OPENQUERY を使用しない長時間実行されるクエリを探してみました。この場合、統計 (STATISTICS TIME ON を設定して取得) は CPU 時間を 3315 ミリ秒と報告しましたが、DMV は 0.511 ミリ秒と報告しました。それぞれの場合の合計経過時間は一致しました。

4

1 に答える 1

0

total_worker_timeinsys.dm_exec_query_statsは累積です。これは、現在コンパイルされているバージョンのクエリのすべての実行の合計実行時間ですexecution_count。これが表す実行回数については、 を参照してください。

個々の実行のタイミングについてlast_worker_timeは、min_worker_timeまたはを参照してください。max_worker_time

参照: http://msdn.microsoft.com/en-us/library/ms189741.aspx

于 2012-01-25T12:19:55.447 に答える