LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
2011-12-26 08:50
330 查看
群里有人提问说刚搭建的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 ***AILABILITY 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 ***AILABILITY 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 ***AILABILITY MAXIMUM ***AILABILITY 网友问我这几句为什么要执行? 日志的传输以及应用可以算作是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 该参数表示由于故障而被关闭的目标文件的最大重试次数.超过设定次数,将不再重试. ...........................................................................
相关文章推荐
- Eclipse. The archive which is referenced by the classpath, does not exist
- HTTP Status 405 - HTTP method GET is not supported by this URL
- Eclipse下启动tomcat报错:/bin/bootstrap.jar which is referenced by the classpath, does not exist.
- operation category read is not supported in state standby
- Archive for required library:xxxxx/spring-beans-3.2.4.RELEASE.jar in project XXXXX cannot be read or is not a valid ZIP file
- JQuery 的 ajax 出现Origin null is not allowed by Access-Control-Allow-Origin 解决方法
- "package gcc-4.4 is not available, but is referred to by another package", 安装gcc时出错的解决方法
- 【Vegas原创】ORA-16040 standby destination archive log file is locked解决
- "make_path" is not exported by the File::Path modul
- 挂载磁盘的问题(/dev/sdb1 is apparently in use by the system; will not make a 文件系统 here!)
- HTTP method GET is not supported by this URL
- XMLHttpRequest cannot load – Origin is not allowed by Access-Control-Allow-Origin.
- 解决Ajax跨域问题:Origin xx is not allowed by Access-Control-Allow-Origin
- session_start():Session data file is not created by your uid
- Project type is not supported by installation! 项目类型不能打开!
- The encryption certificate of the relying party trust identified by thumbprint is not valid
- Project facet Java 1.8 is not supported by target runtime Apache Tomcat v7.0.
- the Project type is not supported by installation 项目类型不能正确加载
- The data directory was initialized by PostgreSQL version 9.6, which is not compatible with this version 10.0.
- HTTP method GET is not supported by this URL