disaster recovery в Oracle

[Dmitry67]

Заранее спасибо

Скажите когда база в Oracle я вляется базой для disaster recovery,
к ней возможны read-only обращения ?

[verzlo]

Да.. Существует несколько способов решения этой задачи...
Все зависит от архитектуры (где физически будет находиться эта вторая база), типа базы даных (OLTP, BW, DSS), и как часто/долго надо чтобы база была открыта для Read-only.

Возможные варианты:
1) Standby database ( + dataguard) - переключается в read-only на определенное время (допустим на время запуска каких то больших отчетов или еще чего). Ньюанс, в это время, пока она будет Read-only все новые изменения не будут applied до тех пор пока база не переключится в standby mode опять.
2) Snapshot replication - это не полноценное disaster recovery solution, так как в случае умирания продакшн, надо повозиться, чтобы 2-я база смогла стать транзакшнл, или чтобы перенести данные куда нить, но они могут быть всегда доступны для read-only, и все обновления могут немедленно появляться во 2-й базе.

[Dmitry67]

Спасибо
А сам disaster recovery как выглядит ? Скрипт какой то ?
То есть я могу сделать бесконечный цикл такого плана

1. сгенерить на production очередной log
2. переслать его на второй сервер
3. применить его
4. перевести базу в readonly
5. сделать нужные selects
6. перевести базу в standby
7. goto 1

?

Соответственно если в этот процесс можно влезть своими шаловливыми ручками, то я могу, например, от одного production вести ДВА disaster recover sites ?

[verzlo]

Если вас интересует standby ( на сколько я понял) то там все намного проще.
Существует бесплатная примочка к самой стендбай базе, называемая dataguard. Это цетральная консоль, со своей командной строкой и набор резидентных агентов на primary and standby sites, которые мониторят log switched and archivelogging, и обеспечивают копирование логов на удаленный сайт и эплаят их на стендбае автоматически, в соответствии с лагом в конф. файле. Перевод стендбая в read-only можно сделать из командной строки или консоли одной командой (так же и обратно).
Как тока стебндбай стал read-only - вы можете делать любые селекты.

Все это не сложно запихнуть в скрипты, так что ваш алгоритм упрощается до

1) log shipping and appying is automatic with dataguard
2) switch standby to read-only
3) selects
4) switch standby to normal standby mode

Сам процесс переключения в read-only и обратно не очень быстрый, так как все лаговые логи (которые не были эпплаены - должны быть включены), поэто постоянно переключать ее туда сюде не рекомендуется..

Сам же дизастер рековери просесс сводится к activate standby database - что делается из dataguard консоли или командной строки.. - при этом эплаятся недостающие логи, обновляются контрол файлы, он-лайн реду логи, делаются все tablespaces RW и стендбай база открывается в OPEN mode (все это делается на заднем плане).
После того как вы активировали стендбай, он будет работать как продакшн и стендбай надо пересоздавать на старом продакшн сервере.

[oMoses]

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

Последнее верно лишь в случае failover. Для switchover вам не нужно пересосздавать standby database. А вообще уважаемый Verzlo прав - не следует изобретать велосипед - Oracle9i Data Guard прекрасно работает в этой ситуации. Честно говоря, я несколько недолюбливаю его logical standby database вариант из-за чрезмерной капризности и привередливости. Куда проще (читай: надежнее) иметь дело с physical standby. Кстати, помните о недопустимости операций в production primary database, не генерирующих логов (лучше превентивно заставить базу ВСЕГДА их генерировать, если вопрос high availability перевешивает все остальное). Oracle9i позволяет вам иметь до десяти различных мест отсылки текущих логов, что позволяет формировать "куст" из одной мастер-базы и девяти - standby. Более того, каждый standby тоже может генерировать логи - здесь появляется возможность каскадирования....

[camel]

Dmitry67, поскольку Вы задаете одни и те же вопросы для оракла и DB2, посмотрите этот документ, про оракл там все правильно написано, а насчет дб2 для равновесия можете попросить аналогичный у zVladа или уточнить у него сомнительные моменты
(если требуется пароль - зарегистрируйтесь, это бесплатно)

[Dmitry67]

Да, и в этом примере

select * from PRD.dbo.PROD where not
exists(select * from ADDIT.dbo.T where T.P=PROD.P)

Таблица PROD берется на время в прошлом, а T - на "сейчас"
Боюсь flashback query не подойдет

[MAMOHT]

Oracle Flashback. Позволяет видеть состояние таблицы в прошлом. Насколько далеко, зависит от размера UNDO. Вторая база для этого не нужна.

[Dmitry67]

Oracle Flashback. Позволяет видеть состояние таблицы в прошлом. Насколько далеко, зависит от размера UNDO. Вторая база для этого не нужна.

1 А если сервер перезапущен, то можно ли открыть таблицу на время ДО перезапуска ?
2 Во flashback query можно ли ПИСАТЬ во временные таблицы ?
3 Ничего что я такие странные вопросы задаю ?
Спасибо

[camel]

Да, и в этом примере

select * from PRD.dbo.PROD where not
exists(select * from ADDIT.dbo.T where T.P=PROD.P)

Таблица PROD берется на время в прошлом, а T - на "сейчас"
Боюсь flashback query не подойдет

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

Code: Select all

select dname, ename
from emp as of timestamp sysdate-1/24,
dept as of timestamp sysdate-2/24
where emp.deptno=dept.deptno;

[camel]

Oracle Flashback. Позволяет видеть состояние таблицы в прошлом. Насколько далеко, зависит от размера UNDO. Вторая база для этого не нужна.

1 А если сервер перезапущен, то можно ли открыть таблицу на время ДО перезапуска ?
2 Во flashback query можно ли ПИСАТЬ во временные таблицы ?
3 Ничего что я такие странные вопросы задаю ?
Спасибо

1.да - если еще не слишком поздно (определяется параметром UNDO_RETENTION)
2.да - результат flashback query можно писать куда угодно
3.нормально (вопросы кстати разумные и не элементарные)