Добрый день.

Появилась необходимость познания Active-Active Golden Gate.
Насколько критично, чтобы все таблицы имели первичные ключи или уникальные индексы? У нас есть приложения, которые не обеспечивают уникальность записей,значит для них не развернуть Active-Active GG ?
Спрашиваю после того, как на моменте тестирования столкнулся с таким моментом, что с настроенной конфигурацией вставляю запись в таблицу без уникальности, она дублируется во вторую базу, а потом та база опять возвращает эту запись и так идут бесконечные инсерты.

Alexander Ryndin,
Добавил запись в файл экстракта.
Но пинг-понг с инсертом продолжается, а если delete сделать, то на 2 базе применяется, возвращается к 1 и так как не находит запись, то REPLICAT переходит в ABENDED

файл Extract

EXTRACT ext
USERID gguser@DB1, PASSWORD ***
EXTTRAIL /u01/app/oracle/product/gg12/dirdat/aa
TRANLOGOPTIONS EXCLUDEUSER DATA_OWNER
DDL INCLUDE ALL
TABLE DATA_OWNER.*;

SQL*Plus,
лучше не надо что именно?

SQL*Plus,
планируется связка 2 баз active-active
об этом и пишу

Dimitry Sibiryakov,
Спасибо, заработало, как я изначально и ожидал))

Только теперь ловлю ошибку при апдейте.
Условия те же, таблицы без индексов и ограничений.
Relicat процесс уходит в Abended
2020-04-18 14:04:18 WARNING OGG-01154 SQL error 1403 mapping OWNER.TAB_2 to OWNER
.TAB_2 No data found.

Source Context :
SourceModule : [er.replicat.errors]
SourceID : [er/replicat/reperrors.cpp]
SourceMethod : [repError]
SourceLine : [1754]

2020-04-18 14:04:18 ERROR OGG-01296 Error mapping from OWNER.TAB_2 to OWNER
.TAB_2.

andrey_anonymous,
это возникло после того, как сделал апдейт.
инсерт/делит реплицируются без проблем

andrey_anonymous,

Вот, что я сейчас сделал
CREATE TABLE CARS_NEW
(
CAR VARCHAR2(50 BYTE),
COLOUR VARCHAR2(80 BYTE)
)
;
таблица на реплике появилась

insert into CARS_NEW values ('FERRARI','RED');commit;
запись на реплике появилась

update CARS_NEW set colour = 'YELLOW' where CAR='FERRARI';commit;
на реплике апдейт не прошёл, процесс в ABENDED

из репорта

2020-04-18 18:49:46 INFO OGG-06511 Using following columns in default map by name: CAR, COLOUR.

2020-04-18 18:49:46 INFO OGG-06510 Using the following key columns for target table OWNER.CARS_NEW: CAR, COLOUR.


2020-04-18 18:51:05 WARNING OGG-01004 Aborted grouped transaction on OWNER.CARS_NEW, Database error 1403 (No data found).

2020-04-18 18:51:05 WARNING OGG-01003 Repositioning to rba 401366 in seqno 0.

2020-04-18 18:51:05 WARNING OGG-01154 SQL error 1403 mapping OWNER.CARS_NEW to OWNER.CARS_NEW No data found.

Source Context :
SourceModule : [er.replicat.errors]
SourceID : [er/replicat/reperrors.cpp]
SourceMethod : [repError]
SourceLine : [1754]

2020-04-18 18:51:05 ERROR OGG-01296 Error mapping from OWNER.CARS_NEW to OWNER.CARS_NEW.

Версия бд 12.2

Dimitry Sibiryakov,
про это вначале писал, не все разработчики создают таблицы с первичным ключом

Dimitry Sibiryakov,
Хорошо, но почему delete корректно работает?

Dimitry Sibiryakov,
как-то некорректно работает, с первичным ключом могу изменять только столбец, на который и построен ключ, при изменении других полей replicat падает

Alexander Ryndin,
А как опыт нарабатывать? Я ж не прод дёргаю, а так...на тестовом контуре шишки набиваю))

andrey_anonymous,
Благодарю за подсказку.
Помогло на обоих сторонах- ADD SCHEMATRANDATA OWNER
До этого лишь делал - ADD TRANDATA OWNER.*

alex722,
Поправлю
ADD SCHEMATRANDATA OWNER ALLCOLS

Alexander Ryndin,
Целей 2:
1. Переключение софта на DB_2 в случае потери основной DB_1;
2. Переключение софта на DB_2 в случае плановых работ на сервере или на самой DB_1(апгрейд например), с последующим возвратом софта на DB_1

Alexander Ryndin,
почему нет?
конфигурация ведь позволяет работать 2 бд на запись с репликацией, хотя по факту 99% будет одна основной.

andrey_anonymous,
как обычный standby сможет заменить прод, пока тот апгрейдится?

andrey_anonymous,
?

Vadim Lejnin,
по второй части:
порой работы на самих серверах по замене дисков, обновлению патчей и тд доходят до часов 5 и более.
по апгрейду тоже есть дополнительные затраты по времени, как например холодный клон перед самим процессом, без него как-то неуверенно себя чувствую)))
по первой части:
active-active планируем использовать:
1. для ситуации выше. На стэндбай, чтоб только прочитать информацию не подойдёт для 90% случаев(считай 100%)
2. для аварийных сбоев на продакшн. Чтобы без участия DBA путём перенаправления DNS апликейшены пошли работать со второй бд. После поднятия основной бд, она должна принять изменения, внесённые на 2 и после синхронизации опять стать основной.
Да процесс надолго, не думаю, что к концу 20г сделаем, тестирование, оценка и тд
Пока щупаем в песочнице))

Добрый день.

Думаю, кто сталкивался с GG, исходя из своего опыта сможет подсказать.

Допустим, стоит задача от бизнеса/руководства настроить GG для определённой системы на БД.
Разработчик системы внешний.
Компетентны ли внешние вендоры в целом насчет, будет ли комфортной работа с GG, поддерживает ли архитектура системы и логика операций быструю репликацию?
Или для DBA это черный ящик, который он сам обычно познает методом проб и ошибок.