而业务需求的快速变化又对信息系统提出了如下挑战：
1) 高速的业务发展，导致产生海量的核心数据、交易量的快速上升；
2) 业务类型的不断增加导致了对核心应用系统的频繁更改。网上银行、手机银行、微信银行等新应用系统的投产及与已有系统的融合，导致每次应用变更时都会对 packages 进行大量 rebind。
3) 业务形态的多样性，业务地域的广阔性，对银行核心系统的要求早已从原来的提供 8*5 小时的服务发展为7*24的服务要求。
以上这些挑战要求银行核心信息系统在不断变化中，同时要保持业务的高可持续性。
随着信息系统灾难备份和业务可持续性设施的逐步建设、完善。因非计划宕机影响业务可持续性的几率逐渐降低而计划内停机成为影响业务可持续性的唯关键因素。
所以目前核心应用系统的变更已经成为影响业务连续性的最重要的因素。我们通过对核心应用系统变更的进一步分析发现，由于大量的应用变更涉及到数据类型的更改，table 表结构的更改，与数据库相连程序的重新绑定等等，因此应用变更中数据库变更在整个变更时间中占了最重要的部分。所以如何能够通过优化，减少数据库操作中的时间，提高关键路径上作业的运行时间，增加并发，减少冲突成为减少应用变更时间，提高业务可连续性的关键因素。
下面提出以下几点关于如何提高金融行业业务连续性的思路以供大家参考学习：
一.DDL 操作
DDL 操作（比如 CREATE TABLE，ALTER TABLE 等）大多是应用变更的第一步，相关的数据迁移，程序绑定等等操作都基于 DDL 变更的完成，因此它是关键路径上的关键一步。提高 DDL 操作效率的主要优化建议包括：
1) 对于新建的 TABLE，在应用变更开始之前就提前创建。新建表与现有应用系统一般没有关联，因此不必占用宝贵的变更窗口时间，可以提前创建完成。
2) 将所有需要进行 DDL 操作的作业按照 DATABASE 进行分类。因为 DDL 操作会更改 DBD lock，而 DBD lock 是以 DATABASE 为范围的。同一个 DATABASE 下的 DDL 操作顺序进行以减少冲突，而不同 DATABASE 下的 DDL 操作可以并行进行以提高并发度，减少运行时间。
3) 在 CREATE INDEX 时使用 DEFER YES 的参数，创建完成后利用 REBUID INDEX utility 来实现 INDEX 的最终创建。客户的 INDEX 往往会非常大，当利用正常的 CREATE INDEX 语句创建 INDEX 时，生成 key 值的动作会耗费非常长的时间，同时后续的 PACKAGE BIND/REBIND 操作由于 INDEX 没有创建也无法进行。而 DEFER YES 这个参数创建 INDEX 时只是创建了 INDEX 的一个逻辑结构，并没有真正的去生成每一个 key 值，因此速度非常快。INDEX 逻辑结构创建完成后，就可以开始后续的 PACKAGE BIND/REBIND 等操作，大大减少了等待时间。同时 REBUID INDEX utility 可以并行生成 key，在很多情况下其效率要远好于 CREATE INDEX，INDEX 逻辑结构创建完成后用 REBUID INDEX utility 能够进一步节省创建 INDEX 所需的时间。
二. 数据迁移
数据备份（COPY）和迁移（UNLOAD/LOAD）是应用变更中另一比较耗时的步骤。加快其性能的建议主要有 2 点：
1) 通过在 partition level 运行 COPY/UNLOAD/LOAD 等作业，尽量提高它的并行度以节省运行时间。
2) 也可以利用 DSNTIAUL 程序进行 UNLOAD，这样 UNLOAD 出来的数据已经是按照 clustering index 的顺序排序好的，再 LOAD 回去的时候可以避免 SORT。
三. Package
BIND/REBIND PACKAGE 是新程序或变更程序投产使用前的最后一个步骤，BIND/REBIND 的过程涉及到对 DB2 catalog，directory，plan table 等多个系统表的读取或更改，因此主要优化建议有：
1) 应用变更提前 REORG plan_table, SYSIBM.SYSPACKAGE, SPT01 等相关表以提高其读取或更改时的性能。
2) 先 BIND/REBIND 联机程序，然后 BIND/REBIND 批量程序。客户业务开门营业往往指的是运行基于 CICS 的联机程序，因此先 BIND/REBIND 联机程序已保证业务开门，然后进行批量程序可以进一步节省相关时间。
四. DB2 Catalog 统计信息同步
数据迁移完成后，传统的做法是运行 RUNSTATS utility，收集数据分布的相关信息，然后 BIND package。但当数据量比较大的时候，RUNSTATS 运行的时间较长。而 RUNSTATS 不完，就发布进行下一步 BIND 操作，新安装或变更的程序也就无法运行，因此延长了整个变更时间。在这种情况下可以考虑将在测试系统中的 DB2 Catalog 统计信息利用 IBM 提供的示例程序 DB2PLI8 手工同步到生产系统中。
原文：http://blog.chinaunix.net/uid-25723371-id-4677685.html