DG日志不应用，GAP,主备切换解决思路与办法

环境ORACLE 10G OS WINDOWS

对于DG故障解决思路，DG日志切换不进行应用，DG出现GAP解决方法，DG主备库切换，

当DG出现故障时，第一时间检测alert日志，服务器OS日志,网络是否通畅。

1、当DG出现日志不能传输到备库
   一、TNS配置错误，监听配置错误。
   二、主备库初始化参数文件配置错误（如archive_log_dest文件位置错误)。
   三、备库控制文件过旧，从主库生成一个STANDBY CONTROL过去。 
       SQL> alter database create standby controlfile as 'c:\control01.ctl';。
   四、备库是否应用了Failovers 。 
               
下面模拟备库应用了Failovers 。
备库执行
SQL>  alter database recover managed standby database finish; 

Database altered.

备库：

SQL> select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;


PROTECTION_MODE      OPEN_MODE            DB_UNIQUE_NAME                 DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- -------------------- ------------------------------ ---------------- --------------------
MAXIMUM PERFORMANCE  READ ONLY            PRIMARY                        PHYSICAL STANDBY TO PRIMARY      


主库：

SQL> select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;

PROTECTION_MODE      OPEN_MODE            DB_UNIQUE_NAME                 DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- -------------------- ------------------------------ ---------------- --------------------
MAXIMUM PERFORMANCE  READ WRITE           STANDBY                          PRIMARY          SESSIONS ACTIVE

主库alert文件：

ARC1: All Archive destinations made inactive due to error 394
ARC1: Failed to archive thread 1 sequence 1 (394)
ARCH: Archival stopped, error occurred. Will continue retrying
Wed Oct 30 10:25:54 2013
Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arc1_1236.trc:
ORA-16038: log 2 sequence# 1 cannot be archived
ORA-00394: online log reused while attempting to archive it
ORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'


ARC1: All Archive destinations made inactive due to error 394
*** 2013-10-30 10:25:54.796 58942 kcrr.c
kcrrfail: dest:1 err:394 force:0 blast:1
*** 2013-10-30 10:25:54.828 20146 kcrr.c
ORA-16038: log 2 sequence# 1 cannot be archived
ORA-00394: online log reused while attempting to archive it
ORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'
*** 2013-10-30 10:27:54.734
*** 2013-10-30 10:27:54.734 20146 kcrr.c
*** 2013-10-30 10:28:54.765
kcrrwkx: work to do 0x1 (start)
*** 2013-10-30 10:28:54.781 20146 kcrr.c

这个时候导致主库不再向备库传送日志了,我们只需要重建STANDBY控制文件就行

SQL> alter database create standby controlfile as 'c:\control01.ctl';。

其中当真正主库出现故障的Failovers的时候

一.查看是否有日志GAP,没有应用的日志： ­
    SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; 
　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 
　　如果有，则拷贝过来并且注册 
    SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径'; 
    重复查看直到没有应用的日志： 
二. 然后停止应用归档： 
　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 
三. 下面将STANDBY数据库切换为PRIMARY数据库：
　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; 
    或 
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; 
　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE; 
　　DATABASE_ROLE 
　　---------------- 
　　PHYSICAL STANDBY 
　　SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 


2、日志传输到备库不能应用。


 一、是否产生了GAP 拷贝缺失的日志重新注册日志，如果GAP缺失的归档日志过多，切归档日志已经删除了，那就必须重新搭建DG。

 二、是否设置了REDO延迟

下面就简单说说手工处理日志GAP的步骤：
1、在备库检查是否有日志缺失
SQL> select * from V$ARCHIVE_GAP;

2、在主库中查询缺失的日志的所在路径和名称

SQL> SELECT NAME FROM V$ARCHIVED_LOG 

如果把日志移动到其他路径，则把日志所在路径换成当前实际所在路径。

3、把日志拷贝到备库上

4、在备库上手工注册上一步中从主库拷贝来的日志
SQL> ALTER DATABASE REGISTER LOGFILE '路径';

5、观察备库的alert日志信息

6、检查备库是否还有日志GAP

SQL> select * from V$ARCHIVE_GAP;

no rows selected

如果有行返回，则重复2-5步，直到查询结果是"no rows selected"。

如果日志只是临时移动到其他地方，过后会再移回原路径，则不用这么大费周折手工去手工处理了，把日志拷回原处后FAL会自动处理GAP。

3、DG主备库切换

主库： ­
1. 查看switchover 状态 ­
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; ­
      to standby 

2 切换成备库 
如果上面的结果不是to standby 还有会话运行
SQL>Alter database commit to switchover to physical standby with session shutdown; 
否则直接
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; 
     Database altered. 
3 启动到mount和应用日志状态 
SQL> SHUTDOWN IMMEDIATE 
SQL> startup nomount; 
SQL> alter database mount standby database; 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 
4. 查看数据库模式 
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status; 
SQL>select status,database_mode from v$archive_dest_status; 
备库： 
1.查看switchover状态 ­
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; 
    TO PRIMARY 
2. 切换成主库 
如果上面的结果不是to PRIMARY 还有会话运行
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown 
否则
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 
Database altered. 
SQL> shutdown immediate; 
SQL> startup; 
SQL> alter system switch logfile; 
3. 查看数据库模式 
SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_status; 
SQL>select status,database_mode from v$archive_dest_status; 


至此，DG相关简单问题全部以列出。