Oracle Data Guard

Программное обеспечение, которое корпорация Oracle продает как Oracle Data Guard, представляет собой расширение системы управления реляционными базами данных Oracle (RDBMS). Он помогает создавать и поддерживать вторичные резервные базы данных в качестве альтернативных/дополнительных репозиториев для производственных первичных баз данных.

Oracle предоставляет как графический интерфейс пользователя (GUI), так и инструменты командной строки (CLI) для управления конфигурациями Data Guard.

Data Guard поддерживает как физические резервные, так и логические резервные площадки. Корпорация Oracle предоставляет Data Guard только в качестве встроенной функции, включенной в «Enterprise Edition» СУБД Oracle . ^[1]

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

Конфигурации

Для целей Data Guard каждая база данных Oracle функционирует либо в роли основной базы данных, либо в роли резервной базы данных с возможностью перехода от одной роли к другой. ^[2]

Физический режим ожидания (Повторить применение)

Физическая резервная база данных реплицирует точное содержимое своей основной базы данных на Oracle Net сетевом уровне . Хотя относительные физические места хранения могут различаться, данные в базе данных будут точно такими же, как и в основной базе данных. Физические резервные базы данных могут работать либо в режиме управляемого восстановления, либо в режиме только для чтения, но не в обоих режимах одновременно (если только базы данных не используют Oracle Database 11.1 или выше и опция Active Data Guard лицензирована — см. ниже). . В режиме ожидания используется технология «Redo Apply».

Физические резервные базы данных имеют те же идентификаторы DBID, что и их основные эквиваленты. ^[3]

Логический резерв (SQL Apply)

Логические резервные базы данных преобразуют повторы, сгенерированные в основной базе данных, в данные и SQL, а затем повторно применяют эти транзакции SQL в резервной логической базе данных. Таким образом, физические структуры и организация будут отличаться от первичной базы данных. Пользователи могут читать данные из логических резервных баз данных во время применения изменений и, если для параметра GUARD установлено значение STANDBY (ALTER DATABASE GUARD STANDBY;), записывать в таблицы в логической резервной базе данных, которые не обслуживаются SQL Apply.

К сожалению, существует ряд неподдерживаемых объектов (например, таблицы или последовательности, принадлежащие SYS, таблицы, использующие сжатие таблиц, таблицы, лежащие в основе материализованного представления или глобальные временные таблицы (GTT)) и неподдерживаемые типы данных (например: типы данных BFILE, ROWID и UROWID, пользовательские TYPE, типы мультимедийных данных, такие как Oracle Spatial, ORDDICOM и текстовые коллекции Oracle (например, вложенные таблицы, VARRAY), объекты SecureFile LOB, OBJECT RELATIONAL XMLTypes и BINARY XML). ^[4] В таком случае логический резерв может оказаться неподходящим.

Активная защита данных

Опция «Oracle Active Data Guard» за дополнительную плату. ^[5] расширяет функциональность Oracle Data Guard в конфигурациях Oracle 11g. Он обеспечивает доступ только для чтения на физическом резервном узле одновременно с применением заархивированных транзакций с основного узла. Также он поддерживает автоматическое восстановление блоков и быстрое инкрементальное резервное копирование в физическом режиме ожидания. ^[6]

Операция

Серверная функциональность

Процессы LNS (сетевой сервер записи журналов) и ARCH (архиватор), работающие в основной базе данных, выбирают архивированные журналы повторного выполнения и отправляют их на хост резервной базы данных. ^[7] где фоновый процесс RFS (удаленный файловый сервер) в экземпляре Oracle выполняет задачу получения архивных журналов повторного выполнения, происходящих из основной базы данных, и записи их в резервный журнал повторного выполнения (SRL). ^[8]

Альтернативно, дополнительный механизм может передавать архивированные журналы повторов. В резервной базе данных клиент Fetch Archive Log ( FAL ) отслеживает пробелы в последовательности полученных журналов. Если он обнаружит пробел, он может вызвать один или несколько серверов Fetch Archive Log (FAL) для запуска в первичной базе данных для пересылки недостающих элементов. ^[9]

После того как архивные журналы повторного выполнения поступают на резервный хост, другие процессы, такие как ARCH (процесс архиватора), MRP (процесс управляемого восстановления) , ^[10]) и/или LSP (логический резервный процесс) – может приступить к применению содержимого журнала к резервной базе данных.

Использование резервных журналов повторного выполнения может ускорить внесение изменений в резервную базу данных. ^[11] с применением в режиме реального времени. ^[12]

Процесс Data Guard Connection ( DRCX ) играет роль в передаче данных между базами данных. ^[13]

Доступ на стороне клиента

Подсистема Data Guard Broker может помочь в настройке, управлении и мониторинге конфигураций Data Guard. ^[14]

Преимущества

Data Guard обеспечивает высокую доступность системы баз данных. Это также может уменьшить вмешательство человека, необходимое для переключения между базами данных во время аварийного восстановления («переключение при отказе») или обновления / обслуживания («переключение»).

Благодаря использованию резервных файлов журналов повторного выполнения Data Guard может свести к минимуму потерю данных. ^[15]

Он поддерживает гетерогенные конфигурации, в которых основная и резервная системы могут иметь разные архитектуры ЦП, операционные системы (например, Microsoft Windows и Linux), двоичные файлы операционной системы (32-разрядные/64-разрядные) или двоичные файлы базы данных Oracle (32-разрядные). бит/64-бит). ^[16]

Недостатки

Если сетевое соединение, соединяющее основной и резервный, перегружено, журналы повторного выполнения не отправляются в хронологическом порядке, что может привести к появлению больших пробелов в доступных повторных операциях на резервном. Такое условие приводит к тому, что резервный сервер оказывается позади основного. ^[5] Эту проблему можно преодолеть с помощью технологии Oracle Active Data Guard Farsync.

Один и тот же выпуск Oracle Database Enterprise Edition должен быть установлен в основной базе данных и во всех резервных базах данных, за исключением периодического обновления базы данных с использованием логических резервных баз данных.

Oracle Data Guard доступен только как функция Oracle Database Enterprise Edition.

См. также

Oracle RAC

Ссылки

^ http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/standby.htm#insertedID3 Концепции и администрирование Data Guard , 11g, выпуск 1 (11.1); Раздел 2.3.2: «Требования к программному обеспечению Oracle». Проверено 1 октября 2007 г.
^ Рич, Кэти; и др. Концепции и администрирование Oracle Data Guard 11g, выпуск 2 (11.2) . Проверено 8 марта 2017 г.
^ Чоко, Флорибер (2012). Oracle: защитите свои данные . АвторДом. п. 128. ИСБН 9781467896214 . Проверено 17 марта 2015 г. [...] новой базе данных присваивается новый идентификатор DBID, если только база данных не является резервной базой данных. В этом случае он сохраняет тот же DBID, что и исходная база данных.
^ Чупрински, Джим (январь 2010 г.). «Использование логических резервных баз данных в Oracle 11g Data Guard» . Проверено 16 июля 2010 г.
^ Jump up to: ^а ^б Лоренц, Диана (январь 2009 г.). «Параметры базы данных Oracle» . Информация о лицензировании баз данных Oracle 11g, выпуск 1 (12c) . Корпорация Оракл . Проверено 22 апреля 2009 г. Если в физической резервной базе данных в конфигурации Data Guard включена какая-либо из вышеперечисленных функций, то опция Active Data Guard должна быть лицензирована для каждой такой физической резервной базы данных, а также для основной базы данных.
^ «Активный защитник данных Oracle» . База данных Oracle . Корпорация Оракл. Январь 2010 года . Проверено 22 апреля 2009 г. Oracle Active Data Guard обеспечивает доступ только для чтения к физической резервной базе данных для запросов, сортировки, составления отчетов, доступа через Интернет и т. д., одновременно непрерывно применяя изменения, полученные из производственной базы данных.
^ Смит, Майкл Т. (февраль 2007 г.). «Лучшие практики Data Guard Redo Transport & Network: Oracle Database 10g Release 2» (PDF) . Корпорация Оракл. стр. 6, 14 . Проверено 11 марта 2009 г. ... процессы отправки (LNS и ARC) в производственной базе данных.... Процесс Data Guard LNS в производственной базе данных выполняет сетевую отправку в процесс Data Guard RFS в резервной базе данных.
^ Карпентер, Ларри; и др. (2009). Руководство по Oracle Data Guard 11g . Оракул Пресс. МакГроу Хилл Профессионал. п. 5. ISBN 9780071621489 . Проверено 17 февраля 2015 г. Записи повторов, передаваемые LNS, принимаются в резервной базе данных другим процессом Data Guard, называемым удаленным файловым сервером (RFS) . RFS получает данные повтора из резервной базы данных и записывает их в последовательный файл, называемый резервным файлом журнала повторов (SRL) .
^ Краткое описание Data Guard на сайте Oracle-Base , получено 5 сентября 2007 г.; Ссылки на документацию Oracle Corp версии 11.1 , получено 5 сентября 2007 г.
^ Олт, Майк (2004). Oracle 10g Grid и кластеры реальных приложений: Grid-вычисления Oracle 10g с RAC . Серия Oracle In-Focus. Мадху Тумма. Безудержный TechPress. п. 640. ИСБН 9780974435541 . Проверено 31 августа 2012 г. [...] процесс управляемого восстановления (MRP) в резервной базе данных определяет правильный порядок применения архивных журналов из разных потоков в резервной базе данных.
^ Бах, Мартин (2013). Экспертная консолидация в базе данных Oracle 12c . Голос эксперта в Oracle. Апресс. п. 320. ИСБН 9781430244295 . Проверено 19 февраля 2015 г. [...] с Oracle 10g, [u] записывайте резервные журналы повторов на резервном сервере базы данных, поток повторов, поступающий в пункт назначения, может быть немедленно применен к резервной базе данных, не дожидаясь архивации резервного журнала повторов и применил.
^ Шупманн, Вивиан (2008). «Концепции и администрирование Oracle Data Guard, 10g Release 2 (10.2)» . Оракул . Проверено 20 февраля 2015 г. Данные повторного выполнения можно применять либо из архивных файлов журнала повторного выполнения, либо, если включено применение в режиме реального времени, непосредственно из резервных файлов журнала повторного выполнения по мере их заполнения, без необходимости предварительного архивирования данных повторного выполнения в резервной базе данных.
^ «Интернет-документация базы данных Oracle, 10g, выпуск 2 (10.2)» . docs.oracle.com . Оракул. 2015 . Проверено 16 июня 2015 г. Процесс Data Guard Connection (DRCX) обнаружил ошибку при переносе данных из одной базы данных в другую.
^ Уэлен, Эдвард (2005). Администрирование Oracle Database 10g Linux . МакГроу-Хилл Профессионал. п. 329. ИСБН 978-0-07-223053-6 . Проверено 7 сентября 2011 г. Data Guard Broker — это набор утилит и служб, которые управляют Data Guard. В состав Data Guard Broker входят как графический интерфейс с использованием Oracle Enterprise Manager, так и интерфейс командной строки (CLI). Data Guard Broker используется для настройки Data Guard, управления конфигурацией и мониторинга Data Guard.
^ Кумар, Бипул (2005). Oracle Data Guard: Руководство по аварийному переключению резервной базы данных . Серия Oracle In-Focus. Том. 19. Безудержный ТехПресс. п. 277. ИСБН 9780974599380 . С введением [...] резервных журналов повторного выполнения [...] стало возможным сделать логическую резервную базу данных частью конфигурации Data Guard, работающей в режиме максимальной защиты. Таким образом, метод Data Guard SQL Apply обеспечивает полную поддержку нулевой потери данных.
^ «Предпосылки для работы Data Guard» . Концепции защиты данных и администрирование . Корпорация Оракл . Проверено 26 августа 2013 г. Начиная с Oracle Database 11g, Data Guard обеспечивает повышенную гибкость конфигураций Data Guard, в которых основная и резервная системы могут иметь разные архитектуры ЦП, операционные системы (например, Windows и Linux), двоичные файлы операционных систем (32-битные/64-битные). ) или двоичные файлы базы данных Oracle (32-битные/64-битные).

[1] ttp://download.oracle.com/docs/cd/B28359_01/server.111/b28294/standby.htm#insertedID3 Концепции и администрирование Data Guard , 11g, выпуск 1 (11.1); Раздел 2.3.2: «Требования к программному обеспечению Oracle». Проверено 1 октября 2007 г.

[2] Рич, Кэти; и др. Концепции и администрирование Oracle Data Guard 11g, выпуск 2 (11.2) . Проверено 8 марта 2017 г.

[3] Чоко, Флорибер (2012). Oracle: защитите свои данные . АвторДом. п. 128. ИСБН 9781467896214 . Проверено 17 марта 2015 г. [...] новой базе данных присваивается новый идентификатор DBID, если только база данных не является резервной базой данных. В этом случае он сохраняет тот же DBID, что и исходная база данных.

[4] Чупрински, Джим (январь 2010 г.). «Использование логических резервных баз данных в Oracle 11g Data Guard» . Проверено 16 июля 2010 г.

[Oracle_Database_Options-5] Jump up to: ^а ^б Лоренц, Диана (январь 2009 г.). «Параметры базы данных Oracle» . Информация о лицензировании баз данных Oracle 11g, выпуск 1 (12c) . Корпорация Оракл . Проверено 22 апреля 2009 г. Если в физической резервной базе данных в конфигурации Data Guard включена какая-либо из вышеперечисленных функций, то опция Active Data Guard должна быть лицензирована для каждой такой физической резервной базы данных, а также для основной базы данных.

[Oracle_Active_data_Guard-6] «Активный защитник данных Oracle» . База данных Oracle . Корпорация Оракл. Январь 2010 года . Проверено 22 апреля 2009 г. Oracle Active Data Guard обеспечивает доступ только для чтения к физической резервной базе данных для запросов, сортировки, составления отчетов, доступа через Интернет и т. д., одновременно непрерывно применяя изменения, полученные из производственной базы данных.

[7] Смит, Майкл Т. (февраль 2007 г.). «Лучшие практики Data Guard Redo Transport & Network: Oracle Database 10g Release 2» (PDF) . Корпорация Оракл. стр. 6, 14 . Проверено 11 марта 2009 г. ... процессы отправки (LNS и ARC) в производственной базе данных.... Процесс Data Guard LNS в производственной базе данных выполняет сетевую отправку в процесс Data Guard RFS в резервной базе данных.

[8] Карпентер, Ларри; и др. (2009). Руководство по Oracle Data Guard 11g . Оракул Пресс. МакГроу Хилл Профессионал. п. 5. ISBN 9780071621489 . Проверено 17 февраля 2015 г. Записи повторов, передаваемые LNS, принимаются в резервной базе данных другим процессом Data Guard, называемым удаленным файловым сервером (RFS) . RFS получает данные повтора из резервной базы данных и записывает их в последовательный файл, называемый резервным файлом журнала повторов (SRL) .

[9] Краткое описание Data Guard на сайте Oracle-Base , получено 5 сентября 2007 г.; Ссылки на документацию Oracle Corp версии 11.1 , получено 5 сентября 2007 г.

[10] Олт, Майк (2004). Oracle 10g Grid и кластеры реальных приложений: Grid-вычисления Oracle 10g с RAC . Серия Oracle In-Focus. Мадху Тумма. Безудержный TechPress. п. 640. ИСБН 9780974435541 . Проверено 31 августа 2012 г. [...] процесс управляемого восстановления (MRP) в резервной базе данных определяет правильный порядок применения архивных журналов из разных потоков в резервной базе данных.

[11] Бах, Мартин (2013). Экспертная консолидация в базе данных Oracle 12c . Голос эксперта в Oracle. Апресс. п. 320. ИСБН 9781430244295 . Проверено 19 февраля 2015 г. [...] с Oracle 10g, [u] записывайте резервные журналы повторов на резервном сервере базы данных, поток повторов, поступающий в пункт назначения, может быть немедленно применен к резервной базе данных, не дожидаясь архивации резервного журнала повторов и применил.

[12] Шупманн, Вивиан (2008). «Концепции и администрирование Oracle Data Guard, 10g Release 2 (10.2)» . Оракул . Проверено 20 февраля 2015 г. Данные повторного выполнения можно применять либо из архивных файлов журнала повторного выполнения, либо, если включено применение в режиме реального времени, непосредственно из резервных файлов журнала повторного выполнения по мере их заполнения, без необходимости предварительного архивирования данных повторного выполнения в резервной базе данных.

[13] «Интернет-документация базы данных Oracle, 10g, выпуск 2 (10.2)» . docs.oracle.com . Оракул. 2015 . Проверено 16 июня 2015 г. Процесс Data Guard Connection (DRCX) обнаружил ошибку при переносе данных из одной базы данных в другую.

[14] Уэлен, Эдвард (2005). Администрирование Oracle Database 10g Linux . МакГроу-Хилл Профессионал. п. 329. ИСБН 978-0-07-223053-6 . Проверено 7 сентября 2011 г. Data Guard Broker — это набор утилит и служб, которые управляют Data Guard. В состав Data Guard Broker входят как графический интерфейс с использованием Oracle Enterprise Manager, так и интерфейс командной строки (CLI). Data Guard Broker используется для настройки Data Guard, управления конфигурацией и мониторинга Data Guard.

[15] Кумар, Бипул (2005). Oracle Data Guard: Руководство по аварийному переключению резервной базы данных . Серия Oracle In-Focus. Том. 19. Безудержный ТехПресс. п. 277. ИСБН 9780974599380 . С введением [...] резервных журналов повторного выполнения [...] стало возможным сделать логическую резервную базу данных частью конфигурации Data Guard, работающей в режиме максимальной защиты. Таким образом, метод Data Guard SQL Apply обеспечивает полную поддержку нулевой потери данных.

[Data_Guard_Operational_Prerequisites-16] «Предпосылки для работы Data Guard» . Концепции защиты данных и администрирование . Корпорация Оракл . Проверено 26 августа 2013 г. Начиная с Oracle Database 11g, Data Guard обеспечивает повышенную гибкость конфигураций Data Guard, в которых основная и резервная системы могут иметь разные архитектуры ЦП, операционные системы (например, Windows и Linux), двоичные файлы операционных систем (32-битные/64-битные). ) или двоичные файлы базы данных Oracle (32-битные/64-битные).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]