[データベース管理者のサイトからクロス投稿されました。私は、必要に応じて、いずれかのサイトを更新します。]SQL Server 2005でOPENQUERYを使用するストアドプロシージャの 'total_worker_time'が高い
をI持って、次の（明確にするために簡略化）
SELECT * FROM OPENQUERY(MYODBC, 'SELECT * FROM MyTable WHERE Option = ''Y'' ')
OPTION (MAXDOP 1)
このprocのような単一のクエリが含まれているSQL Server 2005の（SP2）でストアドプロシージャが実行されている（そして1回だけ実行されています）、私はsys.dm_exec_query_statsに高い 'total_worker_time'の値（例：34762.196 ms）が表示されていることがわかります。これは経過時間に近い。しかし、SQL Management Studioでは、統計情報のCPU時間がかなり短くなっています（たとえば、6828ミリ秒）。この問合せは、サーバーとの通信が遅いために戻すまでに時間がかかりますが、多くの行は戻されません。
SQL Server 2005の並列クエリではCPU時間が奇妙になることがあるため、クエリヒントを使用して任意の派生を無効にしようとしました（ただし、実際にはいずれにしても何でもあった）。
CPU使用量を調べる2つの方法が異なるか、どちらが正確であるかについてはわかりません（CPU使用率が高いと思われる他の理由があります数字は、測定するのは難しいです）。誰も私に操縦を与えることができますか？
UPDATE：問題はOPENQUERYと仮定していたので、OPENQUERYを使用しない長期実行クエリを試してみました。この場合、統計情報（STATISTICS TIME ONを設定して取得）はCPU時間を3315msに報告しましたが、DMVは0.511msで通知しました。各ケースの総経過時間が合意された。
あなたは私たちが同じ結果を取得する場合、私たちが見ることができるので、再現可能なテストケースを提供することができますか？ –
私はそうしようとします。 – Yellowfog
私はテスト機器を製作しようとしましたが、CPU時間と経過時間に真の違いが得られる唯一の方法は、使用中のシステムに対してストアドプロシージャを実行することです。人工的な待つことは役に立たない。だから、私はこの不動産（または少なくともここに投稿するのに十分な単純なもの）でテスト機器を作る方法を見て苦労しています。 – Yellowfog