простой update медленно работает

-error
Дата: 17.03.2011 15:57:28
Коллеги, прошу помощи.
Наткнулся на странную, на мой взгляд ситуацию, информации по решению которой никак не удается найти.

Все вроде бы просто. Необходимо в таблицу добавить столбец со значением по умолчанию и ограничением not null. Таблица обычная, размером 3,32ГБ, содержит ~71М строк. По ней есть 3 индекса, 3 check ограничения, PK и FK.

Проблема в том, что update, порождаемый этим процессом, работает крайне медленно. Теневой процесс при этом практически не производит IO, потребляя при этом около 100% процессорного времени. Лишних ожиданий не наблюдается. В общей сложности оно собирается работать порядка 5 часов (по v$session_longops).

Чтобы исключить перезапуск update'а, перед выполнением этой операции пробовал сделать `lock table ... in exclusive mode'. Так же пробовал отключить FK (к стати, как они могут влиять на производительность update'a?). Не помогает.

Добавлять столбец без `not null' так же не помогает.

Добавить столбец без default, а потом запустить update не пробовал, т.к. получим тот же самый update.

Вопрос классический. "Кто виноват и что делать?".

PS. Action этот происходит на 9.2.0.8 под HP-UX 11.31.
upd
Дата: 17.03.2011 16:27:27
Слишком общая информация.
Дайте подробную статистику по сессии, в которой выполняется данный запрос.

Может у вас система I/O медленная. И это вполне нормальная ситуация.
-error
Дата: 17.03.2011 16:44:44
upd
Дайте подробную статистику по сессии, в которой выполняется данный запрос.


Что под этим понимается?

Может у вас система I/O медленная. И это вполне нормальная ситуация.


Ситуация, на мой взгляд, все же не нормальна, поскольку большую часть времени сессия проводит не в ожидании IO, а на CPU.

Тестовая БД, на которой экспериментирую, лежит на xp24k. Размазана по 216 шпинделям. Не самая тормозная вещь. На хосте 4 fc карты. `select /*+ full(t) */ count(*) from aggr_transaction_log t' на тесте выполняется за 1 минуту.
CV
Дата: 17.03.2011 18:01:14
хм а с undo и redo у вас там при этом все нормально по i/o и тд?
-error
Дата: 17.03.2011 18:42:06
Сейчас нет возможности проверить, но, как я уже писал, дисковой нагрузки эта сессия вообще никакой не создает. Поэтому, вряд ли. В трейсе 10046 видны ожидания чтения файлов данных, принадлежащих таблице и редкие ожидания undo allocation latch. Ожиданий, связанных с redo нет совсем.
upd
Дата: 17.03.2011 18:54:56
-error
Сейчас нет возможности проверить, но, как я уже писал, дисковой нагрузки эта сессия вообще никакой не создает. Поэтому, вряд ли. В трейсе 10046 видны ожидания чтения файлов данных, принадлежащих таблице и редкие ожидания undo allocation latch. Ожиданий, связанных с redo нет совсем.


Что значит редкие?

Нужно время ожидания смотреть.

select 
  event, 
  time_waited_micro/power(10,6)/60 time_min 
 from 
  v$session_event
 where sid=<SID сессии>
 order by 
 time_waited 
desc;
ten
Дата: 20.03.2011 13:41:06
-error,

Есть ли на таблице триггеры?