-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.
-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 минуту.
-error
Дата: 17.03.2011 18:42:06
Сейчас нет возможности проверить, но, как я уже писал, дисковой нагрузки эта сессия вообще никакой не создает. Поэтому, вряд ли. В трейсе 10046 видны ожидания чтения файлов данных, принадлежащих таблице и редкие ожидания undo allocation latch. Ожиданий, связанных с redo нет совсем.