ORACLE FAILOVER 研究

本实验纯模拟主库宕机情况下，激活备库的情况(强行激活)
# uname -a
Linux dbsvr 2.6.9-42.EL #1 Wed Jul 12 23:15:20 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

一：不完全恢复激活备库
1.创建standby ctl
SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';

Database altered.
2。查询控制文件位置
SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/control01.ctl
/oracle/app/oradata/test9i/control02.ctl
/oracle/app/oradata/test9i/control03.ctl

3.将原来的ctl替换掉
[oracle@dbsvr test9i]$ mv c.ctl control01.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control02.ctl
[oracle@dbsvr test9i]$ cp control01.ctl control03.ctl
4.启动备库

SQL> startup nomount
ORACLE instance started.

Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;

Database altered.

SQL> select resetlogs_change# from v$database;

RESETLOGS_CHANGE#
-----------------
227130

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/oracle/app/oradata/test9i/system01.dbf
/oracle/app/oradata/test9i/undotbs01.dbf
/oracle/app/oradata/test9i/drsys01.dbf
/oracle/app/oradata/test9i/indx01.dbf
/oracle/app/oradata/test9i/tools01.dbf
/oracle/app/oradata/test9i/users01.dbf
/oracle/app/oradata/test9i/xdb01.dbf
/oracle/app/oradata/test9i/test01.dbf.bak

8 rows selected.

5。激活备库

SQL> alter database activate standby database;

Database altered.
其中alert日志显示
Sun Jun 14 01:56:18 2009
alter database activate standby database
Sun Jun 14 01:56:18 2009
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE
[b]RESETLOGS after incomplete recovery UNTIL CHANGE 304398[/b][/b]
Resetting resetlogs activation ID 0 (0x0)
Sun Jun 14 01:56:30 2009
Online log 3 of thread 1 was previously cleared
Activation complete - Database shutdown not required
Completed: alter database activate standby database
可见数据库进行了不完全恢复，见粗体部分
6。ctl从standby ctl变成了normal ctl，用正常的mount命令，mount数据库

SQL> alter database mount;

Database altered.
7。查询resetlogs_change#，可以看到数据库其实是resetlogs了

SQL> select resetlogs_change# from v$database;

RESETLOGS_CHANGE#
-----------------
304399
8。打开数据库
SQL> alter database open;

Database altered.
二：完全恢复的情况下激活备份，即不进行resetlogs打开备库
1.查询备份库resetlogs_change，作为基准参考

SQL> select resetlogs_change# from v$database;

RESETLOGS_CHANGE#
-----------------
304399
2。创建standby ctl

SQL> alter database create standby controlfile as '/oracle/app/oradata/test9i/c.ctl';

Database altered.
3.替换控制文件，并重新启动

SQL> startup nomount
ORACLE instance started.

Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
SQL> alter database mount standby database;

Database altered.
4。恢复库
SQL> recover standby database;
ORA-00279: change 304442 generated at 06/14/2009 01:57:33 needed for thread 1
ORA-00289: suggestion : /tmp/1_1.dbf
ORA-00280: change 304442 for thread 1 is in sequence #1


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/app/oradata/test9i/redo02.log
Log applied.
Media recovery complete.
alert日志显示
Sun Jun 14 02:11:31 2009
ALTER DATABASE RECOVER standby database
Sun Jun 14 02:11:31 2009
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Sun Jun 14 02:11:38 2009
ALTER DATABASE RECOVER LOGFILE '/oracle/app/oradata/test9i/redo02.log'
Media Recovery Log /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
Sun Jun 14 02:11:38 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /oracle/app/oradata/test9i/redo02.log
[b]Incomplete recovery applied all redo ever generated.
Recovery completed through change 304731
Media Recovery Complete[/b]
Completed: ALTER DATABASE RECOVER LOGFILE '/oracle/app/ora

5。尝试打开备库
SQL> alter database commit to switchover to primary;
alter database commit to switchover to primary
*
ERROR at line 1:
ORA-16139: media recovery required
alter日志显示
Sun Jun 14 02:12:54 2009
alter database commit to switchover to primary
Sun Jun 14 02:12:54 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO
[b]Switchover: Media recovery required - standby not in limbo[/b]
ORA-16139 signalled during: alter database commit to switchover to primary...
Sun Jun 14 02:13:50 2009
alter database recover managed standby database finish skip standby logfile
Sun Jun 14 02:13:50 2009
Database not recovered through End-Of-REDO

显示恢复还需要syandby redolog，于是使用下列命令。注意此命令在10g不支持了

SQL> alter database recover managed standby database finish skip standby logfile;

Database altered.
查询v$log表可以看到ORACEL自动创建了standby redolog

SQL> select * from v$logfile;

GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------------------------------------------
2 ONLINE
/oracle/app/oradata/test9i/redo02.log

3 ONLINE
/oracle/app/oradata/test9i/redo03.log

1 ONLINE
/oracle/app/oradata/test9i/redo01.log

[b] 4 STANDBY
/tmp/1_0.dbf[/b]
alerlog日志显示次standby redolog再次应用了
Database not recovered through End-Of-REDO
Attempt to do a Terminal Incomplete Recovery
Media Recovery Start: Managed Standby Recovery
Starting datafile 1 recovery in thread 1 sequence 1
Datafile 1: '/oracle/app/oradata/test9i/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 1
Datafile 2: '/oracle/app/oradata/test9i/undotbs01.dbf'
Starting datafile 3 recovery in thread 1 sequence 1
Datafile 3: '/oracle/app/oradata/test9i/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 1
Datafile 4: '/oracle/app/oradata/test9i/indx01.dbf'
Starting datafile 5 recovery in thread 1 sequence 1
Datafile 5: '/oracle/app/oradata/test9i/tools01.dbf'
Starting datafile 6 recovery in thread 1 sequence 1
Datafile 6: '/oracle/app/oradata/test9i/users01.dbf'
Starting datafile 7 recovery in thread 1 sequence 1
Datafile 7: '/oracle/app/oradata/test9i/xdb01.dbf'
Starting datafile 8 recovery in thread 1 sequence 1
Datafile 8: '/oracle/app/oradata/test9i/test01.dbf.bak'
Media Recovery Log
Media Recovery Waiting for thread 1 seq# 1
Terminal Incomplete Recovery: UNTIL CHANGE 304731
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 created '/tmp/1_0.dbf'
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 1
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# 1 redo required
Terminal Incomplete Recovery: End-Of-Redo log /tmp/1_0.dbf
Identified end-of-REDO for thread 1 sequence 1
Sun Jun 14 02:14:05 2009
[b]Media recovery opens logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf
Sun Jun 14 02:14:05 2009
Media recovery closes logfile:
Thread: 1 Sequence: 1 Logfile name: /tmp/1_0.dbf [/b]
Terminal Incomplete Recovery: end checkpoint SCN 304060
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
Sun Jun 14 02:14:05 2009
ARC1: Evaluating archive log 4 thread 1 sequence 1
Sun Jun 14 02:14:05 2009
ARC0: Evaluating archive log 4 thread 1 sequence 1
ARC0: Unable to archive log 4 thread 1 sequence 1
Log actively being archived by another process
Sun Jun 14 02:14:05 2009
ARC1: Beginning to archive log 4 thread 1 sequence 1
Creating archive destination LOG_ARCHIVE_DEST_1: '/tmp/1_1.dbf'
ARC1: Completed archiving log 4 thread 1 sequence 1
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
6.再次尝试FALLOVER备份库
SQL> alter database commit to switchover to primary;

Database altered.
alert日志显示了此过程
Sun Jun 14 02:14:20 2009
End: All standby logfiles have been archived
Resetting standby activation ID 2426500015 (0x90a173af)
Completed: alter database recover managed standby database fi
Sun Jun 14 02:22:14 2009
alter database commit to switchover to primary
Sun Jun 14 02:22:14 2009
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
NORESETLOGS after complete recovery through change 304731
Resetting resetlogs activation ID 0 (0x0)
Online log 1 of thread 1 was previously cleared
Online log 3 of thread 1 was previously cleared
Changing control file format version from 8.0.0.0.0 to 9.0.0.0.0
RESETLOGS changing datafile format version from 9.0.0.0.0 to 8.0.0.0.0
Switchover: Complete - Database shutdown required
Completed: alter database commit to switchover to primary
alter database mount
Sun Jun 14 02:23:25 2009
Database in limbo -- Shutdown Required.

7。打开数据库并查询resetlogs_change

SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01100: database already mounted


SQL> shutdown immediate
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 320308744 bytes
Fixed Size 742920 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
Database mounted.

SQL> select resetlogs_change# from v$database;

RESETLOGS_CHANGE#
-----------------
304399
可以看到reselogs_change并没有改变
总结：
一般情况推荐使用第二种方法，第二种方法如果主库有多个备库，当激活其中一个备库之后可以作为其他备库的主库。
[b]在9i环境中不推荐使用第一种方法[/b]，因为当备库reselog之后以为着需要重新做一次0级全备，当然了在10g环境中不需要做0级备份，因为ORACLE提供了闪回机制。呵呵


附：
切换后，不能将数据库read only打开，alert日志显示：
Errors in file /oracle/app/admin/test9i/udump/test9i_ora_30489.trc:
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/oracle/app/oradata/test9i/system01.dbf'
Sun Jun 14 03:03:46 2009
Error 376 happened during db open, shutting down database
USER: terminating instance due to error 376
Instance terminated by USER, pid = 30489
ORA-1092 signalled during: alter database open read only...

可以看到在read write打开过程中，数据虽然不重置resetlogs_change，[b]但重置了activation ID：
[/b]
LGWR: Primary database is in CLUSTER CONSISTENT mode
Assigning activation ID 2426541760 (0x90a216c0)
Thread 1 opened at log sequence 3
Current log# 2 seq# 3 mem# 0: /oracle/app/oradata/test9i/redo02.log
Successful open of redo thread 1.