> может, конечно, сейчас уже не актуально, но просто интересно пробовали ли вчера стартовать базу с параметром _corrupted_rollback_segments, прежде чем апдейтить дикшинари?

_corrupted_rollback_segments will show list of currupted blocks
if THERE ARE BLOCKS WAS SETING IN SYS.UNDO$ AS CURRUPTED ONLY
He had to use dbverify (or dbv) for get list of currupted blocks.
as i posed before.

then who kill database, if we have only currupted blocks ???????
It has to be usual recovery procedure.

then :
db doesn't start --> what messages

in this situation we have to do (step by step)

> startup nomount pfile=....; <- name of initfile
> alted database mount;
> recovery database automatic;
...
-- check messages

> alter database open;

if recovery was unsuccess then we have to reset log files for exclude
step of rollback forward for uncommited transaction.
In this situation oracle will not use RBSs for restore uncommited transaction.
recovery step MUST be because probably we have different SCNs and differemt timestamps in headers of datafiles. and these SCNs doesn't equal with SCNs in rollback segments.

That is it.

note about dictionary :
I did it a couple times on sys.undo$ table without ANY problems.

Если вевсия 8.0.х то команда:

recover database automatic -->

должна быть

> alter database recover automatic; (я могу ошибиться только в опции automatic, кажется в 8.0 это уже было)

после восстановления и открытия базы:

> alter database open;

Команда : alter system reset logfiles -> имеет форму:

> alter system switch logfile; (т.к 8.0 может только переключать последнй журнал)

можно также применить режим пофайлового восстановления:

> alter database recover datafile '..file_name..'; -- для файлов данных
и
> alter database recover logfile '..file_name..'; для логов (но в случае если база была в режиме noarchivelog это большого смысла не имеет)
---------------------------------------------------------
Как мне видится проблема была в несоответствии SCN (это системный номер транзакции)
между:
-- SCN в заголовочном блоке файла данных
-- в RBS
-- и может быть в лог файле
при силовом переключении журнала последний SCN сбрасывается, но мы теряем транзакции которые записаны в журнал,
но не успели записаться в файлы данных.