ORACLE数据库跨平台升级方案研究和实施12李灿召 孙玉晶（1.中国移动通信集团 吉林有限公司 业务支撑中心 吉林 长春 130021；2.中国移动通信集团 吉林有限公司 长春分公司 吉林 长春 130000）摘 要： 随着关系型数据库的不断发展和新技术的引入，数据库作为各行业的数据核心和业务枢纽，数据量呈几何倍数膨胀，超TB级数据库不再鲜见。
数据量的膨胀导致后续的版本升级和系统迁移更难操作，结合实际操作经验，从时间、风险和应急策略等方面入手，详细阐述大数据量数据库跨平台升级方案的研究、选择和实施，在实际的操作过程中取得良好的效果，具有一定的参考价值。
关键词： ORACLE；数据库；升级；数据迁移中图分类号：TP311 文献标识码：A 文章编号：1671－7597（2012）1110109-012010年基于系统发展实际需要，决定对业务支撑系统数据 2 方案介绍库进行升级，核心CRM和BOSS核心数据库由9i升到10G，服务器“不停机”的跨平台数据库升级和数据迁移方案，通过中更换为IBM平台，存储更换为EMC，CRM和BOSS数据库作为业务支间数据库实现基础数据同步和迁移，规避了前期数据同步期间撑系统的数据中心和业务枢纽，其升级方案的选择尤为重要。
对正常生产的影响，中间数据库利用原系统BC备份搭建，服务CRM和BOSS数据库容量均超过10TB，实际数据量都在5TB左右，器和原系统的主机、数据库保持一致，配置比原系统低很多。
项目要求在完成新、旧系统切换的同时进行垃圾数据清理、分该方案采用数据分级模式组织实施，通过中间数据库实现历史布规划和权限优化。
数据（静态数据）和基础数据的准备，前期准备工作完成后通1 方案选择过SharePlex软件保持活跃数据的准实时同步，正式割接时待1.1 影响因素数据同步完成后即可实施割接，割接同时启用反向同步机制，确保升级失败回切时原库数据的准确性。
业务连续性挑战：业务支撑系统是24x7全天候运行的系统，宕机不仅意味着大量的收入损失，同时严重影响公司的服务形象。
经过业务评估，本次迁移过程中能够承担的最大停机时间不超过12小时。
数据安全性挑战：吉林移动业务支撑系统数据的重要性是不容置疑的。
升级后数据将迁移到一个全新的系统，需要从实现机制上保障数据安全性，同时提供数据校验机制。
项目风险挑战：10G升级涉及到很多因素，包括业务影响、新版本的Bug、10G新特性、平台变更、应用变更、参与人员等等。
确保应用在10G环境的平滑运行是一个非常大的挑战。
上述因素对核心系统升级技术方案提出很高的要求。
数据库升级过程将关注两个关键因素：升级的成功完成和可能导致的宕机时间。
成功不仅仅是指升级过程本身正常完成，更重要的是，升级过程中数据安全性得到保障，生产应用程序能在升级后的数据库中无故障地运行。
通过采用成熟的流程和技术将宕机时间和失败风险降到最低。
1.2 方案选择数据迁移模式：新建10G环境，通过数据移植的模式实现数据库升级。
手工直接升级：手工直接升级方法，在目前现有生产主机上安装10gR2数据库介质，在割接当天配置CRS环境，安装CRS补丁，配置网络环境，把数据库升级为10.2.0.4版本。
该方案的实施有一定的风险，因为手工直接升级的步骤很多，为防止升级过程中任何一个环节的失败，必须准备备用环境作为升级失败时升级回退的备用系统。
如果不能具备备用环境，不建议在关键业务系统上使用该方案。
业务支撑系统CRM和BOSS系统的数据库升级同时需要从HP平台迁移到AIX平台，技术方面必须采用数据移植的方式才能完成。
在这种背景下，经过多方联合测试，最终决定采用SharePlex数据库复制软件承担前期数据同步工作，利用软件+手工迁移的方式实现“不停机”的跨平台数据库升级和数据迁移，保证割接时间控制在10个小时内，同时需要考虑割接回退等应急方案，利用数据库复制软件的反向同步功能，实现原有数据库数据的及时更新，升级失败直接用启用原数据库即可。
图1 升级方案示意图2.1 实施步骤前期准备：调整生产库，中间库和目标库的数据库参数，为配置SharePlex做准备；使用sa_ocap工具分析生产库归档日志确认表的使用频率，划分复制队列；在生产库，迁移目标库上安装、配置SharePlex；在迁移目标库上停止SharePlex复制软件的数据加载进程；在生产库上激活SharePlex配置文件开始复制。
图2 SharePlex配置示意图注：此时原生产端日志捕捉已开始，目标端未开始同步。
2.2 建立中间数据库（下转第111页）设定位孔，定位孔根据煤层仰俯角进行设计，孔深9～15米，孔在110201工作面与回撤通道贯通前10米时先在进入回撤通道的内及时充填白灰，值得注意的是如果不充填白灰或充填不及各个入口设置栅栏，禁止人员入内。
其次，我矿在110201工作时，就会出现塌孔造成定位孔报废，工作面与回撤通道贯通必面使用了由山东浩珂矿业安全产品有限公司生产的柔性树脂纤须首先保证顶板的精确贯通与工作面底板不高于回撤通道的底维网，该网一次性铺设在工作面后，生产过程中不再需要进行板这一基本原则，一般来说顶板贯通允许的误差在-200mm～联网作业，避免了作业人员使用金属网时频繁运网和频繁进入+200mm之间，超出这个范围就会对工作面回撤造成一定影响。
煤壁侧进行联网作业的现象，提高了作业人员安全保障性。
保证工作面底板不高于回撤通道的底板是因为往往由于受采动 5 结束语影响，回撤通道的顶板均会出现不同程度的下沉，导致回撤通枣泉煤矿通过120203、110201两个大采高综采工作面对双道的高度不能满足安全回撤的最低要求，如果贯通时工作面的回撤通道回收技术的现场实践与探索，取得了显著的效果，不底板低于回撤通道的底板，我们就能利用机械化对回撤通道迅仅提高了经济效益和社会效益，而且利用防爆铲车与支架搬装速完成起底作业从而重新使回撤通道底板与支架底座平齐，使运车快速装车外运工作面设备等手段，实现了前所未有的工作回撤通道的高度符合要求。
面快速回撤，为兄弟单位高产高效矿井建设提供了值得借鉴的4.2 工作面超前压力对回撤通道的影响参考。
随着工作面不断向前推进，提前掘好的回撤通道必然会受总之，大采高双回撤通道回收技术原则上适用于所有具备到工作面采动影响，出现顶板下沉、两帮鼓出、巷道变形等受胶轮车运输的大采高工作面，但由于各矿地质条件与工作面布压现象，甚至可能造成回撤通道漏顶等恶性事故的发生，这就置各不相同，在实际应用中还需不断创新，继续完善，灵活选要求我们在回撤通道最初掘进的时候增加其支护强度，保证支用。
护质量且不亦过早施工回撤通道。
另外，根据各矿地质条件及巷道受压规律不同，可在回撤参考文献：[1]国家安全生产监督管理总局，煤矿安全规程，北京：煤炭工业出通道掘好后再架设“一梁二柱”或“一梁三柱”∏形钢梁棚子版社，2006，11.对回撤通道进行加强支护，根据我矿110201工作面经验，最好[2]任秉刚，综采生产管理手册，北京：煤炭工业出版社，1994，12.是在回撤通道完工后就对其进行加强支护，否则支护效果将不甚理想，往往事倍功半。
作者简介：4.3 人员安全管理郑文伟（1984-），男，大学本科，采煤助理工程师，2004年毕业工作面与回撤通道贯通前随着工作面不断向前推进，中间于安徽理工大学采矿工程专业，现任神华宁夏煤业集团有限责任公司枣煤柱的宽度迅速减小，导致工作面片帮煤成倍增加，这就给进泉煤矿生产技术科技术员。
入煤帮的作业人员人身安全造成巨大威胁，针对以上问题我矿接启用原有生产系统即可。
升级完成后利用同步软件进行反向同步，保持新老环境数据一致。
割接完成后，如果应用在新的运行环境中出现问题，可以回退到原有系统环境，极大地降低了项目实施风险。
3）提供了数据安全性保障。
从迁移方案原理的角度，SharePlex通过RMAN+SCN号进行初始化同步，SCN号可以唯一定位Oracle数据库的某个时间点，能够保证在线操作且数据没有丢失；在项目实施过程中，采用了双重数据校验方法，有效地保障了数据一致性。
首先在数据同步后通过SharePlex for Oracle实现了联机的数据检验，另外，在应用切换前，采用了图3 中间库示意图count（*）的方法对表进行数据校验。
使用利用原生产的BC备份，创建生产库到中间库的数据镜4）测试环境即为割接后生产环境，在升级完成并进行了像；停止生产库到中间库的镜像同步；从生产库中select当前充分的测试后，才将用户转移过来，所有由于升级过程意外故的SCN号；将中间数据库恢复到前一步骤取得的SCN号，并打开障所引起的延误都得以消除。
（在中间库open前要设置job_queue_processes=0，这样可避 4 项目实施效果免数据库open时job自动运行）。
业务支撑系统CRM、BOSS数据库升级项目整体历时3个月，2.3 启动生产库到迁移目标库的复制由于方案选择合理，整个割接过程控制在8小时内，达到项目预在目标库上打开SharePlex的post进程，开始追加新增数定目标。
据至目标库；校验两端数据库数据是否一致，应用和软件同时校验；压缩表数据迁移（SharePlex不支持压缩表同步）。
参考文献：3 方案优势描述[1]陈一匡，数据库技术教学心得点滴[J].电脑学习，2009（03）.1）减少整个项目的实施时间，通过SharePlex设计方案，[2]姜延文，基于J2EE技术的呼伦贝尔学院教务管理系统分析与设计停机时间由传统方案所需要的30多个小时降低到8-10小时，而[J].呼伦贝尔学院学报，2009（01）.其中的绝大部分时间为数据校验时间。
[3]邓德贵，交换分区在业务支撑系统数据库迁移中的应用[J].计算2）建立了风险回退机制。
通过SharePlex设计方案，整个机系统应用，2009（05）.迁移过程都是可控的，原有生产环境保留，升级过程中失败直（上接第109页）生产数据库中间数据库新生产数据库。