SharePlex“不停机”的数据库升级和平台迁移方案.docVIP

SharePlex数据库迁移方案 数据库的迁移有两种，一种是数据库从较低的版本到较高版本的升级；另一种是因为运行Oracle的主机更换带来的Oracle数据库中数据的迁移。 无论是那种迁移，使用传统的方案需要很长的停机时间，而且迁移的过程需要DBA长期的经验，而且存在着风险。 借助SharePlex软件，通过数据移植的模式实现数据库升级。该方案在搭建新的生产环境同时保留原生产环境，割接后通过反向同步保持新老系统数据同步，割接完成后短时间内故障可以快速实现回切。通过工具软件提供的成熟方法论，可以将升级需要的宕机时间降到最低。如果不考虑数据校验的因素，对生产用户的中断仅限于新旧两套系统的切换，以及激活复制链路的时间（通常不超过几分钟）。解决方案在升级完成并进行了充分的测试后，才将用户转移过来，所有由于升级过程意外故障所引起的延误都得以消除。 解决方案的优势 减少整个项目的实施时间：通过SharePlex升级方案，会极大地减少停机时间，如果不考虑数据校验，基本上可以做到“零”停机。 建立了风险回退机制：通过SharePlex设计方案，整个迁移过程都是可控的，原有生产环境保留，升级过程中失败直接启用原有生产系统即可。升级完成后利用同步软件进行反向同步，保持新老环境数据一致。割接完成后，如果应用在新的运行环境中出现问题，可以回退到原有系统环境，极大地降低了项目实施风险。 提供了数据安全性保障：从迁移方案原理的角度，SharePlex通过RMAN+SCN号进行初始化同步，SCN号可以唯一定位Oracle数据库的某个时间点，能够保证在线操作且数据没有丢失；在项目实施过程中，采用了双重数据校验方法，有效地保障了数据一致性。首先在数据同步后通过SharePlex for Oracle实现了联机的数据检验，另外，还可以在应用切换前，采用了count(*)的方法对表进行数据校验。 精准模拟割接后系统运行情景：测试环境即为割接后生产环境，在升级完成并进行了充分的测试后，才将用户转移过来，所有由于升级过程意外故障所引起的延误都得以消除。 实施方法和步骤 部署SHAREPLEX软件 为了实现“不停机”的数据库升级和平台迁移，需要借用一台中间服务器，这台中间服务器和原系统的主机、数据库的平台必须一致，但配置可以比原系统低。 SharePlex安装配置示意图： 调整生产库，中间库和目标库的数据库参数 使用sa_ocap工具分析生产库归档日志确认表的使用频率，划分复制队列 在生产库，迁移目标库上安装、配置SharePlex 在迁移目标库上停止SharePlex复制软件的数据加载进程 在生产库上激活SharePlex配置文件开始复制 说明： BOSS数据库建了两个实例，第一个为非压缩表数据15个队列，第二个为压缩表数据2个队列。 CRM数据库建了三个实例，第一个和第二个为非压缩表数据，分别建了6个和5个队列，第三个实例为压缩表数据建了2个队列。 队列中的表是按照变化频率划分的，少的只有几个，多得有3千多个。 建立中间服务器： 使用Rman或磁盘镜像技术，建立生产库到中间库的数据镜像停止生产库到中间库的镜像同步 从生产库中select当前的SCN号 将中间数据库恢复到前一步骤取得的SCN号，并打开（在中间库open前要设置job_queue_processes=0，这样可避免数据库open时job自动运行。 建立目标库并倒入数据: 通过exp/imp方式将中间库数据导入迁移目标库（不导索引） 在目标库上重建索引（可采用并行方式），以及其他数据对象 在目标数据上对数据结构和数据库对象进行校验，确认所有对象全部与中间库同步 禁用目标库中约束以及触发器，Job等对象 在目标库上执行reconcile操作，清除SharePlex队列中该SCN号之前的数据 追加数据，启动生产库到迁移目标库的复制: 在目标库上打开SharePlex的post进程，开始追加新增数据至目标库 数据校验： 校验两端数据库数据是否一致 应用测试： 进行应用连接测试 数据库切换： 停止所有应用访问生产库 确认SharePlex复制正常且队列无数据积累 在原生产库上禁用触发器，约束，JOB 在目标库机上激活SharePlex反向配置文件 在目标库上启用用触发器，约束，JOB 启动所有应用访问C库 应用回退方案 如果应用在新的环境中运行出现问题，可以及时回退原生产环境。回退方法如下： 停止所有应用访问目标库 确认SharePlex复制正常且队列无数据积累 启用原生产库被禁用的对象 第1页