近日,我司在某银行的运维团队收到客户提出的需求,希望进行一次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