模拟一次failover

1.停掉备库的listener

[oracle@rhel132~]$ lsnrctl stop

 

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

SQL>shutdown immediate;

Database closed.

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

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

       122 YES YES YES

       122 NO YES NO

       123 NO YES NO

       124 NO YES NO

       125 NO YES NO

       126 NO YES NO

 

215 rows selected.

查看一下备库的归档信息：

SQL>select sequence#,standby_dest,archived,applied from v$archived_log;

SEQUENCE# STAARC APP

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

       116 NO YES YES

       117 NO YES YES

       118 NO YES YES

       119 NO YES YES

       120 NO YES YES

       121 NO YES YES

       122 NO YES YES

 

128 rowsselected.

 

说明还有四个archivelog没有同步过来。

 

此进的主库alert信息如下：

Thread 1advanced to log sequence 127

  Current log# 3 seq# 127 mem# 0:/u01/app/oracle/oradata/orcl/redo03.log

 

 

4.现在模拟主库出现异常，做failover的操作.

在备库查询看有没有gap：

SQL> select* from v$archive_gap;

 

no rowsselected

 

如果有gap的话需要将缺的log复制过来，并register到备库中。

 

5.比较主库和备库的archivelog，把缺少的log复制到备库。

 

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

oracle@172.17.61.132'spassword:

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

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

oracle@172.17.61.132'spassword:

1_124_793805797.dbf                              100%   57KB 56.5KB/s   00:00

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

oracle@172.17.61.132'spassword:

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

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

oracle@172.17.61.132'spassword:

1_126_793805797.dbf                              100% 2048     2.0KB/s  00:00

 

在备库中将上面四个log应用到数据库：

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

 

Databasealtered.

 

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

 

Databasealtered.

 

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

 

Databasealtered.

 

SQL>  alter database register logfile'/tmp/1_126_793805797.dbf';

 

Databasealtered.

 

  6.所有的archive log都应用到备库后，最后需将redo log也复制到备库做recover

 

[oracle@rhel131orcl]$ scp redo* 172.17.61.132:/tmp

 

在做recover之前需要结束应用日志的状态：

SQL> alterdatabase recover managed standby database cancel;

 

Databasealtered.

 

SQL> recoverstandby database until cancel;

ORA-00279:change 603271 generated at 08/06/2013 13:52:08 needed for thread 1

ORA-00289:suggestion :

/u01/app/oracle/oradata/orcl/archivelog/1_127_793805797.dbf

ORA-00280:change 603271 for thread 1 is in sequence #127

 

 

Specify log:{<RET>=suggested | filename | AUTO | CANCEL}

/tmp/redo03.log

Log applied.

Media recoverycomplete.

 

由于从主库的alert日志上看到的第127号日志是redo03.log产生的，所以需要恢复redo03.log的信息。

 

7.最后变换standby库的角色，将其变成主库并正常打开。

 

SQL> alterdatabase activate standby database;

 

Databasealtered.

 

SQL> alterdatabase open;

 

Databasealtered.

 

SQL> selectdatabase_role,open_mode from v$database;

 

DATABASE_ROLE    OPEN_MODE

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

PRIMARY          READ WRITE

 

SQL> archivelog list;

Database logmode              Archive Mode

Automaticarchival             Enabled

Archivedestination           /u01/app/oracle/oradata/orcl/archivelog/

Oldest onlinelog sequence     1

Next logsequence to archive   2

Current logsequence           2

 

现在这台数据库跟之前的主库已没有任何关系了，并且redo log也从1号开始编了。