0

ユーザーは午前10時前にレポートを実行できました。同じレポートが非常に遅くなった後、ユーザーはたまに忍耐を待っていないことがありました。いくつかのトラブルシューティングの後、私は遅れの原因となっていた列を置き換えます。結果を出すために関数を使った計算列でした。突然計算された列がすべてパフォーマンスを低下させ始めたのはなぜですか?

ほぼ同時に、私は遅い実行レポートについて別の不平を感じました。それはいつもうまくいきました。

where (Amount - PTD) <> 0 

そして再び、Amount列が計算され、カラム:いくつかのトラブルシューティングの後、私は遅延の原因となった列を発見しました。

だから私の質問は以下のとおりです。

常にレポートの一部であった突然の計算列のすべてが、パフォーマンスが大幅に減速し始めた理由?誰もデータベースを使用していないときでも。

午前10時以降に実際に何が起こるか?

これらの列を永続化するとどのような欠点がありますか?ので、私は唯一の一般論で答えることができる -

はあなたがここでは詳細の多くを提供していないあなたに

答えて

1

ありがとうございます。

一般的に、データベースのパフォーマンスはボトルネックによって決まる傾向があります。クエリは1レコード、10レコード、1000レコード、100000レコードのテーブルで正常に実行され、100001レコードでは突然遅くなります。これは、システム内の境界を超えているためです。たとえば、データがもうメモリに収まりきらないなどです。

これらのボトルネックを特定するのは本当に難しいことですが、予測はさらに困難ですが、perfmonに目を留めて、CPU、ディスクのI/O、およびメモリの統計情報を確認してください。

計算された列は問題になることはまずありませんが、「where」ステートメント(特に別の計算)でそれらを使用すると、その列にインデックスがないと処理が遅くなる可能性があります。あなたの例では、別の計算列(Amount - PTD)を作成し、その列にも索引を作成することができます。