Очевидно, что архивные журналы повторного выполнения копируются так часто, как требуется, но имеет ли смысл резервное копирование? онлайн повторить журналы? Является ли онлайн-журнал повторов открытым и активным файлом, поэтому его копирование в этом состоянии является пустой тратой времени (как и резервное копирование открытой базы данных)?
Если онлайн-журнал повторов не переключился в течение 20 минут (чтобы журнал был доступен для архивирования), тогда, если система выйдет из строя и требуется восстановление носителя, и вы не сделали резервную копию онлайн-журнала повторов, вы наверняка только что потеряли последние 20 минут транзакций?
Я знаю, что есть другие, более надежные способы передачи информации о повторном выполнении, чтобы ничего не было потеряно, но меня все еще интересует состояние онлайн-файлов журнала повторного выполнения.
Спасибо за ваше время.
Уточняющее обновление ...
Существует регулярный фоновый процесс, который отправляет архивные файлы журналов и файлы онлайн-журналов. У меня нет особого контроля над этим процессом. Можно ли использовать файлы онлайн-журнала или они могут быть повреждены, если журнал записывался при создании резервной копии?
Рекомендуем вам дуплекс / мультиплекс ваши онлайн-журналы повторного выполнения. Таким образом, они записываются на два разных физических диска. В случае сбоя ваша база данных остановится (так как она не может записывать в журналы повтора). Вы завершаете работу и прерываете работу, затем вызываете базу данных в сохранившихся журналах повторного выполнения, затем вы можете перезапустить базу данных со всем мультиплексированием, когда вы разрешите проблему.
Еще одна вещь, которую следует учитывать, - это резервная база данных. Вы можете настроить это так, чтобы средство записи журнала выполняло повторную запись в приемник удаленной системы с резервной базой данных (применяется в реальном времени). Это делается почти в реальном времени. Преимущество - минимальное время простоя в случае отказа системы без необходимости восстановления. Просто активируйте резервную базу данных и вперед.
Рекомендации по зеркалированию групп журналов повторного выполнения на отдельных дисках - отличный совет. Обычно одновременно активна только одна из ваших групп журналов - остальные либо уже заархивированы, либо ждут архивирования. Вы не захотите копировать активный - он, скорее всего, будет бесполезен в сценарии восстановления.
Короче говоря, нет, вы не можете копировать живые журналы повторов во время работы db и надеяться получить что-нибудь ценное, когда закончите.
Это зависит от того, что вы подразумеваете под резервным копированием. Если вы имеете в виду это в традиционном смысле, то DCookie дал правильный ответ: «Короче, нет, вы не можете копировать живые журналы повторов, пока база данных работает, и надеетесь получить что-нибудь ценное, когда закончите». С другой стороны, есть более новые технологии резервного копирования, которые могут выполнять привязку томов на определенный момент времени. Если они могут привязать ваши файлы данных, файлы управления и журналы повторного выполнения на определенный момент времени, то у вас действительно есть кое-что полезное. Если бы эти данные должны были быть восстановлены при вызове базы данных, они бы вели себя так, как если бы питание было отключено во время моментального снимка. Любые незафиксированные транзакции будут отменены, но зафиксированные транзакции не будут потеряны до момента, когда была сделана привязка.
Если вы хотите «очистить» текущий журнал повторов, чтобы убедиться, что у вас есть его архив, вы можете выпустить
alter system switch logfile;
из SQLPLUS или RMAN
Это приведет к архивированию текущего журнала, который затем можно будет сделать резервную копию за пределами сайта.
Другой вариант - использовать журналы повтора меньшего размера, чтобы естественная скорость транзакций вашей базы данных вызвала переключение журнала и архивирование с интервалом, который вам удобнее.
"alter system switch logfile" не приводит к принудительному архивированию текущего журнала, а только переключает на следующий журнал из текущего, делая его доступным для архивирования. "изменить текущий журнал системного архива" принудительно создает архив текущего журнала.
Если ваши сетевые журналы доступны после перезапуска и не повреждены, Oracle должна иметь возможность распознать их и воспроизвести их, а также заархивированные. Единственное, что будет потеряно, - это транзакции, еще не совершенные на момент сбоя.
Конечно, если ваши жесткие диски выйдут из строя, вы потеряете все, что не было скопировано. Вот почему у вас должно быть зеркальное отображение или, что лучше, журналы повторного выполнения хранятся на разных дисках / контроллерах / компьютерах.