views:

152

answers:

2

I've got a relatively simple update statement:

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

which runs okay on its own (about 1 second for about 150.000 records).

However, if I truncate the table and then re-insert the records:

truncate table sv_konginfo;

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

the update statement runs very slow (more than a minute) working on exactly the same data.

What can I do to improve the performance in the second scenario? (We're using an Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit.)

+3  A: 

My first guess would be an

ANALYZE TABLE sv_konginfo COMPUTE STATISTICS;

or using DBMS_STATS. Have a look at Managing Schema Objects.

Peter Lang
That was my first guess, too, but it didn't change anything.
IronGoofy
Can you reproduce the problem?
Peter Lang
Yes, the problem is totally reproducible. See my own answer for what was going on.
IronGoofy
+4  A: 

Thanks for the input, they helped me figure out what caused the problem: Chained Rows!

  • after the insert of the new rows AnzDarl (and a number of other columns) are null
  • when the columns are set to 1 (or other values), they occupy some more space

I was able to check this using the following SQL:

select chain_cnt 
from user_tables 
where table_name='SV_KONGINFO';

After the Truncate, the chain_cnt was 0. After running the Update, the chain_cnt increased dramatically and was equal to the number of affected rows.

Increasing PCT_FREE like this solved the performance issue for me:

alter table sv_konginfo pctfree 40;

Thanks again for the input, they helped to rule out some potential issues until finally chained rows rose to the top of my mind.

IronGoofy
Interesting! Thanks (and +1) for sharing the solution.
Peter Lang
Thanks for upvoting, but I guess the problem description did not do much to help pointing readers of the question in the right direction ...
IronGoofy