彩票走势图

文 | 刘汉槟

大数据量和高吞吐是银行内容管理系统长期设计的核心问题，本文通过内容管理系统在农信银行后督系统的设计和实现实例 (基于 DB2V97 数据库)，描述对于内容管理系统如何针对每天大约 400 万个图片、可能存放 15 年达到 2PB 文件规模的大数据量系统进行数据模型设计、表分区以及压缩的具体设计实现，以及系统在高并发下一些实际问题的处理，系统上线后吞吐量和性能得到了客户的认可，可以为类似的银行系统提供重要的参考。

前言

本文是对使用 IBM 内容管理系统为平台的广东农信银行客户后督系统的分析和介绍，以及对大数据量和高吞吐的基于 DB2 数据库的 IBM Content Manager 系统的一些设计上的分析以及一些实际问题的解决，系统在调优后性能和吞吐量满足的客户的需求，可以作为类似系统的参考，但是要注意，每一个系统都有自己独特的需求和实际情况，本文无法涵盖您在系统建设过程中的所有问题。

另外，将来实际系统中在数据量达到一定量级时，可能会碰到新的难题，我们希望能和客户一起协作解决并将经验分享给大家。第 2 部分，我们将着重介绍实例问题和分析解决的办法供类似系统参考。

对于实例系统中出现的与性能和高并发相关的关键问题的分析和解决

在客户的实际后督生产系统中，在系统工程师的努力下，经过了对网络、存储、DB2、WAS、TSM 和 CM 的调优以后，依旧在高吞吐和为此设计的高并发的系统中发现了两个棘手的问题，严重影响了性能，并造成了一些 CM 孤儿数据 (Orphan data) 很难被处理，这些问题虽然不一定会在每个系统中都出现，但一旦出现解决起来耗时耗力，在客户和 IBM 支持人员的协作下，问题得到了圆满的解决，本文借此机会感谢所有参与解决这些问题的客户和 IBM 支持人员，并将问题和分析解决的思路共享出来，可以供有类似问题的高吞吐高并发内容管理系统参考。

问题一. 启用迁移后资源数据库占用 CPU 达到 100%

此时 I/O，网络资源都很充足，根据对动态 SQL 语句的监控，发现大量并发操作会执行同一条语句。

清单 1. 造成 CPU100%问题的 SQL

此语句的访问计划 (Access plan) 虽然使用了如下的索引 TRAN_ID_X1，但是访问的行数巨大并造成了巨量的逻辑读，经过分析是造成 CPU 资源占用过大的根本原因。

清单 2. 调优前访问计划

分析 RMTRANSACTIONS 表可以发现此表是 VOLATILE 类型的表，并且有三个索引：

主键索引包含 (OBJ_COLLID, OBJ_ITEMID, OBJ_VERSION, OBJ_LIBRARYID, TRANSACTION_DATE) 字段。

索引 TRAN_TMP_ID_X0包含 (OBJ_TMP_COLLID, OBJ_TMP_ITEMID, OBJ_TMP_VERSION) 字段。

索引 TRAN_ID_X1包含 (TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 字段。

根据清单 1 内动态 SQL 语句的写法，访问执行计划可能使用两种路径，路径 1 就是现在清单 2 中使用的索引 TRAN_ID_X1，路径 2 就是在或 (or) 条件中使用主键索引和索引 TRAN_TMP_ID_X0。

由于 RMTRANSACTIONS 表是 VOLATILE 类型的表，VOLATILE 代表这个表是变动非常频繁的表，统计信息已经不能正确反映实际的数据量，DB2 在表的查询时候只要有满足条件的索引，会忽略统计信息，优先使用索引，这个表的特点就是资源数据库有事务发生时候会记录相应的事务记录，事务结束后会删除相应的记录。

所以一般情况下记录很少或者为 0，当打包迁移发生时，会在短时间内有大量事务产生，记录数可能在 0 到几万条之间频繁变化，非常符合 VOLATILE 表的特性，而且这三个索引都有期望的 SQL 语句会经常使用，索引的设计和定义也没有问题。那么问题出在哪呢?

我们结合迁移的场景仔细分析这个 SQL 语句，会发现，索引 TRAN_ID_X1(TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 影响的查询条件是 TRANSACTIONID<>?，业务的含义是寻找有没有其他的 TRANSACTIONID 和现在要使用的是否有相同的。

对于一个迁移事务，对应的表内应该没有相同的 TRANSACTIONID 或者至多一条，所以在这个<>? 的条件中，将会在索引扫描后对基础表做全表扫描去匹配剩下的条件 (比如 OBJ_ITEMID) 等，这样一来，使用这个索引的结果就是做了一次索引的全扫描加上全表扫描，这样就会造成大量的行读，这样我们就分析出来错误的根本原因是在客户的现场环境中对于 RMTRANSACTIONS 这张 VOLATILE 表没有找到最优的访问计划，实际上数据分析的结果应该是选用路径 2 的访问计划，这样索引扫描的结果应该是几乎为 0 的记录数，也就基本没有任何表扫描。

由于是 VOLATILE 表，此表本身统计信息长期为 0 不具备参考价值，优化器有可能会根据系统的各个条件选取路径 1 或者路径 2，我们测试的系统中都选择了高效的路径 2，但是客户的实际系统中还是有一定的可能选择路径 1，即使选用路径 1 这个问题也不一定都能暴漏出来，只有迁移的并发吞吐达到一定的量级 (比如每秒迁移超过 1000) 才可能会呈现出来，DB2 本身也对这种极少可能发生的访问路径选取异常设计了解决方案。问题分析出来以后，剩下的就是使用 DB2 提供的 OPTPROFILE 的方案去强制为清单 1 的 SQL 指定路径 2 的索引方案。

下面是建立 OPTPROFILE 的步骤：

1.创建 SYSTOOLS.OPT_PROFILE 表

2.创建 PMR35104.PROF1.xml，包含 SQL 的 GUIDELINE

3.创建文件 profiledata，内容为”PMR35104″,”PROF1″,”PMR35104.PROF1.xml”

4.将 profiledata 装载到 systools.opt_profile 表中;

5.检查 SQL 语句是否走了新的索引。

6.检查 db2exfmt_alan_exfmt_opt.out 文件，查看执行计划是否如清单 3 所示。

清单 3. 调优后访问计划

从清单 3 左下部分中我们可以看到，查询的访问计划已经转而使用我们希望的主键索引和索引 TRAN_TMP_ID_X0 做索引查询。

由于资源数据库的应用是部署在 WAS 上的，在 DB2 服务端设置完后，需要对 WAS 端进行设置，使得 WAS 连接数据库的应用使用 PMR35104.PROF1。

图 1. WAS 应用 OPTPROFILE

添加定制属性：

属性名：optimizationProfile

属性值：PMR35104.PROF1

定制完成后，需要重启 WAS 服务器。

结论：在使用了 DB2 的 OPTPROFILE 的方法之后，进行测试后发现开启单个 WAS 集群应用服务器后数据库服务器的 CPU 使用率在 5%左右，4 个应用服务器同时启动后，CPU 使用率大约在 20%左右，网络的吞吐量能达到 400-500MB/秒, 迁移数量每个应用服务器都为 800 笔/秒左右，完全能满足客户的业务需求。

问题二. CM 装载存在孤儿数据

如前文所述，客户系统中每天白天需要装载 400 万图片项，有 10 台客户端上载程序同时工作上传，每台客户机有 10 个进程同时上载，也就是总共有 100 个进程同时上载文档图片，并且使用 4 组 WAS ND 集群服务器，每个集群包含 4 个节点。

在批量上载过程中，每导入几千万的数据，总会有一些孤儿数据产生，经过分析，这些孤儿数据产生的原因是，产生问题的几条数据，每条数据对于同一个上载任务，有时间很近的两条上载任务向资源服务器发出请求，虽然由于主键约束系统会拒绝其中的一条，但实际进入的一条时间戳会产生不一致，检验工具会把这条数据标记为孤儿数据。

经过诊断分析，CM 本身不会对同一条上载记录做重复上载命令，最终认定是由于 RM 使用集群，IHS 使用安装时默认的转发功能导致，建议将 IHS 上的重新转发功能取消。具体表现为同一个请求在一个节点上执行超时(默认为 60 秒)，IHS 可能将该请求转发不同的节点上，而不同节点上的数据信息不一致，导致 CM 报错并产生脏数据(包括孤儿数据)。对 WAS 的具体修改如下：

修改 IHS 的配置文件 plugin-cfg.xml，将其中的 ServerIOTimeout=”60″ 、PostBufferSize=”64″修改为 ServerIOTimeout=”300″ 、PostBufferSize=”0″。这样设置表示，IHS 上的请求在 300 秒内没有收到 WAS 的响应，不会自动进行转发，会报超时错误。

修改 WAS 应用服务器的 ServerIOTimeout 参数(读/写超时)的值为 0，即读写超时时不转发请求。

图 2. WAS 修改读写超时

修改 CM 库数据库 ICMNLSDB 的 ICMSTSYSCONTROL.MAXTXDURATION 字段，默认是 86400(24 小时)，将其修改为较小值，IBM 建议不低于 7200 (2 小时)。该值表示 CM 事务执行的间隔等待时间。(update ICMSTSYSCONTROL set MAXTXDURATION = 7200 where LIBRARYSERVERID = 1)

结论：通过优化后的性能测试验证，该设置起效，CM 多线程并发装载再没有出现脏数据。 小结 通过本文第 2 部分的介绍，我们可以了解 CM 高吞吐高并发实例系统中几个特殊疑难问题的分析和解决方法。