ORACLE数据库跨平台升级方案研究和实施
摘 要： 随着关系型数据库的不断发展和新技术的引入，数据库作为各行业的数据核心和业务枢纽，数据量呈几何倍数膨胀，超TB级数据库不再鲜见。数据量的膨胀导致后续的版本升级和系统迁移更难操作，结合实际操作经验，从时间、风险和应急策略等方面入手，详细阐述大数据量数据库跨平台升级方案的研究、选择和实施，在实际的操作过程中取得良好的效果，具有一定的参考价值。
关键词： ORACLE；数据库；升级；数据迁移
2010年基于系统发展实际需要，决定对业务支撑系统数据库进行升级，核心CRM和BOSS核心数据库由9i升到10G，服务器更换为IBM平台，存储更换为EMC，CRM和BOSS数据库作为业务支撑系统的数据中心和业务枢纽，其升级方案的选择尤为重要。CRM和BOSS数据库容量均超过10TB，实际数据量都在5TB左右，项目要求在完成新、旧系统切换的同时进行垃圾数据清理、分布规划和权限优化。
1 方案选择
1.1 影响因素
业务连续性挑战：业务支撑系统是24x7全天候运行的系统，宕机不仅意味着大量的收入损失，同时严重影响公司的服务形象。经过业务评估，本次迁移过程中能够承担的最大停机时间不超过12小时。数据安全性挑战：吉林移动业务支撑系统数据的重要性是不容置疑的。升级后数据将迁移到一个全新的系统，需要从实现机制上保障数据安全性，同时提供数据校验机制。项目风险挑战：10G升级涉及到很多因素，包括业务影响、新版本的Bug、10G新特性、平台变更、应用变更、参与人员等等。确保应用在10G环境的平滑运行是一个非常大的挑战。
上述因素对核心系统升级技术方案提出很高的要求。数据库升级过程将关注两个关键因素：升级的成功完成和可能导致的宕机时间。成功不仅仅是指升级过程本身正常完成，更重要的是，升级过程中数据安全性得到保障，生产应用程序能在升级后的数据库中无故障地运行。通过采用成熟的流程和技术将宕机时间和失败风险降到最低。
1.2 方案选择
数据迁移模式：新建10G环境，通过数据移植的模式实现数据库升级。手工直接升级：手工直接升级方法，在目前现有生产主机上安装10gR2数据库介质，在割接当天配置CRS环境，安装CRS补丁，配置网络环境，把数据库升级为10.2.0.4版本。该方案的实施有一定的风险，因为手工直接升级的步骤很多，为防止升级过程中任何一个环节的失败，必须准备备用环境作为升级失败时升级回退的备用系统。如果不能具備备用环境，不建议在关键业务系统上使用该方案。
业务支撑系统CRM和BOSS系统的数据库升级同时需要从HP平台迁移到AIX平台，技术方面必须采用数据移植的方式才能完成。在这种背景下，经过多方联合测试，最终决定采用SharePlex数据库复制软件承担前期数据同步工作，利用软件+手工迁移的方式实现“不停机”的跨平台数据库升级和数据迁移，保证割接时间控制在10个小时内，同时需要考虑割接回退等应急方案，利用数据库复制软件的反向同步功能，实现原有数据库数据的及时更新，升级失败直接用启用原数据库即可。
2 方案介绍
“不停机”的跨平台数据库升级和数据迁移方案，通过中间数据库实现基础数据同步和迁移，规避了前期数据同步期间对正常生产的影响，中间数据库利用原系统BC备份搭建，服务器和原系统的主机、数据库保持一致，配置比原系统低很多。该方案采用数据分级模式组织实施，通过中间数据库实现历史数据（静态数据）和基础数据的准备，前期准备工作完成后通过SharePlex软件保持活跃数据的准实时同步，正式割接时待数据同步完成后即可实施割接，割接同时启用反向同步机制，确保升级失败回切时原库数据的准确性。
2.1 实施步骤
前期准备：
调整生产库，中间库和目标库的数据库参数，为配置SharePlex做准备；使用sa_ocap工具分析生产库归档日志确认表的使用频率，划分复制队列；在生产库，迁移目标库上安装、配置SharePlex；在迁移目标库上停止SharePlex复制软件的数据加载进程；在生产库上激活SharePlex配置文件开始复制。
2.2 建立中间数据库
使用利用原生产的BC备份，创建生产库到中间库的数据镜像；停止生产库到中间库的镜像同步；从生产库中select当前的SCN号；将中间数据库恢复到前一步骤取得的SCN号，并打开（在中间库open前要设置job_queue_processes=0，这样可避免数据库open时job自动运行）。
2.3 启动生产库到迁移目标库的复制
在目标库上打开SharePlex的post进程，开始追加新增数据至目标库；校验两端数据库数据是否一致，应用和软件同时校验；压缩表数据迁移（SharePlex不支持压缩表同步）。
3 方案优势描述
1）减少整个项目的实施时间，通过SharePlex设计方案，停机时间由传统方案所需要的30多个小时降低到8-10小时，而其中的绝大部分时间为数据校验时间。
2）建立了风险回退机制。通过SharePlex设计方案，整个迁移过程都是可控的，原有生产环境保留，升级过程中失败直接启用原有生产系统即可。升级完成后利用同步软件进行反向同步，保持新老环境数据一致。割接完成后，如果应用在新的运行环境中出现问题，可以回退到原有系统环境，极大地降低了项目实施风险。
3）提供了数据安全性保障。从迁移方案原理的角度，SharePlex通过RMAN+SCN号进行初始化同步，SCN号可以唯一定位Oracle数据库的某个时间点，能够保证在线操作且数据没有丢失；在项目实施过程中，采用了双重数据校验方法，有效地保障了数据一致性。首先在数据同步后通过SharePlex for Oracle实现了联机的数据检验，另外，在应用切换前，采用了count（*）的方法对表进行数据校验。
4）测试环境即为割接后生产环境，在升级完成并进行了充分的测试后，才将用户转移过来，所有由于升级过程意外故障所引起的延误都得以消除。
4 项目实施效果
业务支撑系统CRM、BOSS数据库升级项目整体历时3个月，由于方案选择合理，整个割接过程控制在8小时内，达到项目预定目标。
参考文献：
[1]陈一匡，数据库技术教学心得点滴[J].电脑学习，2009（03）.
[2]姜延文，基于J2EE技术的呼伦贝尔学院教务管理系统分析与设计[J].呼伦贝尔学院学报，2009（01）.
[3]邓德贵，交换分区在业务支撑系统数据库迁移中的应用[J].计算机系统应用，2009（05）.