Primary Standby (LGWR+ASYNC+NOAFFIRM)

начал разбираться c data guardom.
выставел на primary
init.ora
orcl10.__db_cache_size=92274688
orcl10.__java_pool_size=4194304
orcl10.__large_pool_size=4194304
orcl10.__shared_pool_size=58720256
orcl10.__streams_pool_size=0
*.audit_file_dest='/u02/app/oracle/admin/orcl10/adump'
*.background_dump_dest='/u02/app/oracle/admin/orcl10/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u02/app/oracle/orcl10/control01.ctl','/u02/app/oracle/orcl10/control02.ctl','/u02/app/oracle/orcl10/control03.ctl'
*.core_dump_dest='/u02/app/oracle/admin/orcl10/cdump'
*.db_block_size=8192
*.db_domain='test.ru'
*.db_file_multiblock_read_count=16
*.db_name='orcl10'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orcl10XDB)'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=/u02/app/oracle/orcl10/archive MANDATORY'
*.log_archive_dest_2='SERVICE=standby.test.ru LGWR ASYNC NOAFFIRM OPTIONAL REOPEN=1'
*.log_archive_dest_state_1='enable'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='arch_%t_%s_%r.arc'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_archive_dest='/u02/app/oracle/orcl10/archive_teacher'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u02/app/oracle/admin/orcl10/udump'
*.fal_client = "orcl10.test.ru"
*.fal_server = "standby.test.ru"

tnsnames.ora

orcl10.test.ru =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = pluto.test.ru)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl10.test.ru)
)
)


standby.test.ru =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rh.test.ru)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl10.test.ru)
)
)


standby

init.ora

orcl10.__db_cache_size=92274688
orcl10.__java_pool_size=4194304
orcl10.__large_pool_size=4194304
orcl10.__shared_pool_size=62914560
orcl10.__streams_pool_size=0
*.audit_file_dest='/u02/app/oracle/admin/orcl10/adump'
*.background_dump_dest='/u02/app/oracle/admin/orcl10/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u02/app/oracle/orcl10/control01.ctl','/u02/app/oracle/orcl10/control02.ctl','/u02/app/oracle/orcl10/control03.ctl'
*.core_dump_dest='/u02/app/oracle/admin/orcl10/cdump'
*.db_block_size=8192
*.db_domain='test.ru'
*.db_file_multiblock_read_count=16
*.db_name='orcl10'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orcl10XDB)'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=/u02/app/oracle/orcl10/archive MANDATORY'
*.log_archive_dest_2='SERVICE=standby.test.ru LGWR ASYNC NOAFFIRM OPTIONAL'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='defer'
*.log_archive_format='arch_%t_%s_%r.arc'
*.open_cursors=300
*.pga_aggregate_target=16777216
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.standby_archive_dest='/u02/app/oracle/orcl10/archive_teacher'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u02/app/oracle/admin/orcl10/udump'
*.fal_client=standby.test.ru
*.fal_server=orcl10.test.ru

tnsnames.ora

orcl10.test.ru =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = pluto.test.ru)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl10.test.ru)
)
)

standby.test.ru =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rh.test.ru)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl10.test.ru)
)

на праймари стоит MAXIMUM PERFOMANCE. после запуска redo дышат синхронно все переключения вызывают записи в редо на primary и standby а также архивацию обоих логов у каждого в отдельности. Хочу сэмулировать разрыв сети и сталкиваюст с такой проблемой. Грубо выдираю кабель из standby и при последующем переключении журналов на primary система зависает до тех пор пока кабель на standby не будет снова воткнут. Получается так что и при работе если связь с сервером будет утеряно на некоторое время все встанет на primary? но режим то MAXIMUM PERFOMANCE, указывающий не обращать внимания если поток redo stream отвалился от standby

автор

this is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database's redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data.

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

провел еще раз эксперимент. получаеться вот какая штука. этот таймаут срабатывает только после того как я второй раз переключаю журналы почему то на первом переключении после выключения сети все проходит быстро а но втором завис причем время составляет минуты 4 и вся работа (к примеру делал параллельно создание таблицы зависает) - как бы логично сессия ждет пока сервак скинет лог, скорее всего это задержка указываеться где то в настройках transport services щас попробую поискать. и еще одно любопытное явление после включения сети наблюдается след картинка
на стендбае как я понимаю MRP0 процесс обнаруживает gap если не прав то поправьте меня (может это fal client?)
fal client на стендбае пытается видимо взять недостающие логи с primary и соединяеться с FAL serverom
но выдает в лог стендбая ошибку 12154, потом вознивает сообщение что процесс RFS начинает получать логи но не в archive_dest а в standby_archive_dest а MRP0 начинает их применять для устранения gap
в тоже время картинка на primary зеркальная
FAL server выдает при передачи лога сообщение об ощибке 12560 невозможности создания архилог файла по archive_dest_2 и эта ошибка повторяется несколько раз до той поры пока не будет устранен GAP. вопрос в силу того что явления связанные с подобными ошибками особо не нашел в инете. это нармальная ситуация устранения GAP?

решил сделать эксперимент при использовании режима MAXIMUM PERFOMANCE
настройки на primary
log_archive_dest_2=SERVICE=orcl10.test.ru LGWR SYNC AFFIRM OPTIONAL
NET_TIMEOUT=8 REOPEN=120
log_archive_dest_1=LOCATION=/u02/app/oracle/orcl10/archive MANDATORY
когда сеть стабильна все работает отлично время на тест (делаю инсерты в цикле) составляет 333 секунды
есть в процессе теста сеть у standby то опускаешь то подымаешь (network start|stop) (интервал запуска останова 1 минута) тест занимает примерно 320 секунд.
Но если перед тестом отключить сеть у standby то тест занимает примерно 1700 секунд!!!.
primary проходит в начале несколько переключений журналов порядка 10 раз (всего online log на primary 3 группы) а потом встает просто (не переключаясь в режим Maximum performance )

автор

Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.

в логе в этот момент последнее сообщение
Thread 1 advanced to log sequence 1173
Current log# 1 seq# 1173 mem# 0: /u02/app/oracle/orcl10/redo01.log
Mon Dec 10 15:56:08 2007
ORACLE Instance orcl10 - Can not allocate log, archival required
потом система оживает и продолжает архивировать журналы на primary но почему такое долгое ожидание? чем оно вызвано? и почему этого не было при втором тесте?

Ruslan2005

решил сделать эксперимент при использовании режима MAXIMUM PERFOMANCE настройки на primary log_archive_dest_2=SERVICE=orcl10.test.ru LGWR SYNC AFFIRM OPTIONAL NET_TIMEOUT=8 REOPEN=120 log_archive_dest_1=LOCATION=/u02/app/oracle/orcl10/archive MANDATORY когда сеть стабильна все работает отлично время на тест (делаю инсерты в цикле) составляет 333 секунды есть в процессе теста сеть у standby то опускаешь то подымаешь (network start|stop) (интервал запуска останова 1 минута) тест занимает примерно 320 секунд. Но если перед тестом отключить сеть у standby то тест занимает примерно 1700 секунд!!!. primary проходит в начале несколько переключений журналов порядка 10 раз (всего online log на primary 3 группы) а потом встает просто (не переключаясь в режим Maximum performance ) автор Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode. в логе в этот момент последнее сообщение Thread 1 advanced to log sequence 1173 Current log# 1 seq# 1173 mem# 0: /u02/app/oracle/orcl10/redo01.log Mon Dec 10 15:56:08 2007 ORACLE Instance orcl10 - Can not allocate log, archival required потом система оживает и продолжает архивировать журналы на primary но почему такое долгое ожидание? чем оно вызвано? и почему этого не было при втором тесте?

извиняюсь эксперимент проводился конечно при режиме MAXIMUM AVAILABILITY)))

Ruslan2005

провел еще раз эксперимент. получаеться вот какая штука. этот таймаут срабатывает только после того как я второй раз переключаю журналы почему то на первом переключении после выключения сети все проходит быстро а но втором завис причем время составляет минуты 4 и вся работа (к примеру делал параллельно создание таблицы зависает) - как бы логично сессия ждет пока сервак скинет лог, скорее всего это задержка указываеться где то в настройках transport services щас попробую поискать. и еще одно любопытное явление после включения сети наблюдается след картинка на стендбае как я понимаю MRP0 процесс обнаруживает gap если не прав то поправьте меня (может это fal client?) fal client на стендбае пытается видимо взять недостающие логи с primary и соединяеться с FAL serverom но выдает в лог стендбая ошибку 12154, потом вознивает сообщение что процесс RFS начинает получать логи но не в archive_dest а в standby_archive_dest а MRP0 начинает их применять для устранения gap в тоже время картинка на primary зеркальная FAL server выдает при передачи лога сообщение об ощибке 12560 невозможности создания архилог файла по archive_dest_2 и эта ошибка повторяется несколько раз до той поры пока не будет устранен GAP. вопрос в силу того что явления связанные с подобными ошибками особо не нашел в инете. это нармальная ситуация устранения GAP?

А не пробовали добавить еще redo логов. Скажем, не 3 как по умолчанию а сделать их 6?

У вас встает второй раз потому что нужен свободный реду а его похоже еще нету из за таймаута.

У меня были такие настройки (maximum availability) + три журнальные группы, только Оракл 10.2.0.3. При обрыве связи база не вставала.

log_archive_dest_1	LOCATION=C:\oracle\product\10.2.0\oradata\s01\archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=s01	FALSE
log_archive_dest_2	SERVICE=s02 LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=s02

Кстати в доке (Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04) в гл. 5 Redo Transport Services есть интересное примечание

Note: Beginning with Oracle Database 10g Release 10.2, it is unnecessary to specify the NET_TIMEOUT attribute on the LOG_ARCHIVE_DEST_n destinations configured with both the LGWR and ASYNC attributes. This is because the log writer process never waits for the LNSn for any reason in release 10.2. Thus, specifying the NET_TIMEOUT attribute is not required.

Я сам не до конца проникся что же здесь имеется ввиду, т.к. не имел дело с Data Guard на более ранних релизах.

MinistrBob

Кстати в доке (Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04) в гл. 5 Redo Transport Services есть интересное примечание Note: Beginning with Oracle Database 10g Release 10.2, it is unnecessary to specify the NET_TIMEOUT attribute on the LOG_ARCHIVE_DEST_n destinations configured with both the LGWR and ASYNC attributes. This is because the log writer process never waits for the LNSn for any reason in release 10.2. Thus, specifying the NET_TIMEOUT attribute is not required.

может LGWR и не ждет пока LNS скинет реду на стендбай, но вот переключение журналов
при недоступности стендбая подвисает и на AIXе это подвисание выливалось в 90 секунд
что при нагруженной системе и малом количестве реду групп может таки привести к
ситуации когда уже LGWR некуда будет писать и подвиснет все... кроме селектов конечно :)

а вот когда NET_TIMEOUT выставили в 10, то и жизнь как-то у базки наладилась,
тем более что поставили REOPEN=900 и после неудачной попытки скидывать реду
на стендбай, праймари успешно забывает о стендбае на 15 минут...

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

denix1

MinistrBob Кстати в доке (Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04) в гл. 5 Redo Transport Services есть интересное примечание Note: Beginning with Oracle Database 10g Release 10.2, it is unnecessary to specify the NET_TIMEOUT attribute on the LOG_ARCHIVE_DEST_n destinations configured with both the LGWR and ASYNC attributes. This is because the log writer process never waits for the LNSn for any reason in release 10.2. Thus, specifying the NET_TIMEOUT attribute is not required. может LGWR и не ждет пока LNS скинет реду на стендбай, но вот переключение журналов при недоступности стендбая подвисает и на AIXе это подвисание выливалось в 90 секунд что при нагруженной системе и малом количестве реду групп может таки привести к ситуации когда уже LGWR некуда будет писать и подвиснет все... кроме селектов конечно :) а вот когда NET_TIMEOUT выставили в 10, то и жизнь как-то у базки наладилась, тем более что поставили REOPEN=900 и после неудачной попытки скидывать реду на стендбай, праймари успешно забывает о стендбае на 15 минут... так что доку читать то нужно, то и пробовать в реальных условиях поведение не помешает

исходя из всего что было сказано я так понимаю основным фактором продолжения работы primary при разрыве связи со standby является количество групп свободных, ну хорошо предположим что у меня 32 группы скорость заполнения примерно 3 группы в минуту то есть времени на работу с момента прекращения связи будет составлять чуть более 10 минут а потом система опять встанет?
или я никак не уловлю полноту мысли?)

Ruslan2005

denix1 MinistrBob Кстати в доке (Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04) в гл. 5 Redo Transport Services есть интересное примечание Note: Beginning with Oracle Database 10g Release 10.2, it is unnecessary to specify the NET_TIMEOUT attribute on the LOG_ARCHIVE_DEST_n destinations configured with both the LGWR and ASYNC attributes. This is because the log writer process never waits for the LNSn for any reason in release 10.2. Thus, specifying the NET_TIMEOUT attribute is not required. может LGWR и не ждет пока LNS скинет реду на стендбай, но вот переключение журналов при недоступности стендбая подвисает и на AIXе это подвисание выливалось в 90 секунд что при нагруженной системе и малом количестве реду групп может таки привести к ситуации когда уже LGWR некуда будет писать и подвиснет все... кроме селектов конечно :) а вот когда NET_TIMEOUT выставили в 10, то и жизнь как-то у базки наладилась, тем более что поставили REOPEN=900 и после неудачной попытки скидывать реду на стендбай, праймари успешно забывает о стендбае на 15 минут... так что доку читать то нужно, то и пробовать в реальных условиях поведение не помешает исходя из всего что было сказано я так понимаю основным фактором продолжения работы primary при разрыве связи со standby является количество групп свободных, ну хорошо предположим что у меня 32 группы скорость заполнения примерно 3 группы в минуту то есть времени на работу с момента прекращения связи будет составлять чуть более 10 минут а потом система опять встанет? или я никак не уловлю полноту мысли?)

Да не встанет у вас система...

Вам нужно чтобы время, за которое система пробегает по всем РЕДУ (то есть которое реально есть у каждого реду, чтобы его успели передать) было БОЛЬШЕ чем таймаут на передачу (то есть если передача не сложилась - то она успела бы обломиться и отстать от реду раньше чем он снова понадобится). Поэтому или добавить еще реду, или увеличить размер реду и тоже добавить хотя бы до 4-х.

Где проблема??