Logical Standby Database

Logical Standby Database — это технология резервного копирования и репликации данных в системе управления базами данных Oracle, которая позволяет поддерживать на standby-сервере (резервном сервере) логически согласованную копию основной (primary) базы данных. В отличие от физической standby-базы, где данные копируются на уровне блоков данных, Logical Standby Database использует механизм преобразования archived redo log (архивированных журналов повторного выполнения) в SQL-транзакции и их последующего применения к standby-базе. Это позволяет standby-базе оставаться открытой для операций чтения и, в некоторых конфигурациях, для ограниченных операций записи, одновременно обеспечивая защиту от потери данных.

История и развитие

Технология Logical Standby Database была впервые представлена компанией Oracle Corporation в версии Oracle Database 9i (2001 год) как часть функционала Data Guard. Основной целью разработки было предоставление альтернативы физической репликации, которая требовала бы меньших ресурсов и позволяла бы использовать резервную базу данных для выполнения запросов и отчетов в реальном времени. В последующих версиях (10g, 11g, 12c, 18c, 19c, 21c) функционал был расширен: добавлена поддержка большего числа типов данных, улучшена обработка DDL-операций (Data Definition Language), введена возможность параллельного применения изменений и улучшена интеграция с Oracle Active Data Guard.

Архитектура и принцип работы

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

Logical Standby Database работает в рамках архитектуры Oracle Data Guard. Ключевые компоненты включают:

• Primary Database — основная база данных, в которой выполняются все транзакции.
• Standby Database — логическая копия, которая получает и применяет изменения.
• Redo Log — журналы повторного выполнения, генерируемые на primary-сервере.
• Log Transport Services — службы, отвечающие за передачу archived redo log с primary на standby.
• Log Apply Services — службы на standby-сервере, которые преобразуют redo-данные в SQL-операторы и выполняют их.

Процесс репликации

1. На primary-сервере все изменения данных записываются в redo log.
2. После заполнения или по расписанию redo log архивируется (archived redo log).
3. Архивные журналы передаются на standby-сервер с помощью Log Transport Services (обычно через сеть).
4. На standby-сервере Log Apply Services анализирует redo-записи и преобразует их в последовательность SQL-операторов (INSERT, UPDATE, DELETE, MERGE, а также DDL-операции, если они поддерживаются).
5. Полученные SQL-операторы применяются к standby-базе, которая при этом остаётся открытой для запросов (SELECT).

Отличие от физической репликации

В отличие от Physical Standby Database, где redo-данные применяются на уровне блоков (что делает standby-базу закрытой для операций чтения во время применения), Logical Standby Database работает на уровне строк и таблиц. Это позволяет standby-базе быть доступной для чтения в любой момент, но накладывает ограничения на типы поддерживаемых изменений и требует больше вычислительных ресурсов для преобразования redo в SQL.

Поддерживаемые и неподдерживаемые типы данных и операций

Logical Standby Database поддерживает большинство распространённых типов данных Oracle, включая:

• Числовые (NUMBER, INTEGER, FLOAT)
• Символьные (VARCHAR2, CHAR, CLOB)
• Даты и время (DATE, TIMESTAMP)
• Двоичные (BLOB, RAW, BFILE — с ограничениями)
• Объектные типы (XMLType, SDO_GEOMETRY — частично)

Однако некоторые типы данных и операции не поддерживаются или требуют специальной настройки:

• Неподдерживаемые типы: LONG, LONG RAW, NCLOB (в некоторых версиях), пользовательские типы данных (объекты, коллекции), типы, связанные с расширенной аналитикой (например, SDO_GEOMETRY в полном объёме).
• Неподдерживаемые операции: некоторые DDL-операции (например, создание таблиц с неподдерживаемыми типами данных), операции с последовательностями (SEQUENCE), триггеры на уровне схемы, операции с временными таблицами.
• Ограничения: не поддерживаются операции с таблицами, использующими сегмент-сжатие (compression) в некоторых режимах, а также операции с таблицами, содержащими виртуальные столбцы (в ранних версиях).

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

Настройка и управление

Требования

Для развёртывания Logical Standby Database необходимо:

• Oracle Database Enterprise Edition с лицензией на Data Guard.
• Одна primary-база данных и одна или несколько standby-баз.
• Сетевое соединение между серверами (обычно TCP/IP).
• Одинаковая версия Oracle Database на primary и standby (рекомендуется, но допускается разница в один патч-сет).
• Наличие archived redo log на primary-сервере.

Этапы настройки

1. Создание физической standby-базы (первоначальная копия primary-базы).
2. Преобразование физической standby в логическую с помощью команды ALTER DATABASE RECOVER TO LOGICAL STANDBY.
3. Настройка Log Transport Services (параметры LOG_ARCHIVE_DEST_n).
4. Настройка Log Apply Services (параметры LOG_ARCHIVE_DEST_STATE_n, STANDBY_FILE_MANAGEMENT).
5. Управление таблицами и схемами — определение списка таблиц, которые должны реплицироваться (через DBMS_LOGSTDBY.SKIP).
6. Запуск репликации командой ALTER DATABASE START LOGICAL STANDBY APPLY.

Мониторинг

Для контроля состояния репликации используются представления словаря данных:

• V$LOGSTDBY_STATS — статистика применения изменений.
• V$LOGSTDBY_PROGRESS — информация о текущем состоянии репликации.
• DBA_LOGSTDBY_LOG — список применённых архивных журналов.
• DBA_LOGSTDBY_UNSUPPORTED — таблицы с неподдерживаемыми типами данных.

Преимущества и недостатки

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

• Доступность для чтения: standby-база может использоваться для выполнения запросов, отчётов и аналитики в реальном времени, не мешая репликации.
• Гибкость: возможность реплицировать только выбранные таблицы или схемы, исключая ненужные объекты.
• Снижение нагрузки на primary: часть запросов может быть перенаправлена на standby.
• Поддержка DDL: многие DDL-операции (например, создание индексов, добавление столбцов) реплицируются автоматически.

Недостатки

• Ограничения по типам данных: не все типы данных и операции поддерживаются.
• Высокая нагрузка на standby: преобразование redo в SQL требует значительных вычислительных ресурсов, особенно при большом объёме изменений.
• Задержка репликации: из-за необходимости преобразования и применения SQL-операторов задержка может быть выше, чем у физической репликации.
• Сложность управления: требуется настройка списка реплицируемых объектов и обработка неподдерживаемых операций.
• Отсутствие полной защиты от потери данных: в случае сбоя primary-сервера может быть потеряна часть транзакций, которые не были преобразованы в SQL.

Применение

Logical Standby Database используется в следующих сценариях:

• Отчётность и аналитика: разгрузка primary-базы от запросов, связанных с формированием отчётов.
• Тестирование и разработка: создание изолированной копии данных для тестирования новых приложений или обновлений.
• Миграция данных: перенос данных между базами с разными версиями Oracle или с разными настройками.
• Аварийное восстановление: в случае отказа primary-сервера standby-база может быть преобразована в новую primary (с некоторой потерей данных).

Ограничения и критика

Основные критические замечания в адрес Logical Standby Database связаны с её ограниченной совместимостью с современными типами данных (например, JSON, пространственные данные) и высокой сложностью настройки. В крупных системах с высокой транзакционной нагрузкой (более 10 000 транзакций в секунду) задержка репликации может достигать нескольких минут, что делает технологию непригодной для сценариев, требующих минимального времени восстановления (RPO менее 1 минуты). Кроме того, отсутствие поддержки некоторых DDL-операций (например, изменение структуры таблиц с неподдерживаемыми типами) может приводить к необходимости ручного вмешательства.

Альтернативы

В экосистеме Oracle существуют альтернативные технологии репликации:

• Physical Standby Database — полная блочная репликация, обеспечивающая минимальную задержку и полную защиту от потери данных, но standby-база закрыта для чтения во время применения изменений.
• Oracle GoldenGate — независимая от Data Guard технология репликации на уровне транзакций, поддерживающая более широкий спектр типов данных и операций, но требующая отдельной лицензии.
• Active Data Guard — расширение Physical Standby, позволяющее открыть standby-базу для чтения (но не для записи) с минимальной задержкой.

Источники

• Oracle Data Guard Concepts and Administration (Oracle Documentation, 19c)
• Oracle Database High Availability Best Practices (Oracle Press, 2018)
• Oracle Database Administrator’s Guide (Oracle Documentation, 21c)
• Статья «Logical Standby Database in Oracle Data Guard» на Oracle Technology Network (OTN)