ORACLE数据库跨平台升级方案研究与实施.docVIP

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进程，开始追加新增数据至目标库；校验两端数据库数据是否一致，应用和软件同时校验；压缩表数据迁移（SharePle