Oracle Data Guard: ключевой игрок в аварийном восстановлении

Oracle RAC, Oracle Data Guard и Stream — это три инструмента в системе высокой доступности Oracle. Каждый инструмент можно использовать отдельно или в комбинации. Они имеют разную направленность и применимы в разных сценариях.

Oracle RAC превосходно справляется с устранением единой точки отказа и балансировкой нагрузки.

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

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

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

Streams, основанный на Oracle Advanced Queue, обеспечивает синхронизацию данных и предлагает гибкие конфигурации на нескольких уровнях. Поскольку Oracle обеспечивает обширную поддержку разработки, включая богатые API, Streams больше подходят для совместного использования данных на уровне приложений.

Что такое Oracle Data Guard?

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

Oracle Data Guard дополнительно оптимизирует этот процесс, автоматизируя и оптимизируя задачи передачи и восстановления журналов, а также предоставляя ряд параметров и команд для упрощения работы администраторов баз данных (DBA).

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

Архитектура Data Guard

Архитектуру Data Guard можно разделить на три функциональные части:

1) Redo Send:

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

2) Redo Receive:

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

3) Redo Apply:

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

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

В зависимости от того, когда происходит повторное применение, существует два типа:

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

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

Физический режим ожидания и логический режим ожидания

Существует два типа резервных баз данных: физический резервный и логический резервный.

1. Физический режим ожидания:

Физическая резервная база данных аналогична основной базе данных. Data Guard поддерживает базу данных физического резерва посредством применения REDO. Обычно, когда физический резервный режим не применяет REDO, его можно открыть в режиме ТОЛЬКО ЧТЕНИЕ. Если в базе данных указана область Flashback, ее можно даже временно переключить в режим READ WRITE для выполнения операций. После завершения необходимых операций базу данных можно восстановить обратно в состояние, существовавшее до режима ЧТЕНИЕ-ЗАПИСЬ, с помощью функции Flashback Database, что позволяет продолжить применение данных REDO из основной базы данных.

Примечание. Функциональность приложения физического резерва была расширена в Oracle 11g. В этой версии физический резервный режим может продолжать применять данные REDO, находясь в режиме OPEN READ ONLY. Это значительно повышает удобство использования баз данных физического резерва.

Особенности физического режима ожидания:

1) Аварийное восстановление и высокая доступность.  Физический резерв обеспечивает надежное и эффективное решение для аварийного восстановления и высокой доступности. Это упрощает управление переключением/переключением при отказе и сокращает плановые и внеплановые простои.

2) Защита данных.  Благодаря базе данных физического резерва Data Guard сводит к минимуму потерю данных даже в случае непредвиденных катастроф.

3) Разгрузка рабочей нагрузки основной базы данных.  Перенося определенные задачи, такие как резервное копирование и запросы только для чтения, на физическую резервную базу данных, можно сэкономить ресурсы ЦП и ввода-вывода в основной базе данных.

4) Повышенная производительность.  Механизм применения REDO, используемый в базах данных физического резерва, работает на самом низком уровне восстановления, минуя выполнение кода SQL. Это обеспечивает максимальную эффективность и производительность.

2. Логический резерв:

Логическая резервная база данных также создается на основе основной базы данных (или ее резервных копий или реплик, например физической резервной). Поэтому изначально она похожа на базу данных физического резерва. Однако, поскольку логический резервный сервер применяет данные REDO посредством выполнения SQL, его физическая файловая структура и даже логическая структура данных могут отличаться от основной базы данных.

В отличие от физического резервного режима, логический резервный обычно открывается в режиме ЧТЕНИЕ-ЗАПИСЬ, что позволяет пользователям получить к нему доступ в любое время. Другими словами, выполнение SQL происходит, пока логический резервный модуль находится в состоянии ОТКРЫТО. Это имеет преимущества и недостатки. Из-за характера выполнения SQL существуют эксплуатационные ограничения для определенных типов данных и некоторых операторов DDL/DML в логическом резерве. Вы можете проверить неподдерживаемые типы данных в представлении DBA_LOGSTDBY_UNSUPPORTED. Если используются такие типы данных, невозможно гарантировать полную согласованность в базе данных.

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

Особенности логического резерва:

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

1) Эффективное использование аппаратных ресурсов на резервном сервере.  Логическую резервную базу данных можно использовать для создания дополнительных индексов, материализованных представлений и удовлетворения конкретных бизнес-потребностей. Он также может создавать новые схемы (которых нет в основной базе данных) и выполнять операции DDL или DML, которые не подходят для основной базы данных.

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

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

Режимы защиты данных

Data Guard поддерживает три режима защиты данных: максимальная защита, максимальная доступность и максимальная производительность.

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

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

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

2. Максимальная доступность:

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

Хотя этот режим направлен на минимизацию потери данных, он не может гарантировать абсолютную согласованность данных. Как и максимальная защита, этот режим требует, чтобы резервная база данных была настроена с использованием резервных журналов повторного выполнения, а основная база данных использовала режимы LGWR, SYNC, AFFIRM для архивирования в резервную базу данных.

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

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

Действия по изменению режима защиты данных:

1. Завершите работу базы данных и перезапустите ее в состоянии монтирования. Если это установка RAC, закройте все экземпляры и запустите только один экземпляр в состоянии монтирования.

2. Измените режим, используя следующий синтаксис:

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

Например:

SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3. Откройте базу данных:

ALTER DATABASE OPEN;

4. Подтвердите измененный режим защиты данных:

SQL>select protection_mode,protection_level from v$database;

Журнал применения служб

Data Guard обеспечивает согласованность между основной базой данных и резервными базами данных путем применения REDO. За кулисами этого процесса незаметно поддерживают известные службы Log Apply Services. Существует два типа служб применения журналов:

1. REDO Apply: применяется только к физическим резервным базам данных, обеспечивает их синхронизацию с основной базой данных посредством восстановления с носителя.

2. SQL Apply:  исключительно для логических резервных баз данных. Его основные функции включают в себя анализ операторов SQL с помощью LogMiner и их выполнение на резервной стороне.

Таким образом, при применении данных REDO физическая резервная база данных должна находиться в состоянии MOUNT, а логическая резервная база данных открывается в режиме READ WRITE для приложения данных REDO. Однако обслуживаемые объекты по умолчанию доступны только для чтения и не могут быть изменены напрямую на логической резервной стороне.

Защитите базу данных Oracle с помощью профессионального решения

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

Vinchin Backup & Recovery  предоставляет мощные функциональные возможности для защиты ваших баз данных как на виртуальных машинах, так и на физических серверах, что является достаточно автоматическим, гибким и эффективным. Он обеспечивает многотипную защиту баз данных Oracle DB, MySQL, SQL Server, Postgres Pro и MariaDB , поддерживает сжатие баз данных, централизованное управление заданиями, интеллектуальные стратегии резервного копирования, горячее резервное копирование базы данных и расширенную поддержку SQL Server/Oracle. Кроме того, он также поддерживает мощную функцию защиты от программ-вымогателей  и миграцию V2V  на более чем 10 виртуальных платформ.