模拟物理standby产生GAP的情形

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_793805797.dbf'

Tue Aug  6 11:24:30 2013

Fetching gap sequence in thread 1, gap sequence107-110

 

Tue Aug  6 11:25:00 2013

FAL[client]: Failedto request gap sequence

 GAP - thread 1 sequence 107-110

 DBID 1321586530 branch 793805797

FAL[client]: All defined FAL servers have beenattempted.

 

通过查询备库的视图也可以获得信息：

 

SQL> select* from v$archive_gap;

 

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

         1           107            110

 

7.现在开始做恢复，将主库的日志给copy过来，并注册到备库：

[oracle@rhel131archivelog]$ scp 1_107_793805797.dbf.bk 172.17.61.132:/tmp         oracle@172.17.61.132's password:

1_107_793805797.dbf.bk                           100% 1024     1.0KB/s  00:00

[oracle@rhel131archivelog]$ scp 1_108_793805797.dbf.bk 172.17.61.132:/tmp

oracle@172.17.61.132'spassword:

1_108_793805797.dbf.bk                           100%   75KB 74.5KB/s   00:00

[oracle@rhel131archivelog]$ scp 1_109_793805797.dbf.bk 172.17.61.132:/tmp

oracle@172.17.61.132'spassword:

1_109_793805797.dbf.bk                           100% 4608     4.5KB/s  00:00

[oracle@rhel131archivelog]$ scp 1_110_793805797.dbf.bk 172.17.61.132:/tmp

oracle@172.17.61.132'spassword:

1_110_793805797.dbf.bk                           100% 2560     2.5KB/s  00:00

 

SQL> alterdatabase register logfile '/tmp/1_107_793805797.dbf.bk';

 

Databasealtered.

 

SQL> alterdatabase register logfile '/tmp/1_108_793805797.dbf.bk';

 

Databasealtered.

 

SQL> alterdatabase register logfile '/tmp/1_109_793805797.dbf.bk';

 

Databasealtered.

 

SQL> alterdatabase register logfile '/tmp/1_110_793805797.dbf.bk';

 

Databasealtered.

 

8.此时的备库信息：

alter databaseregister logfile '/tmp/1_107_793805797.dbf.bk'

Tue Aug  6 11:43:28 2013

There are 1logfiles specified.

ALTER DATABASEREGISTER [PHYSICAL] LOGFILE

Completed:alter database register logfile '/tmp/1_107_793805797.dbf.bk'

Tue Aug  6 11:43:30 2013

Media RecoveryLog /tmp/1_107_793805797.dbf.bk

Media RecoveryWaiting for thread 1 sequence 108

Fetching gapsequence in thread 1, gap sequence 108-110

Tue Aug  6 11:43:42 2013

alter databaseregister logfile '/tmp/1_108_793805797.dbf.bk'

Tue Aug  6 11:43:42 2013

There are 1logfiles specified.

ALTER DATABASEREGISTER [PHYSICAL] LOGFILE

Completed:alter database register logfile '/tmp/1_108_793805797.dbf.bk'

Tue Aug  6 11:43:49 2013

alter databaseregister logfile '/tmp/1_109_793805797.dbf.bk'

There are 1logfiles specified.

ALTER DATABASEREGISTER [PHYSICAL] LOGFILE

Completed:alter database register logfile '/tmp/1_109_793805797.dbf.bk'

Tue Aug  6 11:43:56 2013

alter databaseregister logfile '/tmp/1_110_793805797.dbf.bk'

Tue Aug  6 11:43:56 2013

There are 1logfiles specified.

ALTER DATABASEREGISTER [PHYSICAL] LOGFILE

Completed:alter database register logfile '/tmp/1_110_793805797.dbf.bk'

Tue Aug  6 11:44:00 2013

Media RecoveryLog /tmp/1_108_793805797.dbf.bk

Media RecoveryLog /tmp/1_109_793805797.dbf.bk

Media RecoveryLog /tmp/1_110_793805797.dbf.bk

Media RecoveryLog /u01/app/oracle/oradata/orcl/archivelog/1_111_793805797.dbf

Media RecoveryLog /u01/app/oracle/oradata/orcl/archivelog/1_112_793805797.dbf

Media RecoveryLog /u01/app/oracle/oradata/orcl/archivelog/1_113_793805797.dbf

Media Recovery Waiting for thread 1 sequence 114(in transit)

 

说明已应用了所有的归档日志。