Что, продуктив генерирует архивные логи быстрее, чем вы успеваете накатывать? Это не к добру. Тогда как же ваша база будет работать на новом месте? Производительность должна упасть.

Если, как я надеюсь, имеет место обратное, вы можете восстановить сейчас, а потом догонять логами - по мере генерации постоянно подкладывать и накатывать новые логи (в цикле пускать rollforward db XXX to end of logs), а когда настанет пора переключаться, rollforward db XXX to end of logs and complete. (Так реализуется простейшая версия стендбая).

Чтобы последние транзакции со старого места не пропали, перед остановом и переключением на вcякий случай принудительно рветё на старом месте все соединения, убеждаетесь, что их действительно в списке нет (что нет какого-нибудь длительного rollback'а какой-то забытой незакоммиченной транзакции, иначе придётся подождать) и выполняете ARCHIVE LOG FOR DATABASE имябазы (и снова ждёте некоторое время - команда отрабатывает быстро, но это не означает, что архивация логов совершилась так же быстро).

(Обязательно потренируйтесь на чём-нибудь поменьше).

Производительность, быть может, и не упадёт. Надо обладать знанием и пониманием реальных процессов при работе и восстановлении, использумого оборудования, а также проводить тесты. В частности, я не в курсе, используется ли при восстановлении буферный пул, а также не помню, какого размера блоками восстанавливается (но, скорее всего, мелкими - по размеру страницы табличного пространства).

Рассмотрю сферическую продукционную систему в вакууме. 2*N дисков выделено под данные, 2 диска под текущие логи и 2 под архивные. Т.е. 10й-массив и два зеркала. Диски для "текущих" и архивных, в основном, используются под последовательный доступ, потому скорость записи и чтения довольно высока. К данным же, возможно, идёт случайный доступ, весьма медленный, но благодаря буферному пулу грязным страницам нет нужды сбрасываться немедленно, а запись (конечно, нужно иметь ввиду ещё кое-какие настройки) идёт впараллель, то есть одновременно на несколько дисков, и при достаточно большом N скорость сопоставима со скоростью последовательной записи или чтения на одиночный диск.

При восстановлении же, если нет кеширования в буферном пуле и параллельной записи, (предполагаю, что) изменения будут применяться последовательно, картина будет удручающей, и величина N просто не имеет значения - восстановление будет идти сопоставимо со скоростью случайной записи на одиночный диск.

(Ну, конечно, кеш на запись на рейдконтроллере может резко поменять картину).

Я не помню, чтобы о таком было где-то написано. Надо экспериментировать.