一、企业面临的困境
当前IT系统的软硬件迭代越来越频繁，特别是软件产品，客户生产系统中采用的软件都面临原厂的EOS风险。EOS即End Of Support，这是每个客户的IT部门都要面临的运维风险。当生产系统出现问题却又得不到原厂售后服务支持的时候，是一个多么悲催的事情，其中的麻烦谁遇谁知道，所以说跟着原厂的步伐进行大版本更新升级乃上上策。这是一个软件生命周期管理的课题，软件大版本的升级迁移是客户IT运维部门都要接受的重大挑战，同时也是IT运维服务厂商的重大挑战，当然如果IT运维服务厂商有合适的解决方案，那将是重大机遇。
简而言之，促使客户进行大版本升级迁移的两个根本原因：
1.EOS风险，如果不升级将得不到原厂官方的技术支持。
2.新功能新特性的应用，对最新大版本中的某些新特性非常有兴趣。
二、行业解决方案
大部分的金融行业客户使用得最多的是IBM DB2数据库。在网络上关于DB2大版本升级迁移方面的资料并不多，或者说具有指导性建议的文章不多。本文简单介绍一个基于CDC复制技术实现DB2大版本平稳升级的案例，希望能够起到抛砖引玉的作用，达到探讨交流的目的。
众所周知，金融行业的客户对系统要求是7*24小时，对于系统可用性要求非常高，客户对系统升级迁移一般会提出以下三个要求：
1）升级迁移时间窗口要求在分钟级别，新旧系统切换时间尽可能短，如5分钟至10分钟。
2）升级过程中对源数据库（原生产系统）的性能无影响，要保障原系统不会因为升级而导致业务影响。
3）升级失败后要求在分钟级别的时间窗口内回退至原版本运行，并且保障在新系统的变更数据同步回原系统。
如果要满足以上所有要求，传统的升级过程肯定是无法做到的，原因如下：
1）时间窗口无法满足，传统升级过程至少是30分钟，甚至更长。
2）低版本升级到高版本后不可回退，过程是不可逆的。
3）一旦应用切到新版本而且有数据入库，当要切回旧系统版本运行时新数据不能追平。
基于以上原因，那么只能采用IBM的数据复制方案。将常用的IBM数据复制/同步方案比较如下：
数据复制方案 可靠性/可行性分析 备注
HADR 不适用升级迁移，源和目标的版本跨度太大时无法搭建HADR
SQL Replication 无法满足上述要求，需要在源库上创建相应的CD表；首次全量复制对源库有性能影响
Q Replication 无法满足上述要求,首次全量复制对源库有性能影响，即使使用备份还原至目标服务器，后续增量同步时的日志LSN很难找到 这里的LSN是为了定位自上次备份以来的变更数据的事务起点
CDC 完全适用，支持异构平台、大版本、双向复制等 通过bookmark技术，记录自上次备份以来的LSN号，下次CDC同步时仅需复制增量数据
综上所述，我们只能选用CDC软件技术实现。本文的重点就是探讨基于CDC技术如何实现DB2数据库大版本平稳升级迁移。CDC的技术突破在于以下两点：
当首次全量复制同步（源库–>目标库）时，可以通过将源库的备份文件传至目标端进行Restore. 而不是象传统方式（传统做法是每张表先定义然后通过远程导出/导入）做法，这样可以大大减少网络传输开销，以及减轻源库抽数带来的性能的影响。
CDC断点续传功能，即bookmark功能可以标识当前的复制断点，即使源库在“bookmark”操作后有了新变更，CDC可以捕捉到增量的变更数据，下次复制只要从断点开始复制数据即可，既节省了全量复制的时间，同时保证了事务的一致性和连续性。比其他复制方案更智能和先进。
三、CDC是介绍
CDC，现在叫IIDR（IBM Infosphere Data Replication），是一种基于DB2日志的高效复制解决方案，功能强大，使用灵活，可以实现多种方式、多种用途的数据复制，被广泛应用于企业报表、灾难恢复和高可用性环境中。
IBM InfoSphere Change Data Capture ( 以下简称 InfoSphere CDC) 是一个跨不同数据库的实时数据复制解决方案，支持 DB2, Informix，Oracle, Microsoft SQL Server, Sybase, Teradata, SolidDB 等各种主流数据库。InfoSphere CDC 通过读取源数据库的日志获取变化的数据，并经过适当的转换将数据复制到数据目标中。InfoSphere CDC 目标端支持数据库，消息队列、以及 ETL 解决方案（例如 InfoSphere DataStage）等。
从系统性能角度，通过读取数据库的日志来获取变化的数据，InfoSphere CDC 对源数据库造成的影响极低；从系统资源角度，通过仅发送已更改的数据，InfoSphere CDC 还可以减少处理开销和网络流量。从用户体验角度，InfoSphere CDC 提供一个 Eclipse 风格的管理控制台，方便用户轻松创建、配置、监控与管理各种数据复制任务。
总体而言，InfoSphere CDC 主要支持三种数据复制模式，分别为：Refresh、Net change（或称为 Scheduled End）、Continuous mirroring。相关的描述说明与使用场景如表 1 所示。
表 1. 三种 InfoSphere CDC 数据复制模式：
数据复制模式 描述说明 使用场景
Refresh 源数据全部复制到目标数据 常用于初始化数据装载
Net change 基于时间调度复制变更的数据 定期数据复制
Continuous mirroring 实时监控并复制变更的数据 实时数据复制
下面，我们简单描述一下 InfoSphere CDC 的工作原理，如图 1 所示：
初看起来，InfoSphere CDC 的体系结构稍显复杂。总体上，我们可以简单划分为以下几个关键组件：
Datastore Replication Engine： 表示数据库所在的源或目标服务器上运行的 InfoSphere CDC 进程，用于发送与接收变更的数据。我们把发送端进程称为 源捕获引擎(Source capture engine)，接收端进程称为 目标引擎(Target engine)。InfoSphere CDC 支持 Datastore Replication Engine 以多个实例（Instance）的方式同时运行，甚至也可以同时作为源捕获引擎和目标引擎工作。
Access Server：是一组客户机后台进程（Deamon），用于控制客户机 Management Console 对服务器端 InfoSphere CDC 的 UI 交互式访问。当然，InfoSphere CDC 也提供命令行操作接口。
Management Console：如前所述，是一个 Eclipse 风格的管理控制台，方便用户轻松创建、配置、监控与管理各种数据复制任务。通常而言，Management Console 与 Access Server 是一起协同工作的。无论退出 Management Console，或是关闭 Access Server，均不影响 Datastore Replication Engine 的数据复制活动。
Datastore: 可简单理解为源或目标数据库在 InfoSphere CDC 的一种表示法。用户可以通过 Management Console 定义 Source Datastore 与 Target Datastore，并通过 Access Server 进程接收请求，实现与 Datastore Replication Engine 通信，从而启动和管理各种数据复制活动。
四、技术实现
当了解和熟悉了CDC复制技术的架构和原理之后，就可以开始制定DB2大版本升级迁移的流程和步骤。为了保障文章的简洁性，流程步骤简单概述如下：
1）在源端(假设DB2版本为V9.1/V9.5/V9.7)和目标端(假设为V10.5)各自安装CDC相应软件。
2）将源端的最近一次online backup恢复到目标端相应的版本，或者通过DDL创建V10.5版本的空库。
3）在CDC管理控制台中配置源和目标端的复制关系（具体操作参阅CDC管理手册）。
4）导出Subscription定义，并且备份V10.5库中CDC的Metadata表(TS_开头的三张表)
5）在源数据库上执行dmmarkexternunloadstart，用来标记数据导出的起始点。
6）需要重新恢复一次带有CDC bookmark的全备至目标端，前一次恢复是仅仅为了定义复制关系，本次才是关键点。
7）在源数据库上执行dmmarkexternunloadend，用来标记数据导出的结束点。
8）导入步骤4中备份的Metadata表以及CDC的Subscription定义。
9）将目标端的DB2版本逐级升级至V10.5(ESE或PureScale)（假设源库的版本较低，如果为V9.7或以上则忽略此步骤）
10）定义反向复制关系（目标端至源端的方向），在CDC中定义两个方向的同步关系，用于可回退到原版本运行。
11）启动正向复制（源端至目标端的方向），开始进行增量数据的同步。
12）停止所有应用程序（停机的时间取决于应用程序的复杂程度）
13）验证源和目标端数据一致性（停机的时间取决于数据验证和校验的粒度，必须前期做好数据校验的计划和流程，否则无法保障数据库的完整性和一致性）
14）启动反向复制（目标端DB2高版本至源端DB2低版本的方向），当源和目标端数据完全同步后，启动双向复制，保障“双活”情况下数据能完全同步。
15）系统正式切割，启动所有应用程序，但必须保障应用程序要么连接老版本的数据库，要么连接是新版本的数据库。
16）回退机制和流程的启动，如果出现极端情况，应用程序完全可以退回原来版本，恢复如初。