Disaster Recovery DB Essbase

Как восстановить БД Essbase, если исходная среда недоступна либо были утеряны/поломаны файлы с исходной БД? Пример одного восстановления.

Предисловие

Без бекапа восстановить БД невозможно 🙂 Как у нас выполняется бекап и где находятся файлы для восстановления?
Каждую ночь в Essbase делается физический online (без остановки сервиса) бекап данных. Далее эти файлы передаются в резервные ДЦ
БД у нас находится в transaction mode, точнее, включен режим SERVER_CLIENT
Это означает, что все изменения пишутся в transaction лог в каталоге backup, а файлы загрузки данных из реляционных источников — в /opt/hyperion/user_projects/epmsystemesb1/EssbaseServer/essbaseserver1/app/*/*/Replay/
Раз в 15 минут эти файлы передаются в резервные ДЦ утилитой rsync.
Оба эти источника нужны для автоматического наката изменений.

Пример восстановления БД в резервном ДЦ, не оставливая primary БД

Об общем механизме работы и ограничениях по накату изменений можно прочитать в корп. блоге

Ниже пошагово описан процесс восстановления одной из БД Essbase на резервном холодном standby сервере.

1. Запустить хранилище метаданных Oracle. Без хранилища метаданных и агента запустить Essbase невозможно, даже если у нас ещё нет ни одной БД и мы хотим создать новую. Детали можно уточнить в Note How to Start Hyperion Essbase in a Standalone Mode without Hyperion Shared Services Running [ID 1058002.1]

Рядом с резервным сервером у нас есть standby БД Oracle. Поскольку восстановление тестовое, реально переключаться на этот standby я не стал, а запустил standby в режиме Active dataguard (т.е. в режиме read-only с накатом логов). Этого (read-only доступа) оказалось достаточно для старта и восстановления БД.
Технически для соединения со standby пришлось руками создать и запустить (через DBMS_SERVICE) сервис hypro (т.к. у нас нет DataGuard, соответственно через srvctl нельзя создать сервис, поднимающийся в зависимости от роли БД)
Настройки соединенния записаны в файле /opt/hyperion/user_projects/epmsystemesb1/config/foundation/11.1.2.0/reg.properties

2. Стартовать стек компонентов на сервере Essbase (скрипт /opt/hyperion/user_projects/epmsystemesb1/bin/start.sh). Убедился, что в логах /opt/hyperion/user_projects/epmsystemesb1/diagnostics/log/starter/* всё хорошо и порт 1423 слушает агент.

3. Восстановить БД из последнего бекапа

MAXL> alter database HR.HR restore from file '/opt/backup/essbackup/HR.HRFriday.arc';

 OK/INFO - 1051703 - Restore in progress for [HR.HR] 10 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 20 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 30 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 40 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 50 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 60 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 70 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 80 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 90 complete.
 OK/INFO - 1051703 - Restore in progress for [HR.HR] 100 complete.

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

MAXL> query database HR.HR list transactions;

 sequence_id         username            start_time          end_time            req_type            calcscript_name     dataload_file_or_ft dataload_file_type  rule_file           rule_file_loc       sql_or_ftp_username
+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------
                2133 admin@Native Direct Fri Nov 23 10:07:38 Fri Nov 23 10:07:43                   2                                                           0                                       0                   
                2134 admin@Native Direct Fri Nov 23 10:07:47 Fri Nov 23 10:07:51                   7                                                           0 /opt/hyperion/user_                   0 hyp_act_usr       
                2135 essbase@Native Dire Fri Nov 23 10:07:52 Fri Nov 23 10:07:52                   2                                                           0                                       0                   
                2136 essbase@Native Dire Fri Nov 23 10:07:53 Fri Nov 23 10:08:46                   2                                                           0                                       0                   
                2137 essbase@Native Dire Fri Nov 23 10:08:46 Fri Nov 23 10:20:29                   2                                                           0                                       0                   
                2138 essbase@Native Dire Fri Nov 23 10:20:30 Fri Nov 23 10:29:06                   2                                                           0                                       0

Бекап был сделан в 3:00 23 ноября и с этого момента в системе было зафиксировано 6 транзакий, 5 — непосредственный ввод данных и 1 — загрузка из внешнего источника.

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

MAXL> alter database HR.HR replay transactions using sequence_id_range 2134 to 2134;

 OK/INFO - 1056213 - message from server [Reading Rule SQL Information For Database [HR]].
 OK/INFO - 1056213 - message from server [Reading Rules From Rule Object For Database [HR]].
 OK/INFO - 1056213 - message from server [Parallel dataload enabled: [1] block prepare threads, [1] block write threads.].
 OK/INFO - 1056213 - message from server [Data Load Updated [44945] cells].
 OK/INFO - 1056213 - message from server [Data Load Elapsed Time for [dl1353650867.txt] with [dl1353650867.rul] : [1.19] seconds].
 OK/INFO - 1056023 - Database HR.HR altered.

При этом можно наблюдать, как уже восстановленые транзакции последовательно исчезают из списка транзакций:

MAXL> query database HR.HR list transactions;

 sequence_id         username            start_time          end_time            req_type            calcscript_name     dataload_file_or_ft dataload_file_type  rule_file           rule_file_loc       sql_or_ftp_username
+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------+-------------------
                2138 essbase@Native Dire Fri Nov 23 10:20:30 Fri Nov 23 10:29:06                   2

5. Восстановить систему, пока в списке не останется ни одной транзакции. К сожалению, повтор транзакции для некоторых из них означает полный повтор рассчётов (у нас BSO), так что процесс может быть весьма длительным и ресурсоёмким: придётся выполнить весь объём работы, что был проделан в процессе выполнения этих транзакций на основном сервере.
После окончания восстановления имеем актуальную копию БД и можем продолжать работать.

Послесловие

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

  1. Снова восстановиться из резервной копии
  2. Повторить все уже ранее выполненные транзакции
  3. Повторить новые транзакции, которые стали доступны после восстановления и перечитывания файла транзакций

Это не позволяет организовать горячий standby с online повтором транзакций с primary экземпляра.

Update 26.01.14

В каких случаях не работает механизм автоматического восстановления:

1. Для ASO. ASO не содержит transaction log. Идеологически оно не предназначено для online транзакций, так что резервирование следует выполнять в момент поставки данных либо дублируя саму поставку либо ведя подробный лог этой поставки.

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

С момента написания первого поста приходилось уже несколько раз восстаналивать БД (к счастью, только на тесте), и по опыту, время такого восстановления всегда не превышало 1 часа. А вот «уронить» Essbase так, чтобы он не смог самостоятельно подняться, оказалось достаточно просто.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s