Standby数据库维护

以下命令均在Standby端执行

1．如果是使用ARCH传递redo数据，那么执行以下命令：

检查是否有gap archive

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

如果有则register

ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

实行Failover：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE ACTIVATE STANDBY DATABASE;

ALTER DATABASE MOUNT;

ALTER DATABASE OPEN;

2．如果是使用LGWR传递redo数据，那么执行以下命令：

检查是否有gap archive

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

如果有则register

ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

如果是由于网络问题而导致需要切换，那么通常standby端的RFS进程并不会意识到primary已经不可访问，所以RFS进程也不会释放当前的standby redo log文件。

如果是primary端的数据库实例由于故障中断，那么一般情况下standby端的RFS进程会立刻意识到primary已经不可访问，也就会立刻释放当前的standby redo log文件。

只要RFS进程没有释放standby redo log文件，那么执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH命令就会在alertlog文件中发现如下的报错信息

Warning: log 4 of thread 1 is being archived or modified

Recovery interrupted.

Media Recovery failed with error 261

如果在报上述错误的时候，执行SWITCH，那么将会出现下面的错误：

ORA-16139: media recovery required

所以必须检查alertlog文件，直到发现如下信息才表示RFS进程已经释放了standby redo log文件，这时候才可以作FINISH：

RFS: Possible network disconnect with primary database

促使RFS进程释放standby redo log 文件有两种方法：

              1． 等待RFS进程的network timeout，通常需要等待8分钟左右

              2． 关闭standby数据库，再重新开启，这样会强制RFS进程释放standby redo log

 

我们可以通过v$managed_standby视图来监控RFS进程何时释放

实行Failover：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

alertlog中将显示如下信息，表示finish成功：

Terminal Incomplete Recovery: UNTIL CHANGE 3738452

Terminal Incomplete Recovery: End-Of-Redo log allocation

Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 8772

TERMINAL RECOVERY changing datafile format version from 8.0.0.0.0 to

9.0.0.0.0

Switching logfile format version from 8.0.0.0.0 to 9.0.0.0.0

Terminal Incomplete Recovery: clearing standby redo logs.

Terminal Incomplete Recovery: thread 1 seq# 8772 redo required

Terminal Incomplete Recovery: End-Of-Redo log /global/oradata/ctsdb/stdby_redo04.log

Identified end-of-REDO for thread 1 sequence 8772

Terminal Incomplete Recovery: end checkpoint SCN 3738453

Media Recovery Complete

Switching logfile format version from 9.0.0.0.0 to 8.0.0.0.0

Terminal Incomplete Recovery: successful completion

Begin: Wait for standby logfiles to be archived

Wed Sep 1 13:42:28 2004

ARC1: Evaluating archive log 4 thread 1 sequence 8772

Wed Sep 1 13:42:28 2004

ARC0: Evaluating archive log 4 thread 1 sequence 8772

Wed Sep 1 13:42:28 2004

ARC1: Beginning to archive log 4 thread 1 sequence 8772

Wed Sep 1 13:42:28 2004

ARC0: Unable to archive log 4 thread 1 sequence 8772

Wed Sep 1 13:42:28 2004

Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oradata/ctsdb/archive/arch1_8772.log'

Wed Sep 1 13:42:28 2004

Log actively being archived by another process

Wed Sep 1 13:42:28 2004

ARC1: Completed archiving log 4 thread 1 sequence 8772

Wed Sep 1 13:42:43 2004

End: All standby logfiles have been archived

Resetting standby activation ID 4038461969 (0xf0b60a11)

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH

FINSH成功之后再执行SWITCH：

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

SWITCH成功之后，重新启动数据库：

SHUTDOWN IMMEDIATE;

STARTUP;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13132547/viewspace-243682/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13132547/viewspace-243682/