Скрипт пересоздания redo с другим размером

declare
  status varchar(30);
  lim    number := 50;
begin
  for i in (select *
              from v$logfile
             where type = 'ONLINE'
               and group# in
                   (select group# from v$log where bytes / 1024 / 1024 < lim)) loop
    select status into status from v$log where group# = i.group#;
    while status != 'INACTIVE' loop
      execute immediate 'alter system switch logfile';
      execute immediate 'alter system checkpoint';
      select status into status from v$log where group# = i.group#;
    end loop;
    execute immediate 'alter database drop logfile group ' || i.group#;
    execute immediate 'alter database add logfile group ' || i.group# ||
                      ' (''' || i.member || ''') size '||lim||'M reuse';
  end loop;
end;

lim - минимальный размер файла в Мб. Все файлы пересоздаются на месте старых. Скрипт нормально обрабатывает standby-логи, но убивает всех мемберов, кроме первого попавшегося, если их больше одного.

Механизмы обеспечения транзакций

Уровни изоляции, установленные стандартом, во-первых, определены недостаточно четко, во-вторых, не являются обязательными для начального уровня соответствия стандарту. Стандарт также не предусматривает того, как обеспечивается изоляция. Поэтому реальные СУБД достаточно по-разному трактуют изолированность транзакций и используют разные механизмы для обеспечения свойств ACID, в том числе и свойств параллельности.

5.4.1 Механизмы DB2

В DB2 для обеспечения атомарности транзакций применяется "упреждающее протоколирование", при котором изменения в данных записываются в журнальный файл прежде, чем транзакция фиксируется. Изменения в данных производятся в журнальных файлах и лишь при фиксации транзакции переносятся в основную область данных СУБД. Журнал используется для повторения или отката транзакций в случае сбоя.
В основе механизма обеспечения изоляции DB2 лежат блокировки. Суть блокировки состоит в том, что если для выполнения транзакции требуется гарантия того, что определенный объект не будет изменен параллельно выполняющейся транзакцией, объект блокируется, то есть, запрещается доступ к нему из других транзакций.
В самом простом случае СУБД обеспечивает блокировки двух типов:

• S-блокировка - разделяемая блокировка или блокировка чтения, допускающая совместный доступ к строке таблицы;
• X-блокировка - эксклюзивная блокировка или блокировка записи, не допускающая совместного доступа к строке.

Прежде чем считать (select) какую-либо строку из таблицы транзакция должна установить для строки S-блокировку. Прежде чем обновить (update, delete, insert) строку таблицы транзакция должна установить для строки X-блокировку. Если для строки уже установлена блокировка, несовместимая с той, которую пытается установить наша транзакция, то попытка нашей транзакции отвергается, транзакция переводится в ожидание до того момента, пока ранее установленная блокировка не будет снята. Совместимость блокировок показана в следующей таблице.

	S	X
S	да	нет
X	нет	нет

Тот или иной режим изоляции определяется той или иной комбинацией проверки и установки блокировок чтения.
Для уменьшения объема проверяемых при любом доступе блокировок вводятся дополнительные типы блокировок, называемые блокировками намерения. Блокировки намерения накладываются на всю таблицу перед наложением S- или X-блокировки на строку таблицы. Основной набор блокировок намерения следующий (хотя в действительности DB2 этот набор несколько шире):

• IS - блокировка намерения чтения. Накладывается на некоторую таблицу T и означает намерение блокировать некоторую входящую в T строку в режиме S-блокировки.
• IX - блокировка намерения записи. Накладывается на некоторую таблицу T и означает намерение блокировать некоторую входящую в T строку в режиме X-блокировки.
• SIX - блокировка чтения с намерением записи. Накладывается на некоторую таблицу T и означает разделяемую блокировку всей этой таблицы с намерением впоследствии блокировать какие-либо входящие в нее строки в режиме X-блокировок.

Совместимость блокировок с учетом блокировок намерения показана в следующей таблице:

	IS	S	IX	SIX	X
IS	да	да	да	да	нет
S	да	да	нет	нет	нет
IX	да	нет	да	нет	нет
SIX	да	нет	нет	нет	нет
X	нет	нет	нет	нет	нет

5.4.2 Механизмы Oracle

Механизмы обеспечения транзакций в Oracle называют оптимистическими. При этом имеется в виду то, что СУБД предполагает, что вероятность отката транзакции и конфликта транзакций по доступу к данным невелика. Oracle использует журнал, в котором хранит информацию для повторения транзакций в случае сбоя и "сегмент отката". Если транзакция изменяет базу данных, выполненные изменения сразу заносятся в область данных, а старая версия данных сохраняется в сегменте отката. Блокировки чтения, таким образом не накладываются. Подробный протокол чтения данных приводится ниже:

• Для каждой транзакции (или запроса) запоминается текущий системный номер (SCN - System Current Number). Чем позже начата транзакция, тем больше ее SCN.
• При записи страницы данных на диск фиксируется SCN транзакции, производящей эту запись; этот SCN становится текущим системным номером страницы данных.
• Если транзакция читает страницу данных, то SCN транзакции сравнивается с SCN читаемой страницы данных.
• Если SCN страницы данных меньше или равен SCN транзакции, то транзакция читает эту страницу.
• Если SCN страницы данных больше SCN транзакции, то это означает, что некоторая другая транзакция, начавшаяся позже данной, успела изменить или сейчас изменяет данные страницы. В этом случае транзакция данная просматривает журнал транзакций назад в поиске первой записи об изменении нужной страницы данных с SCN меньшим, чем SCN данной транзакции. Найдя такую запись, транзакция использует вариант данных страницы из сегмента отката.

Для транзакции READ ONLY сегмент отката даже не создается.
При изменении данных Oracle накладывает на измененную строку эксклюзивную блокировку.Таким образом, существенная разница в поведении двух рассматриваемых СУБД состоит в следующем: при угрозе возникновения чтения нецелостных данных DB2 блокирует транзакцию, пытающуюся выполнить такое чтение; Oracle же предоставляет транзакции то последнее целостное значение данных, которое существовало на момент начала транзакции. Подход Oracle в этой связи называют многоверсионным, так как одновременно разные транзакции могут видеть разные версии данных. Многоверсионный подход уменьшает количество блокировок, но подход, основанный на блокировках, обеспечивает более согласованное представление данных. Между разработчиками СУБД ведутся ожесточенные дискуссии о превосходстве того или другого подходов, но независимые эксперты, как правило, не могут отдать предпочтения ни тому, ни другому. Следует отметить, что существуют приемы и правила разработки приложений, которые позволяют обеспечить большую согласованность данных в Oracle и меньшее количество блокировок в DB2.

5.4.3 Реализация сценариев

5.4.3.1 Потерянные изменения
В обеих СУБД, независимо от установленного уровня изоляции, действия по сценарию п.5.3.1. будут следующими:

• после ввода оператора UPDATE на шаге 2 транзакция Т1 "зависнет" (заблокируется):
• оператор шага 2 завершится только, когда будет введен оператор COMMIT в транзакции T1.
• на шаге 5 будет выбрано:

   id         dat 
---------- -----------
         1         101
         2         110
         3         120
         4         130

5.4.3.2 Грязное чтение
В DB2 при уровне изоляции CS и выше транзакция транзакция T1 на шаге 2 заблокируется. Оператор этого шага завершится только тогда, когда в транзакции T2 будет введен оператор ROLLBACK или COMMIT. Если транзакция T2 будет зафиксирована, то в транзакции T1 на шаге 3 будет выбрано:

        id         dat 
---------- -----------
         1         101
         2         101
         3         120
         4         130

Если транзакция T2 откатится, то в транзакции T1 на шаге 3 будет выбрано:

        id         dat 
---------- -----------
         1         100
         2         100
         3         120
         4         130

В Oracle блокировок не будет. На шаге 3 будет выбрано:

        id         dat 
---------- -----------
         1         100
         2         100
         3         120
         4         130

Поскольку транзакция T1 не завершается до шага 5, то на шаге 5 будет выбрано исходное состояние таблицы. (Если транзакция T2 зафиксируется, а не откатится, то на шаге 5 будут отображены только изменения, выполненные в T2).
5.4.3.3 Неповторяющееся чтение
В DB2 при уровне изоляции RS и выше транзакция T2 будет заблокирована на шаге 2, пока в транзакции T1 не будет выполнен оператор COMMIT или ROLLBACK. Если зафиксировать транзакцию T1 на шаге 2, то на шаге 4 будут выбраны уже обновленные значения, но это будет уже другая транзакция.
В Oracle при уровне изоляции SERIALIZABLE на шагах 1 и 4 будет выбрано одно и то же:

        id         dat 
---------- -----------
         1         100

Но если ту же выборку повторить после фиксации транзакции T1, то будет выбрано:

        id         dat 
---------- -----------
         1         101

5.4.3.4 Фантом
В DB2 при уровне изоляции RR транзакция T2 будет заблокирована на шаге 2, пока в транзакции T1 не будет выполнен оператор COMMIT или ROLLBACK. Если завершить транзакцию T1 на шаге 2, то на шаге 4 будут выбраны уже обновленные значения, но это будет уже другая транзакция.
В Oracle при уровне изоляции SERIALIZABLE на шагах 1 и 4 будет выбрано:

        id         dat 
---------- -----------
         3         120
         4         130
      

Если ту же выборку повторить после фиксации транзакции T1, будет выбрано:

        id         dat 
---------- -----------
         3         120
         4         130
         5         150

5.4.4 Тупики

Поскольку обе СУБД используют блокировки записи для предотвращения, например, такого нежелательного эффекта, как потерянные изменения, возможно возникновение тупиков. Тупик может возникнуть в том случае, если транзакция T1 требует каких-то ресурсов, которые эксклюзивно блокированы транзакцией T2, а транзакция T2 требует ресурсов, которые эксклюзивно блокированы транзакцией T1. Сценарий возникновения тупика, например, следующий:

Транзакция T1	Шаг	Транзакция T2
UPDATE example SET dat=101 WHERE id=1	1
	2	UPDATE example SET dat=112 WHERE id=2
UPDATE example SET dat=111 WHERE id=2	3
	4	UPDATE example SET dat=102 WHERE id=1

Транзакция T1 должна заблокироваться на шаге 3, а транзакция T2 - на шаге 4. Единственным способом "развязки" тупика является принудительное освобождение одной из транзакций удерживаемого ею критического ресурса.Обе СУБД обнаруживают и развязывают тупики. Дойдя до зависания обеих транзакций на шагах 3-4, обе СУБД после некоторой временной выдержки развязывают тупик, но делают это несколько по-разному. DB2 принудительно откатывает одну из транзакций с сообщением об ошибке, вторая транзакция при этом разблокируется и завершается. Oracle откатывает только оператор UPDATE одной из транзакций с сообщением об ошибке. Вторая транзакция при этом продолжает оставаться заблокированной. Транзакция, в которой был выполнен откат оператора, теперь должна явным образом завершиться (зафиксироваться или откатиться), только после этого будет разблокирована другая транзакция.

5.4.5 Эскалация блокировок

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

Сценарии возникновения нежелательных эффектов (потерянные изменения, грязное чтение...)

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

Таблица EXAMPLE

id INTEGER	dat INTEGER
1	100
2	110
3	120
4	130

5.3.1 Потерянные изменения

Транзакция T1	Шаг	Транзакция T2
UPDATE example SET dat=dat+1 WHERE id=1	1
	2	UPDATE example SET dat=dat+1 WHERE id=1
COMMIT	3
	4	COMMIT
SELECT * FROM example	5

Если потерянные изменения допускаются, то сценарий выполнится без ошибок и блокировок. На шаге 5 будет выбрано:

        id         dat 
---------- -----------
         1         101
         2         110
         3         120
         4         130

5.3.2 Грязное чтение

Транзакция T1	Шаг	Транзакция T2
	1	UPDATE example SET dat=101 WHERE id=1
UPDATE example SET dat= (SELECT dat FROM example WHERE id=1) WHERE id=2	2
SELECT * FROM example	3
	4	ROLLBACK
	5	SELECT * FROM example

Если грязное чтение допускается, то сценарий выполнится без ошибок и блокировок.
На шаге 3 будет выбрано:

        id         dat 
---------- -----------
         1         101
         2         101
         3         120
         4         130

На шаге 5 будет выбрано:

        id         dat 
---------- -----------
         1         100
         2         101
         3         120
         4         130

5.3.3 Неповторяющееся чтение

Транзакция T1	Шаг	Транзакция T2
SELECT * FROM example WHERE id=1	1
[COMMIT]	2	UPDATE example SET dat=101 WHERE id=1
	3	COMMIT
SELECT * FROM example WHERE id=1	4
COMMIT	5

Если неповторяющееся чтение допускается, то сценарий выполнится без ошибок и блокировок. Операцию COMMIT в транзакции T1 на шаге 2 выполнять не придется.
На шаге 1 будет выбрано:

        id         dat 
---------- -----------
         1         100

На шаге 4 будет выбрано:

        id         dat 
---------- -----------
         1         101

Если выполнить операцию COMMIT на шаге 2, то результаты будут те же, что и без нее, но здесь уже не будет эффекта неповторяющегося чтения, так как разные результаты будут прочитаны уже в разных транзакциях.

5.3.4 Фантом

Транзакция T1	Шаг	Транзакция T2
SELECT * FROM example WHERE dat>110	1
[COMMIT]	2	INSERT INTO example VALUES(5,140)
	3	COMMIT
SELECT * FROM example WHERE dat>110	4
COMMIT	5

Если допускаются фантомы, то сценарий выполнится без ошибок и блокировок. Операцию COMMIT в транзакции T1 на шаге 2 выполнять не придется.
На шаге 1 будет выбрано:

        id         dat 
---------- -----------
         3         120
         4         130

На шаге 4 будет выбрано:
        id         dat 
---------- -----------
         3         120
         4         130
         5         150

---

Понятие транзакции и операторы COMMIT и ROLLBACK

Транзакцией называется единица работы СУБД, то есть, такая последовательность операторов SQL, которая обрабатывается СУБД как единое целое. Транзакция характеризуется четырьмя основными свойствами, часто называемыми свойствами ACID:

• атомарность (atomity) - транзакция является неделимой, она выполняется полностью или не выполняется вообще; если транзакция прерывается на середине, то база данных должна остаться в том состоянии, которое она имела до начала транзакции;
• параллельность (concurrency) - эффект от параллельного выполнения нескольких транзакций должен быть таким же, как от их последовательного выполнения; выполняющиеся транзакции не должны накладываться друг на друга;
• целостность (integrity) - транзакция переводит база данных из одного непротиворечивого (целостного) состояния в другое; в ходе выполнения транзакции база данных может временно пребывать в нецелостном состоянии;
• долговременность (duration) - после того, как транзакция завершена и зафиксирована, результат ее выполнения гарантированно сохраняется в базе данных.

Объем транзакции может варьироваться от одного SQL-оператора до всех действий с базой данных, выполняемых приложением. В случае, если транзакции в приложении не определены явным образом, поведение приложения в этом отношении определяется состоянием режима AUTOCOMMIT. Когда этот режим выключен, все приложение составляет одну транзакцию (если в нем не задано явное управление транзакциями), которая завершается с завершением приложения. Когда же этот режим включен, каждый SQL-оператор в приложении выполняется как отдельная транзакция, даже если в приложении имеются операторы явного управления транзакциями. Оператор является минимальной единицей транзакции: некоторые операторы могут включать в себя сложные действия над множеством строк, но все эти операции СУБД выполняет как одну транзакцию.
При выключенном режиме AUTOCOMMIT приложение может само управлять разбиением выполняемых им действий на транзакции. Первый SQL-оператор, выполняемый в приложении, начинает новую транзакцию. Все последующие операторы продолжают эту транзакцию, пока не встретится оператор COMMIT или ROLLBACK.
Оператор фиксации - COMMIT - завершает текущую транзакцию и фиксирует ее результаты. После выполнения оператора COMMIT результаты транзакции гарантированно сохраняются в базе данных и начинается новая транзакция. Оператор отката - ROLLBACK - завершает текущую транзакцию "с откатом". После выполнения этого оператора восстанавливается то состояние базы данных, в котором она была перед началом транзакции, и начинается новая транзакция. При выполнении оператора COMMIT или ROLLBACK снимаются все наложенные в транзакции блокировки (о блокировках - см. ниже).
Стандартом SQL/92 не предусматриваются какие-либо дополнительные возможности операторов COMMIT и ROLLBACK, поэтому их стандартный синтаксис очень прост (см. рис.5.1).

Рисунок 5.1 - Операторы COMMIT и ROLLBACK

Обе наши СУБД предусматривают, так называемые, точки сохранения. Точка сохранения задается оператором SAVEPOINT, и в операторе ROLLBACK имеется возможность отката транзакции не к началу, а к указанной точке сохранения.
С учетом этой возможности синтаксис операторов SAVEPOINT и ROLLBACK в Oracle показан на рис. 5.2, а в DB2 (это новая возможность версии 7.1.) - на рис. 5.3.

Рисунок 5.2 - Операторы ROLLBACK и SAVEPOINT в Oracle

Рисунок 5.3 - Операторы ROLLBACK и SAVEPOINT в DB2

В Oracle откат транзакции к указанной точке сохранения безусловно снимает все блокировки, наложенные после точки сохранения. В DB2 эта возможность является выборочной, задаваемой при создании точки сохранения. Имена точек сохранения могут повторяться в транзакции (в DB2 может быть указано требование уникальности имени) если имена повторяются, то выполнение следующего оператора SAVEPOINT с тем же именем точки отменяет предыдущую точку сохранения.
Выше мы отметили, что внутри транзакции состояние базы данных в принципе может быть нецелостным. В Oracle в описании ограничений целостности может быть задано ключевое слово DEFERRED (отсроченный) - для ограничения, проверка которого откладывается до окончания транзакции. Отключение ограничений может выполняться также оператором SET CONSTRAINT, что соответствует стандарту SQL/92. В DB2 отключения ограничений целостности могут быть сделаны только явным образом - оператором SET INTEGRITY. Подробное описание этих возможностей содержится в [7, 9].

Уровни изоляции

Свойство параллельности является одним из наиболее важных свойств транзакций, которые обеспечивают промышленные базы данных. Современные промышленные СУБД обеспечивают параллельную работу с одними и теми же данными огромного количества пользователей. Так, СУБД DB2 была протестирована при одновременной работе 60 тыс. пользователей; точных данных по Oracle у нас нет, но и здесь речь идет о десятках тысяч пользователей. В таких условиях важно, чтобы параллельно выполняемые транзакции не накладывались, а были изолированы друг от друга.

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

• Потерянные изменения. Транзакция Т1 читает данные. Транзакция Т2 читает те же данные. Транзакция T1 на основании прочитанного значения вычисляет новое значение данных, записывает его в базу данных и завершается. Транзакция T2 на основании прочитанного значения вычисляет новое значение данных, записывает его в базу данных и завершается. В результате значение, записанное транзакцией Т2, "затрет" значение, записанное транзакцией Т1.
• Грязное чтение. Транзакция Т1 изменяет некоторые данные, но еще не завершается. Транзакция Т2 читает эти же данные (с изменениями, внесенными транзакцией Т1) и принимает на их основе какие-то решения. Транзакция Т1 выполняет откат. В результате решение, принятое транзакцией Т2, основано на неверных данных.
• Неповторяющееся чтение. Транзакция Т1 в ходе своего выполнения несколько раз читает одни и те же данные. Транзакция Т2 в интервалах между чтениями данных в транзакции Т1 изменяет эти данные и фиксируется. В результате оказывается, что чтения одних и тех же данных в транзакции Т1 дают разные результаты.
• Фантом. Транзакция Т1 в ходе своего выполнения несколько раз выбирает множество строк по одним и тем же критериям. Транзакция Т2 в интервалах между выборками транзакции Т1 добавляет или удаляет строки или изменяет столбцы некоторых строк, используемых в критерии выборки, и фиксируется. В результате оказывается, что одинаковые запросы в транзакции Т1 выбирают разные множество строк.

Промышленные СУБД в том или ином объеме выполняют требования стандарта по дифференциации уровней изоляции, но при формально одном и том же уровне изоляции поведение транзакций может существенно различаться в разных СУБД.
Определение уровней изоляции в стандарте и в рассматриваемых нами СУБД сведено в таблицу:

Уровни изоляции SQL/92	Аномалии				DB2	Oracle
	А1	А2	А3	А4
READ UNCOMMITTED	нет	да	да	да	UNCOMMITTED READ (UR)	-
READ COMMITTED	нет	нет	да	да	CURSOR STABILITY (CS)	READ COMMITTED
REPEATABLE READ	нет	нет	нет	да	READ STABILITY (RS)	-
SERIALIZABLE	нет	нет	нет	нет	REPEATABLE READ (RR)	SERIALIZABLE
Аномалии:     А1 - Потерянные изменения     А3 - Неповторяющееся чтение     А2 - Грязное чтение     А4 - Фантом

Кроме названных, в Oracle имеется еще уровень изоляции READ ONLY - для только-читающих транзакций.
В Oracle требуемый уровень изоляции может быть установлен для сеанса соединения с базой данных - как одна из возможностей оператора ALTER SESSION или для отдельной транзакции оператором SET TRANSACTION. Синтаксис этих операторов показан на рис. 5.4.

Рисунок 5.4 - Операторы ALTER SESSION и SET TRANSACTION (Oracle)

В DB2 уровень изоляции устанавливается для приложения, и способы его установки различны для разных способов разработки приложений. При работе в среде DB2 Command Line Processor или DB2 Command Center уровень изоляции устанавливается перед соединением с базой данных оператором CHANGE ISOLATION:

Рисунок 5.5 - Операторы CHANGE ISOLATION (DB2)

Alexander Ryndin: Использование GoldenGate Director для управления интеграцией

Использование GoldenGate Director для управления интеграцией

Написал Alexander Ryndin в 1 Февраль 2010, 16:35

АРХИТЕКТУРА GOLDENGATE DIRECTOR

GoldenGate Director (сейчас это называется GoldenGate Management Pack) — это многозвенное клиент-серверное приложение, обеспечивающее возможность конфигурирования и управления экземплярами(instances) GoldenGate с удаленного рабочего места. GoldenGate Director состоит из следующих компонент:

Экземпляры GoldenGate

Каждый экземпляр процесса GoldenGate Manager — индентифицируется полным именем сервера, портом, на котором слушает Manager и пользовательским именем источника данных. Поскольку процесс GoldenGate Manager связан с базой данных, эта комбинация определяется как источник данных в клиенте GoldenGate Director.

GoldenGate Director Server

GoldenGate Director Server координирует управление экземплярами GoldenGate. GoldenGate Director Server инсталлируется как домен в Oracle Weblogic Server и состоит из следующих приложений:

• GoldenGate Director Server  — набор сервисов, управляющих безопасностью, информацией о сервисах, объектной моделью, консолидированным журналированием событий и слежбами уведомления;
• Monitor Agent — клиент для серверов GoldenGate, который устанавливает выделенное соединение с помощью GGSCI. Соединение используется, чтобы получить информацию о статусе процессов и событиях.

Director Database

GoldenGate Director Server использует базу данных как центральный репозиторий для хранения информации о пользователях и группах, графических диаграмм, созданных пользователями, консолидированных событий и другой информации. Пользователь может использовать клиента, проинсталлированного на любом компьютере, но видеть одну и ту же информацию.

Клиенты GoldenGate

• GoldenGate Director Client — это клиентское приложение для GoldenGate Director Server, обеспечивающее GUI интерфейс для управления экземплярами GoldenGate. Клиент может быть запущен на любой платформе, которая поддерживает Java.
• GoldenGate Director Web — это тонкий клиент. Обеспечивает средства контроля за экземплярами GoldenGate и простейшего управления.
• GoldenGate Director Administrator — средство управления метаданными GoldenGate Director Server. Этот инструмент не управляет процессами GoldenGate, но позволяет настроить параметры для подключения к экземплярам, а также управлять пользователями пользователей.

ИНСТАЛЛЯЦИЯ GOLDENGATE АГЕНТОВ

См.  статью  Использование GoldenGate для live reporting. Читать то заголовка «Настраиваем процесс сбора изменений»

ИНСТАЛЛЯЦИЯ GOLDENGATE DIRECTOR

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

• JRE 6 (1.6.x)
• Oracle Weblogic Server 11g (10.3.1) Standard Edition
• База данных (MySQL 5.x EE, SQL Server 2000 или 2005, Oracle 9i

Дальше я останавливаюсь на инсталляции GoldenGate Director на Oracle Database.

Создание пользователя

CREATE USER ggDirector IDENTIFIED BY passw0rd DEFAULT TABLESPACE users;
ALTER USER ggDirector QUOTA UNLIMITED ON users;
GRANT connect,resource TO ggDirector;

Инсталляция

1. Скачиваем дистрибутив с http://edelivery.oracle.com из раздела Fusion Middleware
2. Запускаем инсталляцию ggdirector-serversetup_<version>
3. Welcome screen: Нажимаем Next.
4. Choose Installation Location: Вводим каталог, в который инсталлируем Director
5. Weblogic Location: Вводим путь к каталогу, который на один уровень выше wlserver_10.3.1 (по-умолчанию это каталог Middleware). Этот каталог используется для поиска пути к каталогу с доменами.
6. HTTP port: вводим порт, который будет использоваться. По умолчанию используется порт 7001.
7. Database: Указывается тип базы данных.
8. Database driver configuration: Прописываем информацию необходимую для подключения к базе данных.
9. Database User: Указываем имя пользователя и пароль для создания репозитория.
10. Pre-installation summary: Жмем Next.
11. Затем жмем Finish.

Запуск и останов GoldenGate Director.

Действие	Windows	Unix и Linux
Запуск	domain\startWebLogic.cmd	domain/startWebLogic.sh
Останов	domain\bin\stopWebLogic.cmd	domain/bin/stopWebLogic.sh

Подключение к GoldenGate Director

• Для подключения к толстому клиенту используйте ссылку :/download»>http://<servername>:<port>/download
• Для подключения к тонкому клиенту — :/acon»>http://<servername>:<port>/acon

НАСТРОЙКА GOLDENGATE DIRECTOR

Для того, чтобы управлять инфраструктурой с помощью GoldenGate Director необходимо настроить подключения к каждому установленному GoldenGate Manager. Кроме того, необходимо настроить пользователей, которые будут использоваться при управлении GoldenGate Director.

Для этих целей используется инструмент GoldenGate Director Administrator. Проинсталлировать его можно перейдя по ссылке :/download»>http://<servername>:<port>/download. После запуска мы получаем окно входа в систему:

Имя и пароль по умолчанию — admin. После первого запуска рекомендуется сменить этот пароль. Имя сервера необходимо вводить вместе с  номером порта, на котором слушает weblogic (по-умолчанию 7001).

Учетные записи мы сейчас трогать не будет, поэтому сразу перейдем на вторую закладку, на которой регистрируются источники данных:

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

После того, как все настроено можно перейти на закладку Monitor Agent и попробовать перезапустить агентов.

НАСТРОЙКА РЕПЛИКАЦИИ

После настройки источников данных мы запускаем толстый клиент Oracle GoldenGate-Director. Жмем кнопку Login и вводим того же пользователя admin, что и ранее.

Создаем новую диаграмму, на которую перетаскиваем нужные источники данных:

Далее в простейшем случае мы можем перетащить с закладки Add new действие Capture and Delivery на источник. Необходимые действия на настройки репликации.

МОНИТОРИНГ РАБОТЫ ПРОЦЕССОВ GOLDENGATE

Для мониторинга сервисов можно использовать как толстый клиент, так и веб-клиент, расположенный по адресу :/acon»>http://<servername>:<port>/acon

ЗАКЛЮЧЕНИЕ

Инструмент GoldenGate Director — это мощное, но достаточно простое в использовании средство настройки репликации данных, а также готовое средство мониторинга процессов, участвующих в передаче данных.

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

Для одних задач удобно применять веб-клиент, а для других — удобнее толстый клиент. Кроме того, GoldenGate обеспечивает инфраструктуру для настройки уведомления администратора при возникновении заданных событий.

Installing GoldenGate Director Server and Client

Oracle GoldenGate – Installing GoldenGate Director Server and Client

GoldenGate Director is a multi tier client server application that enables the configuration and management of the GoldenGate environment from a remote client which includes a web browser based client.

There are a number of different components which go to make up the GoldenGate Director product. Let us briefly describe each one of them.

GoldenGate Director Server – It is installed in a Weblogic server domain and enables the management of the different instances of GoldenGate which run in our environment.

GoldenGate Director Database – it is the central repository which is housed in a database (SQL Server/MySQL/Oracle) which contains information about the users, graphical diagrams which are created and other information related to user preferences.

GoldenGate Director Client – it is a GUI tool for managing the GoldenGate instances and runs on any platform which supports Java providing a menu driven interface with standard drag and drop functionality.

GoldenGate Director Web – web application that is hosted in the Director Server which provided browser based access to the GoldenGate environment.

GoldenGate Director Administrator – another client of the Director Server which enables us to carry out admin tasks like creating and modifying the admin user accounts, creating and modifying data sources which can be then used in the Director Client.

Before installing the Director Server we need to ensure that the JRE version 1.6 is already installed on the platform where we are going to install Director Server and also that Oracle 11g Weblogic Server (10.3.1) is available and running.

The following files were used for installation on Red Hat Linux RHEL 5 ….

oepe11_wls1031_linux32.bin – Oracle 11g Weblogic Server 10.3.1.
V19134-01.zip – GoldenGate Director Server
V19136-01.zip – GoldenGate Director Client

Let us look at the screen shots of an Oracle Weblogic Server installation.

Director Server Installation

In addition to the JRE 1.6.x requirement and the providing the location of the Weblogic Server software installation, we need to ensure that a database user has been created in the database which is going to serve as a repository for the Director Server. This database user needs standard privileges to create, alter and drop tables and indexes in it’s own schema. We will provide details of this user account in the course of the GoldenGate Director Server installation.

[oracle@redhat346 bin]$ export PATH=/u01/oracle/jre1.6.0_18/bin:$PATH
[oracle@redhat346 bin]$ java -version
java version “1.6.0_18”
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

[oracle@redhat346 ~]$ ./gg-director-serversetup_unix_v2_0_0_3_007.sh
Starting Installer …

Director Client Installation

[oracle@redhat346 ~]$ ./gg-director-clientsetup_unix_v2_0_0_3_007.sh
Starting Installer …