DATAGUARD物理standby角色切换（笔记二）
角色切换前的准备工作
1）检查各数据库的初始化参数，主要确认对不同角色相关的初始化参数都进行了正确的配置。
2）确保可能成为primary数据库的standby服务器已经处于archivelog模式。
3）确保standby数据库的临时文件存在并匹配primary数据库的临时文件
4）确保standby数据库的RAC实例只有一个处于open状态。（对于rac结构的standby数据库，在角色转换时只能有一个实例startup。其它rac实例必须统统shutdown，待角色转换结束后再startup）
角色切换的两种方式
Switchover
无损转换，通常是用户手动触发或者有计划的让其自动触发，比如硬件升级啦，软件升级啦之类的。通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段，第一步，primary数据库转换为standby角色，第二步，standby数据库(之一)转换为primary角色，primary和standby只是简单的角色互换
Failover
不可预知原因导致primary数据库故障并且短期内不能恢复就需要failover。在执行failover之前，尽可能将原primary数据库的可用redo都复制到standby数据库。嘿嘿，也就是说，如果可用redo没有完全复制到standby数据库，哭吧哭吧不是罪…….
接下来就开始实践physical standby的swithover
一、物理standby的swithover
1、检查是否支持switchover操作-------------primary操作
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY
SQL>
如果该列值为"TO STANDBY"则表示primary数据库支持转换为standby角色，否则的话你就需要重新检查一下Data Guard配置，比如看看LOG_ARCHIVE_DEST_n之类参数值是否正确有效等等。
2、启动swithover -----------primary
首先更换primary数据库为standby数据库
SQL> alter database commit to switchover to physical standby;
Database altered.
SQL>
语句执行完毕后，primary数据库将会转换为standby数据库，并自动备份控制文件到trace。
3、重启动到mount状态-----原primary库操作
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 251658240 bytes
Fixed Size 2019928 bytes
Variable Size 113249704 bytes
Database Buffers 130023424 bytes
Redo Buffers 6365184 bytes
Database mounted.
SQL>
4、检查是否支持switchover操作-------------------原standby库操作
Last login: Mon Aug 31 13:01:23 2009 from bbb-7a9d379e51a
[root@centos76 ~]# su - oracle
[oracle@centos76 ~]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Aug 31 13:56:12 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> select switchover_status from v$database
2 ;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
SQL>
5、转换角色到primay
SQL> alter database commit to switchover to primary;
Database altered.
SQL>
6、完成转换
SQL> alter database open
2 ;
Database altered.
SQL>
7、检查转换是否成功
转换后的Primary库
SQL> alter system switch logfile;
System altered.
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
80
SQL>
转换后的standby库
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
80
SQL>
二、 物理standby的failover
注意几点：
failover 之后，原primary数据库默认不再是data guard配置的一部分。
多数情况下，其它逻辑/物理standby数据库不直接参与failover的过程，因此这些数据库不需要做任何操作。
某些情况下，新的primary数据库配置之后，需要重新创建其它所有的standby数据库。
另外，如果待转换角色的standby处于maximum protection或maximum availability模式的话，归档日志应该是连续存在的，这种情况下你可以直接从第 3 步执行，否则建议你按照操作步骤从第1步开始执行。
一般情况下failover都是表示primary数据库瘫痪，最起码也是起不来了，因此这种类型的切换基本上不需要primary数据库做什么操作。所以下列步骤中如果有提到primary和standby执行的，只是建议你如果primary还可以用，那就执行一下，即使它能用你却不执行，也没关系，不影响standby数据库的切换:)
1、检查归档文件是否连续
查询待转换standby数据库的V$ARCHIVE_GAP视图，确认归档文件是否连接：
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
no rows selected
SQL>
如果返回的有记录，按照列出的记录号复制对应的归档文件到待转换的standby服务器。这一步非常重要，必须确保所有已生成的归档文件均已存在于standby服务器，不然可能会数据不一致造成转换时报错。文件复制之后，通过下列命令将其加入数据字典：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ¨filespec1¨;
2、 检查归档文件是否完整
分别在primary/standby执行下列语句：
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
THREAD# A
---------- ----------
1 80
SQL>
该语句取得当前数据库各线程已归档文件最大序号，如果primary与standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的standby服务器。不过既然是failover，有可能primary数据库此时已经无法打开，甚至无法访问，那你只好听天由命喽
3、 启动failover
执行下列语句：
SQL> alter database recover managed standby database finish force;
数据库已更改。
FORCE 关键字将会停止当前活动的RFS进程，以便立刻执行failover。
剩下的步骤就与前面switchover很相似了
4、 切换物理standby角色为primary
SQL> alter database commit to switchover to primary;
数据库已更改。
5、 启动新的primary数据库。
如果当前数据库已mount,直接open即可，如果处于read-only模式，需要首先shutdown immediate，然后再直接startup。
SQL> alter database open;
数据库已更改。
角色转换工作完成。剩下的是补救措施(针对原primary数据库)，由于此时primary数据库已经不再是data guard配置的一部分，我们需要做的就是尝试看看能否恢复原primary数据库，将其改造为新的standby服务器。具体操作方式可以分为二类：1.重建 2.备份恢复。所涉及的技术前面的系列文章中均有涉及，此处不再赘述。
浙公网安备 33010602011771号