☰

архивировать резервные копии журналов в Oracle

tag-icon • tag-icon oracle-11g
архивировать резервные копии журналов в Oracle

Я администратор баз данных SQL Server и недавно мне поручили отвечать за среду Oracle. (11g)

Теперь я делаю резервные копии журналов транзакций на SQL Server по времени, а затем переношу их на другой сервер. Я хотел бы сделать это и с Oracle.

Журналы повторного выполнения Oracle, по-видимому, зависят от размера до переключения и позволяют серверу архивировать их.

Может ли кто-нибудь дать несколько советов/рекомендаций о том, как этого добиться?

Я также был бы признателен за любые советы по размеру журналов повторного выполнения и тому, как обрабатывать изменения в моделях использования в течение дня.

Я забыл сказать, что это на сервере Redhat 5 Enterprise.

решение1

Первое предложение — никогда не вмешивайтесь в работу вручную, если вы действительно не знаете, что делаете.

Что вам нужно сделать, так это прочитать о rman, инструменте Oracle для выполнения резервного копирования (включая резервное копирование журнала повторного выполнения). Я настоятельно рекомендую изучить это довольно тщательно, чтобы убедиться, что вы полностью понимаете, как работают различные аспекты резервного копирования Oracle, прежде чем предпринимать какие-либо действия.

Теперь, как правило, журналы повторного выполнения/архивирования Oracle должны оставаться там, где они записаны, пока вы не выполните резервное копирование. Резервное копирование обычно настраивается так, чтобы включать архивные журналы, которые требуются вместе с резервным копированием базы данных.

Что касается размера журналов повторного выполнения, он будет напрямую зависеть от объема транзакций изменения базы данных. Чем больше изменений, тем больше объем журнала. Это будет очень индивидуально для ваших приложений и использования, поэтому я бы рекомендовал вам начать записывать статистику по нему (объем транзакций, размер журнала транзакций, размер базы данных и т. д., все с временными метками). Как только у вас появятся данные за несколько недель, вы можете начать сопоставлять активность с журналами и выводить из них некоторые обоснованные оценки.

Редактировать: Я думаю, что я частично не понял исходный вопрос. Я думаю, вы спрашиваете о способе, по сути, сделать контрольную точку для ваших журналов повторов на текущий момент, когда вы запускаете резервное копирование, чтобы вы были полностью согласованы с вашей резервной копией вплоть до того момента, когда вы запустили резервное копирование.

И rman на самом деле сделает всю эту грязную работу за вас. Из документации rman:

При резервном копировании архивных журналов повторов, включающих самый последний журнал (то есть команда BACKUP ... ARCHIVELOG выполняется без параметра UNTIL или SEQUENCE), если база данных открыта, то перед началом резервного копирования RMAN отключит текущую группу онлайн-журналов повторов и все онлайн-журналы повторов, которые еще не были заархивированы, вплоть до группы журналов повторов, которая была текущей на момент выдачи команды. Это гарантирует, что резервная копия будет содержать все повторы, которые были сгенерированы до начала выполнения команды.

Еще один небольшой отрывок, дающий немного больше подробностей:

Вы можете добавить архивные журналы повторного выполнения в резервную копию других файлов, используя предложение BACKUP ... PLUS ARCHIVELOG. Добавление BACKUP ... PLUS ARCHIVELOG заставляет RMAN выполнять следующие действия:

  1. Выполняет команду ALTER SYSTEM ARCHIVE LOG CURRENT.
  2. Запускает BACKUP ARCHIVELOG ALL. Обратите внимание, что если включена оптимизация резервного копирования, то RMAN пропускает журналы, которые уже были скопированы на указанное устройство.
  3. Создает резервную копию остальных файлов, указанных в команде BACKUP.
  4. Выполняет команду ALTER SYSTEM ARCHIVE LOG CURRENT.
  5. Резервное копирование всех оставшихся архивных журналов, созданных во время резервного копирования.

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

Документация rman должна предоставить вам больше подробностей. Я бы дал URL, откуда я это взял (онлайн-документация Oracle rman), но URL уже изменился с того момента, как я добавил его в закладки, поэтому я не верю, что он останется. Хотя, если поискать в Google rman docs, то его можно будет найти.

Редактировать: Еще одна вещь, которую я хотел добавить... Вы упомянули что-то о размерах. Oracle 11g поддерживает сжатые журналы повторного выполнения. Я сам их не использовал, но знаю, что он их поддерживает. Кроме того, Oracle 10g и 11g поддерживают сжатые резервные копии. Если вы еще не делаете сжатые резервные копии,ты должен быть. Уменьшение размера огромно, и, вдобавок ко всему, мы получили значительное увеличение производительности при резервном копировании, когда включили сжатые резервные копии.

решение2

Журналы повторного выполнения Oracle, по-видимому, зависят от размера до переключения и позволяют серверу архивировать их.

Посмотрите параметр archive_lag_target для Oracle 9i и выше.

решение3

Это компромисс. Я слышал, что большие файлы журналов более эффективны, но мы их не используем, потому что A) чем больше потеря файла, тем больше потеря ваших данных и B) наша пропускная способность ужасна

Это приводит к тому, что мы спулим файлы на несколько часов, а затем перенесем и запустим обновления на различных резервных машинах. На самом деле мы все еще используем Oracle8i, и поскольку база данных была разработана давным-давно кем-то, кто не был администратором баз данных, мне все еще приходится вручную создавать новые файлы данных и файлы управления. /вздох

решение4

Прошло некоторое время с тех пор, как я спрашивал об этом, но недавно я нашел ответ. Начиная с Oracle 10G R2 и далее есть параметр, который гарантирует, что переключение журнала произойдет не дольше указанного времени.

Если вы собираетесь изменить систему, установите archive_lag_target=900;

это обеспечит переключение каждые 15 минут, независимо от объема используемого журнала.

Связанный контент