OE REPLICATION И БИЗНЕС-ТРЕБОВАНИЯ
Перед началом настройки after-imaging с OE Replication необходимо четко понимать бизнес-требования. Здесь кратко описаны основные моменты, которые стоит учесть во время настройки.
Время ожидания
Время ожидания в понятии OE Replication определено, как разница между временем начала выполнения изменения на source-базе и временем выполнения изменения на target-базе. Это время зависит от некоторых факторов, которые обязательно должны быть приняты во внимание:
- Количество и частота изменений на source-базе. Если изменения в базе данных происходят часто, и при этом AI-блоки быстро заполняются, то время ожидания будет коротким. Если же активность низкая, то время ожидания будет большим.
- Пропускная способность и загрузка сети. Если сеть медленная или работает на пределе возможностей, то время ожидания между source и target-базами будет возрастать.
- Время простоя target-базы. Если target-база будет длительное время недоступна, то будет расти и время ожидания. В этом случае придется принять решение о необходимости отключения работы OE Replication.
Допустимое время простоя target-базы
Существует несколько критериев, по которым можно определить допустимое время простоя базы:
- Как используется target-база? Если target-база используется только для получения отчетности, то длительное время простоя (более одного дня) не станет проблемой. Тем не менее, если база данных предназначена для резервирования на случай возникновения различных сбоев, то время простоя значительно уменьшается (допустимо 5 - 10 минут).
- Порог устаревания базы данных. Определение базы данных, как устаревшей может быть основано на некоторой временной метке или на объеме данных, который необходимо накатить на target-базу для синхронизации с souce-базой. Пороговое значение для принятия решения о перезапуске репликации определяется по времени или по объему данных.
Факторы, влияющие на восстановление
Способ восстановления может напрямую зависеть от времени ожидания и от допустимого времени простоя базы данных. Дополнительно на выбор способа восстановления оказывает влияние характер повреждения базы данных. Например, потеря базы данных может быть вызвана ее обычным отключением, что исправляется просто перезапуском базы. Потеря базы может быть также связана с аппаратными повреждениями, такими как разрушение дисков. В этом случае доступ к базе невозможен, из методов восстановления выбирается восстановление базы из резервной копии. В последнем случае необходимо определить, можно ли восстановить базу данных за короткое время, продиктованное требованиями вашего бизнеса. Например, если определено, что база данных может быть недоступна не более 15-ти минут, то исходя из этого времени и нужно выбирать метод восстановления базы данных.
Помните, что в результате сбоя некоторые данные могут быть потеряны. Например, если сбой на source-базе произошел между записью в BI и AI файлы, а текущий busy-экстент был применен к target-базе, возникает ситуация, при которой данные будут записаны только в AI и никуда более. Следовательно, source и target базы больше не могут быть синхронизированы.
Перед тем как начать работать с OE Replication, нужно четко понять следующее:
- Выполнение truncate BI на базе после сбоя может повлечь за собой откат большого количества транзакций. Этот процесс будет генерировать большое количество AI-записей, а поскольку OE Replication в этот момент не работает, то все AI-экстенты потенциально могут быть заполнены. Следовательно, перед выполнением truncate BI необходимо убедиться, что есть достаточно AI-экстентов для размещения большого количества AI-записей.
- База данных с включенной репликацией не может быть восстановлена или перезаписана без отключения OE Replication.
- В базе данных с OE Replication не может быть изменена как структура, так и данные, пока OE Replication не работает. Во время работы OE Replication только некоторые действия разрешены на source и target базах. При этом, в случае возникновения неавторизованного действия, выводится соответствующее сообщение.
- OE Replication не поддерживает базы данных, у которых включен механизм two-phase commit.
- OE Replication требует запуска минимум одного ABL-брокера. При этом ABL-брокер должен быть запущен первым по отношению к SQL-брокеру. Так же SQL-брокеру не нужно определять параметр запуска <-DBService>.
- Если свободное пространство на диске закончилось и больше нет AI-экстентов со статусом EMPTY (даже если AI-экстенты переменного размера), необходимо экстренное вмешательство. В противном случае база данных будет аварийно остановлена. Во избежание такой остановки необходимо при страте базы использовать параметр запуска After-image Stall (-aistall).
- Необходимо архивировать и управлять AI-экстентами, как частью стандартного after-image процесса.
| 
Главная
