Вообще странно, если все аривредологи, нагенеренные за период создания бэкапа и необходимые для консистенции бд, перенеслись в бэкап - а комманда "PLUS ARCHIVELOG" должна это гарантировать, то штатного recover database перед открытием с ресетлогом должно хватать!
Возможно паралельно с бэкапированием идет еще и чистка старых архивредологов по регламенту (оставлять 50 последних, например ). Тогда часть архивредологов в бэкап не попадет и БД будет неконсистентная. В любом случае нужно копать не в сторону UNDO или ROLLBACK - которые тут абсолютно не причем, а в сторону наличия всех необходимых для восстановления архивредологов - охватывающих все время от времени перед бэкапом и последний - сразу после бэкапа.

Ну и вот эта волшебная комманда должна помочь -
recover database using backup controlfile until cancel;
alter database open resetlogs

Это очень волшебная комманда. Она всегда помогает при условии, что первый архивредолог создан до начала бэкапа, а последний архивредолог создан после создания бэкапа, да и в архивредологах нет дыр !!!!

Да забудьте вы за контролфайл !!!! Вы вообще его можете удалить и создать из текста коммандой create controlfile, перед восстановлением в режиме nomount. Потом использовать using backup controlfile комманду. Но вот если у вас будут дыры в архивредологах консистентную бд вы никогда не получите.

Ничего. Я лишь хотел сказать, что контролфайл тут не причем. И что бы копипастер не шел по ложному пути, как он уже свернул в сторону undo и redo :) А каталог можно и во внешнем репозитории хранить если что.

Смотрите. Можно еще попробовать вместо бекапа вида -
BACKUP DATABASE FORMAT 'F:\backups\db_%t_%s_p%p' PLUS ARCHIVELOG

Делать так (горячий бекап не обязательно делать используя PLUS ARCHIVELOG во фразе BACKUP DATABASE):

connect target /
sql 'alter system archive log current';
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE disk;
backup AS COMPRESSED BACKUPSET full database tag ORCL_FULL format 'F:\backups\%d_%T_%s_%p_FULL' ;
sql 'alter system archive log current';
backup tag ORCL_ARCHIVE format 'F:\backups\%d_%T_%s_%p_ARCHIVE' archivelog all delete all input ;
backup tag ORCL_CONTROL current controlfile format 'F:\backups\%d_%T_%s_%p_CONTROL';
release channel c1;
}

а потом посмотреть по логам что и как из архивредологов забекапилось

вот поэтому, волшебная комманда - "recover database using backup controlfile until cancel" должна помочь.
Если после нее все с бд хорошо (база открывается и ресетится нормально), то есть при этом все нормально с архивредологами, тогда у вас действительно может быть путаница с контролсами.

если текстом из trace, тогда только коммандой backup controlfile (и until cancel) !!!
иначе не откроется ресетом.

нет. Все длинные и не завершенные транзакции, которые накатились ' ... until cancel', но не завершились
будут откатаны назад при "...open resetlogs" на основе данных в ролбек сегменте (ундо).
Какая бы ни была длинная транзакция если ее завершение не попало в редо, то она будет при открытии БД откатана назад на основе ундо.