ORA-16047: DGID mismatch between destination setting and standby

 

本文转自：
http://jzhil2004.blog.163.com/blog/static/275585042010112911625896/

感谢原作者.

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;

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

[@more@]