群里有人提问说刚搭建的Linux Dataguard 主库日志可以正常应用到备库，但是当主库切换到最大可用模式的时候
备库却还是最大性能模式，让他贴出来警告日志如下
主库警告日志
GWR: STARTING ARCH PROCESSES COMPLETE
ARCt started with pid=45, OS id=3819
Sun Dec 25 17:24:33 2011
LGWR: Primary database is in MAXIMUM AVAILABILITY mode
LGWR: Destination LOG_ARCHIVE_DEST_2 is using asynchronous network I/O
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LNSb started with pid=46, OS id=3821
LNS1 started with pid=47, OS id=3825
Sun Dec 25 17:24:47 2011
Thread 1 advanced to log sequence 24
Sun Dec 25 17:24:47 2011
ARCr: Becoming the 'no FAL' ARCH
ARCr: Becoming the 'no SRL' ARCH
Sun Dec 25 17:24:47 2011
ARCo: Becoming the heartbeat ARCH
Sun Dec 25 17:24:47 2011
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 23-23
DBID 1869375944 branch 770735888
Sun Dec 25 17:24:47 2011
LGWR: Waiting for ORLs to be archived...
Sun Dec 25 17:24:48 2011
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
LNS: Standby redo logfile selected for thread 1 sequence 24 for destination LOG_ARCHIVE_DEST_2
Sun Dec 25 17:24:50 2011
LGWR: ORLs successfully archived
Thread 1 opened at log sequence 24
Current log# 2 seq# 24 mem# 0: /u01/app/oracle/oradata/myoracle/redo02.log
Successful open of redo thread 1
Sun Dec 25 17:24:50 2011
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Dec 25 17:24:52 2011
ARCp: Standby redo logfile selected for thread 1 sequence 23 for destination LOG_ARCHIVE_DEST_2
Sun Dec 25 17:24:52 2011
Successfully onlined Undo Tablespace 1.
备库警告日志
-------------------------------------------------------------
Sun Dec 25 17:47:06 2011
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[9]: Assigned to RFS process 16093
RFS[9]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 16372
RFS[10]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[10]: Successfully opened standby log 5: '/u01/app/oracle/oradata/myoracle/stdby_redo05.log'
Sun Dec 25 17:47:16 2011
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[11]: Assigned to RFS process 16374
RFS[11]: Identified database type as 'physical standby'
RFS[11]: Successfully opened standby log 4: '/u01/app/oracle/oradata/myoracle/stdby_redo04.log'
Sun Dec 25 17:47:29 2011
Media Recovery Log /u01/app/oracle/arch/1_24_770735888.arc
Media Recovery Waiting for thread 1 sequence 25 (in transit)
由于他的备库有standby_redolog,排除了备库缺少standby_redolog导致切换最大可用模式的原因，
看他的警告日志似乎看不出什么问题，那位网友也说警告日志没有报错，其实不然,主库的警告日志已经明显提示了
LGWR: STARTING ARCH PROCESSES COMPLETE
ARCt started with pid=45, OS id=3819
Sun Dec 25 17:24:33 2011
LGWR: Primary database is in MAXIMUM AVAILABILITY mode
这两条信息提示
LGWR: Destination LOG_ARCHIVE_DEST_2 is using asynchronous network I/O
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
由于他使用的是async传输模式，因此即使主库切换至最大可用备库依旧是最大性能模式
建议他重新做一次模式切换，在主库上执行以下SQL，要注意相应的service与db_uniquename保证正确
SQL>alter system set log_archive_dest_2='SERVICE=??? LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=???'
SQL>alter database set standby database to maximize availability;
SQL>shutdown immediate
SQL>startup
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
网友问我这几句为什么要执行？
日志的传输以及应用可以算作是Dataguard的核心所在.在我们搭建DG的过程中,如何配置优化日志传输服务,关系到整个DG体系的性能以及可用性.而且,
不同的保护模式也需要不用的参数组合.10g下,影响配置日志传输的参数主要有以下几个:
1. ARCH/LGWR
设置日志的传送模式,默认使用arch传送.传送发生在日志切换边沿,最大可用和最大保护模式下,需要使用lgwr来传送日志.使用lgwr传送日志,需要备库建立standby logfile,并且支持日志的实时应用.
2. SYNC /ASYNC
该参数表示网络I/O的操作方式, SYNC表示网络I/O将与重做日志的写入同步进行,等待网络i/o完成收到响应后继续下一个写操作.而ASYNC表示日志的传送是异步的,oracle利于LNS进程,接收lgwr发送过来的重做日志信息放入缓冲区,并异步传送到备机,也可以手动指定缓冲区的大小
最大保护和最大可用模式下,需要设置为SYNC AFFIM模式.
3. AFFIM/NOAFFIRM
该参数是LGWR传送模式下的一个属性,表示重做日志的磁盘I/O模式, AFFIM表示同步并且发送成功写操作状态到主数据库, NOAFFIRM表示主库无需等待备库的日志写成功.
4. MANDATORY /OPTIONAL
该参数表示归档的模式,默认值为OPTIONAL. MANDATORY表示强制归档,如果归档不成功会引起主库的归档等待.
5. REOPEN/NOREOPEN
该参数表示归档文件收到错误信息后,是否重试以及重试的最小间隔时间.
6. MAX_FAILURE/ NOMAX_FAILUR
该参数表示由于故障而被关闭的目标文件的最大重试次数.超过设定次数,将不再重试.
...........................................................................