Проблема с fast transaction rollback

Добрый день! Помогите кто может.

автор

SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for 64-bit Windows: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production

автор

Microsoft Windows Server 2003 R2 Enterprise x64 Edition Service Pack 2

Проблема такая
1) шел процесс заливки таблицы "insert into select" на 30-40 Гиг.
2) Закончилось место на винте.
3) Место добавил но поздно.
4) Транзакция начала свой откат...
5) 12 часов ничего не решили. Загрузка винта на 100%.
6) Перегрузил базу.
7) Никаких изменений не произошло, после перезагрузки откат продолжается. Загрузка винта на 100%.

База в ноуархивлоге.
в трейсы сыпяться ошибки следующего содержания:

автор

*** 2009-11-22 19:21:49.999 Parallel Transaction recovery caught error 30319

и

автор

*** 2009-11-22 19:26:26.032 Parallel Transaction recovery server caught exception 10388

Парметры связанные с откатом:
fast_start_parallel_rollback string HIGH
recovery_parallelism integer 16
Такой селект:

автор

select aad.STATE, aad.UNDOBLOCKSDONE, aad.UNDOBLOCKSTOTAL, aad.RCVSERVERS from V$FAST_START_TRANSACTIONS aad; 1\tRECOVERING\t50\t2007859\t32

Была похожая проблема на форуме:
/topic/281532&pg=2&hl=oracle+exe+p000#2552105
Но этот способ не принес ощутимых результатов :(
Спасибо за помощь.

Вроде поползло отктатываться, судя по V$FAST_START_TRANSACTIONS.
Но теперь начался совсем не по человечески рости UNDO. Предполагаю что места не хватит :(
В силах ли Оракла отменить этот долбаный откат?

Zetus,

У меня как-то база рухнула на большой трнзакции. После старта recovery шел бесконечно долго и все время шерстил undo. Поставил fast_start_parallel_rollback=false и отролбачилось за ожидаемое время. 11.1.0.7 Linux x64.

-2-

У меня как-то база рухнула на большой трнзакции. После старта recovery шел бесконечно долго и все время шерстил undo. Поставил fast_start_parallel_rollback=false и отролбачилось за ожидаемое время. 11.1.0.7 Linux x64.

Если я поставлю false то:

автор

If you change the value of this parameter, then transaction recovery will be stopped and restarted with the new implied degree of parallelisme.

значит откат не отменится а будет идти просто в оин поток. Если я правильно понял.
Подскажите, если в курсе - UNDO при этом перестанет рости?

Zetus

Подскажите, если в курсе - UNDO при этом перестанет рости?

Я лишь дал направление для размышлений. Экспериментировать на серьезной системе по совету с форума, тем более моему, ...
Ищите счетчики, чтобы оценить, сколько осталось, и металинк на предмет багов с параллельным откатом.

SUM(BYTES)/1024/1024 TABLESPACE_NAME STATUS
-------------------- ------------------------------ ---------
98232,25 UNDO ACTIVE
68,1875 UNDO EXPIRED
1,1875 UNDO UNEXPIRED


как теперь из статуса Ектив убрать? Пересоздавать?

Кароче как решилось. В конце концов мои параметры:
show parameter:
undo_retention integer 180
fast_start_parallel_rollback string FALSE

from dba_tablespaces:
UNDO NOGUARANTEE

после чего
select spid, p.PID, osuser, s.program from v$process p, v$session s where p.addr=s.paddr;
нашел процесс "ORACLE.EXE (P000)"
сделал ему сипуку, т.е. orakill и тот откат который шел несколько суток перешел и паралельного отката в обычный и за 6 часов рассосался.


P.S. Почему паралельный откат стопорился или шел но с невероятной медлительностью я так и не понял. Если кто-то знает в чем дело то подскажите пожалуйста.

Zetus

Почему паралельный откат стопорился или шел но с невероятной медлительностью я так и не понял. Если кто-то знает в чем дело то подскажите пожалуйста

1CPU, 1HDD 5200rpm, ATA ?

serpv

Zetus Почему паралельный откат стопорился или шел но с невероятной медлительностью я так и не понял. Если кто-то знает в чем дело то подскажите пожалуйста 1CPU, 1HDD 5200rpm, ATA ?

Ксеон с 2мя 4ядерных по 2,5 ГГЦ
16 ГБоепративки
а вот с винтами беда. три сказёвых. - но это не обясняет казус того что паралельный откат делался медленней обычного

автор

5) 12 часов ничего не решили. Загрузка винта на 100%.

это одного из трех?

Zetus

но это не обясняет казус того что паралельный откат делался медленней обычного

recovery_parallelism integer 16 - это чересчур даже для 3-х винтов.