Adg oracle что это

Обновлено: 07.07.2024

Oracle Data Integration, Cloud, Spatial and Analytics (GoldenGate, ODI, Cloud, Spatial, Exadata)

Давайте посмотрим, как это работает. Сначала нам нужно создать экземпляр ADG.

Создаем базу данных ADG

1. Включаем принудительное логгирование всех изменений и архивирование журналов

2. Настраиваем параметры на основной (primary database):

3. На primary создаем standby logs (они будут нужны, когда наш primary станет standby при смене ролей)

3. Делаем резервную копию базы данных

4. Делаем копию управляющих файлов и файла параметров для standby

5. Редактируем файл параметров

6. Копируем файл паролей

7. Создаем серверный файл параметров

8. Копируем управляющий файл

9. Запускаем базу данных

10. Восстанавливаем базу данных

11. Запускаем накат изменений

12. Запускаем standby в режиме Active Dataguard. Для этого на целевой базе выполняем следующие команды:

13. Пересоздадим standby redo на резервной системе

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

16. В listener создаем для брокера сервисы

17. Сбросим значение LOG_ARCHIVE_DEST_2 на primary и standby, чтобы Data Guard Broker мог ими управлять автоматически.

18. Создаем конфигурацию

20. Включаем конфигурацию

21. Попробуем переключиться на резервную систему

Настраиваем GoldenGate для захвата изменений из ADG

Захватывать изменения из ADG может только классический Extract. Связано это с тем, что Integrated Extract создаем объекты внутри базы данных, а в ADG это делать нельзя. Если нужно получать изменения в Real Time с помощью Integrated Extract, то нужно использовать downstream режим.

1. Создаем Alias для подключения к ADG

2. Создаем файл параметров для GoldenGate Extract

3. Добавляем Extract

4. Запуска захват изменений

5. После этого мы получаем вот такой вывод в report-файле GoldenGate

Переключение на резеверную систему

Давайте посмотрим, что будет происходить при переключение GoldenGate на резервную систему.

Switchover

Подключаем к Data Guard Broker, смотрим текущуб конфигурацию и запускаем переключение

В результате GoldenGate Extract падает с ошибкой, чего и следовало ожидать

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

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

Failover

Давайте выполним аварийное переключение на резервную систему

В результате GoldenGate падает с ошибкой

Последующие попытки запуска будет оканчиваться неудачей

Запустим переинициализацию с помощью flashback.

А затем перенастроим GoldenGate Extract, чтобы он смотрел на новую резервную базу. Я также установил текущий SCN:

Согласно документации еще нужно использовать параметр TRANLOGOPTIONS USEPREVRESETLOGSID, но у меня и без него заработало.

Какие были проблемы при настройке

Я тестировал на Oracle Database 12.1.0.2 и GoldenGate 12.2. Судя по всему, связка еще не очень отлаженная, да и документация оставляет желать лучшего. Итак, что я встретил:

ERROR OGG-10144 (cab.prm) line 7: Parameter [MINEFROMACTIVEDG] is not valid for this configuration.

Решение 1. Переключить GoldenGate в классический режим

Проблема 2. При захвате изменений на ADG я получил ошибку

У меня этот запрос возвращает 2:

Если посмотреть поглубже, то становится понятно в чем проблема

Решение 2. Добавлять standby log с явным указанием thread. Вот так

Заключение

Режиме захвата изменений непосредственно из ADG довольно интересен. С одной стороны он полностью real-time, с другой - нагрузка на источник полностью отсутствует - грузим только сервер с ADG. Сопровождать GoldenGate в режиме работы с ADG довольно легко - с downstream немного сложнее.

Но есть и обратная сторона медали: режим с ADG - это классический режим, а значит более ограничен по функционалу.

4 комментария

С уважением,
Василий

Да, действительно, multitenancy поддерживается только integrated extract. Как вариант использовать downstream сервер для приему логов. В случае базы данных 12c можно даже настроить, чтобы логи приходили с adg.

Active Data Guard - простое, высокопроизводительное решение, которое хранит актульную копию производственной БД для перенаправления интенсивных запросов, отчетов и резервных копий с производственной базы данных нарезервную.

Улучшает качество обслуживания

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

Традиционный Data Guard

Самое известное применение Oracle Data Guard - синхронизация физической резервной базы данных с ее производственной частью для защиты данных и их высокой готовности. До выхода Oracle Database 11g, физические резервные базы данных в основном действовали в постоянном режиме Redo Apply (например, постоянное отслеживание изменений в основной базе данных). Такой режим гарантировал, что отказоустойчивость базы данных будет обеспечена в течение нескольких секунд после сбоя. Redo Apply должен быть остановлен для того, чтобы предоставить доступ на чтение для резервной базы данных Data Guard 10g. В результате получалась резервная базы данных, в которой хранятся статические данные, что увеличивало время восстановления после сбоя.

Oracle Active Data Guard

Oracle Active Data Guard позволяет открывать физические резервные базы (physical standby database) данных на чтение - для создания отчетов, простых или сложных запросов, сортировки, доступа через Веб-интерфейс и т.д., в то время, как изменения из производственной базы данных применяются на резервной. Все запросы из резервной физической базы данных выполняются в реальном времени и возвращают текущие результаты. Это означает, что любая операция, которая требует быстрый доступ на чтение, может быть выполнена в резервной физической базе данных, что увеличивает производительность и разгружает основную базу данных. Active Data Guard также поддерживает отслеживание изменений через RMAN, что позволяет выгружать быстрые инкрементальные резервные копии с основной на резервную базу данных. Скорость инкрементальных резервных копий может в несколько раз превышать скорость бэкапов резервных баз данных в ранних версиях продукта.

Самое простое решение, способное повысить производительность, - это перенос рабочих процессов, которым необходим доступ только на чтение, на синхронизированную копию основной базы данных. Опция Oracle Active Data Guard для Oracle Database 11g Enterprise Edition повышает качество обслуживания, перенося отнимающие ресурсы системы рабочие процессы с основной базы данных на одну или более синхронизированные резервные базы данных. Active Data Guard это осуществляет, предоставляя доступ только на чтение к физическим базам данных для запросов, отчетов в реальном времени, Веб-доступу и т.д. При этом постоянно обновляются изменения в соответствии с основной базой данных. Active Data Guard также устраняет затруднения при резервном копировании производственной системы, отслеживая изменения через функции RMAN, и выполняя быстрое инкрементальное резервирование с использованием физической резервной базы данных. Active Data Guard предоставляет новые функциональные возможности, помимо тех функций Data Guard, которые уже включены в Oracle Database Enterprise Edition. В то же время, пользователи Active Data Guard могут значительно улучшить производительность своих систем, получить преимущество от ведущих в отрасли функций высокой готовности и катастрофоустойчивости, реализованных в Data Guard, а также многих других функций. Следующая диаграмма кратко иллюстрирует Oracle Active Data Guard.

Преимущества Active Data Guard

1. Повышает скорость работы производственной базы данных: Перенос части нагрузки в актуальную копию основной базы данных.
2. Упрощает операции: Устраняет сложности управления, свойственные традиционным решениям для репликации.
3. Упрощает обновление: Копия базы данных обновляется и всегда находится в режиме онлайн, что невозможно с использованием традиционной технологии зеркалирования.
4. Сокращает затраты: Резервная база данных Active Data Guard также обеспечивает защиту от катастроф и высокую готовность, и кроме того может служить в качестве тестовой системы. Дополнительного оборудования или программного обеспечения не требуется.
5. Сокращает время резервирования: Совершает инкрементальное резервирование в 20 раз быстрее посредством функции RMAN Block Change Tracking на физической резервной базе данных.Примеры использования Active Data Guard

Active Data Guard позволяет использовать физические резервные базы данных для широкого спектра бизнес-задач. Примеры из разных отраслей:

- Телекоммуникации: Доступ инженеров к графикам обслуживания и запрос клиентами статуса.
- Здравоохранение: Доступ к свежим медицинским сведениям.
- Финансы и администрирование: специализированные запросы, отчеты и информационные панели для руководителей.
- Транспортировка: Отслеживание упаковок, запросы, графики. - Интернет-бизнес: Просмотр каталога, заказы клиентов, поиск.

Active Data Guard Reader Farms

Если рассматривать пример Интернет-бизнеса, то необходимо учитывать,что существует постоянная необходимость увеличивать скорость работы для поддержания запросов через каталог, поиск заказов и других действий, предусматривающих только чтение, которые могут значительно меняться в зависимости от времени года или других непредвиденных обстоятельств, которые ведут к внезапному увеличению объема заказов. Active Data Guard уникальным образом подходит под эти ситуации, поскольку можно легко сконфигурировать дополнительные резервные базы данных под высокую загрузку. Одна производственная база данных способна отслыать изменения на девять и менее резервных баз данных, что создает так называемый Reader Farm. Дополнительные резервные базы данных могут быть использованы для увеличения производительности практически до неограниченного масштаба. На рисунке ниже приведен пример обычного Reader Farm. В дополнение к этому, в связи с тем, что Active Data Guard совместим с функционалом Data Guard, изображенная ниже Reader Farm уже включает в себя функции защиты данных и высокой готовности. Если в основной базе данных произойдет сбой, то любая резервная базаданных может легко перехватить ее роль. Это позволяет автоматически синхронизировать оставшиеся базы данных с самыми последними транзакциями.

Уникальные преимущества Oracle Active Data Guard

Active Data Guard - развитие технологии Data Guard, которая, помимо других улучшений, включенных в Oracle Data Guard 11g, предоставляет уникальные возможности повышения производительности. Например,можно легко переконвертировать любую физическую базу данных Data Guard 11g в резервную базу данных Snapshot Standby. Snapshot Standby открыта на чтение и запись, поэтому она идеально подойдет в качестве тестовой системы, которая обрабатывает транзакции независимо от основной базы данных. Snapshot Standby поддерживает защиту информации, продолжая получать данные с основной базы данных, и архивирует их для дальнейшего использования. Когда тесты завершены, с помощью одной команды можно отменить все изменения, произведенные в процессе открытого чтения/записи, и быстро синхронизировать резервную базу данных с основной. Можно легко проследить, как все эти функции соотносятся друг с другом. В связи с тем, что все они используют одну и ту же общую инфраструктуру, они дают значительные преимущества заказчикам Oracle. Копия базы данных, используемая Oracle Active Data Guard для увеличения качества обслуживания, может быть использована в часы малой загрузки в качестве тестовой базыданных Snapshot Standby, а также может всегда использоваться в качестве катастрофоустойчивого решения. Поэтому вместо того, чтобы хранить несколько копий на дорогостоящем оборудовании, используя различные технологии для удовлетворения различным требованиям, Oracle Active Data Guard предоставляет общую инфраструктуру и единую базу данных с одним интерфейсом управления, который позволяет достичь тех же результатов.

Проще, дешевле и больше функций - Oracle Active Data Guard сложно победить.

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

Системы с высокой готовностью

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

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

Технология Oracle Data Guard и резервные базы данных

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

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

Базы данных, обслуживаемые в рамках конфигурации Oracle Data Guard, могут находиться как в одной и той же локальной сети (LAN), так и в более широкой глобальной сети (WAN). Резервные базы данных, находящиеся в локальной сети, обеспечивают возможность более быстрого восстановления после обычных неполадок, а резервные базы данных, находящиеся в глобальной сети, лучше защищают от катастрофических аварий, охватывающих весь центр данных или целые локальные сайты. Конфигурировать можно одну главную базу данных и несколько резервных. За счет выбора правильного уровня защиты при настройке резервных баз данных время простоя можно сводить до менее чем одной минуты. Ниже приведен краткий перечень тех многочисленных преимуществ, которые дает использование технологии Oracle Data Guard и резервных баз данных:

Высокая степень готовности.
Защита от аварий.
Защита от физического повреждения данных.
Защита от ошибок пользователей.
Возможности передачи управления (failover) или переключения (switchover), которые могут применяться как для запланированного, так и незапланированного переключения производственных и резервных баз данных.
Географическое разделение главных (первичных) и второстепенных (вторичных) серверов посредством Oracle Net.

Для оказания помощи в создании и управлении конфигурациями Oracle Data Guard компания Oracle предоставляет замечательное программное обеспечение Oracle Data Guard Broker (Брокер защиты данных Oracle). Оно способно поддерживать вплоть до десяти баз данных сразу (одну главную и девять резервных) и управлять выполнением административных операций, наподобие применения журналов, их переноса и передачи управления или переключения с главной базы данных на второстепенную. В нем предусмотрено два интерфейса: интерфейс командной строки и графический пользовательский интерфейс под названием Data Guard Manager (Диспетчер средств защиты данных).

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

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

Физические и логические резервные базы данных

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

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

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

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

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

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

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

Режим максимальной защиты. Этот режим, также называемый режимом двойной защиты от сбоев (double failure protection mode), обеспечивает наивысший уровень защиты. Он гарантирует, что в случае выхода из строя главной базы данных никакие данные утрачиваться не будут. Для обеспечения такой защиты данные повторного выполнения перед фиксацией транзакции должны обязательно записываться как в соответствующий оперативный журнал главной базы данных, так и в соответствующий оперативный журнал хотя бы одной резервной базы данных. При невозможности выполнить запись данных повторного выполнения в хотя бы один из журнальных файлов второстепенной базы данных, главная база данных будет останавливаться.
Режим максимальной готовности. Этот режим, также называемый режимом безотлагательной защиты (instant protection mode), обеспечивает защиту от отказа главной производственной базы данных. Он гарантирует наивысший из возможных уровень защиты данных при поддержании главной базы данных в доступном состоянии. При этом режиме данные повторного выполнения с главного сервера записываются на нем асинхронно сразу же после фиксации транзакций. В случае использования этого режима возможна утрата главной базы данных, резервной базы данных или соединения между ними, но не утрата каких-либо данных. При утрате соединения с резервной базой данных главный сервер прекращает пересылать ей изменения, но все равно продолжает работать.
Режим максимальной производительности. При отсутствии необходимости в защите с нулевой потерей данных и желании, чтобы уровень производительности главной базы данных был максимальным, следует выбирать именно этот режим. В этом режиме главная база данных не ожидает получения подтверждения от второстепенной прежде, чем фиксировать транзакции. Из-за этого, в случае выхода главной базы данных из строя, в резервной базе данных может не хватать каких-нибудь изменений, которые уже были зафиксированы в главной базе.

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

Виртуализация, вычислительные платформы, СХД, проектирование, проектная документация

Продолжение, начало тут и тут.

Для начала немного теории:

Data Guard Broker

Fast Start Failover

Автоматический failover на стороне клиента

На серверах произошел failover или switchover, клиент должен подключиться или продолжить работу (т.е. переподключиться). Желательно автоматически. Желательно не потеряв данные. Желательно незаметно для приложения.

В случае Connect-time Failover все просто: даем список адресов и говорим пробовать подключаться к следующему, если предыдущий недоступен.

В случае Run-time Failover есть варианты, но всех их роднит то, что транзакция, в ходе которой произошел failover, вылетает с ошибкой и приложению нужно эту ситуацию обработать:

Transparent Application Failover для OCI based applications like sqlplus and JDBC thick clients
Fast Connection Failover для JDBC thin connections

Подробности в виде презентаций: TAF, FCF и FAN.

1. Лекция по теме: Построение Standby Database на основе технологии Oracle Active Data Guard

2. Технологии Oracle для систем повышенной надежности

Активная реплика
Active Data Guard
RAC
– масштабируемость
– Защита от сбоя сервера
Flashback
– Защита от
ошибок
человека
– Защита от катастроф
– Нагрузка на чтение
GoldenGate
– Active-active
– Heterogeneous
RMAN, Oracle Secure Backup
– Backup to tape / cloud
ADG – это технология, обеспечивающая процесс
односторонней репликации транзакций из основной
БД на резервную БД посредством фоновых процессов
сервера СУБД.
2

3. Когда нужны системы повышенной готовности и системы повышенной надежности ?

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

4. Классификация приложений в системах повышенной надежности

Виды приложений Времени простоя RTO
RPO
Критичные
Недопустим
Секунды
Недопустимо
Бизнескритичные
Уровня
предприятия
Не критичные
Минимальный
Минуты
Недопустимо
Бизнес-час
Часы
Минимальная
Час
Дни
Не имеет значения
RTO (recovery time objective) - показатель определяет допустимое
время простоя в случае наступления катастрофического события.
RPO (recovery point objective) - показатель определяет, какой объем
данных вы можете себе позволить потерять в случае наступления
катастрофического события.
4

5. Oracle Active Data Guard 12c

Standby
ASYNC
SYNC
Primary
Active Standby
ASYNC режим
передачи данных из
STANDBY_REDO_LOG
Active Standby
SYNC режим передачи данных в
STANDBY_REDO_LOG
Far Sync экземпляр,
контейнер для резервных
файлов
журнала транзакций
Синхронный транспорт (SYNC) иногда упоминается как метод "без потери
данных", потому что процесс LGWR не фиксирует транзакцию пока не
подтвердится, что аналогичная запись есть на Standby DB. Если
подтверждения по каким либо причинам не приходит, то это сказывается
на работоспособности основного сервера, поэтому обычно используют
асинхронный транспорт (позволяет не дожидаться ответа со Standby).
5

6. Database в конфигурации DataGuard

Фоновые процессы:
LGWR Log Writer - копирует содержимое буфера журнала из памяти на
диск.
Новый процесс LNS ( LogWriter Network Server – сетевой сервер записи
в журнал)
избавляет процесс LogWriter от накладных расходов,
связанных с передачей журнальных данных в удаленную резервную
базу данных.
При совершении транзакции создается redo log в области SGA, LGWR
читает эту запись из relo log buffer и записывает ее в online redo log file и ждет подтверждения от LNS. LNS читает ту же запись из буфера и
передает ее в резервную базу данных с помощью Oracle Net Services,
процесс Remote File Server (RFS) получает запись и записывает ее в
Standby Redo Logs (SRL).
6

Если LNS не успевает забирать запись из буфера , то он
автоматически переходит к чтению и отправке записи из файла
журнала транзакций вместо redo log buffer. После того, как LNS
(LogWriter Network Server) сможет догнать LGWR, он опять
возвращается к чтению прямо из буфера в SGA.
Соотношение redo log buffer отслеживается с помощью представления
X$LOGBUF_READHIST : низкий коэффициент указывает, что LNS
читает из журнального файла вместо буфера ( на заметку, если это
происходит регулярно, попробуйте увеличить размер буфера журнала).
По мере того как процесс RFS записывает журнальные данные в SRL,
MRP (Managed Recovery Process) читает данные из SRL и применяет
изменения непосредственно к Standby DB.
Процесс MRP может также переключиться на чтение из архивного
журнала резервной базы данных, если SRL архивирован прежде, чем
MRP может закончить чтение SRL (ситуация, которая может произойти
- когда первичная база данных имеет очень высокую скорость
генерации журнальных данных).
7

Если вследствие отказа сети или отказов резервных серверов
разрывается соединение первичной и резервных баз данных, то
первичная база данных продолжает обрабатывать транзакции и
накапливать журнальные данные, которые не могут быть отправлены в
резервные базы данных до тех пор, пока не будет установлено новое
сетевое подключение. В таком случае будет выполнятся следующий
сценарий:
1) Процесс ARCH в Primary постоянно будет опрашивать Standby,
чтобы определить ее состояние.
2) Когда связь восстанавливается, то ARCH опрашивает standby
control file (с помощью процесса RFS), чтобы определить последнюю
версию журнального файла полученных от primary.
3) Data Guard узнает какие журнальные файлы нужны для
синхронизации и сразу начинает их передавать с помощью
дополнительных ARCH процессов.
4) После синхронизации LNS начинает работать в обычном режиме.
8

Иллюстрация работы фоновых процессов в синхронном и асинхронном
режиме передачи информации на резервную базу данных и при разрыве связи.
9

10. Методология конфигурирования DG

До клонирования. Цель – все сервера
должны работать, как одна логическая
машина.
II. Клонирование. Цель – создание такой же
структуры и содержания, как на Primary DB.
III. После клонирования. Цель – запуск процесса
репликации. Настройка DG Broker.
Мониторинг.
I.
10

11. 1. До клонирования

1.1 Перевод базы данных в режим логирования;
1.2 Запуск резервного экземпляра.
1.3 Настройка сетевых файлов;
1.4 Настройка параметров init.ora;
1.5 Создание файла паролей;
1.6 Добавление standby_redo_log файлов;
11

12. 1.1 Перевод базы данных в режим логирования

SQL> archive log list;
SQL> SELECT flashback_on, log_mode FROM v$database;
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> archive log list;
Database log mode
Automatic archival
Archive Mode
Enabled
SQL> alter database force logging;
SQL> select force_logging from v$database;
FORCE_LOGGING
--------------------------------------YES
12

13. 1.2 Настройка параметров init.ora

SQL> show parameter db_unique_name;
SQL> alter system set
log_archive_config='dg_config=(spbstu,spbstu_stb)’ scope=both;
// LOG_ARCHIVE_CONFIG - определяем имена экземпляров,
между которыми будет происходить обмен журналами. //
SQL> alter system set log_archive_dest_2='SERVICE=spbstu_stb
LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=spbstu_stb’ scope=both;
SQL> alter system set log_archive_dest_state_2=ENABLE
scope=both;
SQL> show parameter log_archive_dest_state_2
//log_archive_dest_2 - куда будут передаваться архивлоги файловой системе или сервису. Параметр ASYNC указывает,
что данные, сгенерированные транзакцией, не обязательно
должны быть получены на standby до завершения транзакции.
13

SQL> alter system set FAL_SERVER=spbstu_stb scope=both;
SQL> alter system set FAL_CLIENT=spbstu scope=both;
// fal_client=’spbstu’ – этот параметр определяет, что когда
экземпляр перейдет в режим standby, он будет являться
клиентом для приема архивных журналов (fetch archive log).
fal_server=’spbstu_stb’ – определяет FAL (fetch archive log)
сервер, с которого будет осуществляться передача архивных
журналов. Параметры fal_client и fal_server работают только
когда база запущена в standby режиме. //
SQL> alter system set standby_file_management='AUTO’
scope=both;
//
standby_file_management=’AUTO’
–
задаем
режим
автоматического управления файлами в standby режиме. При
таком значении параметра все создаваемые или удаляемые
файлы основной базы будут автоматически создаваться или
удаляться и на standby базе. //
14

17. 1.4 Добавление standby_redo_log файлов

18. 1.5 Создание файла паролей

19. 1.7 Запуск Standby DB

$ sqlplus / as sysdba
SQL> startup nomount pfile=‘/…. ora’
SQL> show parameter db_unique_name;
SQL> select status from v$instance;
STATUS
-----------------------------------STARTED
19

20. 1.3 Oracle Net

Primary
LISTENER2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(
HOST = 192.168.10.102)(PORT = 1522))
)
)
SID_LIST_LISTENER2 =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = spbstu)
(SID_NAME = spbstu)
(ORACLE_HOME =
/u01/app/oracle/product/12.1.0/db_1)
)
)
Standby
LISTENER2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(
HOST = 192.168.10.103)(PORT = 1522))
)
)
SID_LIST_LISTENER2 =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = spbstu)
(SID_NAME = spbstu_stb)
(ORACLE_HOME =
/u01/app/oracle/product/12.1.0/db_1)
)
)
20

23. Утилиты для проверки сети

24. 2. Клонирование

2.1 Проверка существования директорий
указанных в primary init file на Standby DB;
2.2 Установка параметра local listener;
2.3 Подключение к RMAN;
2.4 Проверка создания standby_log_file на
Standby DB;
2.5 Перевод standby db в режим mount;
24

25. 2.1 Проверка существования директорий указанных в primary init file на Standby

Primary
SQL> show parameter audit
audit_file_dest
/u01/oracle/admin/spbstu/adump
Standby
$ mkdir -p /u01/oracle/admin/spbstu/adump
25

26. 2.2 Установка параметра local listener

Primary
SQL> alter system set local_listener='(DESCRIPTION =(ADDRESS =
(PROTOCOL = TCP)(HOST = …… )(PORT = 1522)))' scope=both;
Standby
SQL> alter system set local_listener='(DESCRIPTION =(ADDRESS =
(PROTOCOL = TCP)(HOST = ….. )(PORT = 1522)))' scope=both;
LOCAL_LISTENER указывает имя сети, указывающее на адрес
или список адресов Oracle Net местных слушателей (то есть,
слушателей, которые работают на той же машине). Адрес или
список адресов указан в TNSNAMES.ORA файле.
26

27. 2.3 Подключение к RMAN

Скрипт для RMAN
run allocate channel chan1 type disk;
allocate channel chan2 type disk;
allocate auxiliary channel aux1 device type disk;
allocate auxiliary channel aux2 device type disk;
duplicate target database for standby from active database
dorecover nofilenamecheck; >
Параметр nofilenamecheck нужен, чтобы rman не ругался на
повторяющиеся имена файлов (если мы используем
одинаковую структуру каталогов на primary и standby).
28

29. 2.4 Проверка создания standby_log_file на Standby

30. 2.5 Проверяем, что standby db в режим mount;

Standby
SQL> select name, db_unique_name, database_role,
protection_mode from v$database;
SQL> select name, controlfile_type, open_mode, log_mode
from v$database;
NAME
CONTROL OPEN_MODE
--------- -------------------- -----------SPBSTU
STANDBY MOUNTED
LOG_MODE
ARCHIVELOG
Если не в mount :
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
30

31. 3. После клонирования

3.1 Узнать max redo log на primary и max standby
redo log на standby;
3.2 Запуск процесса MRP0;
3.3 Мониторинг Redo Apply;
3.4 Перевод базы данных в режим read only
3.5 Переключение ролей баз данных.
31

32. 3.1 Узнать max redo log на primary и max standby redo log на standby

33. 3.2 Запуск и останов процесса MRP0

Переводим нашу standby базу в режим Real-time apply redo:
SQL> alter database recover managed standby database using
current logfile disconnect;
Или
SQL> alter database recover managed standby database using
current logfile disconnect from session;
Если мы не хотим использовать режим Real-time apply redo, а
хотим дожидаться когда будет закончено формирование
очередного архивного журнала на основном сервере и он будет
передан на standby для применения сохраненных в нем
транзакций, то нам необходимо переводить нашу standby базу
в режим redo apply командой:
SQL> alter database recover managed standby database
disconnect;
Если что-то пошло не так, то для решения проблемы в первую
очередь необходимо остановить «накатку» логов:
SQL> alter database recover managed standby database cancel;
33

34. 3.3 Мониторинг Redo Apply

35. Системные представления DG

На стороне Primary
View
На стороне Standby
V$ARCHIVED_LOG
Какие логи отправляются
Полученные логи
V$ARCHIVED_DEST_STATUS
Состояние arch процессов, куда В каком режиме применяются
они
отправляют
файлы, логи.
последний отправленный файл.
V$DATAGUARD_STATUS
-
Информация из alert log файла.
V$MANAGED_STANDBY
-
Запущен ли процесс MRP.
35

37. 3.4 Перевод standby в режим read only

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;
SQL> select name, open_mode, log_mode, database_role from
v$database;
NAME
OPEN_MODE
LOG_MODE
--------- -------------------- ------------ ---------------SPBSTU READ ONLY WITH APPLY
ARCHIVELOG
DATABASE_ROLE
PHYSICAL STANDBY
37

38. Конфигугирование Data Guard Broker

primary и standby:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=" ";
SQL> ALTER SYSTEM set
dg_broker_config_file1='+DATA/db_brocker1.dat' SCOPE=both;
SQL> ALTER SYSTEM set
dg_broker_config_file2='+ARCH/db_brocker2.dat' SCOPE=both;
SQL> ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=both;
38

Остановить bkoker
SQL> ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=both;
Выключить конфигурацию:
DGMGRL> disable configuration;
Удалить конфигурацию:
DGMGRL> REMOVE CONFIGURATION;
Получить подробную информации по базе:
DGMGRL> show database verbose spbstu_stb
Получить подробную информации по экземпляру:
DGMGRL> show instance verbose spbstu on database spbstu_stb
40

41. 3.5 Переключение ролей баз данных.

DGMGRL> switchover to 'SPBSTU_STB';
DGMGRL> switchover to 'SPBSTU';
41

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

В Data Guard предлагаются три режима защиты данных для
балансировки стоимости, готовности, производительности и
защищенности данных. Эти режимы определяют правила,
управляющие поведением конфигурации Data Guard, и могут
быть легко установлены, используя любой из доступных
интерфейсов управления, например, если для первичной базы
данных использовать следующий простой оператор SQL:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE
;
Чтобы определить подходящий режим защищенности данных,
нужно взвесить свои бизнес-требования к защите данных и
соотнести их с допустимым для пользователей временем
ответа системы.
42

Режим
Риск потери данных
Метод
транспортировки
журнальных данных
Maximum Protection
(Максимальная
защищенность)
Нулевая потеря данных
SYNC
Maximum Availability
(Максимальная
готовность)
Нулевая потеря данных
– в предположении, что
до отказа не было
никаких нарушений в
синхронной передаче
данных в то время,
когда первичная база
данных фиксировала
(commit) транзакции
SYNC
Maximum Performance
(Максимальная
производительность)
Минимальная потеря
данных – не более
нескольких секунд – в
зависимости от полосы
пропускания сети
ASYNC
43

44. Практика

Для закрепления полученного материала на
практике слушателям предлагается выполнить ряд
заданий по управлению процессом репликаций:
Подготовить
primary для создания потоковой
репликации;
Клонировать primary database на standby database;
Запустить реплику;
Остановить реплику;
Снова запустить реплику.
44

Читайте также: