3

比較的単純な更新ステートメントがあります。

update sv_konginfo ki
set AnzDarl = 1 
where kong_nr in ( 
    select kong_nr
    from sv_darlehen
    group by kong_nr
    having count (*) = 1);

単独で問題なく動作します (約 150.000 レコードで約 1 秒)。

ただし、テーブルを切り捨ててからレコードを再挿入すると、次のようになります。

truncate table sv_konginfo;

insert into sv_konginfo (kong_nr)
select distinct kong_nr
from sv_darlehen;

update ステートメントは、まったく同じデータに対して非常に遅く (1 分以上) 実行されます。

2 番目のシナリオでパフォーマンスを向上させるにはどうすればよいですか? (Oracle Database 10g Enterprise Edition リリース 10.2.0.3.0 - 64 ビットを使用しています。)

4

2 に答える 2

4

入力していただきありがとうございます。彼らは問題の原因を突き止めるのに役立ちました: Chained Rows!

  • 新しい行の挿入後、AnzDarl (および他のいくつかの列) は null です
  • 列が 1 (または他の値) に設定されている場合、列はさらに多くのスペースを占有します。

次のSQLを使用してこれを確認できました。

select chain_cnt 
from user_tables 
where table_name='SV_KONGINFO';

Truncate の後、chain_cnt は 0 でした。Update の実行後、chain_cnt は劇的に増加し、影響を受けた行の数と等しくなりました。

このように PCT_FREE を増やすと、パフォーマンスの問題が解決しました。

alter table sv_konginfo pctfree 40;

最後にチェーンされた行が頭に浮かぶまで、いくつかの潜在的な問題を除外するのに役立ちました。

于 2010-01-07T15:15:32.883 に答える
3

私の最初の推測は

ANALYZE TABLE sv_konginfo COMPUTE STATISTICS;

または使用しDBMS_STATSます。スキーマ オブジェクトの管理 をご覧ください。

于 2010-01-07T12:42:12.053 に答える