-1

ストアドプロシージャの1つが時間がかかりすぎることが示されている生産上の問題があります。平均して15-20秒かかりますが、1日に100秒以上かかりました。SQL Server 2012のストアドプロシージャに時間がかかりすぎています

これは先週の月曜日に起こったもので、今週もまた火曜日に繰り返されます。私たちはDB上の負荷をすべてチェックしました。月曜日または火曜日には大量のデータはありません。

同じDB上の他のストアドプロシージャはすべて、期待どおりに動作します。しかし、余分なテーブルに手を触れるこのストアドプロシージャだけでは、時間がかかりすぎます。インデックスを再作成した後は、正常になります。このストアドプロシージャは、他にもいくつかのストアドプロシージャと関数を内部的に呼び出します。

何が間違っている可能性がありますか?

ネットワークに関連するものではありません。影響は1つのストアドプロシージャだけです。

影響は1つのストアドプロシージャでのみ発生するため、DBの負荷やCPU使用率には関係しません。

月曜日または火曜日にのみ実行されるスケジュールされたジョブはありません。

+0

詳細が必要なようです。 SQLプロファイラを使用してトレースを実行して、パフォーマンスの問題が発生したときに何が起きているのかを特定できるかどうかを確認することをお勧めします。 –

+0

ええ実行計画は、ボトルネックの原因を調べるための重要な情報を提供します。あなたが共有している場合、私は検討するのに役立ちます。 –

答えて

0

アクティビティを見ると、ほとんどのCPUを処理するプロセスがわかり、SQLプロファイラを使用してクエリのリソース量を確認します。ストアドプロシージャがあまりにも多くのCPUを使用している場合は、クエリの実行方法を調べる必要があります。
クエリアナライザで、[Show Actual Execution Plan]を有効にします。ここでは、クエリがどのように実行されるか、インデックススキャンやテーブルスキャン、並べ替えアルゴリズムなどを使用するかどうかを調べます。最も多くのCPUを消費する関数を示します。読み込みクエリの場合は、テーブルを調べ、内部的に断片化されたテーブルがどのようにテーブルを参照しているか、データを取得するのに必要なパス数を確認します。それが書き込みのクエリなら、私は行/テーブルのロックとジャーナルを調べます。復旧モデルをシンプルからフルに変更すると、書き込みにかなりの時間がかかります。
実行計画を実行した場合は、ここでストアドプロシージャを使用して実行をペーストして、実際に実行を遅くすることがわかります。
SQLクエリ、インデックス作成、クエリヒント、およびテーブルのパーティション分割を変更して、それらを修正します。

関連する問題