Раздел: резервирование

У нас практически стабильно работает связка PRIMARY-STANDBY на ORACLE 10g. Предположу, что некоторым нашим читателям будет интересно посмотреть на файлы TNSNAMES.ORA, LISTENER.ORA, INIT.ORA с какими был запущен в работу standby.

Добавил dbstalker в 18 сентября 2008 г. [Ссылка | Комментарии (0) ]

По этой ошибке вот, что мы имеем:

Добавил dbstalker в 17 сентября 2008 г. [Ссылка | Комментарии (2) ]

О некоторых атрибутах параметра инициализации LOG_ARCHIVE_DEST_n писалось здесь. Продолжим эту тему, затронув опции важные для организации standby.

Первое, на что хотелось обратить внимание: параметр LOG_ARCHIVE_DEST_n можно использовать со множеством атрибутов, но параметр принимает одно значение. То есть все его опции-атрибуты нужно задавать одной строкой. Это его отличает от других параметров, которые могут принимать несколько значений (например, CONTROL_FILES).

Добавил dbstalker в 30 июля 2008 г. [Ссылка | Комментарии (0) ]

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

Добавил dbstalker в 24 июля 2008 г. [Ссылка | Комментарии (4) ]

На этот вопрос исчерпывающе ответил Том Кайт здесь. Но у меня организован standby и к тому же из-за специфики эксплуатации серверов передача архивных файлов может происходить с опозданием. Поэтому технология упаковки архивных журналов другая.Упаковываться должны только те файлы, что уже накатаны на резервном сервере.

Добавил dbstalker в 24 июля 2008 г. [Ссылка | Комментарии (0) ]

Самая ПЕРВАЯ обязанность администратора – поддержка базы данных в рабочем состоянии. Даже если в системе происходит сбой (пропало питание, носитель пришел в непригодность и т.д.), администратор должен в максимально сжатые сроки поднять базу без потерь данных. Значит, к сбоям администратор должен готовиться загодя.

Добавил dbstalker в 7 июля 2008 г. [Ссылка | Комментарии (0) ]

В каком режиме будет работать Ваша база данных, устанавливается во время инсталляции. Если же база создается вручную, то необходимо в операторе CREATE DATABASE указать желаемый режим (обычно по умолчанию NOARCHIVELOG). Однако в процессе работы базы данных есть возможность поменять режим. Об этом здесь.

Добавил dbstalker в 4 июля 2008 г. [Ссылка | Комментарии (0) ]

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

Добавил dbstalker в 4 июля 2008 г. [Ссылка | Комментарии (0) ]

В этом режиме не происходит архивирования. То есть, как только оперативный журнал (группа) становится неактивным, то его уже можно перезаписывать.

Добавил dbstalker в 3 июля 2008 г. [Ссылка | Комментарии (1) ]

У меня на сервере, где организован standby, места на диске не так уж и много. Поэтому очень важно удалять уже накатанные архивные файлы.

Решено было использовать вот такой командный файл (за основу взято обсуждение на sql.ru), который стартует с помощью cron:

Добавил dbstalker в 2 июля 2008 г. [Ссылка | Комментарии (2) ]

Периодически нужно проверять все ли редо логи накатываються на резервном сервере. Для это можно просматривать некоторые предаставления.

Добавил dbstalker в 7 ноября 2007 г. [Ссылка | Комментарии (0) ]

Есть промышленная база данных (primary) и резервная (standby) . Процесс наката журнальных файлов происходил автоматически и без проблем. Случилось так, что standby не работал несколько дней (был выключен). После монтирования резервной базы несколько журнальных файлов не были переданы с primary. В тоже время текущие файлы передаются без проблем. Но накат на standby не происходит, пока не будут получены пропущенные файлы.

Добавил dbstalker в 26 октября 2007 г. [Ссылка | Комментарии (0) ]

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

В результате оказалось, что ORACLE как всегда на высоте - все было сделано без моего участия.

Добавил dbstalker в 26 июня 2007 г. [Ссылка | Комментарии (1) ]

Сегодня у меня возникли проблемы с базой данных, которая имеет две standby базы данных. То есть, на два отдельных сервера посылаются архивные файлы журнализации и там они накатываются (более детально об standby можно увидеть в моих статьях на эту тему). И в один непрекрасный день случилось две проблемы:

1. На основном сервере ночью был сделан холодный бэкап( без rman), который в том числе архивирует с удалением все архивные файлы журнализации. Так случилось, что этот бэкап удалил archivelogs, которые не были переданы на сервера standby.
2. На основном сервере одна redo group не могла заархивироваться.

Сейчас опишу, как нашелся выход из этой ситуации. Может быть, Вы предложите что-нибудь более рациональное?

Добавил dbstalker в 16 июня 2007 г. [Ссылка | Комментарии (1) ]

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

Добавил dbstalker в 12 июня 2007 г. [Ссылка | Комментарии (6) ]

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

Добавил dbstalker в 12 июня 2007 г. [Ссылка | Комментарии (0) ]

Есть у меня база данных, которую в рабочее время остановить никак нельзя, информация обновляется практически постоянно, информация очень важная. Никакие потери не будут мне прощены. Пришлось обратить свой взор к STANDBY.

Добавил dbstalker в 12 июня 2007 г. [Ссылка | Комментарии (0) ]