Построение отказоустойчивой системы с помощью Oracle Physical Standby::Журнал СА 7.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

Книжная полка  

От создания сайтов до разработки и реализации API

В издательстве «БХВ» недавно вышли книги, которые будут интересны системным администраторам, создателям

 Читать далее...

Разбор полетов  

Ошибок опыт трудный

Как часто мы легко повторяем, что не надо бояться совершать ошибки, мол,

 Читать далее...

Принципы проектирования  

Dependency Inversion Principle. Принцип инверсии зависимостей в разработке

Мы подошли к последнему принципу проектирования приложений из серии SOLID – Dependency

 Читать далее...

Рынок труда  

Вакансия: Администратор 1С

Администратор 1С – это специалист, который необходим любой организации, где установлены программы

 Читать далее...

Книжная полка  

Книги для профессионалов, студентов и пользователей

Книги издательства «БХВ» вышли книги для тех, кто хочет овладеть самыми востребованными

 Читать далее...

Принципы проектирования  

Interface Segregation Principle. Принцип разделения интерфейсов в проектировании приложений

Эта статья из серии «SOLID» посвящена четвертому принципу проектирования приложений – Interface

 Читать далее...

Книжная полка  

Секрет успешных людей

Книги издательства «БХВ» по ИТ рассчитаны на разные категории читателей: от новичков

 Читать далее...

Учебные центры  

Карьерные мечты нужно воплощать! А мы поможем

Школа Bell Integrator открывает свои двери для всех, кто хочет освоить перспективную

 Читать далее...

Гость номера  

Дмитрий Галов: «Нельзя сказать, что люди становятся доверчивее, скорее эволюционирует ландшафт киберугроз»

Использование мобильных устройств растет. А вместе с ними быстро растет количество мобильных

 Читать далее...

Прошу слова  

Твердая рука в бархатной перчатке: принципы soft skills

Лауреат Нобелевской премии, специалист по рынку труда, профессор Лондонской школы экономики Кристофер

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 11252
Комментарии: 0
Потоковая обработка данных

 Читать далее...

19.03.2018г.
Просмотров: 9505
Комментарии: 0
Релевантный поиск с использованием Elasticsearch и Solr

 Читать далее...

19.03.2018г.
Просмотров: 9554
Комментарии: 0
Конкурентное программирование на SCALA

 Читать далее...

19.03.2018г.
Просмотров: 5975
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 6684
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 3978
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 2903
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3704
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3714
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6204
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3055
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3359
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7171
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10552
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12264
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 13901
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9033
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 6996
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5304
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4532
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3345
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

Друзья сайта  

 Построение отказоустойчивой системы с помощью Oracle Physical Standby

Архив номеров / 2007 / Выпуск №7 (56) / Построение отказоустойчивой системы с помощью Oracle Physical Standby

Рубрика: Администрирование /  Продукты и решения

Сергей Косько

Построение отказоустойчивой системы с помощью Oracle Physical Standby

Развернув информационную систему на базе СУБД Oracle и организовав надёжную стратегию резервного копирования-восстановления, можно приступать к производственной эксплуатации системы. В случае аварии возможно будет восстановить данные на требуемый момент времени. Но что делать, если допустимое время простоя не должно превышать нескольких минут? Тогда не обойтись без различных способов дублирования данных в режиме реального времени.

Один из вариантов такой репликации можно реализовать с помощью специальной базы данных Oracle Standby. Её можно применять совместно с обычным резервным копированием. Режим Standby DB обеспечивает опция Data Guard базы данных Oracle. Конфигурация Data Guard состоит из одной производственной и одной или более резервных баз данных standby, которые находятся в особом режиме, предусматривающем непрерывный приём и применение потока изменений от производственной базы. Изменения передаются по универсальной сети между разнесёнными географически серверами средствами Oracle Net [1]. Упрощённую схему взаимодействия смотрите на рисунке.

Структура Oracle Data Guard

Структура Oracle Data Guard

В зависимости от конкретных требований по времени восстановления и допустимой потери данных при аварии (recovery time objective, recovery point objective [2]). Возможны различные сценарии реализации:

  • Physical standby DB – резервная база данных является точной физической копией основной, находится в монтированном состоянии и при этом переносится поток redo-информации.
  • Logical standby DB – резервная база данных не является точной копией основной, открыта в режиме чтения–записи и при этом переносится поток SQL-команд.

Конфигурация Oracle Data Guard может находиться в трёх режимах защиты: максимальной производительности (maximum performance), максимальной доступности (maximum availability) или максимальной защиты (maximum protection) [3]. Изменения передаются копированием журналов базы данных, текущих или архивных. Их запись осуществляется двумя процессами LGWR или ARCn. Процесс LGWR ведёт запись активных журналов, дополнительные настройки вынуждают его передавать изменения на резервный сервер с помощью так называемых standby redo log-файлов. Процесс ARCn переносит обычные архивные журналы, дополнительные настройки вынуждают его передавать их ещё и на удалённый сервер. Если выбраны режимы максимальных доступности или защиты, поток изменений передаётся с помощью данных, записываемых процессом LGWR. В режиме максимальной производительности возможна передача изменений как LGWR, так и ARCn.

В случае необходимости такая база может быть в короткий срок активирована в качестве производственной.

Поскольку БД Logical Standby не является точной копией основной базы и не поддерживает некоторые типы данных, SQL-команды, имеет требования по обеспечению уникальности строк в таблицах [4], рассмотрим реализацию именно Physical Standby DB. Мне кажется, что использовать БД Logical Standby лучше не как резервную копию, а в качестве базы для отчётов. Выберем для работы основной и резервной баз следующие настройки: производственная база работает в режиме maximum availability, переданные изменения применяются резервной базой в режиме Real-Time Apply Redo. Для такого режима работы инициатором передачи информации об изменениях выступает как раз процесс LGWR. Разница между режимами защиты заключается в том, что в режиме maximum protection транзакция фиксируется только тогда, когда запись произведена и в локальные журналы, и удалённо, в случае невозможности удалённой записи база данных останавливается, а в режиме maximum performance для продолжения работы достаточно только локальной записи, и основная БД продолжает свою работу, даже если связь с резервной базой отсутствует.

Режим maximum availability представляет компромиссный вариант, переключаясь между двумя режимами автоматически. Если связь работает без ошибок, передача происходит синхронно, если произошел сбой, автоматически осуществляется переход в менее строгий режим. После устранения сбоев режим максимальной защиты восстанавливается [5].

Что необходимо для создания тестовой среды:

  • Два сервера одинаковой архитектуры, они могут отличаться по количеству процессоров, памяти, дисков, релизом операционной системы и т. п. Пусть сервер primary DB будет называться Poltava, а сервер standby – Fastiv.
  • Режим базы данных должен быть ARCHIVELOG.
  • Необходимо использовать программное обеспечение Oracle Server версии Enterprize Edition. В тестах будем использовать версию Oracle10.2 EE for Solaris.

Подготовка рабочей конфигурации

Итак, у нас имеется работающая производственная (primary) база данных Oracle, расположенная на сервере Poltava, и нам необходимо создать резервную базу standby на сервере Fastiv. Необходимо подготовить конфигурационные файлы и сделать дополнительные настройки.

Пусть имя базы будет «TST», присвоим для производственной primary-базы значение ORACLE_SID=ORCL, для standby – DB ORACLE_SID=ORCL1. Файлы primary DB находятся в каталоге /tstb/ORCL, файлы standby DB – в каталоге /tstb/ORCL1.

Для работы БД standby присваивать различные значения переменной ORACLE_SID для окружения основной и резервной баз данных необходимости нет, но это позволяет сделать так, чтобы файлы двух баз не накладывались друг на друга. Это позволяет перемещать базы между серверами, временно или в тестовых целях совмещать их на одном и том же сервере, имеющем два сетевых адресса (poltava и fastiv).

Необходимо выполнить следующие действия:

Включим режим force logging на производственной системе для принудительной записи в журналы БД информации, даже для так называемых операций Nologging:

SQL>ALTER DATABASE FORCE LOGGING;

Создадим файлы standby redo log. Они нужны только для работы БД standby, но мы создадим их и на primary, и на standby, в случае переключения ролей между базами не будет необходимости в их создании.

Файлы standby redo необходимо создать не меньшего размера, чем online redo log, и в количестве n+1 от количества redo group (cм. листинг 1).

Листинг 1. Добавление файлов Standby Redo

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/tstb/ORCL/redo01.stb' SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 '/tstb/ORCL/redo02.stb'  SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/tstb/ORCL/redo03.stb'  SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 '/tstb/ORCL/redo04.stb'  SIZE 100M REUSE;

exit

EOF

Установим параметры в файлах параметров init.ora/spfile.ora для primary и standby (см. листинг 2).

Листинг 2. Список параметров файла init.ora/spfile.ora

*.audit_file_dest='/ora/admin/ORCL/adump'

*.background_dump_dest='/ora/admin/ORCL/bdump'

*.control_files='/tstb/ORCL/control01.ctl', '/tstb/ORCL/control02.ctl', '/tstb/ORCL/control03.ctl'

*.core_dump_dest='/ora/admin/ORCL/cdump'

*.db_name='TST'

*.log_archive_format='log_%t_%s_%r.dbf'

*.remote_login_passwordfile='EXCLUSIVE'

*.STANDBY_FILE_MANAGEMENT=AUTO

*.DB_UNIQUE_NAME=poltava

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(poltava,fastiv)'

*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=poltava'

*.LOG_ARCHIVE_DEST_2='SERVICE=fastiv LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=fastiv'

*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

*.LOG_ARCHIVE_DEST_STATE_2=ENABLE

*.FAL_SERVER=poltava                 

*.FAL_CLIENT=fastiv

*.STANDBY_ARCHIVE_DEST=/tstb/log1/

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

 

*.audit_file_dest='/ora/admin/ORCL1/adump'

*.background_dump_dest='/ora/admin/ORCL1/bdump'

*.control_files='/tstb/ORCL1/control01.ctl', '/tstb/ORCL1/control02.ctl', '/tstb/ORCL1/control03.ctl'

*.core_dump_dest='/ora/admin/ORCL1/cdump'

*.db_name='TST'

*.log_archive_format='log_%t_%s_%r.dbf'

*.user_dump_dest='/ora/admin/ORCL1/udump'

*.STANDBY_FILE_MANAGEMENT=AUTO

*.DB_UNIQUE_NAME=fastiv

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(poltava,fastiv)'

*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=fastiv'

*.LOG_ARCHIVE_DEST_2='SERVICE=poltava LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=poltava'

*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

*.LOG_ARCHIVE_DEST_STATE_2=ENABLE

*.FAL_SERVER=poltava

*.FAL_CLIENT=fastiv

*.STANDBY_ARCHIVE_DEST=/tstb/log/

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

*.DB_FILE_NAME_CONVERT=('/tstb/ORCL','/tstb/ORCL1')

*.LOG_FILE_NAME_CONVERT=('/tstb/ORCL','/tstb/ORCL1')

Настроим Oracle Net для сетевых адресов Poltava и Fastiv.

Пример настроек файлов listener.ora и tnsnames.ora приведены в листинге 3.

Листинг 3. Настройки Oracle Net

# listener.ora Network Configuration File:

# /ora/oracle10/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1525))

    )

  )

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = TST)

      (ORACLE_HOME = /ora/oracle10)

      (SID_NAME = ORCL)

    )

    (SID_DESC =

      (GLOBAL_DBNAME = TST)

      (ORACLE_HOME = /ora/oracle10)

      (SID_NAME = ORCL1)

    )

  )

# tnsnames.ora Network Configuration File:

# /ora/oracle10/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

Poltava =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = poltava)(PORT = 1525))

    )

    (CONNECT_DATA =

    (SID = ORCL)

    )

  )

Fastiv =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = fastiv)(PORT = 1525))

    )

    (CONNECT_DATA =

    (SID = ORCL1)

    )

  )

Создание резервной БД standby

Создадим резервные копии базы данных и файла паролей и перенесем скопированные файлы на резервный сервер Fastiv.

Поскольку значения ORACLE_SID для основной и резервной баз отличаются, файлы паролей тоже будут иметь разные имена, например, orapwORCL и orapwORCL1.

Создадим standby control file и скопируем его на сервер standby в местоположение, указанное в файле параметров базы данных standby:

SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';

Переключим основную базу данных в режим maximum availability следующей командой:

SQL>STARTUP MOUNT;

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Базы данных готовы к работе. Теперь обе базы данных можно запускать.

Операции с БД во время работы

Во время работы необходимо выполнять определённые действия – пуск, остановка, открытие для чтения, регистрация пропущенных логов, активация резервной базы (failover), обмен статусом (switchover). Рассмотрим эти операции:

Скрипт stbstart отвечает за старт БД standby в режиме real-time apply. Остановку БД standby обеспечивает скрипт stbshut (см. листинг 4).

Листинг 4. Пуск и остановка БД Physical Standby

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

startup nomount;

alter database mount standby database ;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT FROM SESSION;

exit

EOF

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SHUTDOWN IMMEDIATE;

exit

EOF

Проверим механизм передачи изменений переключением журналов. На primary:

SQL>ALTER SYSTEM SWITCH LOGFILE;

на standby:

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

Скрипт stbreadonly отвечает за запуск БД standby в режиме read-only (см. листинг 5). Доставка Redo в этом случае продолжается, однако изменения будут отложены до выхода из этого режима.

Листинг 5. Запуск БД standby в режиме read-only

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

spool readonly.log

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

alter database open read only;

exit

EOF

Switchover – скрипт для смены ролей между базами данных. Необходимо, чтобы БД primary была открыта, а standby была в режиме mount или recover (см. листинг 6). Как можно видеть в скрипте, для переключения ролей необходимо иметь доступ к каждой из баз данных, участвующих в операции.

Листинг 6. Обмена ролями между базами Poltava и Fastiv

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

spool switchover.log

REM connect primary

connect sys/manager@poltava as sysdba

column SWITCHOVER_STATUS format A20 heading 'Switchover status|primary'

SELECT SWITCHOVER_STATUS FROM V\$DATABASE;

column DATABASE_ROLE format A20 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

column DATABASE_ROLE format A20 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

REM connect standby db on redo apply mode

connect sys/manager@fastiv as sysdba

column SWITCHOVER_STATUS format A20 heading 'Switchover status|standby'

SELECT SWITCHOVER_STATUS FROM V\$DATABASE;

column DATABASE_ROLE format A20 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

ALTER DATABASE OPEN;

REM if in read only, do not open - restart

REM SHUTDOWN IMMEDIATE;

REM STARTUP;

column DATABASE_ROLE format A20 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

exit

EOF

Failover – cкрипт, активирующий резервную базу в случае аварии на базе primary. Поскольку резервной базы больше нет, перед активацией резервной базы её следует перевести в режим maximum performance (см. листинг 7).

SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Регистрация пропущенных логов наглядно показана в листинге 8.

Листинг 7. Активация резервной базы данных в случае аварии

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

spool failover.log

column DATABASE_ROLE format A15 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

ALTER DATABASE OPEN;

column DATABASE_ROLE format A15 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

exit

EOF


Листинг 8. Определение и разрешение вручную пропусков передачи журналов

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

THREAD#      LOW_SEQUENCE#   HIGH_SEQUENCE#

----------   -------------   --------------

         1              90               92

SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

Автоматизация мониторинга работы

Поскольку БД primary находится в режиме maximum availability, то в случае остановки резервного сервера основная БД продолжит свою работу. Между состоянием primary и standby образуется разрыв. Для обнаружения и устранения поломки потребуется время, в течение которого основная база данных не резервируется. В этот момент, в случае повторной аварии уже на основной базе данных, возможна потеря данных. Чтобы своевременно обнаруживать и устранять подобные ситуации, необходимо автоматизировать процесс наблюдения за работой обеих БД.

Листинг 9. Скрипт, выполняющий поиск ошибок в файле alert.log

#!/bin/sh

#

if [ -f /tmp/memsg_no ]

    then exit ;

fi

HOST=`/bin/hostname`

MYMAIL="sergkosko@ua.fm"

FILESLIST=`ls -R /ora/admin/*/bdump/*.log`

for i in ${FILESLIST}

    do

filename1=`basename ${i}`

dir1=`dirname ${i}|sed 's/\/ora\/admin\///g

s/\/bdump//g'`

    MSG=`/usr/local/bin/fetchlog -F 1:100:1000:s ${i} /var/adm/${filename1}.${dir1}`

    if [ $? -gt 0 ]

    then

    MSG1=`echo  "${MSG}" | egrep -i "ora-"`

    if [ -n  "$MSG1" ]

    then

echo "\n${HOST}:${filename1}:${MSG1}\n"| /bin/mail ${MYMAIL}

fi

fi

done

Это можно сделать, например, с помощью пакета fetchlog [6]. На базе этого программного обеспечения создан скрипт fetchalert (см. листинг 9), который можно запускать с помощью демона crond:

testcase$EDITOR=vi;export EDITOR

testcase$crontab -e

testcase$0,15,30,45 * * * * /usr/local/bin/fetchalert >/dev/null 2>&1

Выводы

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

  • Один из серверов находится в пассивном состоянии и не обслуживает запросы пользователей.
  • Если поток транзакций на БД primary будет слишком большой, это создаст дополнительную нагрузку из-за репликации в общей сети, к которой подключены сервера.
  • В данной конфигурации не предусмотрено специальных программно-аппаратных средств, контролирующих состояние системы-партнёра, наподобие тех, что применяются при построении, например, кластерных систем. В этом случае при возникновении сбоя, скажем, разрыва сетевого соединения, серверы не смогут однозначно определить источник проблем. В этом случае необходимо вмешательство системного администратора для принятия решения о переключении на резервный сервер. Время, необходимое человеку для принятия такого решения, следует учитывать при оценке общего времени восстановления работоспособности системы после сбоя наряду с длительностью самой процедуры переключения.

Но эти факторы могут и не оказать серьёзного влияния на работу системы, поскольку современные сетевые технологии позволяют передавать большие объёмы данных на значительные расстояния, а в качестве резервного может использоваться сервер меньшей мощности.

Удачи!

  1. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/concepts.htm#g1049956 – механизм работы Oracle Data Guard.
  2. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14210/hadesign.htm#i1006243 – понятие RTO и RPO.
  3. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#i1179318 – режимы защиты Oracle Data Guard.
  4. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm#i76646 – ограничение Logical Standby DB.
  5. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#i1008082 – различные сценарии реализации Oracle Data Guard.
  6. http://sourceforge.net/projects/fetchlog – проект fetchlog.

Комментарии отсутствуют

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

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru