Oracle Data Guard: документация и аналитика по резервированию и восстановлению

На практике я не раз сталкивался с одной и той же ситуацией: компания формально внедрила Data Guard, лицензии куплены, standby поднят, отчёты зелёные — а в момент реального инцидента выясняется, что лаг давно не контролировался, параметры transport/apply настроены не под реальную нагрузку, а switchover никто не проверял месяцами. В итоге технология, которая должна была сократить RTO и удержать RPO в разумных пределах, не даёт ожидаемого эффекта.

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

Что такое Oracle Data Guard и зачем он нужен

Oracle Data Guard — это встроенный механизм Oracle Database для создания и сопровождения резервной базы данных, которая поддерживается в актуальном состоянии за счёт передачи и применения redo. И здесь ключевое слово именно redo: система не просто копирует файлы по расписанию, а воспроизводит изменения практически в реальном времени, опираясь на журналы транзакций основной базы.

Иными словами, приложения продолжают работать с основной базой, Oracle записывает изменения в redo logs, а Data Guard организует доставку этих изменений на резервную площадку и их применение на standby. За счёт этого резервная база остаётся максимально близкой к production-состоянию и может быть использована для планового или аварийного переключения.

Зачем это нужно:

• Защита от отказов: если Primary Database выходит из строя, standby может взять на себя роль рабочей базы за минуты, а при хорошей подготовке — ещё быстрее.
• Соответствие требованиям: стандарты и внутренние политики вроде ISO 27001, PCI DSS, GDPR и корпоративных DR-регламентов обычно требуют не просто бэкапа, а управляемого механизма восстановления с прогнозируемым временем возврата сервиса.
• Снижение RTO (Recovery Time Objective): вместо восстановления из резервной копии за часы можно перейти на заранее подготовленную standby-систему за секунды или минуты.
• Минимизация RPO (Recovery Point Objective): при правильно выбранном режиме транспортировки логов потери данных могут быть минимальными, а в некоторых сценариях — нулевыми.

С инженерной точки зрения ценность Data Guard в том, что он встроен в саму платформу Oracle Database и работает на уровне её собственной архитектуры. Это не внешний инструмент-надстройка, которому приходится «догонять» СУБД, а штатный механизм, понимающий redo, роли базы и процедуры переключения. Именно поэтому при грамотной настройке он даёт предсказуемый и управляемый результат.

Практический нюанс: Data Guard не заменяет резервное копирование через RMAN. Он решает задачу непрерывности и быстрого переключения, но не защищает, например, от логических ошибок, которые уже успели реплицироваться на standby. В production Data Guard почти всегда должен идти в связке с регулярными backup/restore-процедурами.

Архитектура Oracle Data Guard: как это устроено

Основные компоненты

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

Если говорить проще, Primary генерирует изменения, transport доставляет их, standby принимает и применяет, а Broker помогает этим управлять и контролировать состояние конфигурации. На проектах это удобно представлять как две независимые задачи: доставка redo и применение redo. Ошибки могут возникать на любом из этих этапов, и лечатся они по-разному.

Как работает синхронизация

Типовой цикл синхронизации выглядит так:

1. На Primary Database: приложение выполняет транзакцию, Oracle фиксирует изменения и записывает их в redo logs.
2. Передача логов: соответствующие redo отправляются на Standby Database по сети.
3. На Standby Database: полученные логи принимаются и применяются к копии базы.
4. Синхронизация: standby поддерживается в актуальном состоянии и при необходимости может быть быстро переведена в роль рабочей базы.

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

На практике, конечно, многое зависит от конкретного типа standby и лицензирования. Например, при использовании Active Data Guard появляется возможность открывать standby на чтение, что полезно для отчётности и разгрузки primary. Но даже в таких сценариях нельзя забывать, что главная задача standby — быть корректной и готовой к роли основного узла, а не просто служить «бесплатной копией для запросов».

Режимы защиты Data Guard: выбираем правильный

Одна из самых частых ошибок при внедрении Data Guard — выбирать режим защиты по описанию «самый безопасный» или «самый быстрый», без привязки к реальным SLA и характеристикам инфраструктуры. В Oracle здесь всё довольно честно: чем выше требования к нулевой потере данных, тем сильнее система зависит от качества канала и тем заметнее влияние на подтверждение транзакций.

Data Guard предлагает три режима передачи логов. По сути это выбор между RPO, latency и доступностью самой primary в условиях проблем со standby.

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

Как работает: Primary ждёт подтверждения от Standby, прежде чем завершить транзакцию.

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

Плюсы:

• Нулевая потеря данных (RPO = 0)
• Максимальная гарантия консистентности

Минусы:

• Задержка транзакций на величину сетевой latency
• Если Standby недоступна — Primary не может работать
• Требует надёжного сетевого канала

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

Из практики: Maximum Protection имеет смысл только там, где инфраструктура действительно соответствует режиму. Если standby вынесена далеко, канал нестабилен, а бизнес не готов к остановке primary при сбое связи, такой выбор быстро превращается в источник инцидентов.

2. Maximum Availability (Максимальная доступность)

Как работает: Primary ждёт подтверждения, но если Standby недоступна, Primary продолжает работать.

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

Плюсы:

• Очень низкая потеря данных в нормальной ситуации
• Primary не зависит жёстко от доступности Standby
• Хороший баланс между безопасностью и производительностью

Минусы:

• Возможна потеря нескольких последних транзакций при отказе Primary
• Требует настройки таймаутов

Когда использовать: большинство production-систем, где важны предсказуемое восстановление и низкий риск потери данных, но при этом инфраструктура не должна «падать вместе с резервом» при любой проблеме на standby.

Именно этот режим я чаще всего рекомендую как стартовую точку. При условии, что команда понимает свои RTO/RPO и умеет мониторить transport/apply lag, Maximum Availability даёт очень здоровый баланс между эксплуатационной устойчивостью и защитой данных.

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

Как работает: Primary отправляет логи асинхронно, не ждёт подтверждения.

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

Плюсы:

• Минимальное влияние на производительность Primary
• Наименьшая latency для приложений
• Подходит для высоконагруженных систем

Минусы:

• Возможна потеря данных (RPO может быть несколько минут)
• Требует мониторинга отставания Standby

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

Ключевой риск здесь в том, что асинхронный режим иногда внедряют «по умолчанию», а затем ошибочно считают standby полноценной zero data loss-защитой. Если бизнес ожидает одно, а фактический RPO другое, проблема не техническая, а архитектурная.

Таблица сравнения режимов

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

Установка и настройка Oracle Data Guard

Предварительные требования

До начала настройки стоит проверить не только «наличие двух серверов», но и совместимость всего контура. В Data Guard масса проблем возникает не на этапе создания standby, а позже — из-за разных patch level, несовпадения путей, неучтённой сетевой задержки или нехватки места под архивы.

Перед началом убедитесь, что у вас есть:

• Две машины с одинаковой версией Oracle Database (минимум 12c для современных подходов)
• Сетевое подключение между серверами с низкой latency (желательно < 10 ms)
• Достаточно дискового пространства на Standby (как минимум столько же, сколько на Primary)
• Одинаковая файловая структура или использование ASM (Automatic Storage Management)
• Резервная копия Primary Database в режиме open resetlogs

От себя добавлю важный эксплуатационный момент: версии Oracle должны совпадать не только «в целом», но и по patch level. На бумаге мелкая разница может казаться несущественной, а на деле именно она приводит к неприятным сбоям при apply redo или неожиданному поведению broker-команд.

Пошаговая настройка

Шаг 1: Подготовка Primary Database

Сначала на основной базе нужно убедиться, что включён режим архивирования логов:

ARCHIVE LOG LIST;

Вывод должен показать:

Database log mode              Archive Mode
Automatic archival             Enabled

После этого включите Force Logging:

ALTER DATABASE FORCE LOGGING;

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

Шаг 2: Создание резервной копии Primary

На Primary создайте резервную копию в режиме open:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

Передайте резервную копию на Standby-сервер.

В production лучше заранее продумать способ доставки и проверки целостности бэкапа. Формально можно просто «переложить файлы», но при больших объёмах данных удобнее использовать стандартизованный pipeline с checksum-контролем, чтобы не искать потом причину сбоя в испорченном backup piece.

Шаг 3: Подготовка Standby Database

На Standby-сервере восстановите datafiles из резервной копии:

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;

Создайте init-параметры для Standby на основе Primary, но добавьте параметры Data Guard:

DB_UNIQUE_NAME=standby_db
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,standby_db)'
LOG_ARCHIVE_DEST_1='LOCATION=/archivelog VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=standby_db'
LOG_ARCHIVE_DEST_2='SERVICE=primary_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=primary_db'
FAL_SERVER=primary_db
STANDBY_FILE_MANAGEMENT=AUTO

Запустите Standby в режиме mount:

STARTUP MOUNT;

Здесь особенно важно не относиться к параметрам как к формальности. Неверно заданный DB_UNIQUE_NAME, неаккуратная настройка LOG_ARCHIVE_DEST_n или забытый STANDBY_FILE_MANAGEMENT=AUTO потом оборачиваются ручным сопровождением, проблемами с новыми datafile и ошибками в role transition.

Шаг 4: Включение Log Apply Services

На Standby запустите автоматическое применение логов:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Проверьте статус:

SELECT PROCESS, STATUS, THREAD#, SEQUENCE#
FROM V$MANAGED_STANDBY;

Вывод должен показать активные процессы применения логов:

MRP0   APPLYING_LOG
RFS    IDLE

Если процессы поднялись, это ещё не означает, что всё действительно работает стабильно. Всегда стоит дополнительно проверить, двигаются ли sequence, нет ли зависания на конкретном archived log и не накопился ли transport lag. Именно на этом этапе чаще всего проявляются проблемы с сетью, параметрами listener/service name и доступностью архивов.

Шаг 5: Настройка Data Guard Broker (опционально, но рекомендуется)

Data Guard Broker заметно упрощает управление конфигурацией и делает операции switchover/failover более предсказуемыми. В современных инсталляциях я бы рассматривал его не как «дополнительную опцию», а как нормальный рабочий инструмент для администрирования.

На обеих базах включите Broker:

ALTER SYSTEM SET DG_BROKER_START=TRUE;

На Primary создайте конфигурацию:

DGMGRL> CREATE CONFIGURATION dg_config AS
PRIMARY DATABASE IS primary_db
CONNECT IDENTIFIER IS primary_db;

Проверьте статус:

DGMGRL> SHOW CONFIGURATION;

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

Мониторинг и управление Data Guard

Data Guard нельзя считать настроенным, если для него не выстроен мониторинг. Это одна из тех технологий, которые выглядят надёжными ровно до первого инцидента, если команда не отслеживает lag, статус archive destination и состояние apply-процессов. В production полезно следить не только за фактом «есть связь/нет связи», но и за динамикой отставания.

Проверка синхронизации

Регулярно проверяйте, что Standby синхронизирована:

На Primary:

SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;

На Standby:

SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;

Если SEQUENCE# на Primary больше, чем на Standby, значит есть отставание.

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

Мониторинг отставания Standby

SELECT ARCHIVED_SEQ#, APPLIED_SEQ#
FROM V$ARCHIVE_DEST_STATUS
WHERE STATUS='VALID';

Разница между этими значениями — это отставание в архивах.

Если лаг растёт постепенно, а не скачком, это обычно говорит не о разовом сбое, а о системной нехватке ресурсов: пропускной способности канала, IOPS на standby или CPU для recovery-процессов. Такие ситуации особенно опасны тем, что долго остаются незамеченными.

Проверка задержки передачи логов

SELECT DEST_NAME, DELAY_MINS
FROM V$ARCHIVE_DEST
WHERE TARGET='STANDBY';

Если DELAY_MINS > 0, значит есть задержка в передаче логов.

Здесь важно различать намеренную задержку и проблему транспорта. В некоторых архитектурах delay может быть задан осознанно, но в большинстве production-контуров любое ненулевое значение требует внимания. Особенно если бизнес ожидает почти синхронную защиту.

Failover и Switchover: когда и как переключаться

Обе операции часто упоминают вместе, но по смыслу это разные сценарии. Switchover — штатное и управляемое изменение ролей, failover — аварийная мера, когда primary уже потеряна или недоступна. Для эксплуатации принципиально важно понимать разницу: не только техническую, но и организационную.

Switchover (плановое переключение)

Switchover используется для планового обслуживания Primary или для переноса нагрузки на другой сервер.

Процесс:

DGMGRL> SWITCHOVER TO standby_db;

Важно: Switchover — это управляемый процесс, данные не теряются.

Время выполнения: обычно 5–15 минут, в зависимости от размера базы и количества активных транзакций.

На практике длительность зависит ещё и от дисциплины подготовки. Если перед переключением не проверен lag, не остановлены чувствительные batch-процессы и не согласованы действия с приложенческой командой, даже формально простой switchover может пройти нервно. Хорошая практика — использовать его не только для обслуживания, но и как регулярную проверку готовности DR-контура.

Failover (аварийное переключение)

Failover используется, когда Primary недоступна и требуется срочное восстановление.

DGMGRL> FAILOVER TO standby_db;

Важно: после failover Standby становится Primary, но старая Primary больше не может быть восстановлена как Primary без пересоздания Data Guard конфигурации.

Время выполнения: 2–5 минут.

Именно здесь чаще всего вскрываются реальные пробелы в подготовке. Если команда не знает, как затем реинтегрировать бывшую primary, не понимает фактический RPO на момент аварии или не имеет чёткой runbook-последовательности, сам failover может пройти быстро, а дальнейшее восстановление нормальной архитектуры затянется на часы.

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

Типичные проблемы и их решение

Даже корректно настроенный Data Guard со временем сталкивается с вполне типовыми проблемами: лаг применения логов, разрывы канала, рассинхронизация controlfile, нехватка места под архивы. Хорошая новость в том, что большинство этих случаев давно знакомы администраторам и относительно предсказуемы. Плохая — если их долго не замечать, они быстро превращаются из мелкой деградации в полноценную потерю готовности standby.

Проблема 1: Standby отстаёт от Primary

Признаки: V$ARCHIVE_DEST показывает DELAY_MINS > 0, логи на Primary не применяются на Standby.

Причины:

• Низкая пропускная способность сети
• Медленный диск на Standby
• Недостаточно ресурсов CPU на Standby

Решение:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Перезагрузите Standby:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Если проблема повторяется, не ограничивайтесь перезапуском recovery. Это временная мера. Нужно смотреть, где именно образуется узкое место: в сети, на storage, в архивировании или в параметрах самой standby. Иначе лаг вернётся, просто чуть позже.

Проблема 2: Сетевой разрыв между Primary и Standby

Признаки: логи перестали передаваться, V$ARCHIVE_DEST показывает CLOSED или ERROR.

Решение:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Если это не помогает, стоит проверить listener, service name, DNS/host resolution, firewall и реальную доступность порта между площадками. В enterprise-среде сетевой разрыв далеко не всегда означает «упал канал» — нередко причина в промежуточной сетевой политике, изменившемся маршруте или незаметной смене параметров балансировщика.

Проблема 3: Controlfile на Standby несинхронизирован

Признаки: ошибки при попытке восстановления, inconsistent database.

Решение:

ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';

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

Лучшие практики для production-среды

Набор лучших практик для Data Guard несложен, но именно его соблюдение отделяет «стенд есть» от действительно рабочей схемы аварийного восстановления. Ниже — те вещи, которые стоит делать не по чек-листу ради галочки, а как часть регулярной эксплуатации.

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

Даже если выбран Maximum Availability, используйте асинхронную передачу (ASYNC) в параметрах log_archive_dest. Это снижает latency для приложений.

LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db'

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

2. Разместите Standby в отдельном ЦОД

Если Primary и Standby находятся в одном ЦОД, при отказе площадки можно потерять обе базы сразу. Поэтому standby имеет смысл географически отделять. Это базовый принцип disaster recovery, который почему-то до сих пор игнорируют в проектах, где резервный сервер «для скорости и простоты» ставят в том же машинном зале.

3. Регулярно проверяйте восстановление

Раз в месяц выполняйте тестовый switchover:

DGMGRL> SWITCHOVER TO standby_db;

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

4. Мониторьте задержку передачи логов

Установите alert, если задержка превышает 5 минут:

SELECT DEST_NAME, DELAY_MINS
FROM V$ARCHIVE_DEST
WHERE DELAY_MINS > 5;

Порог в 5 минут — хороший ориентир для многих систем, но его нужно привязывать к вашим SLA. Если допустимый RPO — 1 минута, то и алерт должен срабатывать раньше. Главное — не ограничиваться ручной проверкой раз в день, а выводить эти метрики в постоянный мониторинг.

5. Используйте Fast Recovery Area (FRA)

FRA упрощает управление архивами и автоматически удаляет старые архивы:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/fra';

Это действительно облегчает сопровождение, особенно если объём archived redo значителен. Но FRA не бесконечна: если её размер выбран без учёта peak-нагрузки и возможных задержек на standby, переполнение произойдёт в самый неудобный момент. Размер FRA лучше рассчитывать с запасом, а не «по минимально достаточному объёму».

6. Документируйте RTO и RPO

Определите приемлемые значения для вашей системы:

Это очень важный момент. Пока RTO и RPO не зафиксированы документально, любая дискуссия о «достаточной отказоустойчивости» остаётся субъективной. Для DBA и архитекторов такие параметры — не формальность, а рамка, в пределах которой выбираются режимы Data Guard, сетевые требования и регламент тестирования.

Интеграция Data Guard с облачными решениями

Сегодня Data Guard давно вышел за пределы классической схемы «два физических сервера в собственных ЦОД». Его активно используют в облачных и гибридных архитектурах, где standby выступает не только как DR-узел, но и как этап миграции или промежуточный контур для переноса нагрузки.

Oracle Cloud Infrastructure (OCI)

OCI предоставляет встроенную поддержку Data Guard. Вы можете создать Primary в OCI и Standby в другом регионе OCI.

# Пример развертывания зависит от используемого сервиса OCI и конкретной конфигурации Data Guard

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

Гибридная схема (On-Premise + Cloud)

Вы можете разместить Primary на on-premise сервере, а Standby в облаке (OCI, AWS RDS):

• Плюсы: географическое разделение, масштабируемость облака
• Минусы: зависимость от интернет-подключения, потенциально выше latency

Гибридная схема особенно интересна как переходный вариант при миграции в облако. На ряде проектов standby в OCI фактически становилась сначала DR-контуром, а затем точкой переключения в новую целевую среду. Но такие сценарии требуют аккуратной проработки маршрутов, безопасности каналов, DNS-переключения и поведения приложений после смены роли базы.

Заключение

Oracle Data Guard — это не просто инструмент резервирования и не замена классическим backup-процедурам. Это архитектурный механизм обеспечения непрерывности бизнеса, который позволяет подготовить базу к отказу primary заранее, а не импровизировать уже после аварии. Его ценность проявляется там, где команда понимает режимы защиты, следит за синхронизацией, контролирует lag и регулярно проверяет сценарии восстановления.

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

Для большинства production-систем разумная отправная точка — Maximum Availability, выстроенный мониторинг и ежемесячный тестовый switchover. Это практичный и трезвый подход: он даёт высокий уровень защиты без излишнего риска для производительности и доступности primary. А дальше уже можно углублять архитектуру под требования конкретной системы, будь то жёсткое RPO, распределённая инфраструктура или гибридная миграция в облако.

FAQ: Часто задаваемые вопросы

В: Можно ли использовать Data Guard для балансировки нагрузки?

О: Нет, в классическом варианте Standby находится в режиме mount и недоступна для обычного чтения. Однако в Oracle 11g и выше появилась функция Active Data Guard, которая позволяет читать данные со Standby. Но это требует дополнительной лицензии.

На практике Active Data Guard часто используют для отчётности и разгрузки основной базы, но к такому сценарию нужно подходить аккуратно: standby не должна превращаться в «ещё одну рабочую базу», которую боятся трогать для DR-проверок.

В: Какой максимальный размер базы, которую можно защитить Data Guard?

О: Нет технических ограничений. Data Guard работает с базами размером от нескольких ГБ до нескольких ТБ. Ограничения только в сетевой пропускной способности и дисковом пространстве.

На больших объёмах, конечно, растут требования к bandwidth, storage throughput и времени инициализации standby. То есть вопрос обычно не в поддержке размера как такового, а в том, насколько инфраструктура способна выдержать требуемый RPO/RTO.

В: Что происходит с Standby, если Primary упадёт?

О: Standby остаётся в режиме mount и продолжает применять логи из архива, если они доступны. После failover Standby становится Primary.

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

В: Нужна ли одинаковая версия Oracle на Primary и Standby?

О: Да, для надёжной работы нужна одна и та же версия и patch level. Различия в версиях могут привести к ошибкам при применении логов.

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

В: Можно ли иметь несколько Standby для одной Primary?

О: Да, это называется cascading standby. Одна Primary может иметь несколько Standby, и Standby может передавать логи другой Standby (каскадная архитектура).

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

В: Как часто нужно проверять синхронизацию Data Guard?

О: Минимум раз в день. Для критичных систем рекомендуется непрерывный мониторинг через инструменты типа Oracle Enterprise Manager или Zabbix.

Из практики — для действительно критичных контуров ручной ежедневной проверки недостаточно. Нужны алерты по lag, состоянию transport/apply и доступности broker-конфигурации, иначе проблема будет замечена слишком поздно.

В: Что такое Data Guard Fast-Start Failover?

О: Это автоматический failover, который срабатывает, если Primary недоступна более N секунд (обычно 30). Не требует ручного вмешательства, но требует дополнительной лицензии.

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

В: Можно ли использовать Data Guard с резервными копиями RMAN?

О: Да, RMAN и Data Guard работают вместе. Вы можете создавать резервные копии на Primary, и они будут автоматически применяться на Standby.

Именно сочетание RMAN и Data Guard даёт зрелую стратегию защиты данных: первый отвечает за восстановление из резервных копий, второй — за быстрое переключение и сокращение простоя. В enterprise-контуре эти механизмы обычно должны дополнять друг друга, а не заменять.