Standby(физический) почему primari db не останавливается?

ale-Just
Дата: 01.08.2005 17:49:02
Не понимаю что не так.Oracle 9.2.0.4(win32)
Параметры primary db в init.ora:
FAL_CLIENT = CLONE
FAL_SERVER = ST10
LOG_ARCHIVE_DEST_2 = 'location=c:\oracle\admin\st10\arch_standby\ MANDATORY'
LOG_ARCHIVE_DEST_3 = 'SERVICE=clone LGWR SYNC AFFIRM'
log_archive_dest_state_2=enable
log_archive_dest_state_3=enable
log_archive_format = "st10_%T%TS%S.ARC"
REMOTE_ARCHIVE_ENABLE=SEND
standby_file_management=AUTO
log_archive_start = true
#log_archive_dest = C:\oracle\admin\st10\arch\archive

Параметры в Standby:
FAL_SERVER = st10
FAL_CLIENT = clone
LOG_ARCHIVE_DEST_1='location=E:\oracle\admin\clone\arch\ MANDATORY'
LOG_ARCHIVE_DEST_2='location=E:\oracle\admin\clone\arch_standby\ MANDATORY'
log_archive_dest_state_1='enable'
log_archive_dest_state_2='enable'
standby_archive_dest='E:\oracle\admin\clone\arch_standby\'
db_file_name_convert=('c:\oracle\oradata\st10\',
'e:\oracle\oradata\clone\')
log_file_name_convert=('c:\oracle\oradata\st10\',
'e:\oracle\oradata\clone\')
standby_file_management=AUTO
remote_archive_enable=RECEIVE
instance_name='clone'
lock_name_space='clone'

just@ST10>select database_role, open_mode, protection_mode
2 from v$database;

DATABASE_ROLE OPEN_MODE PROTECTION_MODE
---------------- ---------- --------------------
PRIMARY READ WRITE MAXIMUM AVAILABILITY

just@ST10>SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#
2 FROM V$ARCHIVE_DEST_STATUS
3 WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';

DESTINATION
-----------------------------------------------------------------------
STATUS ARCHIVED_THREAD# ARCHIVED_SEQ#
--------- ---------------- -------------
c:\oracle\admin\st10\arch_standby\
VALID 1 319

clone
VALID 1 319

Всё работает, транзакция пишется в primary и в standby одновременно.Но при падении standby, primary продлжает работать как ни чём не бывало.А alert.log показывает ошибки что писать во второй путь не может и пишет спокойно к себе
в первый.В DataGuard при режиме 'MAXIMUM AVAILABILITY' пишут A primary database transaction will not commit until the redo data needed to recover that transaction is written to at least one standby database that meets the minimum requirements for this mode.МОжет кто подскажет где я допустил ошибку.Заранее спасибо.
Vadim_Maximov
Дата: 01.08.2005 17:52:03
ИМХО, тебе нужен MAXIMUM PROTECTION. Тогда primary благополучно завалится :)
ale-Just
Дата: 01.08.2005 18:07:18
Vadim тогда не понятно почему я могу зафиксировать транзакцию.Transaction will not commit until the redo data needed to recover that transaction is written to at least one standby database - это что шутка такая?
Wolfon Stromboy
Дата: 01.08.2005 18:12:15
Если я правильно понял вопрос, то в Primary init.ora надо дабавить параметр
log_archive_min_succeed_dest=2
тогда при завале StandBy и Primary не сможет работать, а иначе он (Primary) думает, что в одно место логи запишу -- и нормально :)
ale-Just
Дата: 01.08.2005 18:39:10
log_archive_min_succeed_dest=2 - да возможно это то я и упустил, попробуем.Sencs Wolfon Stromboy
Сергей Тихонов
Дата: 01.08.2005 20:56:51
ale-Just
Vadim тогда не понятно почему я могу зафиксировать транзакцию.Transaction will not commit until the redo data needed to recover that transaction is written to at least one standby database - это что шутка такая?

Вам же уже ответили. У вас - MAXIMUM AVAILABILITY, а Вам нужен MAXIMUM PROTECTION.
ale-Just
Дата: 01.08.2005 20:59:32
Если кому то будет интересно alert.log
После того как остановил Standby в Primary выдоло следуюсщее:

Mon Aug 01 19:25:20 2005
ARC1: Evaluating archive log 3 thread 1 sequence 366
ARC1: LGWR is actively archiving destination LOG_ARCHIVE_DEST_3
ARC1: Beginning to archive log 3 thread 1 sequence 366
Creating archive destination LOG_ARCHIVE_DEST_3: 'clone'
Creating archive destination LOG_ARCHIVE_DEST_2: 'C:\ORACLE\ADMIN\ST10\ARCH_STANDBY\ST10_001001S00366.ARC'
Mon Aug 01 19:25:50 2005
ARC1: Completed archiving log 3 thread 1 sequence 366
Mon Aug 01 19:31:52 2005
Network asynch I/O wait error 3114 log 1 service 'clone'
Mon Aug 01 19:31:52 2005
Errors in file c:\oracle\admin\st10\bdump\st10_lgwr_1756.trc:
ORA-03114: not connected to ORACLE

Mon Aug 01 19:34:08 2005
LGWR: Completed archiving log 1 thread 1 sequence 367
LGWR: Error 1010 disconnecting from destination LOG_ARCHIVE_DEST_3 standby host 'clone'
LGWR: Destination LOG_ARCHIVE_DEST_3 not using standby redo logfiles; cannot reconnect
LGWR: Error 1010 closing archivelog file 'clone'
Mon Aug 01 19:34:08 2005
Errors in file c:\oracle\admin\st10\bdump\st10_lgwr_1756.trc:
ORA-01010: invalid OCI operation

В st10_lgwr_1756.trc:
Receiving message from NetServer 0
Destination LOG_ARCHIVE_DEST_3 is in CLUSTER CONSISTENT mode
Destination LOG_ARCHIVE_DEST_3 is in MAXIMUM AVAILABILITY mode
Receiving message from NetServer 0
rfxslfact:0
--------------------------
Error 12571 closing standby archive log file at host 'clone'
Receiving message from NetServer 0
LGWR: Failed
--------------------------
*** 2005-08-01 19:18:34.765
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.
*** 2005-08-01 19:18:37.218
*** 2005-08-01 19:31:52.328
Network asynch I/O wait error 3114 log 1 service 'clone'
*** 2005-08-01 19:31:52.328
kcrrfail: dest:3 err:3114 force:0
------------------------
ORA-03114: not connected to ORACLE
*** 2005-08-01 19:34:08.234 44144 kcrr.c
Making upinblc request to NetServer 0
NetServer pid:364
*** 2005-08-01 19:34:08.234 44279 kcrr.c
upinblc done status is 0
Receiving message from NetServer 0
LGWR: Failed
------------------------
после этих слов база продолает прекрано работь если не выставлен правильно параметр log_archive_min_succeed_dest
Сергей Тихонов
Дата: 01.08.2005 21:00:28
Wolfon Stromboy
Если я правильно понял вопрос, то в Primary init.ora надо дабавить параметр
log_archive_min_succeed_dest=2
тогда при завале StandBy и Primary не сможет работать, а иначе он (Primary) думает, что в одно место логи запишу -- и нормально :)

Основной сервер в этом случае перестанет работать только тогда, когда онлайн-редо-логи все заполнятся. Что проблемы не решит...
LOG_ARCHIVE_MIN_SUCCEED_DEST defines the minimum number of destinations that must succeed
in order for the online logfile to be available for reuse.
ale-Just
Дата: 01.08.2005 21:02:09
Сергей я же объснил почему я жду другого результата.В Help написано черным по белому.Транзакция в режиме MAXIMUM AVAILABILITY не должна завершиться если standby отвалился.
Сергей Тихонов
Дата: 01.08.2005 21:05:22
ale-Just
после этих слов база продолает прекрано работь если не выставлен правильно параметр log_archive_min_succeed_dest

MAXIMUM AVAILABILITY - Unlike Maximum Protection mode, the primary database will not shut down if it is unable to write the redo records to at least one such standby database. Instead, the primary database will run in Maximum Performance mode until the fault has been corrected... - это из учебника.