某电信EDW系统X2-2至X5-2数据迁移及故障处理

作者简介:周振中,Oracle数据库技术顾问。拥有电信、银行及制造业等多个行业oracle数据库故障处理、数据迁移的方案制定及实施等经历。持有11gOCM、Mellanox证书。

背景介绍

某省电信客户由于数据仓库系统数据量与日俱增,原硬件平台在未来不再满足业务增长,甲方决定从原X2-2(1/2)迁移至X5-2(1/4)平台。

环境介绍

迁移前:

数据库服务器
服务器型号 SUN FIRE X4170 M2 SERVER
操作系统版本 OEL 5.8 x86(64)
主机名 xxxxxxxxxxxx
管理IP xxxxxxxxxxxx
Client IP xxxxxxxxxxxx
私网IP xxxxxxxxxxxx
VIP xxxxxxxxxxxx
SCANIP xxx scan
升级Oracle 版本 Oracle Enterprise Edition 11.2.0.3.20 RAC
dbname dbm
数据文件存储 ASM
归档存储方式 非归档

迁移后:

数据库服务器
服务器型号 Sun Oracle Server X5-2
操作系统版本 OEL 6 x86(64)
主机名 xxxxxxxxxxxx
管理IP xxxxxxxxxxxx
Client IP xxxxxxxxxxxx
私网IP xxxxxxxxxxxx
VIP xxxxxxxxxxxx
SCANIP xxx dw01-scan
升级Oracle 版本 Oracle Enterprise Edition 11.2.0.4.20 RAC
dbname dbm
数据文件存储 ASM
归档存储方式 非归档

方案介绍

需要将X2-2(1/2)中的75TB数据其中的15T迁移至新的X5-2(1/4)上。原X2-2系统,由于存储空间及停机窗口等多方面原因,无法选择逻辑迁移或物理迁移方式。最终,选择将X2-2上的原数据通过Veritas netbackup备份软件进行0级备份,恢复至X5中,后期产生的不一致数据,由应用人员负责补全。当X2-2X5-2中的数据基本一致后,应用正式切换至X5-2环境中运行。

方案测试

由于备份窗口及RTO的时间要求,需要对此方案进行测试,对时间进行预估(新X5-2已完成刷机及GI、数据库软件的安装)。方案测试的大致步骤为:

  1. 将原X2-2平台承载业务进行停机,通过Veritas netbackup备份软件进行0级备份,预估备份时间。
  2. 恢复参数文件、控制文件时间预估。
  3. 恢复数据文件时间预估。
  4. 升级数据库时间预估(11.2.0.3 à 11.2.0.4)。
  5. 编译无效对象时间预估。
  6. 升级后处理(logfile重命名、重建临时表空间、UNDO处理、CRS注册数据库等)时间预估。

测试故障

通过以上方案的制定,本以为可以顺利的推进了,没想到在方案测试的第一步就出现故障了。

由于方案测试是在晚上十二点开始,于是跟Veritas的哥们通了电话说开始之后正常备份之后咱们就先睡一觉休息一下,备份要持续很长一段时间。一切都拉起来之后,立马在Master Server上查看备份的状况,一切正常。于是Veritas的哥们也躺下休息了,过了几个个小时那哥们觉得心里不踏实,起来查看备份状况。一看傻眼了,由于停数据库的哥们是其他公司的人,只停了数据库,不到一段时间,CRS又把数据库给拉起来,备份失败了,本次方案测试到此为止。刘备是创业未半而中道崩殂,我们的这次测试还未上道就已崩殂。

调整架构

由于本次测试甲方申请了停机窗口,失败对于他们来说需要重新申请停机窗口,所以甲方对于此次失败非常不满,并且对停机窗口进行了压缩,要求我们调整方案,并且此次测试如果成功直接作为准生产环境,后期数据由应用进行补充。调整后的时间窗口为48小时,由于恢复时间基本上是备份时间的2倍,除去回退时间和恢复后的处理时间,备份的时间窗口定在10小时。方案是没法变动了,只能在架构上进行调整,整个架构类似下图:


说明:

数据量:15T

RTO10H

理论上备份的速度需要高于450M/s。现状是计算节点到Media Servers40GIB网络,Media Servers到带库是FC网络。其中计算节点到Media ServersIB网络不存在瓶颈。实际上Media Servers到带库的FC网络中,带库的网卡是一块单口的4G卡,理论速度最高为400M/s,所以备份的瓶颈就在Media Servers到带库的FC网络。建议将带库的4G卡换成8G卡,理论上可以达到800M/s,满足需求450M/s

再次实施方案

  1. 编写参数文件

  2. 恢复控制文件

  3. Restore数据库注意:通道分配与备份时保持一致,否则会出现驱动器争用,数据量过大等待时间过长将导致失败

  4. 恢复后处理
  5. 打开数据库并升级

重启数据库报错处理

 

解决方法:

1. Shutdown the instance.

2. Make the following changes in the init.ora or spfile:

3. Restart the instance.

4. Execute the following statements as the SYSDBA user:

5. Issue the following query and ensure that only a single row for OTHER_GROUPS is returned:

6. If so, shutdown the instance.

7. Reset the resource manager parameters in the init.ora or spfile:

8.  Restart the instance.

参考文档:MOS ID 1386080.1

总结

由于数据库升级导致应用存在部分问题,随后帮助应用进行参数及应用调优,以及一些大大小小的故障处理。至此,整个数据迁移过程完成!通过这个项目,感悟到对于客户提出的技术无法实现的需求时,需要坚持站在技术的角度分析需求,提出可行又能满足客户需求的方案。


未经允许不得转载:Oracle一体机用户组 » 某电信EDW系统X2-2至X5-2数据迁移及故障处理

相关推荐