关于Oracle Data Guard的角色切换
1.概述
Oracle数据库通过其 Data Guard技术通过网络将数据实时异地的Oracle数据库中，实现其数据的异地安全机制。
它的实现过程是一般是这样：
首先，在异地建立一样的环境，包括主机操作系统，数据库版本和数据文件存储方式，先模拟建个库，后在此库基础上创建physical standby。
其次，在主库和备库节点上修改一下init.ora，listener.ora和tnsnames.ora文件配置，及主库的v$database的protection_mode修改为MAXIMUMAVAILABILITY（最大可用）。
再次，在主库上备份一下控制文件，当然是for standby方式。
最后，在备库上创建一下standby logfile，启动到recover managed standbydatabase 状态；并在主库上将指向该备库的log_archive_dest_state_*做一下defer和enable，即激活一下。
这样，整个过程就此完成。
好吧，这不是重点。
重点是，在DataGuard环境搭建完成后备库能切换吗？如何切换呢？
2.主备库相互切换
其实，OracleData Guard的切换有两种，其专业术语称为switchover和failover。
正常切换switchover的操作步骤简单明了，如下：
第一步，关掉主库上的监听，再将主库上的所有连接也关掉。可以直接kill -9 local=no的oracle进程，我就是这么干的。
第二步，在主库上将数据库角色设置为PHYSICAL STANDBY,切换状态设置为TO PRIMARY。
操作的SQL为：alter database commit to switchover to physical standby;
结果检查：
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
主库已经变成一个standby库了。但该库的切换状态设置是TO PRIMARY，如果你这个时候反悔，就可以再切换回去。
切换操作完成后，数据库实例需要重启，init.ora文件需要更换，实例设置为实时恢复状态。
操作的SQL为：
startupnomount force;
alterdatabase mount standby database;
alterdatabase recover managed standby database using current logfile disconnect fromsession;
第三步，在备库上将数据库角色设置为PRIMARY。
操作的SQL为：alter database commit to switchover to primary;
结果检查：
先检查数据库角色和切换状态，决定备库能不能切换。
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
SQL>alter database commit to switchover to primary;
Databasealtered.
切换操作完成后，数据库实例需要重启，init.ora文件需要更换。
SQL>conn / as sysdba
Connected.
SQL>startup open force;
ORACLEinstance started.
Databasemounted.
Databaseopened.
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PRIMARY TO STANDBY
通过这三步，切换操作就完成了。这个切换操作可以用来做数据迁移。比以前使用RMAN的backup/restore简单多了。更重要的是，它还可以再切换回去。
这三步操作，看上去很简单，但是涉及到了主库角色转换的问题。如果在主库的角色转换后，备库因某些原因如硬件不能转换为主库了，又该怎么办？
没有了主库，对于任何应用系统都是灾难啊。
好吧，我承认，这才是我想说的重点。
3.主库二次切换
如果备库切换失败了，主库也变成了一个新的备库，那么需要将该主库再次恢复成主库。
在主库上执行转换操作的SQL：alter database commit to switchover tophysical standby;时，从alert.log中看到这些记录信息。
Wed Apr 1014:39:40 2013
Thread 1advanced to log sequence 32 (LGWR switch)
Current log# 2 seq# 32 mem# 0:+VG1/tesdb/redo02.log
********************************************************************
LGWR:Resetting 'active' archival for destination LOG_ARCHIVE_DEST_2
********************************************************************
Wed Apr 1014:39:45 2013
DestinationLOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Wed Apr 1014:39:45 2013
Thread 1advanced to log sequence 33 (LGWR switch)
Current log# 3 seq# 33 mem# 0:+VG1/tesdb/redo03.log
Wed Apr 1014:39:45 2013
Stoppingbackground process CJQ0
Wed Apr 1014:39:45 2013
SMON:disabling tx recovery
Wed Apr 1014:39:45 2013
Stoppingbackground process QMNC
Wed Apr 1014:39:47 2013
StoppingJob queue slave processes, flags = 27
Wed Apr 1014:39:47 2013
Job queueslave processes stopped
Waiting fordispatcher 'D000' to shutdown
Alldispatchers and shared servers shutdown
Wed Apr 1014:39:49 2013
SMON:disabling cache recovery
Wed Apr 1014:39:49 2013
Shuttingdown archive processes
Archivingis disabled
Wed Apr 1014:39:54 2013
ARCHshutting down
ARC1:Archival stopped
Wed Apr 1014:39:59 2013
ARCHshutting down
ARC0:Archival stopped
Wed Apr 1014:40:00 2013
Thread 1closed at log sequence 33
Successfulclose of redo thread 1
Wed Apr 1014:40:00 2013
ARCH:Noswitch archival of thread 1, sequence 33
ARCH:End-Of-Redo Branch archival of thread 1 sequence 33
ARCH:Archiving is disabled due to current logfile archival
Clearingstandby activation ID 1566058370 (0x5d582782)
The primarydatabase controlfile was created using the
'MAXLOGFILES40' clause.
There isspace for up to 37 standby redo logfiles
Use thefollowing SQL commands on the standby database to create
standbyredo logfiles that match the primary database:
ALTERDATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTERDATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTERDATABASE ADD STANDBY LOGFILE &
