Репликация Oracle быстро меняющейся таблицы

Вам, вероятно, понадобится комбинация потоков Oracle и, возможно, захвата измененных данных. Также обратите внимание, что Oracle движется к прекращению поддержки Streams и поощряет будущих пользователей переходить на Goldengate. См. здесь: http://docs.oracle.com/cd/E16655_01/server.121/e17642/deprecated.htm#BABEAJJE

Итак, вот требования, которые я вижу, которые я могу понять:

1. 100% безошибочная репликация данных.
2. Не влияет на производительность источника.

Ни один из них недостижим по отдельности, а тем более оба вместе. Репликация любого типа всегда будет иметь задержку между системами в зависимости от загрузки исходной и целевой системы, ввода-вывода, ЦП, сетевого трафика и задержки, коммитов БД и всех этих других вещей. И да, я смешиваю слои в этих элементах, не все из них «яблоки к яблокам», но дело в том, что для репликации должно произойти много вещей.

Я также немного сбит с толку тем, как вы будете переключаться на эту вторичную систему базы данных, если первичная выйдет из строя? Планируете ли вы разрешить запись на вторичный, если первичный не работает? Достаточно ли интеллектуально ваше приложение, чтобы обнаружить сбой основного? Если реальным бизнес-требованием является «приложение должно иметь 99,9% (или любой другой процент) доступности, я не уверен, что репликация является ответом на то, что вы хотите.

Вот что вы можете сделать:

1. Попросите вашего руководства/бизнес-пользователей определить допустимый уровень простоя. Если они скажут «Нет!» затем перейдите к пункту 2. Иногда люди просят о совершенстве, не задумываясь о бесконечной цене.
2. Соберите несколько вариантов в презентации и скажите что-то вроде следующего:

«Для НЕПЛАНОВОГО времени простоя в размере 99,9 %, что составляет 45 минут в месяц (31 * 24 * 60 * 0,001), восстановление после аварии занимает 24 часа, а в худшем случае данные теряются до последнего часа. сценарий, тогда мы можем запустить автономный сервер Oracle, иметь под рукой оборудование для резервного копирования, и это будет стоить X долларов / евро / сколько угодно.

Для 99,99% нам нужен второй сервер, на который мы регулярно восстанавливаем резервные копии и т. Д., И это будет стоить 5X.

Для 99,999% нам нужна репликация, несколько мастеров, обновления нашего программного приложения, более высокий уровень тестирования, больше персонала и т. д., и это будет стоить в 10 или 20 раз больше или что-то в этом роде».

Я просто выдумал все эти цифры и сценарии, но вы можете видеть, как это работает. Когда люди сталкиваются с тем, сколько стоит на самом деле делать это — и сколько стоит ЕГО ПОДДЕРЖАНИЕ — они часто меняют свое мнение.

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

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

CREATE OR REPLACE TRIGGER Example
AFTER INSERT ON Emp_tab
FOR EACH ROW
BEGIN
   Insert_row_proc;
END;

CREATE OR REPLACE PROCEDURE Insert_row_proc AS
BEGIN
    INSERT INTO Emp_tab@Remote
    VALUES ('x');
EXCEPTION
   WHEN OTHERS THEN
       INSERT INTO Emp_log
       VALUES ('x');
END;

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