Если на основном сервере в параметре log_archive_dest_n указана опция delay с ненулевым значением, то при выполнении операций, создающих большой объём redo (например, удаление или вставка большого количества данных в таблицы, импорт, пересекционирование крупных таблиц, etc.), возможна ситуация, при которой за этот временной промежуток нагенерится такое количество логов, что заполнится файловая система для их хранения и база остановится. Самое неприятное, что RMAN не бэкапит логи, которые ещё не были применены на standby-сервере.
Решение проблемы:
За некоторое время до проведения работ на standby-сервере выполняем команды
-- Остановим накат логов ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -- Запустим его снова с опцией NODELAY ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;
Опция NODELAY указывает, что standby должен игнорировать задержку, указанную в параметре log_archive_dest_n основного сервера, и накатывать логи сразу же по мере их появления.
Теперь можно проводить работы на основном сервере. В случае, если аппаратные конфигурации обоих серверов совпадают (прежде всего, у них должны быть сравнимые по производительности дисковые подсистемы) и пропускной способности сети, соединяющей их, достаточно для передачи логов, то standby не будет "отставать" от основного сервера и единственное, о чём нужно заботиться - это своевременный бэкап логов. Тут может помочь cron.
Необходимую минимальную пропускную способность сети в мегабайтах/с можно вычислить по формуле (Metalink Doc ID 247129.1)
Required bandwidth = ((Redo rate in bytes / 0.7) * 8) / 1000000
В некоторых случаях Redo rate in bytes может достигать нескольких Гб в минуту.
Когда работы будут завершены, надо вернуть обратно задержку при накате логов:
-- Снова остановим накат логов ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -- Запустим его с задержкой ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;