Медленное обновление после усечения - PullRequest
3 голосов
/ 07 января 2010

У меня относительно простая инструкция по обновлению:

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 Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit.)

Ответы [ 2 ]

4 голосов
/ 07 января 2010

Спасибо за вклад, они помогли мне понять, что вызвало проблему: Chained Rows!

  • после вставки новых строк 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;

Еще раз спасибо за вклад, они помогли исключить некоторые потенциальные проблемы до тех пор, пока, наконец, цепочка строк не достигла моей головы.

3 голосов
/ 07 января 2010

Моим первым предположением будет

ANALYZE TABLE sv_konginfo COMPUTE STATISTICS;

или используя DBMS_STATS. Взгляните на Управление объектами схемы .

...