近日，我司在某银行的运维团队收到客户提出的需求，希望进行一次Oracle数据库迁移工作。该数据库所使用的两台存储比较老旧，无论是性能还是容量均不能满足现有的业务需求，因此客户购进了两台新存储，准备将数据库迁移到新存储上，并对磁盘组进行扩容。客户希望能在尽量短的停机时间内完成迁移。

一、需求分析

1、客户使用的是Oracle10g数据库，数据存放在ASM磁盘组上，迁移应该不是很复杂，从Oracle10gR2开始引入了ASM的概念，可以自动管理磁盘组并提供有效数据冗余功能，ASM支持条带化和磁盘镜像，实现了数据库被加载的情况下添加或移除磁盘及自动平衡I/O。这次迁移可以使用ASM在线添加和移除磁盘的功能实现。　　

2、OCR、VOTEDISK和SPFILE使用裸设备的方式，为避免错误，替换VOTEDISK最好停止集群再做，在操作前需要对OCR、VOTEDISK及SPFILE做好备份，做好应急方案。　　

3、客户希望停机维护时间控制在1小时内，因为此数据库所在的操作系统是HPUX，在存储Map盘到主机后，不需要重启就可以直接使用命令扫描到新盘，并直接产生字符设备号，但经过团队分析后认为HPUX虽然可以不重启认盘，但是有可能会两个节点认到的字符设备号不相同，但是OCR、VOTEDISK和SPFILE必须是相同的，如果不同就需要更改字符设备号，要永久生效，必须重启主机，这样的话，1小时是不够的，经与客户协商后，将停机维护时间更改为2小时。

二、变更申请

经过详细的讨论后，团队成员编写了迁移方案和应急处理方案，迁移工作分成两个部分分别在两个晚上进行，第一部分，在线迁移ASM磁盘组，第二部分，替换OCR、VOTEDISK和SPFILE。客户审核并通过了迁移方案，并为第二部分的操作申请了停机维护时间，提出了变更申请。

方案部分信息如下图：

三、变更实施

1、迁移ASM磁盘

第一个晚上操作比较顺利，唯一的问题是两个主机认到的磁盘字符设备号确实不一致，但是不影响ASM磁盘组的迁移，只要在一个节点上，按照此节点认到的字符设备号操作即可。所有磁盘组的存储盘都通过ASM加盘、删盘的操作进行了替换，并完成了重平衡，客户也非常满意。

2、迁移OCR、VOTEDISK、SPFILE

可能是由于第一晚的操作太过顺利，第二个晚上问题接踵而至。首先因为要改字符设备号需要重启两个节点的主机，客户申请的维护时间只有两个小时，对于这套业务量非常大的库来说，停应用、停库、重启就需要很久，时间并不宽裕，在重启完主机后，已经过去了1个小时，备份和替换OCR花费了10分钟，剩下的50分钟里要完成VOTEDISK和SPFILE的替换并检查验证。

a.发现问题

备份完VOTEDISK后，开始进行替换操作，加盘顺利、删盘顺利，大家都跟着松了一口气，但是当进行信息查看时发现VOTEDISK的信息混乱了，里面出现了多条重复的记录。这时离维护时间结束还剩35分钟。难道这次迁移要以失败收场？

b.排查问题

在经过初始的慌乱后团队马上冷静下来，经过分析后迅速找到了原因，原来替换完OCR后，客户没有停集群就进行了VOTEDISK的替换，在线替换OCR不是每次都可以成功，并且在Oracle10g中替换VOTEDISK需要使用-force选项，也可能会造成集群信息混乱。离维护结束时间还有30分钟，继续做还是和客户说再找时间做？

c.解决问题

经过初步计算时间上是可以完成的，于是马上启用应急方案，先停了集群，然后将所有VOTEDISK旧盘加回，删除新盘和多余的条目，并进行OCR还原，然后重新进行替换操作，信息全部正确，集群顺利启动。此时离维护时间结束不到20分钟，继续替换SPFILE，这个过程很顺利，最后，在维护时间还有10分钟的时候重新启动了集群和数据库，验证磁盘均已替换，拉起了应用，一切正常。

四、经验总结

1、Oracle数据库相关的存储迁移操作需要实施人员具备专业的系统、主机、存储、数据库等方面的综合能力，本次迁移环境相对比较复杂，应该请专业的服务公司来进行方案撰写和实施操作，安图特公司在该领域有非常丰富的经验。　　

2、进行综合性强、复杂度高的存储迁移相关操作时，应提前做好详细的变更方案和回退方案，并严格按照既定计划进行，不可随意更改原定方案，避免意外情况产生。　　

3、在方案执行过程中，如果出现计划外情况不要慌乱，冷静判断问题发生的原因，并按照应急方案解决。如果不能短时间内解决，应向客户说明情况启用回退方案，恢复到操作前的状态，择日再做。

4、安图特公司拥有专业的技术团队，能提供HP、IBM、SUN、EMC、Oracle等跨厂家、跨平台、多层次的综合支持，为客户的数据库迁移保驾护航。

如欲了解更多，请登录安图特官方网站:www.antute.com.cn