一、项目背景
通过架设ActivePhysical Standby DataGuard，将现有2-Node 11gR2 RAC数据库迁移到新硬件设备(更换服务器和存储)，且生产环境又增加一套双节点备库。
实施过程中我们用Orion做了IO性能测试，也用SPA性能对比分析，这些都是前期工作，这里不做赘述。
1、技术架构
2、数据库环境
3、网络配置
二、实施流程
三、实施前准备工作
RAC to RAC 11g R2Dataguard 所需要的初步需求已经建立好了,下面是主从部分。
1、Primary Site
数据库目前已是ADG主库
2、Standby Site
（1）双节点Linux安装和配置
（2）双节点Oracle11g Grid Infrastructure安装和配置
（3）双节点Oracle11g RAC Software安装和配置
RAC的安装我们这里不做赘述。
四、实施步骤
1、现有环境调整
（1）/etc/hosts/设置
--主备4台主机添加主备SCAN IP解析信息
2、配置PrimaryRAC Database的参数
（1）检查Force Logging
--目前应该是开启的
（2）创建Standby日志
--查看现有redo日志构成
（3）修改Dataguard相关的初始化参数
--修改前后查看参数信息
（4）创建Standby数据库的Pfile
--创建一个临时的备份路径
（5）更新tnsnames.ora
（6）备份数据库
--通过下面脚本全备数据库
3、准备Standby RAC Database
（1）创建相关目录
（2）拷贝备份文件
（3）复制密码文件
--配置DataGuard 需要两边数据库密码保持一致
（4）创建参数文件
（5）修改环境变量
（6）添加tnsnames.ora
4、创建Physical Standby Database
（1）连接测试
--在所有主备节点分别执行
（2）将Standby实例启动到MOMOUNT状态
（3）恢复数据库
（4）检查参数
（5）创建online redo，standby redo，重启数据库
--创建standbyredo logs
（6）Standby Database注册到OCR里
（7）开启日志应用
（8）检查日志应用进度
5、物理Standby和Physical切换
RAC环境的切换必须是单实例状态下去完成，所以要关闭一个节点。
（1）switchover切换时需要考虑的操作
如果在执行switchover时不想指定with session shutdown，以下过程可能需要在主备库上操作：
（2）检查现有的事务
（3）检查各实例alert日志
检查主备库各实例的alert日志是否正常。
（4）主库只保留一个实例
--在主RAC和备RAC的第二节点分别执行
（5）检查备库日志应用情况
（6）主库上操作
（7）备库上操作
（8）备用主备库另外节点
--在主RAC和备RAC的第二节点分别执行
（9）确认新备库的日志应用情况
6、切换后的数据确认
理论上，物理standby database与primary database是相同的数据库，switchover操作也不会导致数据丢失。为安全起见，仍需对数据库做一系列检查，包括：
五、实施影响评估
（1）主备角色切换过程中，涉及到启停数据库。为了顺利启停数据库，需要避免在有大事务运行期间执行主备切换。否则会延长数据库的停机时间。建议在业务量小的时间段进行操作。
（2）通常情况下，DataGuard switchover操作不会引起数据丢失，并且切换的过程是可逆的。
（3）ADG主备切换会启停数据库，手动切换时间正常情况下不超过3分钟。切换完成后，业务访问数据库的地址需要更改。
六、应急回退措施
如果在切换过程中存在异常且会影响业务停机时间，建议停止ADG主备切换操作，重新选择合适的切换时间。
如果物理备用数据库发生错误的情况，并且不可能继续切换，可能需要将已转换成物理备用角色的数据库回退到主数据库角色。以下是回退步骤：
七、趟过的坑
我们的生产库上之前还有一个单机ADG的，前面为了表述简单，我将这个细节给去了。
我们在做测试的时候因为设备不够，没有模拟到这个环节。在进行切换的时候，出现下面的情形：
作者介绍：郭军伟
中科大软件工程硕士
曾供职于阿里巴巴，华夏媒体信息技术有限公司
现供职于某第三方支付公司高级数据库工程师
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-03-25
