Войти
Программное обеспечение, которое Oracle Corporation продает как Oracle Data Guard, является расширением для система управления реляционными базами данных Oracle (СУБД). Он помогает в создании и обслуживании вторичных резервных баз данных в качестве альтернативных / дополнительных репозиториев к производственным первичным базам данных.
Oracle предоставляет инструменты графического пользовательского интерфейса (GUI) и командной строки (CLI) для управления конфигурациями Data Guard.
Data Guard поддерживает как физический резервный, так и логический резервный сайты. Корпорация Oracle делает Data Guard доступным только в виде связанной функции, включенной в ее "Enterprise Edition" Oracle RDBMS.
. С соответствующим образом настроенными операциями Data Guard DBA может облегчить отработку отказа или переключение на альтернативные хосты в тех же или альтернативных местах.
Для целей Data Guard каждая база данных Oracle функционирует либо в роли первичной базы данных или в роли резервной базы данных - с возможностью перехода от одной роли к другой.
Физическая резервная база данных реплицирует точное содержимое своей первичной базы данных на сетевом уровне Oracle Net . Хотя относительные места физического хранения могут отличаться, данные в базе данных будут точно такими же, как в первичной базе данных. Физические резервные базы данных могут работать либо в режиме управляемого восстановления, либо в режиме только для чтения, но не в обоих режимах одновременно (если только базы данных не имеют Oracle Database 11.1 или выше и опция Active Data Guard не лицензирована - см. Ниже). Резервный использует технологию "Redo Apply".
Физические резервные базы данных имеют те же идентификаторы DBID, что и их основные эквиваленты.
Логические резервные базы данных преобразуют повторяющиеся операции, созданные в первичной базе данных, в данные и SQL, а затем повторно примените эти транзакции SQL в логическом резервном сервере. Таким образом, физические структуры и организация будут отличаться от первичной базы данных. Пользователи могут читать из логических резервных баз данных, пока применяются изменения, и, если GUARD установлен в STANDBY (ALTER DATABASE GUARD STANDBY;), записывать в таблицы в логической резервной базе данных, которые не поддерживаются SQL Apply.
К сожалению, существует ряд неподдерживаемых объектов (например, таблицы или последовательности, принадлежащие SYS, таблицы, использующие сжатие таблиц, таблицы, лежащие в основе материализованного представления или глобальные временные таблицы (GTT)) и неподдерживаемые типы данных (например: типы данных BFILE, ROWID и UROWID, определяемые пользователем ТИПЫ, типы мультимедийных данных, такие как Oracle Spatial, ORDDICOM и Oracle Text Collections (например, вложенные таблицы, VARRAY), SecureFile LOBs, OBJECT RELATIONAL XMLTypes и BINARY XML). В таком случае логический режим ожидания может не подходить.
Опция «Oracle Active Data Guard», дополнительная плата, расширяет функциональность Oracle Data Guard в конфигурациях Oracle 11g. Он обеспечивает доступ только для чтения на физическом резервном узле одновременно с применением архивированных транзакций с основного узла. Также он включает автоматическое восстановление блоков и быстрое инкрементное резервное копирование в физическом резерве,
LNS (сетевой сервер записи журнала) и Процессы ARCH (архиватора), запущенные в первичной базе данных, выбирают архивированные журналы повторного выполнения и отправляют их на хост резервной базы данных, где фоновый процесс RFS (удаленный файловый сервер) в экземпляр Oracle выполняет задачу получения архивных журналов повторного выполнения, происходящих из первичной базы данных, и записи их в резервный журнал повторного выполнения (SRL).
В качестве альтернативы дополнительный механизм может передавать архивированные журналы повторного выполнения. В резервной базе данных клиент Fetch Archive Log (FAL ) отслеживает пропуски в последовательности полученных журналов. Если он обнаруживает пробел, он может вызвать один или несколько серверов Fetch Archive Log (FAL) для запуска в первичной базе данных для пересылки отсутствующих элементов.
После того, как архивированные журналы повторов поступят в резервный хост, другие процессы, такие как ARCH (процесс архиватора), MRP (управляемый процесс восстановления) и / или LSP (логический резервный процесс) - может приступить к применению содержимого журнала к резервной базе данных.
Использование резервных журналов повторов может ускорить внесение изменений в резервную базу данных с применением в реальном времени.
Процесс подключения Data Guard (DRCX ) играет роль в передаче данных между базами данных.
Подсистема Data Guard Broker может помочь в настройке, управлении и мониторинге конфигураций Data Guard.
Data Guard обеспечивает высокую доступность для системы баз данных. Это также может уменьшить вмешательство человека, необходимое для переключения между базами данных при аварийном восстановлении («переключение при отказе») или обновлении / обслуживании ( "переключение") время.
За счет использования резервных файлов журнала повторного выполнения Data Guard может минимизировать потерю данных.
Он поддерживает гетерогенные конфигурации, в которых основная и резервная системы могут иметь разные архитектуры ЦП, операционные системы (например,, Microsoft Windows и Linux), двоичные файлы операционной системы (32-разрядные / 64-разрядные) или двоичные файлы базы данных Oracle (32-разрядные / 64-разрядные).
Если сетевой канал, соединяющий первичный и резервный, переподписан, журналы повторов не доставляются в хронологическом порядке, что может привести к появлению больших пропусков в доступных повторах на резервном. Такое состояние приводит к тому, что резервный находится за основным. Это можно преодолеть с помощью технологии Oracle Active Data Guard Farsync.
Один и тот же выпуск Oracle Database Enterprise Edition должен быть установлен в первичной базе данных и во всех резервных базах данных, за исключением периодических обновлений базы данных с использованием логических резервных баз данных.
Oracle Data Guard доступен только как функция Oracle Database Enterprise Edition.
