2

大量のデータ (この例では約 5m 行) を処理するストアド プロシージャがあります。パフォーマンスは大きく異なります。わずか 15 分でプロセスが実行され、4 時間も実行されたことがわかりました。

メンテナンスのため、およびロジックと処理が正しいことを確認するために、SP をセクションに分割しました。

  1. TRUNCATE後で自動テスト ツールを使用して検証できる作業テーブル (インデックス付き) にデータを入力します。

  2. 複数のテーブル (これらの作業テーブルの一部を含む) を結合して、別の作業テーブルを作成します。

最終出力が生成されるまで、1 および/または 2 を繰り返します。

私の懸念は、これが単一の SP であるため、最初の実行時に実行計画を取得することです (でもWITH RECOMPILE)。ただし、その時点では、作業テーブル (Work スキーマの永続テーブル) は空です。

索引付けスキームに関係なく、実行計画が貧弱になることを懸念しています。

作業テーブルのデータが構築された後に再評価された実行計画を利用できるように、SP を分割し、その中から個別の SP を呼び出すことを検討しています。また、EXEC を使用して動的 SQL を実行することへの言及も見ましたが、これRECOMPILEも明らかに取得される可能性があります。

私はまだSHOWPLAN許可を得ようとしているので、かなり盲目的に飛んでいます。

4

7 に答える 7

2

ロックの問題があるかどうかを判断できますか? 十分に小さいトランザクションで SP を実行していますか?

それをサブプロシージャに分割しても、何のメリットもありません。

基本的な最適化リソースなしで作業することで、誰かがあなたの生産性を心配する必要があります。これは、他にも目に見えない問題がある可能性があることを示唆しています。

于 2009-02-06T09:17:06.380 に答える
1

あなたが見ている変動性は「悪い」実行計画によって引き起こされていると確信していますか？これが原因である可能性がありますが、他にもいくつかの理由が考えられます。

  • dbマシンの「その他」のロード
  • 異なるデータを使用する場合、「簡単な」データと「難しい」データが存在する可能性があります
  • より多くのメモリ/ファイルストレージを割り当てる必要があるという問題
  • ..。

同じデータでSPを数回実行してみましたか？

また、実行時間/変動の原因を特定するために、詳細な測定を行って、問題をコードの特定のセクションに特定しようと思います。（最も簡単な方法は、spのさまざまなポイントにいくつかのログ呼び出しを挿入することです）。次に、そのセクションが遅い理由（「5M行;-)以外）を説明し、それを速くする方法を見つけてください。

今のところ、「spを分割する」ルートを進む前に答えるべきいくつかの質問があると思います。

于 2009-02-06T06:30:48.027 に答える
1

以下のリンクで「実行計画の分析」の無料コピーを入手してください。SP のフードの下で実際に何が起こっているかについてのヒントを得ることができるかもしれません。

http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/

于 2009-02-06T04:48:51.710 に答える
1

全体的なプロセスのいくつかの実行から「実際の」実行計画を取得するまで、舞台裏で何が起こっているのかを明確に把握することは非常に困難です。

おそらく考慮すべき1つのポイント。作業テーブルは一時テーブルの物理的なものですか? それらが物理的なものである場合、すべてのデータが挿入された後にインデックスを構築できるインデックス (つまりヒープ) なしで新しいテーブルに新しいデータを挿入することで、パフォーマンスが向上します。

また、あなたのプロセスの目的は何ですか。かなりの量のデータを移動しているように思えます。この場合、パーティション分割の使用を検討することをお勧めします。比較的簡単にメイン テーブルにデータを切り替えたり、切り替えることができます。

私が詳しく説明したことが明確であることを願っていますが、お気軽にさらに質問をしてください.

乾杯、ジョン

于 2009-02-06T09:11:36.157 に答える
1

In several cases I've seen this level of diversity of execution times / query plans comes down to statistics. I would recommend some tests running update stats against the tables you are using just before the process is run. This will both force a re-evaluation of the execution plan by SQL and, I suspect, give you more consistent results. Additionally you may do well to see if the differences in execution time correlate with re-indexing jobs by your dbas. Perhaps you could also gather some index health statistics before each run.

If not, as other answerers have suggested, you are more likely suffering from locking and/or contention issues.

Good luck with it.

于 2009-02-08T22:35:47.017 に答える
0

テーブル全体がメモリに収まる場合、テーブルスキャンは超高速であるため、データがないときに実行計画が間違っていると私が考えることができる唯一のことは、インデックスの代わりにテーブルスキャンを使用する側のエラーです。実行計画が作成されたときにデータがないために、実際に観察している、または確実に発生している他の問題はありますか?

クエリでインデックスの使用を強制できます...

私には、あなたが間違った道を進んでいるように思えます。

于 2009-02-06T04:40:38.200 に答える