Отцы, дорого времени суток.

Есть ситуация: клиент хранил FRA в рейде. Пара дисков екнулось, поменяли на новые, ушли в ребилд, который может продлится видимо очень долго. Пространство недоступно. По договоренности решили, что FRA будет новой. В целом я думаю это будет не проблематично, но все же хотел уточнить правильный порядок действий:


На сколько я вижу:

1) Задаем новый путь к FRA
2) Делаем копию контрол файла
3) Ресет редо-логов
4) Удаляем инфо о предыдущих бэкапах и архив логах

Не нашел инфы по такой ситуации, может что посоветуете. Не хочется в слепую ориентироваться на ora алерты.

В общем справился сам:

1) Соединяемся с простаивающим экземпляром

2) create pfile from spfile;
создаем файл с параметрами в текстовом виде

3) Руками удаляем в pfile параметр *.db_recovery_file_dest='путь'

4) startup mount pfile='путь к отредактированному файлу'
Запускаем с отредактированным pfile

5)alter system set bd_recovery_file_dest='путь'
Путь к новой папке FRA(создал перед выполнением комманды ..FRA\SID\)

6) alter database recover until cancel
рекавер до падения

7) alter database open resetlogs;
ресетим логи

8) create spfile from pfile='путь'
создаем spfile из pfile

9) shutdown immediate;
10) startup force;
останавливаем и стартуем с новым spfil и новым FRA

Vivat!San, имеется в виду разнести редо логи по разным физическим дискам, как рекомендовано? Должно быть так, но реальность вносит свои коррективы. В условиях, когда все экономят на системе и отказоустйчивости, да и на специалистах, это возможно только на крупных проектах, где население около миллиона и больше. Там могут себе позволить и железа побольше и спеца даже иногда нанять. В остальном просто помогаю всем кому требуется по всей стране, где есть проект. Для них оракл черный ящик. FRA вывели на отдельный физический диск, хватает места на архивлоги, бэкары делают и то блажь)