背景说明：
公司计划升级一下数据库所在机器的配置，目前的环境是两节点的11.2.0.4的RAC。
初步的方案有四种：
方案一>>新搭建一套RAC环境，备份原有数据，做备份恢复。
方案二>>用新机器配合现有环境直接做一个DG，可以做到无障碍切换。
方案三>>采用加减节点的方式，将新机器加入现有环境，运行正常后剔除老机器。
方案四>>在新机器上安装GRID和DB的软件，老的RAC机器停机以后，直接将底层存储挂载到新机器上。
方案优缺点：
方案一：这样做，不影响原来的环境，如果在恢复过程中出现问题，可以随时将老库拉起来，风险性较小。应用端需要修改配置，注意是否有遗漏。我们数据量在18T左右，采用备份恢复方式过慢，所以放弃了。
方案二：DG的方式对于我们目前状态是比较好的。但是后端存储的量不够，拿不出18T的额外空间了，所以放弃了。
方案三：这个方式不管前端还是后端，基本是没有变化的。一开始我们选择的是这个方案，结果新机器到了以后发现，新机器不支持以前老机器的OS版本了，这个要特别注意，加减节点的时候，软件环境一定要保持一致，不然后期会出现杂七杂八的问题，所以我们只能放弃。
方案四：在新机器上安装了软件，申请了停机时间，直接拉存储过去。这个效率比较高。主要注意启动应用的时间，一旦数据修改，新机器有问题，回退麻烦。
技术细节：
操作过程就是简单的一些命令，不做赘述。需要注意点是一定要备份磁盘头信息。
后记：
前机器为华为的机器，os版本是suse 11 sp3。目前升级的机器为dell的机器，os版本要求最低为suse 12 sp3。在实操过程中碰到了两个坑，一个是suse 12 sp3 中lib包不全，这个在oracle support上找到了解决方案。还有一个是底层的是华为存储做的raid10,操作系统使用的是华为的多路径识别软件，发现启动过程中，华为多路径的udev和oracle asm udev识别的顺序有问题，混合识别导致oracle asm udev识别到的主设备号和次设备号不一致，可能是直接在华为多路径识别之前导致的。最后决定，oracle asm udev手动来做，在机器彻底启动之前不识别来缓解这个问题，后续向华为咨询这个问题。