当前位置：首页 -> 基础 -> 数据库编程

模拟物理standby产生GAP的情形(一)

2014-11-24 11:46:45 · 作者: · 浏览: 0
标签: 模拟 物理 standby 产生 GAP 情形
模拟物理standby产生GAP的情形
dataguardOracledatabase 数据库
gap的产生可能是由于归档文件太大，或者网络不稳定，导致部分归档无法传到standby上。
一般处理的方法：
-加入compression参数 
    log_archive_dest_2='SERVICE=orcl_standby ASYNC COMPRESSION=ENABLE'

  -MAX_CONNECTIONS

    log_archive_dest_2='SERVICE=orcl_standby ASYNC MAX_CONNECTIONS=3'

下面是模拟出现gap后的情形以及如何处理的。
1.停掉备库的listener 
[oracle@rhel132~]$ lsnrctl stop

2.主库需要重启一下（不重启的话，即使备库关闭了监听器，由于主库和备库之间的通信还是没有断，是长连接的原故吧），之后再做几次switch logfile: 
SQL>shutdown immediate;

Databaseclosed.

Databasedismounted.

ORACLE instanceshut down.

SQL> startup

ORACLE instancestarted.



Total SystemGlobal Area  281018368 bytes

Fixed Size                  1218944 bytes

VariableSize             100664960 bytes

DatabaseBuffers          171966464 bytes

RedoBuffers                7168000 bytes

Databasemounted.

Databaseopened.

SQL> altersystem switch logfile;



System altered.

SQL> altersystem switch logfile;

System altered.

SQL> altersystem switch logfile;

System altered.

3.在主库查看归档信息： 
SQL>select sequence#,standby_dest,archived,applied from v$archived_log;

SEQUENCE# STAARC APP

---------- ------ ---

       103 NO YES NO

       104 YES YES NO

       104 NO  YES NO

       105 YES YES YES

       105 NO YES NO

       106 YES YES YES

       106 NO YES NO

       107 NO YES NO

       108 NO YES NO

       109 NO YES NO

       110 NO YES NO



187rows selected.

在备库也查询一下： 
SQL>select sequence#,standby_dest,archived,applied from v$archived_log;



SEQUENCE# STAARC APP

---------- ------ ---

        94 NO YES YES

        95 NO YES YES

        96 NO YES YES

        97 NO YES YES

        98 NO YES YES

        99 NO YES YES

       100 NO YES YES

       101 NO YES YES

       102 NO YES YES

       103 NO YES YES

       104 NO YES YES



 SEQUENCE# STA ARC APP

---------- ------ ---

       105 NO YES YES

       106 NO YES YES



112rows selected.

这是应该是缺少了107~110的归档。
备库的日志文件也是等待107号归档：
Tue Aug 6 11:08:04 2013
Media RecoveryLog /u01/app/oracle/oradata/orcl/archivelog/1_106_793805797.dbf
Media Recovery Waiting for thread 1 sequence 107
4.如何模拟gap呢，由于无法模拟日志文件太大和网络不稳定，只有将主库的这几个日志给改名，使无法同步到备库。
在主库： 
[oracle@rhel131~]$ cd /u01/app/oracle/oradata/orcl/archivelog/



[oracle@rhel131archivelog]$ mv 1_107_793805797.dbf 1_107_793805797.dbf.bk

[oracle@rhel131archivelog]$ mv 1_108_793805797.dbf 1_108_793805797.dbf.bk

[oracle@rhel131archivelog]$ mv 1_109_793805797.dbf 1_109_793805797.dbf.bk

[oracle@rhel131archivelog]$ mv 1_110_793805797.dbf 1_110_793805797.dbf.bk

5.这时可以将备库的监听打开： 
[oracle@rhel132~]$ lsnrctl start

6.在主库做几次switchlogfile: 
SQL> altersystem switch logfile;



System altered.



SQL>  alter system switch logfile;



System altered.

过了一会儿，备库的日志如下，说明新的arch同步到来了，而缺少了107-110的日志。
Tue Aug 6 11:24:28 2013
Redo ShippingClient Connected as PUBLIC
-- ConnectedUser is Valid
RFS[5]:Assigned to RFS process 4084
RFS[5]:Identified database type as 'physical standby'
RFS[5]:Archived Log: '/u01/app/oracle/oradata/orcl/archivelog/1_111_793805797.dbf'
RFS[5]:Archived Log: '/u01/app/oracle/oradata/orcl/archivelog/1_112_7938