0

カーソルを使用する既存のストアド プロシージャのグループがパフォーマンスの問題の多くの原因であるという証拠を経営陣に提供する必要があります。これを達成するためのスクリプトとクエリを見つけるために、誰かが私を正しい方向に向けることができますか? カーソルを監視および測定する方法など。SQL Server 2005 を使用します。

ありがとう。

========更新============

経営陣は、サードパーティのベンダーに戻って、私たちにほとんどまたはまったく費用をかけずにプロセスを変更するように伝えるための弾薬を必要としています. これらは私たちの会計システムに影響を与えるサードパーティの proc であるため、最初にそれらを書き直す方法はありません。

トレース（すでに実行中）以外に、他にできることはありますか？sys.dm_exec_cursors(0) を使用すると、既存のカーソルのクイック リストを取得できることがわかりました。このようなものは他にもありますか？

4

4 に答える 4

4

厳密な測定を行い、実行時間と統計を収集して、問題の手順がカーソルを使用した手順であることを示しましたね。次に、収集された情報は、あなたの主張を証明するための優れた議論です。そうでない場合は...では、カーソルが何であるかをどのように知っていますか?

sys.dm_exec_query_statsを確認することから始めて、ワーカー時間 (CPU)、経過時間 (期間)、および I/O ごとに最もコストのかかるクエリを収集します。これらは、犯人を指摘し、実際に問題がカーソルによるものかどうかを確認するのに十分なはずです。

カーソルが実際に問題であることが判明した場合は、専用の DMV sys.dm_exec_cursors もあります。

たとえば、最も高価な CPU で頻繁に実行されるステートメントの上位:

select top(10) substring(Text,
  statement_start_offset/2, 
  (statement_end_offset-statement_start_offset)/2) as Statement
  , *
from sys.dm_exec_query_stats q
cross apply sys.dm_exec_sql_text(sql_handle)
where execution_count > 100
order by total_worker_time/execution_count desc
于 2009-12-17T22:35:45.227 に答える
0

最良の方法 (時間が許せば) は、一部のプロシージャをセットベースのステートメントとして書き直し、2 つを待機分析と比較することです ( http://technet.microsoft.com/en-us/library/cc966413.aspxには、この種のことを行う方法についての良い論文）。前後がないと、敵対者は「セットベースはこれ以上良くならないでしょう :-)」と言うだけかもしれません。

于 2009-12-17T22:31:08.207 に答える
0

SQL プロファイラーを実行し、問題のある sprocs でトレースをキャプチャできます (これにより、読み取り、CPU、期間などの重要な測定値が得られます)。

たとえば、セットベースのアプローチとして書き直すのが非常に簡単な例としてそれらの 1 つを取り上げ、それを実行して、そのプロファイラー トレースをキャプチャすることをお勧めします。このようにして、実際のパフォーマンスの違いを示すことができます。

可能であれば (つまり、本番環境ではない場合)、sproc の各バージョンを実行する前に実行計画とデータ キャッシュをクリアして、公平な比較ができるようにする必要があります。

また、カーソル バージョンとセットベース バージョンの実行計画を取得することもできます。

結局のところ、最終的な統計がすべてを物語っているので、「前」と「後」を比較することは有益です。

于 2009-12-17T22:32:31.533 に答える
0

パフォーマンス モニター (perfmon.exe) は、SQL Server のパフォーマンスをリアルタイムで分析するための優れたツールです。

于 2009-12-17T22:32:55.680 に答える