ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-16401: archivelog rejected by RFS

ORA-16401: archivelog rejected by RFS

原创 Linux操作系统 作者:杨奇龙 时间:2011-08-10 14:23:25 0 删除 编辑
早上检查邮件的时候发现有ORA-16401: archive log rejected by Remote File Server (RFS)报警邮件!
通常此问题是由于主库的fal_client参数与备库的log_archive_dest_n中的service参数不匹配造成的。
模拟一下环境(案例来自metalink [ID 1183143.1])
********* Primary ********
log_archive_config DG_CONFIG=(p1ncm1,p1ncm2)
log_archive_dest_1 location=/u99/ORACLE/p1ncm1/archive valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=p1ncm1
log_archive_dest_2 service=p1ncm2_dgfal.csm.fub.com optional reopen=60 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=p1ncm2
fal_client=p1ncm1_fc.csm.fub.com
fal_server=p1ncm2_fs.csm.fub.com 

********* Standby ********
log_archive_config DG_CONFIG=(p1ncm1,p1ncm2)
log_archive_dest_1 location=/u99/ORACLE/p1ncm2/archive valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=p1ncm2
log_archive_dest_2 service=p1ncm1_dgfal.csm.fub.com optional reopen=60 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=p1ncm1
fal_client=p1ncm2_fc.csm.fub.com
fal_server=p1ncm1_fs.csm.fub.com
注意:从以上的配置中可以看出主库的fal_client=p1ncm1_fc.csm.fub.com,与备库中的LAD_2 中的service=p1ncm1_dgfal.csm.fub.com的值不一样。也正是此问题导致ORA-16041..
--- 主库告警日志 alert_p1ncm1.log ---
ARC0 started with pid=14, OS id=23650
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE ---启动归档日志进程arc0,arc1
ARC1 started with pid=15, OS id=23652
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Thread 1 opened at log sequence 4722
ARC1: Becoming the heartbeat ARCH
.....skipping ....
ALTER SYSTEM SET log_archive_trace=1 SCOPE=BOTH; <<--------- 启动跟踪文件功能
ALTER SYSTEM ARCHIVE LOG <<-----切换归档
Thread 1 cannot allocate new log, sequence 4938
Private strand flush not complete
.....skipping ....
Thread 1 advanced to log sequence 4939 (LGWR switch)
.....skipping ....
ALTER SYSTEM ARCHIVE LOG
ARCH: Evaluating archive log 3 thread 1 sequence 4939
Thread 1 advanced to log sequence 4940 (LGWR switch)
Current log# 4 seq# 4940 mem# 0: /u04/ORACLE/p1ncm1/p1ncm1.redo.g04.m01.rdo
Current log# 4 seq# 4940 mem# 1: /u01/ORACLE/p1ncm1/p1ncm1.redo.g04.m02.rdo
ARCH: Destination LOG_ARCHIVE_DEST_2 archival not expedited
ARCH: Beginning to archive thread 1 sequence 4939 (7809558586167-7809568175169) (p1ncm1)
ARCH: Creating local archive destination LOG_ARCHIVE_DEST_1: '/u99/ORACLE/p1ncm1/archive/p1ncm1.arch.4939.1.673712453.log' (thread 1 sequence 4939)
(p1ncm1)<<--归档日志到本地

ARC0: Evaluating archive log 3 thread 1 sequence 4939
ARC0: Unable to archive thread 1 sequence 4939
Log actively being archived by another process
ARCH: Closing local archive destination LOG_ARCHIVE_DEST_1: '/u99/ORACLE/p1ncm1/archive/p1ncm1.arch.4939.1.673712453.log'
(p1ncm1)
Committing creation of archivelog '/u99/ORACLE/p1ncm1/archive/p1ncm1.arch.4939.1.673712453.log'
Invoking non-expedited destination LOG_ARCHIVE_DEST_2 thread 1 sequence 4939 host p1ncm2_dgfal.csm.fub.com
Wed Aug 11 00:00:58 2010
ARCH: Completed archiving thread 1 sequence 4939 (7809558586167-7809568175169) (p1ncm1)
Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid
FAL[server, ARC1]: Begin FAL noexpedite archive (dbid 0 branch 673712453 thread 1 sequence 4939 dest p1ncm2_dgfal.csm.fub.com)
ARC1: Creating remote archive destination LOG_ARCHIVE_DEST_2: 'p1ncm2_dgfal.csm.fub.com' (thread 1 sequence 4939)
(p1ncm1)
Wed Aug 11 00:01:19 2010
ARC1: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'p1ncm2_dgfal.csm.fub.com'
(p1ncm1)
FAL[server, ARC1]: Complete FAL noexpedite archive (dbid 0 branch 673712453 thread 1 sequence 4939 destination p1ncm2_dgfal.csm.fub.com) <<--- arc1 completed remote archival of seq# 4939 to destination "p1ncm2_dgfal.csm.fub.com"
FAL[server, ARC1]: Begin FAL archive (dbid 0 branch 673712453 thread 1 sequence 4939 dest p1ncm2_fc.csm.fub.com)
ARC1: Creating remote archive destination LOG_ARCHIVE_DEST_1: 'p1ncm2_fc.csm.fub.com' (thread 1 sequence 4939) <<<<--- arc1 again attempts to create same log seq# 4939 to destination "p1ncm2_fc.csm.fub.com" by means of FAL resolution
(p1ncm1)
Errors in file /u00/oracle/admin/p1ncm1/bdump/p1ncm1_arc1_23652.trc:
ORA-16401: archivelog rejected by RFS
FAL[server, ARC1]: Complete FAL archive (dbid 0 branch 673712453 thread 1 sequence 4939 destination p1ncm2_fc.csm.fub.com)
alter database backup controlfile to trace
Completed: alter database backup controlfile to trace
ALTER SYSTEM ARCHIVE LOG
Thread 1 cannot allocate new log, sequence 4941
Private strand flush not complete

********* Standby ********
log_archive_config DG_CONFIG=(p1ncm1,p1ncm2)
log_archive_dest_1 location=/u99/ORACLE/p1ncm2/archive valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=p1ncm2
log_archive_dest_2 service=p1ncm1_dgfal.csm.fub.com optional reopen=60 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=p1ncm1
fal_client p1ncm2_fc.csm.fub.com
fal_server p1ncm1_fs.csm.fub.com
---备库告警日志  alert_p1ncm2.log ---
ALTER SYSTEM SET log_archive_trace=1 SCOPE=BOTH;

Media Recovery Waiting for thread 1 sequence 4939
RFS[2]: Begin archive primary thread 1 sequence 4939 (p1ncm2)
RFS[2]: No standby redo logfiles created
RFS[2]: Completed archive primary log 0 thread 1 sequence 4939 (p1ncm2)
RFS[2]: Archived Log: '/u99/ORACLE/p1ncm2/archive/p1ncm1.arch.4939.1.673712453.log'
Committing creation of archivelog '/u99/ORACLE/p1ncm2/archive/p1ncm1.arch.4939.1.673712453.log'
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[14]: Assigned to RFS process 32487
RFS[14]: Identified database type as 'physical standby'

RFS[14]: Begin archive primary thread 1 sequence 4939 (p1ncm2)
Errors in file /u00/oracle/admin/p1ncm2/udump/p1ncm2_rfs_32487.trc:
ORA-16401: archivelog rejected by RFS
Media Recovery Log /u99/ORACLE/p1ncm2/archive/p1ncm1.arch.4939.1.673712453.log
原因:错误的fal_client命名。
主库派分指定的log到log_archive_dest_2=p1ncm2_dgfal.csm.fub.com指定的目的地址,备库可以自己做日志间断分析并且根据实际情况向FAL_SERVERS请求间断日志。FAL servers 这个案例中是primary库,会接受请求并传送间断日志。当standby尝试解决日志间断问题时,主库得到一个不同的fal_client=p1ncm1_fs.csm.fub.com。实际上p1ncm2_dgfal.csm.fub.com and p1ncm1_fs.csm.fub.com 指向同一个备库。如果我们在备库上设置一个与主库上的LADn不同的tns别名,ORA-16401就会发生。
如果TNS别名匹配正确,那么我们就可以看见standby发出的FAL 请求和正常的LADn 派分的redo的FAL 请求一样,这样就不会有创建第二个FRB(FAL Request Block)
这样,ORA-16401就不会发生了。
在oracle 11gr2中oracle 明确地指出FAL_CLIENT 是可选的并且不应该被使用。
标识:LADn=log_archive_dest_n

解决办法:

设置主库上的 log_archive_dest_n的指向备库中的地址使用和备库上的 fal_client 配置一样的tns 别名。
--- 主库 ---
log_archive_dest_2 service=p1ncm2_dgfal.csm.fub.com optional reopen=60 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=p1ncm2
alter system set fal_client=p1ncm1_dgfal.csm.fub.com scope=both sid='*';
--- 备库 ---
当前的值:
fal_client=p1ncm2_fc.csm.fub.com
推荐的值:
alter system set fal_client=p1ncm2_dgfal.csm.fub.com scope=both sid='*'; ## same as primary's LAD_2

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22664653/viewspace-704589/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
MySQL DBA NoSQL DEVOPS

注册时间:2009-10-07

  • 博文量
    1026
  • 访问量
    7717783