前文再续，书接上一回，这次折腾Data Guard的一个重要目的是利用switchover实现机器的升级，怎么switchover呢？按照我的理解，Data Guard的角色切换是这样一个过程：
（1）让primary节点变为standby节点。
（2）让其中一个standby节点变为primary节点
这里比较有意思是“其中一个”，也就是说节点A原来是primary转成standby后，突然我后悔了，还是可以马上让他变回primary节点的，具体看操作：
此时 test02 是primary 节点，test03是standby节点，由于test03缺少一个参数，一点test03变为primary，归档不会自动发到test02，于是第一步要补全这个参数：
|
1
2
|
##### test03 target priamry, standby now #####alter system set log_archive_dest_2=‘service=mydb_test02‘; |
让test02由primary变为standby：
|
1
2
|
##### test02, target standby, primary now #####alter database commit to switchover to physical standby ; |
以上语句有可能会遇到如下错误：
|
1
2
3
4
|
alter database commit to switchover to physical standby*ERROR at line 1:ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected |
这是由于一些连接还没有释放所致的，将前端应用关闭后如果还出现这种情况，可以用以下语句确认一下有哪些连接：
|
1
2
3
4
|
##### test02, target standby, primary now #####SELECT SID, PROCESS, PROGRAM FROM V$SESSION WHERE TYPE = ‘USER‘AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT); |
如果是Oracle内部进程的连接就不用管他了，执行如下语句就可以了：
|
1
2
3
4
|
##### test02, target standby, priamry now #####alter database commit to switchover to physical standby with session shutdown |
将test03也就是原来是standby的节点转为primary：
|
1
2
3
|
##### test03, target primary, standby now #####alter database commit to switchover to primary;##### test03, target primary, primary now ##### |
打开primary节点的数据库，使其可对外服务：
|
1
2
3
|
##### test03, target primary, primary now #####shutdown immediate;startup; |
启动standby的归档恢复进程：
|
1
2
|
##### test02, target standby, standby now #####alter database recover managed standby database disconnect from session; |
此时已经完成了Data Guard 主备切换了，可以监控住standby的alert文件，在primay中做一次日志切换，看看是否有归档日志传送过来并且恢复。
如果监控时间比较长的（超过5分钟）会看到如下错误：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
##### primary alert #####Fri Dec 17 14:04:46 2010Redo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[10]: Assigned to RFS process 12079RFS[10]: Database mount ID mismatch [0x9e217391:0x9e217bca]RFS[10]: Client instance is standby database instead of primaryRFS[10]: Not using real application clustersFri Dec 17 14:04:46 2010Errors in file /u01/app/admin/mydb/udump/mydb_rfs_12079.trc:ORA-16009: remote archive log destination must be a STANDBY database ##### standby alert #####Fri Dec 17 14:04:54 2010Errors in file /u01/app/admin/mydb/bdump/mydb_arc1_6821.trc:ORA-16009: remote archive log destination must be a STANDBY databaseFri Dec 17 14:04:54 2010PING[ARC1]: Heartbeat failed to connect to standby ‘mydb_test02‘. Error is 16009. |
虽然不影响 Data Guard 的功能和使用，但如何解决呢？其实这是归档进程ARCHn进程在作怪，想办法屏蔽就可以，一个比较土的方法就是将备节点的log_archive_dest_2设为空，也就是回到上一篇中提到那种配置上，另外一种聪明点的做法就是引入valid_for参数：
|
1
2
3
4
5
|
##### test02 #####alter system set log_archive_dest_2=‘service=mydb_test03 valid_for=(online_logfiles,primary_role)‘;##### test03 #####alter system set log_archive_dest_2=‘service=mydb_test02 valid_for=(online_logfiles,primary_role)‘; |
alert文件中再也看不到这两个错误了。
原文：http://www.cnblogs.com/hllnj2008/p/4028886.html