РАСШИРЕННОЕ ТИРАЖИРОВАНИЕ ДАННЫХ (ADVANCED REPLICATION)

Источник: http://www.soft.velton.net.ua/public060102.html
Автор: Давид Стэнглэнд
Перевод: Андрей Яхновец, АБД Oracle, Велтон.Soft, г.Харьков
Опубликовано: Oracle Professional (PINNACLE) April 2002 (Volume 9, Number 4)

Это первая часть серии из трёх статей Давида Стенгленда, посвященная тиражированию данных (репликаци) в СУБД Oracle. Первая статья концентрирует внимание на концепции тиражирования данных, конфигурации БД, настройке ведущего и ведомого узлов. В этой части и в последующих, будет говориться о тиражировании моментальных снимков (snapshot replication) и тиражировании с несколькими ведущими узлами (multi-master replication). Для иллюстрации технологии тиражирования все разделы сопровождаются конкретными примерами.

Репликация в Oracle является средством "размножения" данных и объектов (таблицы, последовательности, объекты PL/SQL и т.д.) в различные БД. Эта статья фокусирует внимание на основных понятиях тиражирования и специфических параметрах БД Oracle на ведущем (master site) и ведомом (snapshot site). Прежде чем собственно говорить о репликации, выясним, почему необходимо тиражировать (размножать) данные? Имеются четыре причины:

• Репликация в Oracle является средством "размножения" данных и объектов (таблицы, последовательности, объекты PL/SQL и т.д.) в различные БД. Эта статья фокусирует внимание на основных понятиях тиражирования и специфических параметрах БД Oracle на ведущем (master site) и ведомом (snapshot site). Прежде чем собственно говорить о репликации, выясним, почему необходимо тиражировать (размножать) данные? Имеются четыре причины:
• Аварийное восстановление, снижение нагрузки сети- Если основная БД в Калифорнии, например, из-за землетрясения, выходит из строя, то может использоваться БД (находящаяся в безопасном месте) в которую тиражировались данные. Также можно снижать сетевой трафик, разделяя выполнение приложений по региональным БД.
• "Разъединенные" вычисления- использование технологии тиражирования снимков таблиц, позволяет "отключить" БД от ведущей, после обновления всех необходимых данных. Приложение может быть выполнено на ней независимо. В последующем все "отсоединенные" данные могут быть синхронизированы с ведущим узлом и регенерироваться, при изменении в ведущей БД.
• Массовые шаблоны- Шаблоны могут использоваться для создания "похожей" распределенной среды, например для торговой БД, поддерживающую "разъединенные" вычисления.

В Oracle существует два основных способа тиражирования данных: тиражирование снимков (snapshot replication) и тиражирование с несколькими ведущими узлами (multi-master replication).

Технология Snapshot replication описывает методику получения набора данных таблицы, который существовал в некоторый момент времени, так называемый моментальный снимок таблицы. Это требует, по крайней мере, одного управляющего или ведущего узла (master site) и ведомого узла (snapshot site). Эти снимки (начиная с версии 8. материализованные представления) могут быть созданы как копии основных таблиц, и быть доступными только по чтению (read-only snapshots), либо как редактируемые снимки (updateable snapshots), их изменения передаются (propagate) от ведомого на ведущий узел. Снимки таблиц обновляются (регенерируются) по таблицам ведущего сервера вручную или периодически по расписанию, с интервалом устанавливаемым администратором. Обновление этих снимков может быть выполнено способом, при котором пересоздаются все строчки в таблице-снимке по ведущей таблице (это может занимать значительное время для больших таблиц), или снимок может обновляться по технологии называемой быстрое обновление (fast refresh), при этом тиражируются только изменения, произошедшие начиная с момента последнего обновления.

При тиражировании с несколькими ведущими узлами (Multi-master replication) данные могут тиражироваться непрерывно между двумя или более ведущими узлами (или БД). Это наиболее общий способ тиражирования является асинхронным. В этом случае транзакция завершается в одной БД, и асинхронно производятся изменения на всех других ведущих узлах. Транзакция может производиться синхронно; она не рассматривается завершенной, пока не завершится на всех узлах. И так и этак, тиражирование с несколькими ведущими узлами учитывает распределенность БД.

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

Узлы тиражирования

Имеется два основных типа узлов тиражирования: ведущий (master site) и ведомый узел(snapshot site). Ведущий узел - это БД, имеющая полный набор данных, который необходимо тиражировать. Ведомый узел - это БД, содержащая все или часть данных, находящихся на ведущем узле. Ведомый узел может содержать объекты из одного или более ведущего узла. Тиражирование с несколькими ведущими узлами - это просто два или более ведущих узла, по которым синхронизируются тиражируемые объекты. В этой статье, я буду создавать одиночный ведущий узел и ведомый узел.

Что такое тиражирование (репликация)?

Данные в таблицах могут размножаться (тиражироваться), индексы созданные по этим таблицам, также могут тиражироваться. В этом случае работа с индексом будет такая же, если бы индекс был создан локально. Другие объекты БД также могут тиражироваться, и PL/SQL объекты (пакеты, процедуры, и функции), и представления, триггера, и последовательности. Тиражирование последовательностей так же возможно. Однако при тиражировании последовательностей синхронизация значения nextvals не поддерживается, потому что две последовательности в различных БД могут генерировать одно то же значение.

Механизм тиражирования

Снимки таблиц или материализованные представления (синоним, начиная с Oracle 8.1) - это моментальные снимки (копии в определенный момент времени) данных таблицы, находящейся на ведущей стороне. В нижеследующем примере, создается снимок scott.dept_snap таблицы scott.dept_snap доступный только по чтению (по умолчанию).

create snapshot scott.dept_snap as
select * from scott.dept_snap@stg1.collegeclub.com

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

Журнал изменений снимка или материализованного представления (snapshot log или materialized view log) - таблица, содержащая изменения таблицы, находится на ведущем узле. Снимок таблицы может быть обновлён (регенерирован) полностью или к нему могут применены те изменения, которые содержатся в журнале изменений снимка. Этот тип обновления называется быстрым обновлением (fast refresh).

Группы мастер таблиц (Master groups) и Группы снимков (snapshot groups) служат для объединения объектов тиражирования. Тиражируемые объекты (таблицы, последовательности ...) могут принадлежать одной и только одной группе. Это служит для обеспечения легкости администрирования и требуется для обновляемых снимков. Единственный ведущий узел должен быть определен для каждой группы снимков, подробнее об этом позже. Группы мастер таблиц и группы снимков будут созданы в примерах тиражирования снимков и для тиражирования с многими ведущими узлами.

Установка и настройка БД
В этой части вы изучите особенности установки и конфигурации среды тиражирования.

Установка Расширенного Тиражирования

При установке Oracle с использованием Универсального Установщика (Universal Installer) будут установлены необходимые компоненты и скрипты для Расширенного Тиражирования (Advanced Replication). Необходимо отметить "галочкой" опцию в пункте: Oracle 8i Enterprise Edition | Product Options | Oracle 8i Server | Advanced Replication. Если Вы выбираете опцию "установить начальную БД" (в типичной или минимальной конфигурации), Расширенное Тиражирование будет установлено, и никакие дополнительные действия не требуются. Если вы не устанавливали начальную БД, необходимо выполнить скрипт:/rdbms/admin/catrep.sql. Этот скрипт используется при создании "начальной" БД и необходим для создания каталогов тиражирования в системных табличных пространствах (все каталоги начинаются сrepcat$).

Интерфейс программиста для тиражирования (Replication API ) и Менеджер Тиражирования (Replication Manager)

Replication API - это основной набор инструментов для управления и конфигурирования узлов тиражирования. Этот API представляет собой набор пакетов PL/SQL, которые устанавливаются в ходе выполнения скрипта catrep.sql. Он может самостоятельно использоваться для конфигурации узлов тиражирования, однако это может быть достаточно длительным по времени занятием. Наиболее простым способом настройки узлов тиражирования является использование Oracle Replication Manager.

Replication Manager - это инструмент входящий в состав Oracle Enterprise Manager, который позволяет достаточно быстро устанавливать и конфигурировать среду тиражирования, используя графический интерфейс. Он прост в использовании и может применяться для решения основных задач тиражирования. Replication Manager не альтернатива API, он построен "сверху" его (вы это можете проверить, используя кнопку "View SQL", доступную в функциях Replication Manager). В этой статье Oracle Replication Manager используется для конфигурирования ведомого и ведущего узлов, груп тиражирования и объектов.

Параметры инициализации Базы данных

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

В Таблице 1 приведен список параметров с примерами и примечаниями описывающими как они используются.

Таблица 1. Параметры инициализации БД

Параметр	Пример	Примечание
COMPATIBLE	8.1.6	Когда на ведомом узле параметр COMPATIBLE менее чем 8.1.0., создаются дополнительные объекты (snapshot view) для поддержания совместимости.
DB_DOMAIN	collegeclub.com	Сетевое имя (логическое). По умолчанию world.
GLOBAL_NAMES	TRUE (default)	При установкe параметра TRUE, необходимо чтобы указатель (связь) на БД (db links) совпадал с именем БД.
JOB_QUEUE_PROCESSES	4 (default is 0)	JOB_QUEUE_PROCESSES определяет количество SNPN процессов в очереди заданий (SNP0, ... SNP9, SNPA, ... SNPZ).Должно быть установлено значение 3 и добавляться по 1 для каждого дополнительного ведущего узла. Эти процессы ответственны за выполнение назначенных заданий тиражирования данных(replication jobs).Если JOB_QUEUE_PROCESSES установлен на нуль, вы не можете выполнять задания по расписанию, придется инициировать процесс вручную.
JOB_QUEUE_INTERVAL	60 (default)	Определяет время, через которое запускаются фоновые процессы SNPn. По умолчанию 60 сек, максимальная установка 3600.
MAX_ENABLED_ROLES	20 (default)	Роли используются при конфигурировании пользователей тиражирования (replication users), имеющих, как правило, и другие роли. Это значение устанавливает максимально возможное количество ролей, по умолчанию 20.
OPEN_LINKS	4 (default)	OPEN_LINKS определяет максимальное число открытых связей к удалённым БД в одной сессии.Так как при тиражировании используются связи к удалённым БД, должно быть установлено не нулевое значение.
PARALLEL_MAX_SERVERS	10	Максимальное количество параллельно выполняющихся процессов и процессов восстановления для экземпляра БД.
PARALLEL_MIN_SERVERS	1	Минимальный номер паралельных процессов. Номер процесса присваивается при старте экземпляра.
PROCESSES	+12	Добавить 12 к текущему значению.
REPLICATION_DEPENDENCY_TRACKING	TRUE (default)	Слежение за зависимостями чтение/запись в БД. TRUE - существенно для параллельного распространения изменений в среде тиражирования.
SHARED_POOL_SIZE	+40M	Добавить 20M для обычного и 40M для расширенного тиражирования.

Параметр JOB_QUEUE_PROCESSES определяет, сколько SNP процессов будут работать для выполнения заданий на узле тиражирования. В Таблице 1, значение 4 означает, что при открытии БД будут порождаться четыре SNP процесса. Для того чтобы убедиться в этом, после открытия БД, используйте команду "ps" (UNIX). В следующем примере команда "ps" выдает четыре различных SNP процесса, работающих на узле тиражирования main.

main$ ps -ef | grep snp
oracle 9573 1 0 Jan 16 ? 0:08 ora_snp0_main
oracle 9579 1 0 Jan 16 ? 0:08 ora_snp3_main
oracle 18518 18508 0 14:54:33 pts/2 0:00 grep snp
oracle 9577 1 0 Jan 16 ? 0:07 ora_snp2_main
oracle 9575 1 0 Jan 16 ? 0:09 ora_snp1_main


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

Понимание параметра GLOBAL_NAMES может помочь Вам избежать головной боли. Когда установлено значение TRUE, требуется, чтобы БД имела имя совпадющее с именем связи на неё. Например, если ведомая БД имеет имя main.collegeclub.com, то связь к этой БД также должна называться main.collegeclub.com. Если существует проблема из-за этого (например, ORA-12154), выполните следующий запрос в SQL*PLUS:

sql> select * from global_name;

Сравните результат выполнения этого запроса с именем связи к этой БД. Если они не совпадают, существует проблема с вашей настройкой. Вам придется использовать команду "alter database rename global_name" для установки нового значения global_name. Например, если выдается значение main, следующая команда установит значение global_name с main на main.collegeclub.com:

sql> alter database rename global_name to
main.collegeclub.com;

Полный список допустимых параметров приведен в документе Oracle Replication Reference. Если Вы планируете использовать Java Replication API или параллельное тиражирование (не описывается в этой статье), либо промышленную эксплуатацию БД, необходима техническая консультация.

Настройка тиражирования данных

Существует некоторые стандартные шаги, которые необходимо выполнить для настройки ведущего и ведомого узла при использовании Расширенного Тиражирования данных (Advanced Replication). Для простых случаев установка может быть произведена с использованием интерфейса Replication Manager. Все узлы тиражирования требуют, по крайней мере, одного ведущего узла (минимум два необходимы для тиражирования с несколькими ведущими узлами), и ведомого узла, для тиражирования снимков. В этой статье, будут конфигурироваться единственный ведущий узел stg1 и ведомый узел, который называется main.

Настройка ведомого узла

Для начала настройки ведомого узла, запустите Replication Manager и зайдите как системный пользователь. Из главного меню, выберите Setup | Snapshot Sites для старта мастера установки. Этот мастер предложит несколько форм, которые необходимо заполнить для настройки. В Таблице 2 приведены формы, для чего они необходимы, и ответы, использующиеся для типовых случаев.

Таблица 2. Настройка ведомого узла с использованием Replication Manager

Экранная форма мастера	Вход	Что производится
Snapshot Master Site	Stg1.collegeclub.com	Идентификация ведущего узла для тиражируемых объектов
Snapshot Sites	main.collegeclub.com	Идентификация ведомого узла, который мы настраиваем.
Default Users	snapadmin	Определение администратора тиражирования снимков (snapshot administrator) и (необязательно) других распространителей.
Snapshot Site Schemas	scott	Выбор схемы на ведущем узле, в которой будут находиться объекты, подлежащие тиражированию.
Set Default Link Scheduling	Установки по умолчанию	Расписание соединений для передачи изменений от ведомого узла к ведущему. По умолчанию - каждый час.
Set Default Purge Job Scheduling	Установки по умолчанию	Расписание выборки из очереди успешно завершенных транзакций. По умолчанию - каждый час.
Customize Snapshot Sites	Нажмите Next	Допускаются пользовательские настройки узлов.
Finish	Нажмите Finish	Нажмите Finish и будет произведена генерация скрипта.

После завершение работы мастера установки, на ведомом узле:

• Создается расписание связей (scheduled link), для передачи изменений от ведомого узла на ведущий каждый час. Для этого используется процедура DBMS_DEFER_SYS.SCHEDULE_PUSH.
• Каждый час "чистятся" завершенные транзакции из очереди. Для этого используется процедура DBMS_DEFER_SYS.SCHEDULE_PURGE. Поскольку изменения распространяются на все ведущие узлы, это "убирает устаревшую информацию".
• Пользователи получают некоторые роли, как показано в Таблице 3. Пользователь Snapadmin перечислен дважды, потому что роль propagator (распространитель) может быть назначена другим способом, если вы используете руководство Oracle Replication Management API Reference, как руководство для настройки. Это предпочтительнее для более сложных конфигураций.

Таблица 3. Пользователи и их Роли

Узел	Схема	Название Роли	Описание Роли
snapshot	Snapadmin	Snapshot Administrator	Эта роль предназначена для создания и управления ведомым узлом. В Replication Manager ипользуйте эту учётную запись.
snapshot	Snapadmin	Propagator/Receiver	Эта роль необходима для передачу транзакций от ведомого к ведущему узлу, используя очередь отложенных транзакций. Это используется для обновляемых снимков (updateable snapshots).
master	Snapadmin_main	Proxy user	Это название схемы, которая используется ведомым узлом для соединения с ведущим через связь БД.

Настройка ведущего узла

Для старта зайдите в Replication Manager системным пользователем. Из главного меню выберите: Setup | Master Sites для запуска мастера установки. Этот мастер предложит несколько форм, которые необходимо заполнить для настройки. В Таблице 4 приведены формы, для чего они необходимы, и ответы, использующиеся для типовых случаев. После завершение работы мастера установки, на ведущем узле выполняются следующие задачи.

• Создается расписание связей (scheduled link), для передачи изменений от ведущего узла каждый час.
• "Чистка" успешно выполненных заданий из очереди, выполняется каждый час.
• Пользователи на ведущем узле получают специфические роли, как показано в Таблице 5.

Таблица 4. Настройка ведущего узла с использованием Replication Manager

Экранная форма мастера	Вход	Что производится
Master Sites	stg1.collegeclub.com	Идентификация ведущего узла для тиражируемых оъектов.
Default Users	Repadmin	Определение администратора тиражированияи (необязательно) других распространителей.
Master Site Schemas	<не входить>	Необязательно, идентификация схемы для объектов тиражирования на ведущем узле.
Set Default Link Scheduling	Установки по умолчанию	Расписание соединений для передачи изменений от ведущего узла. По умолчанию - каждый час.
Set Default Purge Job Scheduling	Установки по умолчанию	Расписание "чистки" завершенных транзакций из очереди, по умолчанию - каждый час.
Customize Master Sites	Нажмите Next	Допускаются пользовательские настройки узлов.
Finish	Нажмите Finish	Нажмите Finish и будет произведена генерация скрипта.

Таблица 5. Роли пользователей на ведущем узле

Схема	Название роли	Описание роли
repadmin	Replication Administrator	Роль необходима для создания и управления ведущим узлам. Используйте эту учетную запись в Replication Manager.
repadmin	Propagator/Receiver	Отвечает за передачу транзакций.

Заключение

Мы провели установку и настройку узлов тиражирования. Теперь время приступить к сути тиражирования данных. В статье следующего месяца описывается технология тиражирования снимков snapshot replication, как это работает. Используются специфические примеры для иллюстрации этой концепции. Будет создаваться конфигурация со снимками доступными только по чтению, а так же обновляемыми (редактируемые) снимками, данные в них будут обновляться вручную или с использованием технологии fast refresh.

Литература

• Oracle8i Server and Data Warehousing-Oracle8i Replication.
• Oracle8i Server and Data Warehousing-Oracle8i Replication Management API Reference.
• Oracle9i Replication Release 1 (9.0.1)-Вы можете найти этот документ с помощью Technet.