更新緩慢截斷

後，我已經有了一個相對簡單的更新語句：更新緩慢截斷

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

運行在它自己的好（約1秒約150.000記錄）。

但是，如果我截斷表，然後重新插入記錄：

truncate table sv_konginfo; 

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

更新語句運行（超過一分鐘）非常緩慢的工作完全一樣的數據。

如何在第二種情況下提高性能？（我們使用Oracle數據庫10g企業版發佈10.2.0.3.0 - 64位）

來源

2010-01-07 Thorsten

在您可以說您已經改進了更新的性能之前，您需要確定是什麼導致它首先變慢。我將開始在truncate + insert之前和之後獲取執行計劃，並且我也想知道在truncate + insert之前和之後有多少行正在更新。例如，在插入之後，sv_konginfo中的行比在截斷之前有更多的行嗎？ – 2010-01-07 12:46:21

感謝您的想法，但您提到的一點是爲什麼我對性能感到困惑：表中的數據和執行計劃完全相同！ – Thorsten 2010-01-07 15:10:20

感謝您的意見，他們幫助我找出造成問題的原因：連鎖行！

新行AnzDarl的所述插入件（和其他一些列）後均爲空
當列被設置爲1（或其它值），它們佔據更多空間

我可以檢查此使用下面的SQL：

select chain_cnt 
from user_tables 
where table_name='SV_KONGINFO';

的截斷後，chain_cnt爲0運行更新後，chain_cnt急劇增加，等於麻木呃受影響的行。

這樣增加PCT_FREE解決了性能問題對我來說：再次

alter table sv_konginfo pctfree 40;

感謝您的輸入，它們幫助排除一些潛在的問題，直到最後行鏈接上升到我心中的頂部。

來源

2010-01-07 15:15:32 Thorsten

有趣！感謝（和+1）分享解決方案。 – 2010-01-07 15:18:47

感謝upvoting，但我想問題描述並沒有太多的幫助將問題的讀者指向正確的方向...... – Thorsten 2010-01-08 10:17:02

我的第一個猜測將是一個

或使用DBMS_STATS。看看Managing Schema Objects。

來源

2010-01-07 12:42:12

這也是我的第一個猜測，但它沒有改變任何東西。 – Thorsten 2010-01-07 15:02:51

你能重現這個問題嗎？ – 2010-01-07 15:06:09

是的，這個問題是完全可重複的。看看我自己的回答是怎麼回事。 – Thorsten 2010-01-07 15:17:19

更新緩慢截斷

回答

相關問題