Oracle Data Guard 11g.
Новая эра в готовности и защите данных

(Oracle Data Guard 11g. The Next Era in Data Protection and Availability)

 

Источник: сайт публикаций по технологиям, технический документ Oracle (An Oracle Technical White Paper), февраль 2009 г.,
http://www.oracle.com/technetwork/database/options/compression/overview/twp-dataguard-11gr1-132684.pdf

Содержание

ВВЕДЕНИЕ

Основные свойства Data Guard 11g

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

Механизм синхронного (SYNC) транспорта расширен так, чтобы устранить воздействие времени задержки на пропускную способность сети.

Автоматическое аварийное переключение (Automatic failover) в режиме максимальной производительности (ASYNC).

Автоматическое аварийное переключение как немедленный ответ на определенные события или ошибки.

Быстрое обнаружение повреждений в случае потери записей в среде хранения.

Большая конфигурационная гибкость primary/standby (например, первичная база данных на Windows, а резервная – на Linux).

SQL Apply поддерживает тип данных XML (CLOB).

Много усовершенствований производительности, управляемости и защиты.

Поддержка новых опций Oracle Database 11g – Oracle Active Data Guard и Oracle Advanced Compression

 

Эффективное ведение бизнес-операций, высококачественное обслуживание заказчиков, соответствие правительственным правилам и инструкциями, а также охрана корпоративных информационных активов – всё это зависит от достижения максимально возможного уровня защищенности данных и готовности системы. Таким образом, неудивительно, что защита данных и готовность системы входят в число высших приоритетов непрерывности бизнеса для компаний всех размеров и отраслей.

На первый взгляд кажется, что уже известны и неинтересны продукты и сервисы для выполнения подобных требований. Резервное копирование на ленту и последующее восстановление, создание зеркальных копий на удаленных узлах и складирование файлов журнала базы данных – вот традиционные решения для защиты и восстановления данных (disaster recovery – DR) в аварийных ситуациях. К сожалению, традиционные решения имеют столь же традиционные недостатки. Так, они неспособны успешно справиться с агрессивными планами как для точек восстановления (защита данных), так и по времени восстановления (высокая доступность), или сделать это таким способом, который обеспечивал бы максимальный коэффициент окупаемости инвестиций, устраняя недостаточно использованные активы, высокую стоимость приобретения и сопровождения и возросшую сложность.

Напротив, в Oracle Data Guard 11g [1] переопределяется все то, чего пользователи должны ожидать от решения для восстановления в аварийных ситуациях. Эта технология может разрешить как их требования к высокой доступности (High Availability), так и требования в области восстановления в аварийных ситуациях, и является идеальным дополнением к решению Oracle Real Application Clusters (Oracle RAC). В Data Guard заложены все необходимые сведения о базе данных Oracle, чтобы надежно защитить резервную базу данных от искажений, которые могут пытаться перейти из первичной базы данных. Это решение просто в реализации и управлении. Кроме того, оно позволяет использовать в производственных целях все резервные базы данных – и физические, и логические, даже если они продолжают оставаться в роли резервных баз данных. Data Guard обеспечивает:

Независимо от степени высокой доступности, ранее встроенной в ваши системы и инфраструктуру, защищенность данных и готовность системы универсально повышаются при задействовании технологии  Data Guard в ИТ-архитектуре.

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

ORACLE DATA GUARD –  КРАТКИЙ ОБЗОР

Технология Data Guard является центральным компонентом интегрированного набора решений Oracle Database High Availability(HA - высокая готовность Oracle Database), который гарантирует непрерывность ведения бизнеса, сводя к минимуму время различных видов запланированных и незапланированных простоев, которые могут затронуть предприятие. На приведенной ниже диаграмме показаны различные возможности HA, доступные в Oracle Database 11g. Дальнейшие детали для каждой из этих возможностей можно найти в документе Oracle Database High Availability [3], размещенном в сети Oracle Technology Network.

Рисунок 1 - Интегрированные возможности высокой готовности для Oracle Database 11g

Технология Data Guard предлагает инфраструктуру программного обеспечения для управления, мониторинга и автоматизации создания, обслуживания и мониторинга одной или нескольких резервных баз данных, которая позволяет защитить данные предприятия от отказов, стихийных бедствий, ошибок и нарушений целостности данных. Если пользователь пожелает, Data Guard будет автоматически проводить переключение с промышленной (первичной) системы на резервную систему в случае отказа в промышленной системе, чтобы поддерживать высокую доступность и готовность, что необходимо для стратегически важных приложений. В дополнение к обеспечению функций HA/DR, резервные базы данных Data Guard могут также выполнять производственные функции: составление отчетов, выполнение запросов [только на чтение – прим.ред], резервное копирование и тестирование, оставаясь при этом в роли резервных баз  данных.

Data Guard состоит из проверенных временем сервисов в трех различных областях:

Служба Data Guard транспортировки журналов (Data Guard Redo Transport Services): конфигурация Data Guard включает промышленную (первичную)базу данных и до девяти резервных баз данных [в Data Guard Oracle Database11g R2 их число увеличено до 30 – прим.ред]. Технология Data Guard поддерживает синхронизацию первичных и резервных баз данных, используя для этого журнальные данные. Поскольку транзакции выполняются на первичной базе данных, журнальные данные (информация, требующаяся для восстановления транзакций) генерируются и записываются в её локальные журнальные файлы. Сервисы Data Guard транспортировки журналов используется для синхронной или асинхронной пересылки этих журнальных данных на резервные узлы. Подобная гибкость дает возможность располагать резервные базы данных в отдаленных на тысячи миль от промышленного центра данных и друг от друга сайтах (узлах) для восстановления при возникновении аварийных ситуаций. Хотя, конечно же, они могут быть расположены в том же самом городе, в том же самом университетском вычислительном центре, в том же самом здании или даже в одном компьютерном зале.

Служба Data Guard Apply: после того как журнальные данные переданы в резервный узел, сервисы Data Guard Apply предлагает два различных метода для применения полученных журнальных данных к резервной базе данных: Data Guard Redo Apply для физической резервной базы данных и Data Guard SQL Apply для логической резервной базы данных. Структура файлов физической резервной базы данных полностью идентична структуре файлов первичной базы данных с точностью до блока, которые обновляется средствами  восстановления носителей Oracle. Логическая резервная база данных является независимой базой данных, которая содержит те же самые данные, что и первичная база данных, и обновляется при использовании SQL-операторов [то есть, может иметь отличающуюся структуру – прим ред]. У каждого метода имеются свои преимущества, дающие заказчикам гибкость в выборе метода для наилучшего удовлетворения своих требований. Эти различия подробно рассматриваются далее в этой статье.

Служба Data Guard управления ролями (Data Guard Role Management Services): если промышленная база данных становится недоступной вследствие запланированного или незапланированного выхода из строя, служба управления ролями быстро переключит выбранную резервную базу данных в роль промышленной базы данных, минимизируя время простоя и предотвращая потерю данных. В Data Guard предлагается гибкость при выполнении передачи роли (с помощью ручного управления или автоматически), без вмешательства оператора и согласно набору правил, которые могут задаваться самими пользователями. В технологии Data Guard предлагается инфраструктура для автоматизации преодоления последствий сбоя для пользователей, позволяющая обеспечить высокий уровень готовности, требующийся для стратегически важных приложений. После автоматического преодоления последствий сбоя вышедшие из строя первичные базы данных могут быть быстро восстановлены в качестве резервной базы данных для новой первичной базы данных, быстро возвращая конфигурацию в защищенное состояние.

Создание конфигурации Data Guard и управление ею: первичными и резервными базами данных, также как различными их взаимодействиями, можно управлять при помощи SQL*Plus. Технология Data Guard также предлагает распределенную инфраструктуру управления, которая называется Data Guard Broker и автоматизирует и централизует создание, обслуживание и мониторинг конфигурации Data Guard. Администраторы могут взаимодействовать с брокером, используя для этого либо предлагаемую Oracle универсальную утилиту управления Enterprise Manager Grid Control, либо специализированную утилиту брокера (DGMGRL), работающую в режиме командной строки.

Использование ресурсов Standby: для любой резервной базы данных Data Guard можно активировать доступ по чтению, в то время как к ней применяются журнальные данные, получаемые из первичной базы данных. Это делает все резервные базы данных превосходными кандидатами для разгрузки первичной базы данных от накладных расходов на поддержку запросов только_для_чтения и составления отчетов.

Все резервные базы данных Data Guard поддерживают оперативное резервное копирование с использованием механизма RMAN [4]. Поскольку физическая резервная база данных является точной копией (репликой) первичной базы данных, физическая резервная база данных может использоваться для разгрузки первичной базы от накладных расходов на выполнение резервного копирования.

Физическая резервная база данных (Redo Apply) может быть преобразована в так называемую базу Snapshot Standby. В этом состоянии могут быть активизированы так называемое «горячее исправление» (технология hot patch позволяет устанавливать “заплаты” для приложений и ядра ОС без перезагрузки приложений и/или ОС) и другие виды тестирования, используя истинную реплику (для чтения/ записи) промышленных данных. Технология Data Guard поддерживает защиту данных и в это время, продолжая поставлять журнальные данные в Snapshot Standby, где они архивируются для сохранности и остаются доступными для быстрой синхронизации, когда после завершения тестирования она (Snapshot Standby) будет преобразована и снова станет резервной базой данных.

Логическая резервная база данных (SQL Apply) имеет дополнительную гибкость, так как она открыта для чтения/записи. Хотя данные, поддерживаемые SQL Apply, не могут быть изменены, в логической резервной базе данных могут быть добавлены дополнительные локальные таблицы, созданы локальные индексные структуры, чтобы оптимизировать составление отчетов, использовать резервную базу данных как хранилище данных или обрабатывать информацию, используемую для загрузки витрин данных.

Логическая резервная база данных может быть использована для выполнения накатываемых модификаций ( rolling database upgrades) базы данных, что минимизирует время простоя при проведении обновления новым набором исправлений к базе данных (database patch–set) или полностью новым релизом базы данных. Более того, физическая резервная база данных может также быть временно преобразована в переходную (transient) логическую резервную базу данных, чтобы выполнить накатываемую модификацию базы данных, а затем возвращена к своему нормально действующему состоянию, как физическая резервная база данных.

DATA GUARD 11g R1

В Data Guard 11g R1 включены новые возможности для расширения его мощных функциональных возможностей по защите данных и восстановлению в аварийных ситуациях, включены также усовершенствования в функциональных возможностях высокой готовности, впервые введенные в Data Guard 10g Release 2. В релизе 11g R1 обеспечиваются новые способы продуктивного использования физической резервной базы данных, когда она остается в резервной роли, не ставя при этом под угрозу защиту данных. Кроме того, в Data Guard 11g R1 поддерживаются новые опции Oracle Database 11g R1, которые используют технологию Data Guard для генерации дополнительных выгод для пользователей Oracle. Краткое изложение этих усовершенствований предлагается в следующих разделах. [Сводка дополнительных функциональных возможностей Data Guard 11g Release 2 содержится в отдельной публикации в этом выпуске журнала – прим. ред.]

Новые функциональные возможности в Data Guard 11g R1

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

Автоматическое аварийное переключение на резервную базу данных для синхронной (SYNC) и асинхронной (ASYNC) транспортировки журнальных данных: в Data Guard 10g Release 2 было введено автоматическое аварийное переключение на резервную базу данных с использованием новой опции быстрого запуска аварийного переключения (Fast-Start Failover) в режиме защиты максимальной готовности (SYNC). В Data Guard 11g опция Fast-Start Failover распространяется и на режим защиты максимальной производительности (ASYNC). Для этого был добавлен определяемый пользователем порог потери данных, гарантирующий, что автоматическое аварийное переключение никогда не приведет к потере данных, превышающей установленный директивный срок восстановления (Recovery Point Objective – RPO).

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

Новый PL/SQL-пакет DBMS_DG дает приложениям возможность уведомить процесс Fast-Start Failover Observer о режиме инициации автоматического аварийного переключения на резервную базу данных.

Усовершенствования производительности: Среди усовершенствований производительности можно назвать:

  • Параллельное восстановление носителей (физическая резервная база данных) значительно увеличивает производительность процесса применения журнальных данных к физической резервной базе данных для всех профилей рабочей нагрузки.
  • Усовершенствования SQL Apply (логическое резервирование) увеличивают производительность процесса применения журнальных данных для операций вставки и обновлениях в несекционированных таблицах, которые не содержат столбцов типа LOB, LONG или XML. Кроме того, в SQL Apply теперь  применяет DDL (язык описания данных) параллельно, а не последовательно, как это практиковалось в предыдущих выпусках.
  • Модификации асинхронной ( ASYNC) транспортировки журнальных данных увеличивают пропускную способность сети, устраняя сетевые задержки, особенно существенные при развертывании глобальных сетей.
  • Дальнейшее сокращение времени аварийного переключения на резервную базу данных, благодаря использованию быстрого запуска аварийного переключения.

Транзитная логическая резервная база данных (Transient Logical Standby): Пользователи могут преобразовать физическую резервную базу данных в транзитную логическую резервную базу данных, чтобы произвести накатываемую модификацию базы данных, а затем вернуться к – физической резервной базе данных, как только обновление будет завершено (используя фразу KEEP IDENTITY). Это дает преимущества пользователям физической резервной базы данных, которые желают выполнить накатываемую модификацию базы данных, не делая инвестиций в избыточную дисковую память, которая потребовалась бы для создания логической резервной базы данных.

Усиленная защита данных (Enhanced Data Protection): Физическая резервная база данных может теперь обнаруживать потерю блоков данных при записи в файл данных, вызванную дефектными аппаратными средствами памяти и встроенным программным обеспечением, которые приводят к нарушению целостности данных. В Data Guard проводится сравнение версии блоков в резервной базе данных с версиями блоков из входящего журнального потока. Если имеется несоответствие версий, это подразумевает, что была потеряна операция записи. После этого пользователь может автоматически переключиться на резервную базу данных и восстановить согласованность данных.

Усиленная безопасность (Enhanced Security): Для подтверждения подлинности передачи журнальных данных вместо файла пароля может использоваться SSL-аутентификация. Замечание: для SSL-аутентификации требуется использовать сертификаты PKI, ASO и OID.

Поддержка дополнительных типов данных в SQL Apply (Additional SQL Apply Data Type Support): В SQL Apply добавляется поддержка дополнительных типов данных и других возможностей Oracle, а также   PL/SQL, в том числе:

  • Тип данных XMLType (когда данные сохранены, как LOB)
  • Возможность параллельного выполнения команд DDL в логической резервной базы данных
  • Прозрачное шифрование баз данных (Transparent Database Encryption – TDE)
  • DBMS_FGA (детальный аудит)
  • DBMS_RLS - (виртуальная частная база данных)

Усовершенствования управляемости SQL Apply (SQL Apply Manageability Enhancements): Задания планировщика могут быть созданы в резервной базе данных, используя для этого пакет DBMS_SCHEDULER, и могут быть связаны с соответствующей ролью базы данных, так что они будут выполняться в назначенные периоды времени (например, когда база данных является первичной, резервной или в обеих ее ролях).

При запланированном переключении, использующем SQL Apply для баз данных Oracle RAC, больше не требуется предшествующего ему завершения работы всех экземпляров, кроме первого, в каждом кластере Oracle RAC.

Параметры Data Guard SQL Apply могут также быть установлены динамически, не требуя перезапуска SQL Apply. Используя пакет DBMS_LOGSTDBY.APPLY_SET, можно динамически установить параметры инициализации, повышая, таким образом, управляемость, время безотказной работы и автоматизацию конфигурирования логической резервной базы данных.

Усовершенствования модуля Data Guard Broker (Data Guard Broker Enhancements): Следующие усовершенствования еще более упрощают управление с использованием брокера Data Guard:

  • Улучшенная поддержка опций транспортировки журнальных данных, что дает администратору возможность определить описание подключения для Redo Transport Services.
  • Устранение времени простоя базы данных при изменении режима защиты, как с режима максимальной готовности на режим максимальной производительности, так и в обратную сторону.
  • Поддержка одно-экземплярных баз данных, сконфигурированных для функциональности HA с использованием Oracle Clusterware, как кластера с холодным резервированием (cold failover cluster).

Усовершенствования Enterprise Manager Grid Control 10.2.0.5: применение утилиты Enterprise Manager еще более упрощает управление для:

  • легкого создания резервных баз данных непосредственно из первичной базы данных без использования временной среды хранения в любом из узлов.
  • создания резервных баз данных из существующих резервных копий RMAN.
  • легкого преобразования резервных одно-экземплярных баз данных в Oracle RAC с использованием EM-визарда.
  • автоматического преобразования резервных баз данных для составления отчетов, разработки и тестирования.
  • автоматического распространения заданий Enterprise Manager и пороговых значений метрик в новую первичную базу данных после запланированного или аварийного переключения.
  • быстрого запуска аварийного переключения при использовании отказоустойчивой утилиты Observer (Обозреватель).
  • использования всех доступных резервных баз данных с помощью средства Enterprise Manager Data Recovery Advisor (советчик по восстановлению данных), который формулирует рекомендации для Intelligent Data Repair (IDR - интеллектуальное восстановление данных).

Новые опции базы данных Oracle Database 11g R1

Конфигурации Data Guard могут также быть расширены путем использования новых опций базы данных, ставших доступными в Oracle Database 11g R1 Enterprise Edition. Опции базы данных – это отдельно лицензируемые продукты, которые расширяют возможности и производительность Oracle Database. Особенно релевантными для базы данных являются две опции Data Guard 11gOracle Active Data Guard Option и Oracle Advanced Compression Option.

Опция Active Data Guard активирует доступ только на чтение к обновленной   физической резервной базе данных. Это повышает производительность промышленной базы данных и делает физическую резервную базу данных расширением рабочей среды, даже если она выступает в роли резервной.

 

Oracle Active Data Guard (Активный Data Guard) – это опция Oracle Database 11g R1 Enterprise Edition, которая улучшает качество обслуживания, освобождая промышленную базу данных от излишней загрузки ресурсоемкими действиями и перенося часть этих действий в одну или несколько синхронизированных резервных баз данных. Характеристика Real-time, включенная в состав Active Data Guard Option, активирует доступ к физической резервной базе данных в режиме «только для чтения» для запросов, сортировки, составления отчетов, web -доступа к базе данных через Сеть и т.д. В то же самое время к ней непрерывно применяются изменения, полученные из промышленной базы данных.

Опция Active Data Guard также активирует отслеживание изменения блоков утилитой RMAN для физической резервной базы данных, позволяя выполнять быстрое инкрементное резервное копирование физической резервной базы данных. Тесты показали, что инкрементные резервные копии для базы данных с умеренной скоростью изменений могут быть выполнены по сравнению с традиционными инкрементными резервными копиями в 20 раз быстрее, чем при использовании отслеживания изменений блоков RMAN.  

Опция Advanced Compression позволяет использовать сетевое сжатие, когда требуется передача журнальных файлов для наверстывания отставания (от первичной базы данных – прим.ред.) и повторной синхронизации резервных баз данных после отказов сети или резервных серверов.

 

Oracle Advanced Compression (Расширенная компрессия) – это опция Oracle Database 11 gR1 Enterprise Edition, которая помогает более рентабельным образом управлять возрастающими количествами данных (объемы которых, в среднем, утраиваются раз в два года). При расширенной  компрессии можно сжимать любой тип данных, включая структурированные и неструктурированные данные, например, документы, изображения и мультимедийные данные, а также сетевой трафик и данные в процессе копирования.

Опция Advanced Compression Option выполняет сжатие потока данных в сети для журнальных данных в процессе преодоления Data Guard 11g отставания архивных файлов для резервной базы данных. Она может ускорить синхронизацию резервных баз данных после выхода из строя сети или резервной базы данных и более эффективно использует пропускную способность сети.

АРХИТЕКТУРА ПРОЦЕССА DATA GUARD

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

В первичной базе данных для захвата журнальных данных, записанных процессом   Log Writer, и синхронной или асинхронной передачи журнальных данных в резервную базу данных Data Guard использует  специализированный фоновый процесс, который называется LogWriter Network Server (LNS – сетевой сервер записи в журнал). Процесс LNS избавляет процесс Log Writer от накладных расходов, связанных с передачей, изолирует от разрушения сети.

Для синхронной транспортировки журнальных данных (SYNC) требуется, чтобы Log Writer в первичной базе данных ожидал от LNS подтверждения, что резервная база данных получила журнальные данные и записала их в журнал этой резервной базы данных, прежде чем Log Writer сможет подтвердить передачу данных в клиентское приложение. Это служит гарантией того, что все зафиксированные транзакции записаны на диск и защищены на резервном узле.

Для асинхронной транспортировки журнальных данных ( ASYNC) не требуется, чтобы Log Writer в первичной базе данных ждал от резервной базы данных подтверждения, что журнальные данные были записаны на диск; все операции фиксирования транзакций подтверждаются клиентским приложением асинхронно с процессом транспортировки журнальных данных.

Рисунок 2 Архитектура процесса Data Guard

Асинхронная транспортировка журнальных данных значительно повышает использование сети и улучшает директивный срок восстановления.

 

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

Если вследствие отказа сети или отказов резервных серверов или же в зависимости от выбранного режима защиты (режимы защиты обсуждаются далее в этой статье) разрывается соединение первичной и резервных баз данных, первичная база данных продолжает обрабатывать транзакции и накапливать задел журнальных данных, которые не могут быть отправлены в резервные базы данных до тех пор, пока не будет установлено новое сетевое подключение (так называемое отставание файлов архивного журнала). Но даже в таком состоянии Data Guard постоянно ведет мониторинг состояния резервной базы данных, обнаруживает, когда   вновь устанавливается подключение, и автоматически  синхронизирует резервную базу данных с первичной базой данных, чтобы возвратить конфигурацию к защищенному состоянию так быстро, насколько это возможно. Для того, чтобы выполнить отправку журнальных файлов, необходимых для наверстывания отставания, всегда используются процессы архиватора (ARCn). Есть несколько опций, используемых для ускорения преодоления отставания.

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

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

Если «в заделе» накопилось небольшое число неотправленных файлов архивного журнала, но они имеют очень большой размер, можно сконфигурировать до пяти процессов ARCn, чтобы начать параллельную поставку контента каждого журнального файла.

Наконец, резервная база данных Data Guard будет с упреждением (проактивно) запрашивать новую копию архивированного журнала, если процесс применения журнальных файлов в резервной базе данных обнаруживает недостающий журнальный файл, или любой дефект, или искажение в полученном архивном журнале. Для выполнения таких запросов используется процесс ARCn.

На принимающей стороне процесс Data Guard Redo Transport Services использует один или несколько процессов дистанционных файл-серверов (Remote File Server – RFS) в резервных базах данных, чтобы получить журнальные данные и записать их в файл, который называется Standby Redo Log (SRL – оперативный журнал резервной базы данных). Для координирования применения журнальных данных к физической резервной базе данных используется процесс Managed Recovery Process (MRP – управляемый процесс восстановления), а для координирования применения восстановленных из журнальных данных SQL-предложений в логической резервной базе данных используется процесс Logical Standby Process (LSP – процесс логического резервирования).

Также, если активирован Data Guard Broker, Data Guard использует процесс Data Guard Broker Monitor (DMON) и еще один процесс для управления и ведения мониторинга первичной базы данных и резервных баз данных, как единой объединенной конфигурации.

КЛЮЧЕВЫЕ КОМПОНЕНТЫ ТЕХНОЛОГИИ

Конфигурация Data Guard

Первичная и резервные базы данных в конфигурации Data Guard могут функционировать, как в одиночной среде, так и в среде Oracle RAC. Резервные базы данных соединяются с первичной базой данных по TCP/IP, используя для этого Oracle Net Services. Какие-либо ограничения на место дислокации баз данных отсутствуют при условии, что эти узлы могут общаться друг с другом. Однако для восстановления в аварийных ситуациях рекомендуется, чтобы резервные базы данных были размещены на узлах, которые географически удалены от первичного узла.

Data Guard 11g обладает несколькими возможностями для развертывания на CPU различных архитектур, на различных ОС и в различных двоичных реализациях Oracle для первичной и резервных систем. Например, первичная база данных может работать под управлением Windows, а резервная база данных – под Linux.
См. памятную записку MetaLink 413484.1, где приводится перечень последних возможностей и ограничений

 

Data Guard 11g обеспечивает повышенную гибкость конфигураций Data Guard, в которых первичные и резервные системы могут иметь центральные процессоры различной архитектуры, различные операционные системы (например, Windows и Linux), исполняемые файлы ОС (32/64-бит) и Oracle (32/64-бит) – в зависимости от ограничений, определенных в памятной записке MetaLink 413484.1. Два постоянных требования к первичной и резервным базам данных заключаются в том, что должен быть одинаковым порядок следования байтов в форматах. Также должны быть одинаковыми версии выпусков Oracle Database, за исключением моментов проведения накатываемых апгрейдов базы данных с использованием логических резервных баз данных.

Режимы защиты

В Data Guard предлагаются три режима защиты данных для балансировки стоимости, готовности, производительности и защищенности данных. Эти режимы определяют правила, управляющие поведением конфигурации Data Guard, и могут быть легко установлены, используя любой из доступных интерфейсов управления, например, если для первичной базы данных использовать следующий простой оператор SQL:

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE 
              {PROTECTION |AVAILABILITY |PERFORMANCE};

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

Режим

Риск потери данных в случае события отказа первичной базы данных

Метод транспортировки журнальных данных

Maximum Protection
(Максимальная защищенность)

Нулевая потеря данных

SYNC

Maximum Availability
(Максимальная готовность)

Нулевая потеря данных – в предположении, что до отказа не было никаких нарушений в синхронной передаче данных в то время, когда первичная база данных фиксировала (commit) транзакции

SYNC

Maximum Performance
(Максимальная производительность)

Минимальная потеря данных – не более нескольких секунд – в зависимости от полосы пропускания сети

ASYNC

В следующих разделах эти варианты будут описаны более подробно.

Максимальная защита

Режим максимальной защиты (Maximum Protection) предлагает самый высокий уровень защиты данных. В этом варианте записи журнала синхронно передаются в резервную базу(ы) данных, используя синхронную (SYNC) транспортировку журнальных данных. Процесс Log Writer для первичной базы данных не подтвердит прием данных приложением-клиентом, пока Data Guard не подтвердит, что данные транзакции находятся в безопасности на диске, по крайней мере, одного из резервных серверов. Вследствие природы синхронной передачи журнальных данных  режим максимальной защиты может влиять на время ответа первичной базы данных. Конфигурирование сети с низким временем задержки и с достаточной полосой пропускания для пиковой загрузки транзакции может минимизировать это влияние. Финансовые учреждения и лотерейные системы – вот два примера, где был развернут этот самый высокий уровень защищенности  данных.

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

Максимальная готовность

Режим максимальной готовности (Maximum Availability) обеспечивает следующий по силе уровень защищенности данных, поддерживая в то же самое время готовность первичной базы данных. Как и в случае максимальной защиты, журнальные данные синхронно передаются в резервную базу данных, используя синхронные ( SYNC) сервисы транспортировки журнальных данных. Процесс Log Writer не выдаст подтверждения фиксации транзакции на первичной базе данных, пока Data Guard не подтвердит, что данные транзакции доступны на диске, по крайней мере, для одного резервного сервера. Однако в отличие от режима максимальной защиты обработка в первичной базе данных продолжится, даже если последняя участвующая резервная база данных станет недоступной (например, из-за проблем со связью или из-за отказа резервного узла). Резервная база данных временно отстанет по сравнению с первичной базой данных, так как она находится в недоступном состоянии. Когда контакт будет вновь установлен, Data Guard автоматически повторно синхронизирует резервную и первичную базы данных.

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

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

Максимальная производительность

Режим максимальной производительности (Maximum Productivity) является выбираемым по умолчанию режимом защиты. Он предлагает несколько меньшую защиту данных с потенциалом для более высокой производительности первичной базы данных, чем в режиме максимальной готовности. В этом варианте, когда первичная база данных обрабатывает транзакции, журнальные данные асинхронно передаются в резервную базу данных, используя асинхронную (ASYNC) транспортировку. Процесс Log Writer в первичной базе данных не ждет подтверждения от резервного узла, прежде чем он сам признает факт фиксации для клиентского приложения. Это устраняет потенциальные накладные расходы на "круговой" обмен данными по сети и дисковый ввод/вывод в резервном узле из времени ответа первичной базы данных. Если резервный пункт назначения становится недоступным, обработка продолжается в первичной базе данных. При этом оказывается небольшое (или вовсе никакого) воздействие на производительность.

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

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

Автоматическое преодоление отставания – обработка отказов связи

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

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

Apply-сервисы – Redo Apply и SQL Apply

Резервная база данных первоначально создается из резервной копии первичной базы данных. После её создания Data Guard автоматически синхронизирует первичную базу данных и все резервные базы данных в рамках конфигурации Data Guard, передавая журнальные данные первичной базы данных в резервную систему (ы), а затем применяя журнальные данные на резервной базе.

Data Guard предлагает два метода для применения журнальных данных на резервной базе. Эти методы соответствуют двум типам резервных баз данных, поддерживаемых Data Guard:

  • Redo Apply, используемый для физических резервных баз данных
  • SQL Apply, используемый для логических резервных баз данных

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

Физическая резервная база данных – Redo Apply

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

Как работает Redo Apply

В Data Guard Redo Apply используется специализированный процесс, который называется Managed Recovery Process (MRP – процесс управляемого восстановления). По мере того как процесс RFS записывает журнальные данные в оперативные журналы резервной базы данных (Standby Redo Log – SRL), MRP читает журнальные данные и применяет их к физической резервной базе данных.

MRP запускается в физической резервной базе данных при монтировании базы данных и для этого используется следующая команда:

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING
          CURRENT LOGFILE DISCONNECT FROM SESSION; 

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

Для повышения производительности Data Guard Redo Apply процесс MRP может выполняться параллельно. При запуске он автоматически определяет оптимальное число параллельных процессов восстановления.

Проверка достоверности данных перед применением журнальных данных к резервной базе данных

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

Data Guard Redo Apply также обнаруживает потерю записей, вызванную дефектами аппаратных средств и неисправностями встроенного программного обеспечения среды хранения, тем самым, устраняя еще один источник нарушения целостности данных, влияющий на резервную базу данных.

Включенная в состав Active Data Guard Option опция Real-time Query активирует доступ только на чтение к самой последней версии физической резервной базы данных, чтобы разгрузить первичную базу данных от накладных расходов на выполнение запросов и ведение отчетности

 

Проверки обнаружения искажения производятся в следующих ключевых интерфейсах:

  • Для первичной базы данных – во время транспортировки журнальных данных: LGWR, LNS, ARCH
  • Для резервной базы данных – во время Redo Apply: RFS, ARCH, MRP, DBWR.

Если процесс Redo Apply в резервной базе данных обнаружит искажение журнальных данных, то Data Guard повторно извлечет правильные журналы, как часть обработки отставания архивного журнала, в надежде, что оригинальный архивный журнал свободен от искажений.

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

DB_LOST_WRITE_PROTECT

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

Обнаружение потерянных записей наиболее эффективно, когда используется Data Guard. В этом случае, устанавливается параметр DB_LOST_WRITE_PROTECT как в первичной, так и в резервных базах данных. Когда резервная база данных применяет журнальные данные в процессе управляемого восстановления, она читает соответствующие блоки, сравнивает их SCN с SCN в журнале и:

  • Если SCN блока в первичной базе данных меньше, чем SCN в резервной базе данных, это значит, что обнаружена потерянная запись в первичной базе данных, и будет сгенерирована внешняя ошибка (ORA-752). Рекомендованная процедура для восстановления потерянной записи состоит в том, чтобы переключиться с первичной базы данных на физическую резервную базу данных и обновить первичную базу данных.
  • Если SCN больше, можно говорить об обнаружении потерянной записи в резервной базе данных. Генерируется -внутренняя ошибка (ORA-600 3020). Для восстановления потерянной записи в резервной базе данных нужно обновить резервную базу данных или затронутые файлы.

В обоих случаях резервная база данных запишет причину отказа в журнале оповещения (alert) и в файле трассировки.

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

Redo Apply и Real-time

Используя опцию Real-time из Active Data Guard Option, можно открыть физическую резервную базу данных только на чтение, во время применения журнальных данных (восстановление активно), что позволяет выполнять запросы к актуальной реплике первичной базы данных. Это достигается путем использования Enterprise Manager Grid Control 11g, или следующим способом вручную из командной строки:

База данных Snapshot standby может быть открыта на чтение/запись и использоваться для тестирования и других целей. Первичная база данных продолжает передавать журнальные данные во временно обновляемую резервную базу данных, гарантируя, что данные на удаленном узле остаются защищенными. База данных Snapshot standby для сохранности архивирует эти журнальные данные. Когда связанные с тестированием действия завершаются, временно обновляемая база данных Snapshot standby синхронизируется с первичной базой данных путем конвертирования её в резервную базу данных и применения журнальных файлов, которые она всё время получила от первичной базы данных, хотя и она работала как Snapshot Standby.

 

  • Чтобы открыть резервную базу данных для доступа только на чтение, когда активно применение журнальных данных, сначала отмените применение журнальных данных, используя следующее предложение:
    SQL>  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
  • Затем откройте базу данных для доступа только на чтение, используя следующее предложение:
    SQL>  ALTER DATABASE OPEN;
  • После того как резервная база данных была открыта, перезапустите применение журнальных данных, используя следующую команду:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

Snapshot Standby

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

Snapshot Standby может быть создана посредством Enterprise Manager, из интерфейса командной строки Data Guard Broker (DGMGRL) или же при использовании SQL*Plus. Чтобы создать Snapshot Standby из SQL*Plus, просто выполните для физической резервной базы данных следующую команду:

SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

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

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY DATABASE;

Data Guard неявно выполняет ретроспективный откат базы данных назад к гарантированной точке восстановления и автоматически применяет журнальные данные первичной базы данных, которые в Snapshot Standby были занесены в архив за время, прошедшее после создания снапшота. Гарантированная точка восстановления удаляется сразу же после завершения этого процесса.

Логическая резервная база данных – SQL Apply

В логической резервной базе данных содержится та же самая логическая информация, что и в первичной базе данных, хотя ее физическая организация и структура данных могут отличаться от первичной базы данных. Технология SQL Apply обеспечивает синхронизацию логической резервной базы данных с первичной базой путем преобразования в SQL-операторы журнальных данных, полученных из первичной базы данных. Далее эти SQL-операторы выполняются в резервной базе данных. Подобно физической резервной базе данных это позволяет обеспечить в логической резервной базе данных выполнение запросов и составление отчетов в то же самое время, когда активным является процесс применения [архивированных журналов, принимаемых с первичной базы данных – прим.ред.].

В SQL Apply добавлена поддержка для:

  • Типа данных XMLType (CLOB )
  • Параллельного выполнения команд языка описания данных
  • Прозрачного шифрования баз данных (Transparent Data Encryption – TDE)
  • DBMS_FGA (детального аудита)
  • DBMS_RLS (виртуальной приватной базы данных)
  • DBMS_SCHEDULER (планировщика)

 

Логическая резервная база данных имеет большую гибкость, чем физическая резервная база, что следует из того, что она обновляется с использованием SQL-операторов. Это позволяет логической резервной базе данных быть открытой в режиме чтения/записи и выполнять другие задачи, которые требуют доступа к базе  на чтение/запись (например, добавление локальных таблиц, которые существуют только в резервной базе данных, или выполнение отчетов или суммирований, требующих доступа на чтение/запись). Эти задачи могут быть оптимизированы путем создания дополнительных индексов и материализованных представлений для таблиц, которые поддерживаются SQL Apply (отметим, что хотя база данных открыта на чтение/запись, SQL Apply не допустит изменений данных, которые отвечают за синхронизацию с первичной базой данных). В логической резервной базе данных могут храниться несколько схем данных, и пользователи могут выполнять обычные операции манипулирования с табличными данными в схемах, которые не обновляются из первичной базы данных.

Для логической резервной базы данных имеются некоторые ограничения на типы данных, типы таблиц и DML- и DDL- операций. В документации [2] можно найти перечень неподдерживаемых типов данных и атрибутов хранения.

Как работает SQL Apply

В SQL Apply используется набор фоновых процессов, которые выполняют задачу применения изменений из первичной базы данных в логической резервной базе данных. На Рис. 3 показан поток информации и роли, выполняемые каждым процессом.

Рисунок 3 - Схема процессов SQL Apply

Производительность SQL Apply была увеличена для рабочих нагрузок, характеризующихся вставками и обновлениями несекционированных таблиц, которые не содержат столбцов типа LOB, LONG или XML. Параллельные DDL-операции выполняются в SQL Apply также параллельно, еще более повышая производительность процесса применения.

 

Ниже следует краткое перечисление функциональных возможностей каждого из процессов:

  • Процесс Reader читает входящие записи журнала из оперативных журналов резервной базы данных.
  • Процесс Preparer - конвертирует изменения блоков в изменения таблицы, или логические записи файла изменений (Logical Change Records – LCR).
  • Процесс Builder собирает из индивидуальных LCR законченные транзакции.
  • Процесс Analyzer исследует завершенные транзакции, определяя зависимости между различными транзакциями.
  • Процесс Coordinator (также известный как процесс логического резервирования, или LSP), назначает транзакции процессам применения, ведет мониторинг зависимостей между транзакциями и авторизует фиксацию изменений в логической резервной базе данных.
  • Процессы Applier применяют к базе данных LCR для назначенной транзакции и фиксируют транзакции, когда это разрешается Координатором.

Эти процессы SQL Apply запускаются при вводе следующего SQL-предложения:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

Подобно Redo Apply проверки обнаружения искажений происходят в ключевых интерфейсах:

  • В первичной базе данных – во время транспортировки журнальных данных: LGWR, LNS, ARCH
  • В резервной базе данных – во время SQL Apply: RFS, ARCH, SQL, LSP, DBWR.

Как решить, что использовать – Redo Apply или SQL Apply

Оба подхода имеют много общего. Физические и логические резервные базы данных используют один и тот же метод транспортировки журнальных данных и сервисы управления ролями. Различие – только в процессе применения. Любой из них может использоваться для освобождения первичной базы данных от излишней загрузки запросами и отчетностью. Любой из них может использоваться для выполнения накатываемого апгрейда базы данных (пользователи физической резервной базы данных используют временную логическую резервную базу данных, как было описано выше). Все резервные базы данных сначала создаются как физические резервные базы в течение процесса инсталляции резервной базы данных. Для преобразования физической резервной базы данных в логическую требуется несколько дополнительных шагов.

Пользователи обычно выбирают между физическим или логическим резервированием по следующим причинам:

Соображения, влияющие на решение использовать Redo Apply

  • Если воспользоваться Active Data Guard Option, то физическую резервную базу можно легко использовать для освобождения промышленной базы данных от излишней загрузки накладными расходами по обработке отчетов и запросов только_для_чтения.
  • Очень высокие требования к производительности – процесс применения журнальных данных, используемый физической резервной базой данных, очень эффективен, и, следовательно, реализуется  меньшим числом операций ввода/вывода и циклов центрального процессора по сравнению с SQL Apply. Эффективность процесса применения журнальных данных делает его практичным для машин с несколькими промышленными и/или резервными базами данных на одном и том же сервере, и напротив   –  потребление ресурсов может сделать совершенно непрактичным использование SQL Apply. Это может быть важным для компаний, которые желают сократить расходы, развертывая разделяемые ресурсы на серверах, где находятся несколько резервных баз данных.

Гистограмма времени ответа подсказывает пользователям оптимальное значение параметра net_timeout, основываясь на данных из их промышленной среды.

 

  • Относительная простота – Redo Apply является более простым процессом, что весьма притягательно для пользователей, склонных предпочитать более простые решения.
  • Физическая резервная база данных может стать базой Snapshot Standby для тестирования, разработки или для других целей.
  • Физическая резервная база данных может использоваться для разгрузки первичного сервера от выполнения резервного копирования, так как она является точной репликой первичной базы данных.
  • У физической резервной базы данных не имеется никаких ограничений. Ее функционирование и производительность полностью прозрачно для типов данных или профилей транзакций – журнал есть журнал.
  • В сценарии восстановления в аварийных ситуациях некоторые пользователи предпочитают, чтобы их резервная база данных была точной физической копией первичной базы данных.

Соображения, влияющие на решение использовать SQL Apply:

  • Логическая резервная база данных имеет более большую гибкость, поскольку она открыта на чтение/запись. Например, для некоторых приложений для составления отчетов требуется доступ к базе данных на чтение/запись, и хотя пользователи физической резервной базы данных могут обойти это ограничение путем использования связей базы данных с другой базой, в логической резервной базе данных доступ на чтение/запись активируется без каких бы то ни было дополнительных шагов. Поскольку защищенные Data Guard таблицы логической резервной базы данных могут храниться в другом физическом формате, чем в первичной базе, в них можно создавать дополнительные индексы и материализованные представления, чтобы повысить производительность запросов.
  • Логическую резервную базу данных легче использовать для переноса и обработки данных в приложениях для хранилищ данных, поддержки принятия решений или заполнения витрин данных. В логической резервной базе данных могут храниться дополнительные схемы, помимо тех, которые защищены конфигурацией Data Guard, и пользователи могут в любое время выполнять DDL- и DML- операции для этих схем.

Управление конфигурацией Data Guard

Системные представления. Data Guard предлагает различные представления для мониторинга оперативной (run-time) производительности Data Guard во всех деталях. К ним можно обратиться через интерфейсы SQL*Plus, Data Guard Broker или Enterprise Manager Grid Control.

Например, V$REDO_DEST_RESP_HISTOGRAM является фиксированным представлением, содержащим гистограмму времени ответа для адресатов с синхронной (SYNC) транспортировкой журнальных данных. Данные этого представления очень полезны при определении подходящего значения времени сетевого ожидания, используемого для синхронных пунктов назначения. Используемый в режиме максимальной готовности атрибут NET_TIMEOUT представления  LOG_ARCHlVE_DEST_n определяет максимальное время, которое Log Writer ждет подтверждения LNS перед тем, как отказаться от дистанционного пункта назначения, и позволить Log Writer продолжить функционирование. Установка слишком малого значения этого параметра может привести к частым таймаутам, снижающим уровень защищённости данных. Слишком высокое значение может негативно воздействовать на производительность первичной базы данных, вследствие остановок базы данных, когда она должна отказаться от удаленного пункта назначения. Данные из этой гистограммы дают администраторам информацию, необходимую для оптимизации компромисса между целями HA и защиты данных.

Инфраструктура Data Guard Broker – это распределенная инфраструктура управления, которая автоматизирует и централизует создание, обслуживание и мониторинг конфигураций Data Guard. Все операции управления могут быть выполнены либо утилитой Oracle Enterprise Manager Grid Control, которая использует модуль брокера, либо через специализированный интерфейс командной строки самого брокера (DGMGRL).

В следующем списке приводятся некоторые операции, которые автоматизирует и упрощает брокер:

  • Создание и активация конфигураций Data Guard;
  • Управление всей конфигурацией Data Guard с любого узла в конфигурации;
  • Вызов запланированного (switchover) или аварийного (failover) переключения (включая Fast-Start Failover (быстрый запуск аварийного переключения)), в которых задействованы сложные изменения ролей по всем системам в конфигурации;
  • Мониторинг скоростей применения, захват диагностической информации и быстрое обнаружение проблемы с централизованным мониторингом, а также уведомление о событиях.

Страницы (pages) и визарды (wizards) Enterprise Manager для управления Data Guard еще более упрощают создание и управление конфигурацией Data Guard. Enterprise Manager делает возможным анализ исторических трендов для показателей Data Guard, мониторинг которых он ведет. Например, какими были показатели производительности за последние 24 часа или за прошедшие 5 дней и т.д. Кроме того,  через Enterprise Manager можно настроить уведомления и аварийную сигнализацию, чтобы администраторы были уведомлены в случае, если какой-либо показатель достигает или превышает заданное пороговое значение. Приведенный на Рис. 4 скриншот показывает домашнюю страницу Data Guard в – Enterprise Manager.

Примеры показателей Data Guard, мониторинг которых ведется с помощью Enterprise Manager:

  • Estimated Failover Time – предполагаемое время автоматического преодоления последствий сбоя (при аварийном переключении на резервную базу данных) – приблизительное время в секундах, которое потребуется для аварийного переключения к этой резервной базе данных.
  • Apply Lag –  задержка применения изменений – показывает, насколько резервная база данных отстает от первичной базы данных.
  • Redo Apply Rate  скорость применения журнальных изменений (Redo Apply) – скорость, с которой применяются журнальные данные в резервной базе данных.
  • Redo Generation Rate –  скорость генерации журнальных изменений – скорость, с которой в первичной базе данных генерируются журнальные данные.
  • Transport Lag –  задержка транспортировки –  приблизительное число секунд, в течение которого журнальные данные еще недоступны для этой резервной базы данных. Это может происходить потому, что журнальные данные еще не были отправлены, или может быть следствием информационного разрыва.
  • Data Guard Status –  состояние Data Guard – показывает состояние каждой базы данных в конфигурации Data Guard.
  • Fast-Start Failover Occurred – произошел быстрый запуск аварийного переключения – когда активируется быстрый запуск аварийного переключения, этот показатель генерирует критичный сигнал для новой первичной базы данных (старая резервная база данных), если произойдет быстрый запуск аварийного переключения.
  • Fast-Start Failover Time –  время быстрого запуска аварийного переключения – когда активируется быстрый запуск аварийного переключения, этот показатель генерирует критичный сигнал для новой первичной базы данных (старая резервная база данных), если произойдет быстрый запуск аварийного переключения, указывая временную метку происшествия.

Рисунок 4 – Домашняя страница Data Guard в Oracle Enterprise Manager.

Служба управления ролями

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

Запланированное переключение

Switchover (запланированное переключение) применяется для сокращения времени простоя первичной базы данных при так называемых запланированных выходах из строя, например, при обновлении операционной системы или аппаратных средств, или при накатываемых обновлениях программного обеспечения базы данных Oracle и наборах исправлений (patch sets).

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

Запланированное переключение инициализируется администратором через графический интерфейс (GUI) пользователя Oracle Enterprise Manager, интерфейс командной (CLI) строки Data Guard Broker или непосредственно SQL-предложением.

К примеру для инициализации и завершения запланированного переключения к резервной базе данных " Chicago " требуется всего одна команда интерфейса командной строки Data Guard Broker (DGMGRL):

DGMGRL>SWITCHOVER  TO Chicago ;

После инициализации Data Guard автоматизирует фактические процессы перехода роли. Никакие данные в этом процессе потеряны не будут.

Аварийное переключение

Failover (аварийное переключение) – это операция оперативного перевода одной из резервных баз данных в статус   первичной базы данных в тех случаях, когда происходит незапланированный отказ первичной базы данных. Это позволяет обеспечить директивное время восстановления работы системы путем быстрого перехода резервной базы данных в роль первичной, что исключает ответственность за простой базы данных на время, пока будут диагностированы и разрешены события, оказавшие воздействие на первичную базу данных. Для операции аварийного переключения не требуется перезапуск резервной базы данных. Кроме того, при условии, что файлы базы данных в первоначальной первичной базе данных не повреждены и она может быть перезапущена, первоначальная первичная база данных может быть восстановлена и повторно синхронизирована в качестве резервной базы данных для новой первичной базы данных при использовании Flashback Database – ее не требуется восстанавливать с резервной копии.

Ручное аварийное переключение инициализируется администратором через   GUI пользователя Oracle Enterprise Manager, CLI -интерфейс Data Guard Broker или непосредственно через SQL*Plus в резервной базе данных, которая принимает на себя роль первичной. Например, приведенная ниже единственная команда CLI Data Guard Broker – (DGMGRL) инициализирует и завершает аварийное переключение к резервной базе данных "Чикаго":

DGMGRL> FAILOVER TO Chicago ;

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

Быстрый запуск аварийного переключения (автоматическое преодоление последствий сбоя) поддерживает конфигурацию Data Guard в режиме Maximum Performance – максимальной производительности – (асинхронная (ASYNC) транспортировка журнальных данных) с использованием порога потери данных, устанавливаемого пользователем.

 

Быстрый запуск аварийного переключения

Fast-Start Failover (быстрый запуск аварийного переключения) позволяет Data Guard автоматически переключаться к ранее выбранной резервной базе данных, не требуя каких-либо ручных операций  для вызова аварийного переключения. Более того, после возвращения в строй отказавшей первичной базы она будет автоматически восстановлена  как резервная для новой первичной базы данных. Быстрый запуск аварийного переключения может быть использован только в конфигурации Data Guard Broker и может быть сконфигурирован только через DGMGRL или Enterprise Manager.

Мониторинг конфигурации fast-start failover осуществляется отдельным процессом Observer (наблюдатель), который представляет собой процесс легкого типа (lightweight), входящий в состав клиентской части утилиты DGMGRL. Он непрерывно ведет мониторинг среды быстрого запуска аварийного переключения, чтобы проверить доступность первичной базы данных. Если и Observer, и резервная база данных теряют связь с первичной базой данных, Observer пытается повторно соединиться с первичной базой данных в течение заданного при конфигурировании времени, прежде чем приступить к инициализации быстрого запуска аварийного переключения. Процесс быстрого запуска аварийного переключения спроектирован таким образом, чтобы можно было гарантировать: из трех компонентов быстрого запуска аварийного переключения – первичной базы данных, резервной базы данных и процесса наблюдателя – по крайней мере, два соглашаются на это принципиальное изменение состояния. Таким образом удается избежать сценариев «с раздвоением» (split-brain scenario), в которых могут быть две различные первичные базы данных, обслуживающие промышленную рабочую нагрузку. Простая, но тем не менее изящная, архитектура быстрого запуска аварийного переключения делает его превосходным кандидатом для использования в ситуациях высокой готовности, где также важна защита данных.

Преимущество использования Enterprise Manager (EM) заключается в том, что благодаря ему становится возможной высокая готовность Observer в конфигурации с быстрым запуском аварийного переключения Data Guard. EM может вести мониторинг состояния Observer, обнаруживать его отказы, пытаться перезапустить Observer на том хосте, где он был запущен первоначально. А если это не удастся сделать, то EM перезапустит Observer на предварительно назначенном втором хосте. Способность Enterprise Manager обеспечивать высокую готовность процесса Observer является критичным элементом любой стратегии HA, в которой используется быстрый запуск аварийного переключения Data Guard.

Возможность настраиваемого конфигурирования

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

Ниже перечисляются некоторые свойства, предлагаемые для управления поведением быстрого запуска аварийного переключения:

  • FastStartFailoverThreshold – определяет интервал времени (в секундах), в течение которого Observer и целевая резервная база данных будут ждать (после обнаружения недоступности первичной базы данных) до начала инициализации  аварийного переключения.
  • FastStartFailoverLagLimit – является свойством, используемым для определения предельного контролируемого по времени размера потери данных, позволенного при автоматическом аварийном переключении. Если применяемая к резервной базе данных точка журнала (redo point) будет в пределах этого количества секунд от точки генерации журнальных данных в первичной базе данных, то быстрый запуск аварийного переключения будет разрешен. Если же применяемая точка находится вне этого предела, быстрый запуск аварийного переключения не разрешается. Это свойство применимо только в режиме максимальной производительности; оно не используется, если быстрый запуск аварийного переключения активируется, когда конфигурация работает в режиме максимальной готовности.
  • FastStartFailoverAutoReinstate – это свойство может быть установлено в FALSE, чтобы предотвратить автоматическое восстановление отказавшей первичной базы данных после того, как произошло аварийное переключение, если желательно  выполнение диагностики и восстановление старой первичной базы данных.

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

 

Oracle Enterprise Manager или команды ENABLE FAST_START FAILOVER CONDITION утилиты DGMGRL могут определять конкретные условия (события), при которых должен произойти быстрый запуск аварийного переключения, не дожидаясь истечения периода времени порога аварийного переключения. Это относятся следующие события:

  • "Datafile Offline" – файл данных переведен в автономный режим из-за ошибки при записи.
  • "Corrupted Controlfile" – разрушен управляющий файл.
  • "Corrupted Dictionary" – повреждение словаря данных для критичного объекта базы данных.
  • "Inaccessible Logfile" – процесс Log Writer неспособен выполнить запись ни в один из членов группы журнальных файлов из-за ошибки ввода/вывода.
  • "Stuck Archiver" – процесс-архиватор неспособен заархивировать журнал, потому что устройство переполнено или недоступно.

Наконец, можно использовать PL/SQL-пакет DBMS_DG, чтобы позволить приложению запросить быстрый запуск аварийного переключения, если оно столкнётся с определенными состояниями. Если обнаружено однозначно известное приложению состояние, оно может вызвать процедуру DBMS_DG.INITIATE_FS_FAILOVER, таким образом предупреждая первичную базу данных о том, что требуется немедленно произвести быстрый запуск аварийного переключения. Первичная база данных уведомит об этом Observer, и тот немедленно инициализирует быстрый запуск аварийного переключения в предположении, что резервная база данных находится в допустимом состоянии быстрого запуска аварийного переключения (наблюдаемом и либо синхронизированном, либо с допустимым отставанием), чтобы принять аварийное переключение.

ВОССТАНОВЛЕНИЕ СТАРОЙ ПЕРВИЧНОЙ БАЗЫ ДАННЫХ В КАЧЕСТВЕ НОВОЙ РЕЗЕРВНОЙ

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

Если старая первичная база данных может быть перезапущена и смонтирована с неповрежденными файлами данных, то можно использовать Flashback Database, чтобы восстановить старую первичную базу данных, как резервную базу для новой первичной базы данных. При этом не потребуется восстанавливать данные с резервной копии новой первичной базы данных (опция Flashback Database должна быть активирована прежде, чем произойдет событие отказа). Как описано выше, это восстановление является автоматическим, если используется быстрый запуск – аварийного переключения.

В случае ручного аварийного переключения это достигается тоже просто: сначала выполняется ретроспекция старой первичной базы данных к моменту времени, когда произошло аварийное переключение (содержится в столбце STANDBY_BECAME_PRIMARY_SCN представления V$DATABASE), а затем база данных запускается как резервная база данных. После этого Data Guard предоставляется возможность автоматически синхронизировать новую резервную базу данных с новой первичной базой данных. Чтобы достичь этого используя DGMGRL, просто перезапустите старую первичную базу данных, а затем выдайте следующую команду:

DGMGRL> REINSTATE DATABASE  'database';  

АВТОМАТИЧЕСКОЕ АВАРИЙНОЕ ПЕРЕКЛЮЧЕНИЕ КЛИЕНТА

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

  • Полное аварийное переключение узла  использует вторичный узел как хост-машину резервной базы данных Data Guard с полным дублирующим набором серверов приложений промежуточного уровня (middle-tier application servers). При переключении на вторичный узел запускаются серверы промежуточного уровня, а стабилизатор сетевой нагрузки переадресовывается на новый первичный узел. Аварийное переключение Data Guard переведет резервную базу данных во вторичном узле на роль первичной базы данных. Посвященная Oracle MAA статья под названием Oracle Database High Availability Best Practices [5], предлагает руководство по реализации полного аварийного переключения узла.
  • Когда происходит отказ узла в составе Oracle RAC, клиенты, присоединенные к отказавшему узлу, должны быть быстро уведомлены о произошедшем отказе и должны повторно соединиться с выжившими узлами кластера, чтобы продолжить обработку. Технический официальный документ Oracle, который называется Workload Management with Oracle Real Application Clusters [6], предлагает руководство для обработки отказов узлов в составе Oracle RAC.
  • Частичное аварийное переключение узла происходит в тех случаях, когда стала недоступной первичная база данных, но первичный узел остался неповрежденным, и затронутые клиенты после аварийного переключения Data Guard должны быть переадресованы к новой первичной базе данных на вторичном узле. Краткий обзор реализации аварийного переключения клиентов при частичном отказе узла предлагается ниже. Все детали можно найти в документе Client Failover Best Practices for Highly Available Oracle Database [7].

На высоком уровне, автоматизация аварийного переключения клиентов в конфигурации Data Guard включает перемещение Database Services (Сервисы базы данных) в новую первичную базу данных, как часть аварийного переключения Data Guard, уведомление пользователей о произошедшем отказе, чтобы можно было вырвать их из таймаута TCP и переадресовать в новую первичную базу данных.

Перемещение сервисов

В Oracle Database 10g было введено автоматическое средство для управления рабочей нагрузкой кластерных баз данных Oracle (RAC) и баз данных, состоящих из единичного экземпляра, получившее название Database Services [8]. Это средство позволяет группировать рабочие нагрузки баз данных и легко определять вычислительные ресурсы для обслуживания этой рабочей нагрузки. Вы можете определить сервис базы данных для отдельного приложения, например, для приложения 'sales', используемого в приводимом ниже примере. Если первичная база данных, предлагающая этот сервис, выходит из строя, сервис может быть автоматически перемещен в новую первичную базу данных, как часть аварийного переключения Data Guard.

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

Та же самая концепция перемещения сервиса применима и к конфигурации Data Guard. Чтобы проиллюстрировать, как это происходит, представьте себе простую конфигурацию Data Guard, состоящую из единичных узлов первичной и резервной баз данных и сервиса базы данных, названного 'sales', который был создан и сконфигурирован со всеми соответствующими параметрами настройки высокой готовности [7]. Клиентские приложения подключаются к сервису 'sales ', используя алиас Oracle Net, который включает все хосты (и первичные, и резервные) в конфигурации. Нежелательные попытки подключения к резервной базе данных предотвращаются, потому что сервис, упомянутый в алиасе Oracle Net, выполняется только на экземпляре первичной базы данных. Перемещение сервиса на новую первичную базу данных автоматизируется при помощи триггера, который срабатывает, когда изменение роли Data Guard переводит резервную базу данных на роль первичной, запуская сервис в новой первичной базе данных. Например:

CREATE OR REPLACE TRIGGER manage_service AFTER STARTUP ON database 
DECLARE
  role VARCHAR(30); 
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE('sales');
  END IF; 
END;

Уведомление и восстановление соединения клиентов

Продолжим описанный выше пример. Уведомление клиента и восстановление соединения предотвращает возможность клиентов, которые были связаны с первоначальной первичной базой данных во время отказа, оказаться в подвешенном состоянии длительного ожидания истечения TCP-таймаута. Oracle уведомляет этих клиентов о том, что произошел отказ, выводит их из TCP- таймаута и направляет и новые, и существующие подключения на выжившие узлы RAC или в новую первичную базу данных после аварийного переключения Data Guard.

Для OCI-клиентов это достигается путем использования механизма Fast Application Notification (FAN – быстрое уведомление приложений). Новые первичные базы данных знают, какие клиенты были связаны с отказавшим экземпляром, и – как часть процесса аварийного переключения – уведомят таких клиентов, чтобы они повторно подключились к сервису 'sales ', используемому в вышеупомянутом примере.

Для JDBC-уведомления клиентов в конфигурации Data Guard используется механизм Fast Connection Failover (аварийное переключение с ускоренным соединением) и триггер, созданный для резервной базы данных, который срабатывает от системного события DB_ROLE_CHANGE [7], когда резервная база данных переходит к роли первичной. Триггер вызывает программу публикации, предлагаемую Oracle [7], которая уведомляет JDBC-клиентов, что сервис базы данных теперь доступен в новой первичной базе данных, выводя остановившихся («зависших») клиентов из их TCP-таймаута.

Конечная задача состоит, чтобы клиенты были уведомлены об отказе и в предотвращении  TCP-таймаутов, если они впоследствии попытаются повторно соединиться с отказавшим хостом. Это достигается путем использования параметров исходящих соединений SQLNET, определяющих быстрое соединение  клиентов со следующим хостом в списке адресов, если первый адрес не доступен [7].

Дополнительные детали конфигурации для клиентов OCI, OLE DB и JDBC наряду с примерами триггеров, используемых для перемещения сервисов базы данных и публикации событий HA для клиентов JDBC, описаны в статье MAA Client Failover Best Practices for Highly Available Oracle Database [7].

Пользователи физической резервной базы данных могут выполнять накатываемые апгрейды SQL Apply, не используя дополнительной дисковой памяти для логической резервной базы данных. Просто надо преобразовать физическую резервную базу данных в логическую, выполнить накатываемый апгрейд, а затем возвратить логическую базу данных в состояние резервной физической, используя для этого фразу KEEP IDENTITY.

 

События перехода роли

Системное событие Data Guard DB_ROLE_CHANGE срабатывает всякий раз, когда база данных переходит от одной роли к другой. Это очень похоже на системное событие ON STARTUP, за исключением того, что оно срабатывает после изменения роли. Администраторы могут разработать триггеры, которые будут выполняться в случае, если произойдет это событие, как способ для управления задачами, возникающими после изменения роли. Событие срабатывает, когда база данных впервые открывается после перехода роли, независимо от ее новой роли.

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

НАКАТЫВАЕМЫЕ АПГРЕЙДЫ БАЗЫ ДАННЫХ

Обновления программного обеспечения Oracle Database для главных выпусков и обновлений наборами исправлений (10.1.0.3 и последующих) могут быть выполнены близким к нулю временем простоя – базы данных методом наката, если использовать Data Guard SQL Apply (см. Рис. 5).

Рисунок 5 – Накатываемые апгрейды базы данных с SQL Apply.

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

Начиная с Oracle Database 11g физическая резервная база данных может также воспользоваться всеми преимуществами опции накатываемого апгрейда, обеспечиваемыми логической резервной базой данных. Если применить новую опцию фразы KEEP IDENTITY к оператору

 SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY;

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

КАСКАДНЫЕ ПУНКТЫ НАЗНАЧЕНИЯ

Data Guard предлагает много вариантов гибкого конфигурирования. Используя возможность Cascaded Destinations (каскадные пункты назначения), физическая резервная база данных может переадресовать журнальные данные, которые она получает из первичной базы, в другую резервную базу данных. Так как первичная база посылает журнальные данные всего лишь в несколько первых резервных баз, эта опция снижает нагрузку на первичную систему и может при этом сократить сетевой трафик и снизить использование ценных сетевых ресурсов на первичном узле, если необходимо обеспечить наличие большого числа резервных баз данных. Отметим, что в конфигурациях Data Guard, в которых имеют место каскадные пункты назначения, не поддерживаются Oracle RAC и Data Guard Broker.

DATA GUARD И ORACLE REAL APPLICATION CLUSTERS

Data Guard и Oracle RAC – это дополняющие друг друга технологии, обеспечивающие максимально возможный уровень масштабируемости, готовности и защиты данных. За исключением ограничения, распространяющегося на использование каскадных пунктов назначения (описанных выше), интеграция между Oracle RAC и Data Guard является полной и органичной. Любая комбинация Oracle RAC и состоящих из единичного узла баз данных может участвовать в конфигурации Data Guard и принимать на себя любую роль. Технология Oracle RAC обеспечивает идеальное HA-решение для защиты против отказов сервера одновременно с предоставлением уникальных для отрасли функциональных возможностей управления рабочей нагрузкой и масштабируемости. Технология Data Guard предлагает дополнительный уровень готовности и защиты данных с полной избыточностью, где минимизируется время простоя, необходимое для устранения отказов устройств хранения, ошибок оператора, некоторого планового обслуживания, которое не может быть сделано накатываемым способом по узлам Oracle RAC, а также многократных и коррелированных отказов, которые могут привести к отказу узла.

АРХИТЕКТУРА МАКСИМАЛЬНОЙ ГОТОВНОСТИ

Архитектура максимальной готовности Oracle – Maximum Availability Architecture (MAA) [9] – это проверенный Oracle и подтвержденный заказчиками проект лучших методов развертывания технологии высокой готовности Oracle. Цель MAA состоит в том, чтобы устранить сложность при проектировании оптимальной архитектуры высокой готовности.

Лучшие методы MAA включают рекомендации по различным аспектам конфигурации Data Guard, например, конфигурирование с Oracle RAC, оптимизация транспортировки журнальных данных, операции планового или аварийного переключения, аварийное переключение клиентов, производительность Redo Apply, конфигурирование и настройка SQL Apply и т.д. Заказчикам, заинтересованным в реализации Data Guard, настоятельно рекомендуется обратиться к рекомендациям по применению лучших методов MAA.

DATA GUARD И УДАЛЁННОЕ ЗЕРКАЛИРОВАНИЕ

Решения удалённого зеркалирования (remote mirroring solutions) часто рассматриваются как способ предложить простую и полную защиту данных. Есть два вида решений с созданием зеркальных копий в удаленном узле:  

(a) серверная репликация (host-based replication)

(b) зеркалирование массивов хранения (storage array-based mirroring).

В решениях серверной репликации специализированные драйверы файловой системы или компоненты менеджера томов на первичном сервере перехватывают локальные операции записи, упаковывают их в логические сообщения и синхронно или асинхронно посылают их по IP на удаленные (или вторичные) хосты. Такие решения должны поддерживать специализированные журналы для отслеживания порядка записи. Тома данных на вторичном сервере не могут быть использованы (даже для доступа только для чтения) во время выполнения репликации.

В решениях с зеркалированием массивов хранения контроллеры массива хранения на зеркале первичного узла заменяют дисковые блоки ввода/вывода на аналогичный массив хранения на вторичном узле. Эти изменения посылаются с использованием протоколов типа ESCON, FICON и Fibre Channel, хотя в некоторых современных версиях также поддерживается транспортировка на базе iSCSI и IP. Зеркалирование по соответствующим каналам связи управляется специализированными адаптерами связи, загруженным соответствующим встроенным программным обеспечением. По мере того как на первичном сервере происходит ввод/вывод, данные записываются в кэш исходного массива и помещаются в очередь. Адаптер связи берет первый элемент очереди и перемещает его по связи в зеркалированный массив.

Технология Data Guard по своей природе более эффективна, менее дорога и лучше оптимизирована для защиты баз данных Oracle, чем решения с зеркалированием на  удаленном узле. Для того чтобы с помощью Data Guard защитить базу данных Oracle, заказчики не должны покупать или интегрировать решения с зеркалированием в удаленном узле. Существенная дополнительная выгода Data Guard – это возможность использовать резервную базу данных для промышленных целей, в то время как она находится в резервной роли. Для детального анализа этой темы рекомендуем обратиться к документу [10].

ПОЛЬЗОВАТЕЛИ DATA GUARD

Функциональность Data Guard стала доступна, начиная с Oracle Version 7. С каждым последующим выпуском Oracle в ней продолжали добавляться новые функциональные возможности, и она становилась все более зрелой технологией . Она развертывается для стратегически важных приложений на вычислительных площадках заказчиков во всем мире. Множество детализированных конкретных учебных примеров реализации можно найти в сети OTN [11].

ЗАКЛЮЧЕНИЕ

Data Guard 11g фундаментально изменяет традиционную парадигму восстановления в аварийных ситуациях , предлагая интегрированное решение для HA/DR с беспрецедентной защитой данных, в котором резервные системы одновременно поддерживают и промышленные функции, и функции QA, в то время как они находятся в резервной роли.

Технология Oracle Data Guard обеспечивает всеобъемлющую защиту данных, восстановление в аварийных ситуациях и решение с высокой готовностью для всего предприятия. Она предлагает гибкую и простую в управлении инфраструктуру, решающую вопросы как запланированных, так и незапланированных выходов из строя. Физические и логические резервные базы данных обеспечивают высококачественную защиту данных, освобождая от излишней загрузки первичные базы данных. Различные режимы защиты данных обеспечивают гибкость, необходимую для приспособления к различным требованиям уровней защиты, производительности и инфраструктуры. Модуль Data Guard Broker в комбинации с Oracle Enterprise Manager обеспечивает удобную в работе инфраструктуру и конфигурацию управления.

Независимо от той глубины, на которую высокая готовность была ранее встроена в вашу ИТ-инфраструктуру с использованием кластеров, зеркалированим дисков или различных стратегий резервного копирования и восстановления, фактом является то, что защита данных, готовность и возврат ваших инвестиций в ИТ многократно усиливаются при добавлении к архитектуре ваших ИТ-технологии решений Data Guard.

ССЫЛКИ

  1. Oracle Data Guard
    http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html
  2. Oracle Data Guard Concepts and Administration
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/toc.htm
  3. Oracle Data Guard Broker
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28295/toc.htm
  4. Overview: Oracle Database High Availability
    http://www.oracle.com/technology/deploy/availability
  5. Using RMAN with Data Guard – MAA Best Practices
    http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_10g_wp.pdf
  6. Oracle High Availability Architecture and Best Practices
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b25159/toc.htm
  7. Workload Management with Oracle Real Application Clusters (Provides a detailed explanation of the implementation of Services, FAN and Fast Connection Failover)
    http://www.oracle.com/technology/products/database/clustering/pdf/twpracwkldmgmt.pdf
  8. Client Failover Best Practices for Highly Available Oracle Databases
    http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf
  9. Database Services
    http://download-west.oracle.com/docs/cd/B19306_01/rac.102/b14197/hafeats.htm
  10. Oracle Maximum Availability Architecture,
    http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
  11. The Right Choice for Disaster Recovery: Data Guard, Stretch Clusters or Remote Mirroring,
    http://www.oracle.com/technology/deploy/availability/techlisting.html
  12. Oracle High Availability Case Studies,
    http://www.oracle.com/technology/deploy/availability/htdocs/HA_CaseStudies.html

Отзывы некоторые пользователей о применении механизма Oracle Data Guard в промышленной практике

"В компании Fidelity National Financial успешно реализованы инфраструктуры Grid и Oracle RAC. Помимо них был развернут диспетчер восстановления Oracle (RMAN ), чтобы реализовать функциональные возможности резервного копирования и восстановления (Backup and Recovery ), а технология Data Guard использовалась для обеспечения дистанционного восстановления в аварийных ситуациях и высокой готовности в глобальных сетях. В cовокупности, использование возможностей высокой готовности ( High Availability) Oracle и реализация с использованием лучших методов архитектуры максимальной готовности Oracle (Oracle Maximum Availability Architecture – MAA) позволило FNF выполнить все соглашения об уровне сервиса по самой низкой стоимости".
Чарльз Ким, глава совета по проектированию баз данных Oracle, компания Fidelity Information Services

"Fast-Start Failover (механизм Data Guard быстрого запуска аварийного переключения) обеспечивает быстрое, простое, автоматическое преодоление последствий сбоя в системе управления отказами. В компании PPL  эта система круглосуточно обеспечивает критичные сервисы заказчика, особенно, в напряженных ситуациях.  Хотя мы использовали Data Guard для восстановления в аварийных ситуациях, начиная еще с Oracle9i, опция быстрого аварийного переключения на резервную базу данных размывает грань между High Availability и DR – делая для нас возможным разрешение обоих требований в рамках единого решения".
– Крис Картер, директор службы корпоративных технологий корпорация PPL Services

«Применение Data Guard Rolling Upgrade привело к ограничению времени простоя в процессе полного обновления нашей базы данных (от Oracle10.1.0.3 к Oracle 10.1.0.4), серверов и дисковой памяти. Мы полностью исключили простой для доступа по чтению, а время простоя для транзакций чтения/записи теперь не превышает 30 минут».
– Дэн Дрессель,
архитектор базы данных, компания Thomson Legal & Regulatory

“Data Guard является нашим предпочтительным решением для восстановления данных Oracle в аварийных ситуациях. Наши приложения отличаются очень высокой производительностью. Никакой другой продукт производства третьих фирм не может даже приблизиться к производительности, которой может достигнуть Data Guard в конфигурациях с нулевой потерей данных”.
– Манохар Малайянур, Менеджер и архитектор инфраструктуры, компания Fannie Mae

"Логическая резервная база данных Data Guard является важным компонентом долгосрочных стратегических аппаратных и программных платформ, в значительной степени увеличивая емкость и масштабируемость для наших пользователей. После реализации этого полного решения, мы достигли повышения производительности большинства операций пакетной обработки на 50-95%".
– Дэвид Синк, архитектор систем анализа бизнес-информации, компания e-Reward Market Research

"Data Guard, вследствие нашего знакомства с Oracle, стал для нас естественным выбором. Мы были достаточно компетентны в области Oracle. Нам не нужно было покупать новые виды памяти или новые компоненты для имеющихся у нас систем запоминающих устройств или обучать наших сотрудников использованию решений для репликации от третьих фирм. Применение Data Guard позволяет нам достигнуть более высокого уровня защиты данных и готовности".
– Майк Балинт , старший администратор базы данных, компания Burligton Coat Factory

"Мы используем Symmetrix EMC и располагаем широкой полосой пропускания, таким образом, у нас имеется возможность использовать решения типа SRDF, но для этой критичной системы баз данных мы выбрали Data Guard. Главным стимулом для нас стали согласованность и целостность данных ".
– Дэвид Вилен, Главный директор по технологиям, компания BarnesandNoble.com

"Наше трансатлантическое развертывание Data Guard через 3 000 миль обеспечивает уровень надежности и защиты данных, требующийся для многих регулирующих органов, перед которым мы являемся подотчетными как специализирующаяся в областях фармацевтической продукции и биологии компания, работающая в 27 различных странах на нескольких континентах".
– Кевин Брэдли , заместитель директора, компания Global R&D Business Systems, Support and Delivery


Oracle Data Guard 11g, The Next Era in Data Protection and Availability
February 2009
Authors: Ashish Ray, Larry Carpenter, Joseph Meeks
Technical Review: Serge De La Sablonniere, Mike Dietrich, Holger Kalinowski, Michael Rhys
Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.
Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com
Copyright © 2007, Oracle. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.