2010-12-31 9 views
0

私は約60列のテーブルにデータを格納するために使用しているストアドプロシージャを持っています。私はこのように1000個のexec文をgenereatedていますストアドプロシージャを1000回実行する方法

exec PopulateCVCSTAdvancement 174, 213, 1, 0, 7365 
exec PopulateCVCSTAdvancement 174, 214, 1, 0, 7365 
exec PopulateCVCSTAdvancement 175, 213, 0, 0, 7365 

たびに、ストアドプロシージャが1〜3000記録(通常は約2,000の記録)から、任意の場所に挿入されます。 「サーバー」は、サーバーOS上で使用可能な4ギガバイトのメモリを搭載したデスクトップハードウェアを実行しています。私が持っている問題は、最初の10〜15回の実行のたびに平均1〜2秒後、次の10〜15は決して終わらないように見えるということです。私はこれを正しくしていますか?私はこれをどのようにするべきですか?

ありがとうございます! トップ10ウェイター:

LAZYWRITER_SLEEP 
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 
REQUEST_FOR_DEADLOCK_SEARCH 
XE_TIMER_EVENT 
FT_IFTS_SCHEDULER_IDLE_WAIT 
CHECKPOINT_QUEUE 
LOGMGR_QUEUE 
SLEEP_TASK 
BROKER_TO_FLUSH 
BROKER_TASK_STOP 
+0

ボトルネックが何であるかを調べる必要があります。 waitstats DMVは何を言っていますか? –

+0

このテーブルには400以上の行があります。私が投稿すべき具体的なものは何ですか? –

+1

その数字は累積的なので、一時的なテーブルにスナップショットを作成し、長い待ち時間を生成するアクションを実行し、次に2つを比較してどのWaitタイプが最も増加したかを確認します。 (または、DBV SQLPERF( "sys.dm_os_wait_stats"、CLEAR);でモニタリングツールを使用していない場合は、DMVの数値を0にリセットしてください) –

答えて

0

optimise for unknownヒントを追加することができます。

具体的には、私は別のテーブルに戻って参加しましたが、cteのジョイン基準の中にはnull値が含まれていて、それが永久に続行されました。 cteの選択基準の単純なisnull()が問題を解決しました。助けていただいた皆様に感謝します。

P.S.私はトランザクションでそれをラップした後に実行するには4分かかりました。

1

トランザクションで包み - それはかなり速く

+0

合意しましたが、なぜそれが突然の時間差を説明するのか分かりません(チェックポイントが多分蹴られていない限り) –

+0

トランザクションは効果がありません –

+0

(mysqlについては話す)、トランザクションでラップすると、 THENが実行されます(可能な限り最適化されています)。 – sethvargo

3

ランダムな思考ロードします:データベースのサイズは外の自動拡張取るのに十分な大きさであることを確認してください

  1. を方程式。デフォルトの成長率は10%で、データベースを増やしている可能性があります。これは、MDFとLDFの両方に適用されます。

  2. と同様にLDFのサイズをチェックし、あなたがパラメータスニッフィングを有していてもよく、負荷

  3. の期間中、あまりにSIMPLEに復旧モデルを変更します。あなたは、特定のパラメータで実行している場合、原因は私のストアドプロシージャのバグからあったが、ストアドプロシージャ

+0

良いヒント。ログが10%の自動増加に設定されていることがわかりました。今すぐ他人をチェックしてください。 –

+0

すでにシンプルに設定されています。私はまた、SPに再コンパイルを加えました。 –

関連する問題