注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

常在心

淡泊明志,人生自在

 
 
 

日志

 
 

ORA-16047: DGID mismatch between destination setting and standby  

2010-12-29 11:08:39|  分类: oracle问题 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

ORA-16047: DGID mismatch between destination setting and standby
一般是由于主库上log_archive_dest_?参数设置的db_unique_name和实际备库上设置的db_unique_name不一致引起

处理过程:
1)由于之前的standby备机是可以应用日志的,后面由于机房停电,在关闭主从的时候,先关闭主,然后再关闭从,可是当时关闭了主以后,由于从库已经非法停了,类似于停电,后面进行主从库重新开启应用的时候,过程如下:
从库:
startup mount;
alter database recover managed standby database disconnect from session;

主库:
startup;

可是在主库的alter_SID.log发现了这个错误,于是我进行如下的命令:
主库:
alter system switch logfile;

然后检查主从库中归档路径的目录,发现主库不会传日志到从库,更谈不上应用,可是当时一直以为是从库的db_unique_name参数和归档应用进程mrp的问题,于是我在从库上进行如下的操作:
从库:
alter database recover managed standby database cancel
shutdown immediate;
startup mount;
alter database db_unique_name=bladebak scope=both;
alter database recover managed standby database disconnect from session;

可是再在主库上查询的时候,发现错误仍然存在,于是切换日志,可是在告警alter_SID.log中不存在那个错误,可是在主库进行如下的查询却仍然存在,日志也传输不到备库:
主库:
select dest_id,status,destination,error from v$archive_dest where dest_id<=5;

当时非常苦恼,查看网上的很多资料,都说是主库中log_archive_dest_2参数对应的db_unique_name和从库的db_unique_name不一致造成,于是详细检查下了主从库关于initSID.ora的参数文件,但是仔细想一下,在停电前,日志归档都停好的,而且传输到备库应用也没有出现过问题,为什么现在就不行了?

于是怀疑是主库的传输归档日志的进程已经僵死造成,由于我是采用physical standby的模式,传输归档日志到备库也是采用ARCn进程负责传送,肯定是归档进程还有主库的log_archive_dest_2参数的问题,于是进行如下的操作:
主库:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=bladebak LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bladebak' SCOPE=BOTH;
再用命令检查,其中dest_id=2对应的status变成DEFERRED - Manually disabled by the user,意思是用户手工修改成不可用
select dest_id,status,destination,error from v$archive_dest where dest_id<=5;
于是再进行如下的操作,status变成status
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
alter system switch logfile;

马上切换到从库查看归档日志,已经传输过去,因为之前缺失的有些归档日志,我手工copy过去,并手工应用的,下面是手工copy的过程和应用日志的过程
主库:
1)查询未应用在备库的日志
SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#)
LAST_SEQ_SENT FROM
V$ARCHIVED_LOG R, V$LOG L WHERE R.DEST_ID=2 AND L.ARCHIVED='YES';

2)查询这些归档日志的路径
SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1
AND SEQUENCE# BETWEEN 191 AND 202;

3)检查备库中那些归档没有传输过去,并copy

从库:
1)手工应用这些没有归档的日志
alter database recover managed standby database cancel;

alter database register logfile '/u03/arclog/1_9208_2348249.dbf';   --其它的也一样

但如果是很多归档没有应用的话,会麻烦很多,可以采用如下的办法进行应用:
alter database recover managed standby database cancel;
alter database recover automatic standby database;    --自动将那些归档日志应用进去,有错误看下是不是还没有归档的日志,是的话,就不用理会,继续进行如下的操作

alter database recover managed standby database disconnect from session;

2)检查日志的应用情况
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME,APPLIED FROM
V$ARCHIVED_LOG ORDER BY SEQUENCE#

注意:如果出现有NO的情况,先取消应用,然后再打开应用,就会看到YES
alter database recover managed standby database cancel;

alter database recover managed standby database disconnect from session;

通过这次的问题,让我明白了一个道理,就是一定要把问题定位清楚了再详细进行应该的操作,这次的问题,之前一直怀疑是从库那边的问题,但最后才定位到是主库的问题,但其实仔细想想,在手工应用归档日志的过程中,其它也没有什么错误,最大的可能还是出现在主库上


 
 

  评论这张
 
阅读(1118)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018