核心数据库版本升级策略及步骤

较短停机时间方法：
1. 搭建新的V10.5的系统
2. 数据复制；
3. CDC数据同步；
4. 生产系统停机切换。
这个方法可以实现较短停机时间。另外如果追求极限短停机时间，还可以通过在线日志复制方式，实现更短停机窗口。

有更多需求，可以联系新数科技: http://www.newdt.cn/

常规方法：
1. 生产系统停机
2. 升级9.1-9.7;
3. 升级9.7-10.5
这个方法停机时间较长,常规升级方法下， DB2 不支持直接从9.1升级到10.5.收起

那一般就是按我前面说的方案来做，这是比较成熟可行的方案，还可以考虑用Q复制代替CDC来同步。这种方案可是实现停机在分钟级别。收起

回复 10# 新数科技
这种方式，里面如果有存储过程之类的话，怎么处理，导出来重建？收起

回复 8# 新数科技


   库大概1T，停机窗口越小越好。这个升级计划暂时不着急。需要提前做些准备工作。收起

你们的数据库大小是多少？ 停机窗口是多久？收起

这个非常规方案是比较成熟的，当然比常规方案要复制，详细的方案需要根据需求来制定。建议咱们直接沟通。收起

回复 5# 新数科技


   常规方法我们是了解的，大版本升级跨度不超过2个版本，根据您推荐的方法是否有较为详细的步骤或者案例呢，核心系统比较重要，我们想寻找一种成熟的解决方案，和较为详细的解决方法。还希望您不惜笔墨多多指导。收起

用lv做裸设备的话可以考虑使用镜像，停库后splitvg，再做升版。回退的话用回旧vg数据。
理论上的应该是可行的，没验证过。收起

我做过的是8.2迁移到9.7
9.7到10.5

不过核心系统完全不同了吧，我没有经验，如果想升级时间尽量短，应该要用到存储的特性做备份。我迁移的系统可以接受的停机时间比较长，所以用的普通的backup restore方式升级的。

我们核心是大型机的，所以升级迁移的方法也没有什么可以借鉴的，我就不瞎支招了。收起

我是用8.1迁移到10.5
9.7迁移到10.5收起