| « | 十月 2008 | » | ||||
|---|---|---|---|---|---|---|
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||
主库出问题时,我们可以对备库做失败切换,使得应用继续运行。但是做失败切换的前提是:
主库的日志完全传送到备库上(包括联机日志上的redo信息),如果DATAGUARD是运行在最大保护或者最大可用模式下,这种切换一般没有问题。
但是如果DATAGUARD运行在最大性能保护模式下,可能需要用强行切换的方式来激活备库了。
强行切换与普通的失败切换的最大差别是:强行切换在数据库打开时需要resetlogs。由此带来的后果是:
1、可能有数据丢失
2、破坏了整个DATAGUARD的结构。
如果存在多个standby,则其他的standby在没有重建的情况下不能以被激活的库作为priamry,所有的standby必须要重建。
所以,不到万不得已,不要轻易强行切换备库。
下面提供一个强行切换的脚本:
[oracle@standby ~]$ more activestandby.sh
lsnrctl stop
$ORACLE_HOME/bin/sqlplus /nolog <<EOF
connect / as sysdba
alter database recover managed standby database cancel;
recover managed standby database cancel;
alter database activate standby database;
shutdown immediate
startup
exit
EOF
lsnrctl start
在执行这个脚本后,在备库的alert会看到如下信息:
RESETLOGS after incomplete recovery UNTIL CHANGE 8799100
Resetting resetlogs activation ID 1463929150 (0x5741c93e)
Online log /u01/oracle/oradata/primary/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/oracle/oradata/primary/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/oracle/oradata/primary/redo03.log: Thread 1 Group 3 was previously cleared
Online log /u01/oracle/oradata/primary/redo10.log: Thread 1 Group 10 was previously cleared
Standby became primary SCN: 8799098
Wed Aug 15 20:44:17 2007
Setting recovery target incarnation to 2
Wed Aug 15 20:44:20 2007
ACTIVATE STANDBY: Complete - Database shutdown required (primary)
Wed Aug 15 20:44:20 2007
Completed: alter database activate standby database
这表明数据库在重启后会被resetlogs。
最后不要忘了修改被激活的库的一些与原来DATAGUARD相关的参数。
如果存在多个standby,则其他的standby在没有重建的情况下不能以被激活的库作为priamry,所有的standby必须要重建。
只需要重建stnadby控制文件就可以吧
小李飞刀 | 12/06/2008, 09:13