银行影像内容大数据系统设计与实例问题分析

第一部分：设计篇

前言

本文是对使用 IBM 内容管理系统为平台的广东农信银行客户后督系统的分析和介绍，以及对大数据量和高吞吐的基于 DB2 数据库的 IBM Content Manager 系统的一些设计上的分析以及一些实际问题的解决，系统在调优后性能和吞吐量满足的客户的需求，可以作为类似系统的参考，但是要注意，每一个系统都有自己独特的需求和实际情况，本文无法涵盖您在系统建设过程中的所有问题，欢迎联系我们做进一步探讨。另外，将来实际系统中在数据量达到一定量级时，可能会碰到新的难题，我们希望能和客户一起协作解决并将经验分享给大家。第一部分, 我们将着重介绍系统背景需求以及设计。

中英文术语对照表/缩略语

IBM 内容管理系统：英文名 IBM Content Manager，简称 CM。

广东农信影像化事后监督系统：简称广东农信后督系统。

库数据库：英文名 Library server database，简称 LSDB。

资源数据库：英文名 Resource manager database，简称 RMDB。

资源管理应用程序：英文名 Resource manager application，简称 RMApp。

项类型：英文名 Itemtype。

资源项类型：英文名 Resource itemtype。

文档项类型：英文名 Document itemtype。

项：英文名 Item。

项级别：英文名 Item Level。

访问控制列表：英文名 Access control list，简称 ACL。

本地索引：英文名 Local index。

表分区分离：英文名 Detach partition。

级联目录：英文名 Hierarchical folder。

系统及架构简述

IBM 内容管理系统，是一套基于数据与内容的企业级整体行业解决方案平台，它能够帮助企业快速地解决复杂的问题，在当今瞬息万变的市场环境中更快速地制定高效的决策。客户可以利用 IBM 内容管理系统产品方便的做到：对各种原始票据、凭证、档案、影像等海量的非结构化数据的存储和管理；数据的生命周期管理；并且可以支持基于内容的分析与查找，高级案例管理，和流行的社交内容管理。

广东农信影像化事后监督系统是提供给全省各农合机构事后监督中心和网点使用，是监督各项业务处理的正确性、合规性、真实性和完整性，及时发现各种核算差错事故，暴露业务核算中发生的各种违章、违纪、违法行为，完善业务操作风险控制体系，实现差错处理的电子化流转，实现凭证的电子化管理的一整套管理系统。系统主要包括影像处理、重点监督、再监督、风险预警、差错处理流程管理，实物档案流程管理等功能，使用 IBM 内容管理平台实现对影像数据存储的生命周期管理，满足用户对大数据量历史影像数据的实时在线调阅需求。

经过前期的数据收集和业务估算，广东农信后督系统全省上线后，日均凭证影像张数将达到 400 万张，最近 60 天的凭证影像经常会发生调整、修改信息、整改差错的业务操作。而从系统建设层面考虑，日均 400 万张的凭证影像将导致系统的记录数和数据量非常庞大，需要考虑多个影像文件打包成一个大文件后部份读取的可能性，恰好 CM 的聚合迁移支持这种打包操作。如果按照会计档案需保管十五年的要求，广东农信后督系统影像文件的总存储空间将达到 2PB，为保证数据的读取效率同时兼顾项目建设成本，广东农信规划了如下的后督系统影像文件总体存储策略：

存储宿主	后督系统 （10 台文件服务器）	CM 在线 （LBOSDATA）	CM 近线 （CM TSM 存储卷）	CM 离线 （CM TSM 磁带卷）
存储介质	SAN 存储	NAS 存储	NAS 存储	磁带库
存储期限	60 天	7 天	22 个月	如果按照会计档案需保管十五年的要求，那么 CM 离线数据的存储期限将达到 13 年
存储模式	同一日期同一网点同一柜员几百张影像形成的一个大数据包	具体一张一张的影像	CM 聚合迁移形成的 300 张影像一个文件的大数据包	CM 聚合迁移形成的 300 张影像一个文件的大数据包

根据广东农信后督系统的实际使用需求，广东农信还规划了影像数据的生命周期管理时间窗口要求，具体为：后督系统影像文件装载至 CM（两个小时） CM 影像文件迁移至 TSM（两个小时） TSM 存储卷迁移至磁带卷（四个小时）。

针对广东农信后督系统影像文件的总体存储策略和影像数据生命周期管理的时间窗口要求，结合后督系统、CM 内容管理平台的扩展性（除了 CM 的索引库不能扩展，其他都可以扩展），加上 IBM 工程师的指导，广东农信设计了满足此高吞吐大数据量的 CM 系统架构。

具体为：

CM 数据库服务器采用 HA(High Available) 架构，每个数据库服务器节点包含 1 个库数据库和 4 个资源数据库、每个资源数据库对应的资源管理应用程序采用 WAS cluster 架构，保证资源管理应用程序的并发性和扩展性，每个 WAS cluster 由一个 Dmgr 管理并分配 2 台物理服务器，每个物理服务器节点下有两个应用服务器，这样对于每个 WAS cluster 共四个应用服务器。同时，整套 CM 系统内部采用万兆网连接，TSM(Tivoli Storage Manager) 服务器也采用 HA 架构，确保影像数据生命周期管理的时间窗口要求以及高可用要求。下图 1 展示了一个内容管理系统比较通用基于 AIX 的 HA 系统架构图 (包含多个 RM 和 RMApp)：

图 1. 系统架构图

数据模型的选型以及表分区的设计

根据计算，广东农信后督系统如果满负荷上线，大约每天需要装载 400 万条数据，每月 1.1 亿，每年约 13 亿数据，IBM 内容管理系统的一些表会相应的有这个数量级的记录，如此大的表会带来可能的一些问题，比如维护 (备份、Runstats、Reorg 等) 时间长等。另外当数据量达到一定的量级时，整个系统也可能会有一定的性能下降。我们要从数据模型设计以及数据库逻辑物理设计上尽量降低这种发生的可能性，或者能支持更大量的数据，比如银监会要求的 15 年数据。首先，我们根据业务的需要去设计数据模型，以下是几点可供参考的考虑：

• 选择合适的项类型

内容管理系统支持两种主要带文件的项类型：资源项类型和文档项类型。资源项类型相对简单，每个项只能带一个文件，但是相对文档项类型来说，每一个资源项类型可以减少操作至少 2 张大表，相对应的在超过 10 亿的海量数据量的系统来说，同样的设计，装载和其他业务的效率会更高，也更能节省空间，同时降低维护时间，所以对于海量数据的系统，如果能满足业务需求，我们更建议使用资源项类型存放扫描的文件。另外，对于需要建立多个类似项类型的设计，建议把一些共用的属性先建立一个属性组存放起来，这样能更方便的建立项类型。

• 资源数据库均衡负载设计

对于多个营业网点的数据，有时候为了便于管理，希望通过一定的机制把不同的营业网点的数据通过不同的资源管理应用程序导入到不同的资源数据库里，这样便于权限管理和分担一定的负载。我们可以把库数据库的默认存储设置为用户级别，如图 2 所示，然后为每一个营业网点或网点组建立一个装载用户，为每一个装载用户设置一个默认的 Collection 和相应的默认项访问控制列表，然后对于新建的项类型，选择使用项级别的检查级别，并使用用户默认 ACL 检查 (User’s default ACL)，参考图 3，然后用相应的用户做装载数据，就可以控制数据装载在不同的资源数据库。

• 建立合适索引

对于业务查询常用的属性项，需要建立相应的索引以加快查询和获取数据的速度。

• 减少不必要的关系

如果没有需求，可以不建立目录、连接、引用、级联目录等复杂的关系，这些都会影响将来可能会实现的表分区分离的可能性。

• 文件聚合迁移到 TSM

如果对文件没有修改的需求，并且都是最大几兆的小文件，大数据影像系统可以考虑使用 CM 提供的聚合迁移功能，聚合迁移会将文件按照打包大小的设置进行打包后迁移到 TSM 中，会大大减少过量小文件产生的网络问题和 TSM 服务器的压力，并大大降低 TSM 数据库的数据量和维护成本。

图 2. 库数据库默认存储设置

图 3. 项级别 ACL 检查以及用户默认 ACL 设置

另外，对于可预见的大表将来的使用和维护，我们建议使用 DB2V97FP1 以上的表分区方案，好处是可以更好的分时间段存放数据，更灵活的分配物理资源 (盘阵等)，同时可以利用 DB2V97FP1 之后支持的表分区中的本地索引减少维护的时间空间，对于业务模型合适的系统，将来甚至可以做到将超过一定时间不常用或者只读的数据从在线业务系统之中分离出去，然后导入到另一个内容管理系统中，降低在线系统的数据量。对于表分区的设计，我们已经有相应的白皮书和文章 (请参考参考资源) 做了系统的介绍，本文这里只介绍一下广东农信的现在应用的实例，也就是在 CM843 系统里对于一个只包含一个资源项类型的实例系统的表分区设计。

1. 首先找到固定的大表

   固定的大表包括库数据库的 ICMSTITEMS001001 和资源数据库的 RMOBJECTS 表。

2. 其次找可能的大表

   对于激活了历史版本文档的设计，库数据库需要增加大表 ICMSTITEMVER001001 表，对于使用的连接关系的表 (比如使用了目录文档结构) 需要增加大表 ICMSTLINKS001001 表，如果使用了文档类型的项类型，需要增加大表 ICMUT00300001 表和 ICMRI001001 表，如果使用了级联目录关系，那么需要增加大表 ICMSTHLINKS 表。

3. 动态表名的大表

   下面介绍一下如何找到一个具体项类型元数据实例表。

   --取得 Itemtype ID，假设项类型名字是 ITNAME1
   select keywordcode from icmstnlskeywords where keywordclass=2 and keywordname ='
   ITNAME1'
   --取得 ComponentType ID
   select * from icmstcompdefs where itemtypeid = '1004';

   注意：1004 应该是第一步取得的值，请用实际值替换。假如 COMPONENTTYPEID 实际值是 1007，项组件类型实例表就为 ICMUT01007001。有几个 COMPONENTTYPEID，就对应有几张 ICMUT0XXXX001 表，其中 XXXX 为 COMPONENTTYPEID。

4. 表分区分区频率设计

   根据内容管理系统数据库的特点，上述大表都有包含有时间戳的 ITEMID 字段或者类似字段，以及 DB2 对表分区键选取按时间分区的建议，我们可以选取 ITEMID 或者类似的字段作为表分区的分区键，表分区可以按一定时间间隔分区，比如按月分区、按季度分区、按年分区等，对于一个月有 1 亿数据量的系统来说，我们可以选取一个月一个分区的设计。

5. 表分区初始分区以及结束分区的考虑

   分区并不是无限的，所以总会有开始分区并且有结束分区，那么我们又希望结束分区不要包含太多时间段的数据，那么最好先和客户沟通一个第一次做表分区的时间段，比如客户希望系统至少运行 10 年，以 2013 年 1 月到 2022 年 12 月为例，我们先要为 0-2013 年 1 月 1 日 (不包含结束日期) 建立初始分区，这个初始分区包含内容管理系统的一些初始数据和可能的临时数据，假设命名为 PSTART。然后中间是每个月一个分区一直建立到 2023 年 1 月 1 日 (同样不包含结束日期)，最后需要建立一个结束分区 (如名字为 PEND) 从 2023 年 1 月 1 日一直到 MAX(最大时间) 作为封尾分区。需要注意的是，如果在系统使用年限接近到达第一次划分预期的结尾时间时，比如提前 1 年的 2021 年底选取业务空闲时期停止业务，分离现有封尾分区 PEND, 创建新的 5 年或者其他年数的表分区，然后用新的预期系统最终使用时间一直到 MAX 重新封尾。

6. 表分区中用户自定义的索引设计

   如果用户的数据模型中需要对一些字段做检索，最好使用系统管理客户端去为这些字段建立相应的索引，这样索引内就会自动加入 ITEMID 作为索引的一部分，这样就可以使用本地索引，这样会对分区维护和性能对会有好处。如果用户想自己使用数据库命令为数据模型的相关实例表建立自己的索引，应该在 IBM 服务团队的支持下进行，对于表分区的情况，建议尽量在索引定义中加入 ITEMID 字段，当然具体情况需要具体分析。

7. 表及索引压缩

   对于有海量数据的表，在做表分区的同时可以考虑做表的压缩，也可以考虑同时压缩索引，这样会降低磁盘的使用空间，对于瓶颈主要在 I/O 而 CPU 资源充足的系统，表压缩也会以牺牲一定量 CPU 资源的情况下减少 I/O 占用，理论上会产生一定好的效果，实际情况，应该根据性能测试是否满足客户需要去决定最终的方案。

8. 表空间及缓冲池设计

   为表分区的数据和索引分别建立独立的表空间和缓冲池。为索引建立单独的缓冲池好处是，对于海量数据调整数据表空间所在的缓冲池无法调优的情况下，单独调整需要内存较小的索引表空间所在的缓冲池，可能会有比较好的效果。另外即使使用了条带化的磁盘阵列作为数据库物理存储，已经可以做到将数据打散到不同的磁盘已达到 I/O 并行访问的效果，我们还是建议为数据和索引建立不同的表空间 (组)，这样方便维护和管理，比如可以对每年或者每季度的表分区建立一个或几个数据表空间，为所有大表的索引每年建立一个表空间。

ICMSTITEMS001001 表分区示例

我们下面以库数据库里存放所有项基本信息的大表 ICMSTITEMS001001 表为例介绍按月分表分区 (2013 年和 2014 年共 2 年) 的示例，其他大表的表分区可以类似去设计和撰写。

首先，创建存储过程 SET_CONSTRAINTS 可以暂时不检查外键，便于数据表重建。

db2 connect to icmnlsdb user icmadmin using icmadmin
db2 –td@ -vf set_constraints.sql

其次，为 ICMSTITEMS001001 所在的库数据库增大部分缓冲池，并增加一个索引单独使用的缓冲池。注意下列所有缓冲区具体每个缓冲区的大小需要根据你系统实际可以分配给库数据库的内存大小去调整。

--为数据表空间调整现有 bufferpool
ALTER BUFFERPOOL ICMLSMAINBP32 IMMEDIATE SIZE 120000;
ALTER BUFFERPOOL ICMLSFREQBP4 IMMEDIATE SIZE 32768;
ALTER BUFFERPOOL ICMLSVOLATILEBP4 IMMEDIATE SIZE 65536;
--增加新的 bufferpool 为了索引表空间
CREATE BUFFERPOOL ICMLSIDXBP32 SIZE 60000 PAGESIZE 32 K

第三，为 ICMSTITEMS001001 表及其他类似的大表创建单独数据表空间，每年都会用一个表空间存放。表数据将会存放到 LSSTPART20YY(YY 表示年号的后两位，下同) 表空间，索引将会存放在 LSIDXPART20YY 表空间。

--为所有非 2013，2014 年数据建立默认数据表空间
CREATE LARGE TABLESPACE LSSTPART
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSSTPART' 100M)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSMAINBP32;
--建立 2013 年以及 2014 年数据表空间
CREATE LARGE TABLESPACE LSSTPART2013
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSSTPART2013' 10G)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSMAINBP32;
CREATE LARGE TABLESPACE LSSTPART2014
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSSTPART2014' 10G)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSMAINBP32;
--为所有非 2013，2014 年索引建立默认索引表空间
CREATE LARGE TABLESPACE LSIDXPART
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSIDXPART' 1G)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSIDXBP32;
--建立 2013 年以及 2014 年索引表空间
CREATE LARGE TABLESPACE LSIDXPART2013
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSIDXPART2013' 1G)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSIDXBP32;
CREATE LARGE TABLESPACE LSIDXPART2014
 PAGESIZE 32 K MANAGED BY DATABASE
 USING (FILE '/home/db2inst1/db2inst1/ICMNLSDB/LSIDXPART2014' 1G)
 AUTORESIZE YES MAXSIZE NONE 
 EXTENTSIZE 32
 BUFFERPOOL ICMLSIDXBP32;

第四，生成 ICMSTITEMS001001 分区前表的定义。

db2look -d icmnlsdb -i icmadmin -w icmadmin -e -t ICMSTITEMS001001 -o items_part.sql

第五，修改 items_part.sql，为每个表每个月建立表分区，总共创建到 2014 年底共 2 年的表分区。修改后的代码见附件 items_part.sql。

以此为范例，我们可以类似的为所有需要分区的表定义和设计不同分区年数，分区使用的缓冲池，表空间以及分区频率等。

第二篇：实例问题分析篇

前言

本文是对使用 IBM 内容管理系统为平台的广东农信银行客户后督系统的分析和介绍，以及对大数据量和高吞吐的基于 DB2 数据库的 IBM Content Manager 系统的一些设计上的分析以及一些实际问题的解决，系统在调优后性能和吞吐量满足的客户的需求，可以作为类似系统的参考，但是要注意，每一个系统都有自己独特的需求和实际情况，本文无法涵盖您在系统建设过程中的所有问题，欢迎联系我们做进一步探讨。另外，将来实际系统中在数据量达到一定量级时，可能会碰到新的难题，我们希望能和客户一起协作解决并将经验分享给大家。第 2 部分，我们将着重介绍实例问题和分析解决的办法供类似系统参考。

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

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

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

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

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

Statement : SELECT TRANSACTIONID FROM RMTRANSACTIONS WHERE (( OBJ_LIBRARYID = ? AND OBJ_ITEMID = ? AND
OBJ_VERSION =? AND OBJ_COLLID = ? ) OR ( OBJ_TMP_ITEMID = ?
AND OBJ_TMP_VERSION = ? AND OBJ_TMP_COLLID = ? )) AND TRANSACTIONID<>?

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

清单 2. 调优前访问计划

Optimizer Plan:
 Rows 
 Operator 
 (ID) 
 Cost 
 0 
 n/a 
 RETURN 
 ( 1) 
 0.015443 
 | 
 0 
 n/a 
 FETCH 
 ( 2) 
 0.015443 
 / \
 0 0 
 n/a n/a 
 IXSCAN Table: 
 ( 3) RM2ADMIN 
 0.0150991 RMTRANSACTIONS 
 | 
 0 
 Index: 
 RM2ADMIN 
 TRAN_ID_X1

分析 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 表

   db2 connect to rmdb
   db2 "call sysinstallobjects('opt_profiles', 'c', '', '')"

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

   <?xml version="1.0" encoding="UTF-8"?>
   <OPTPROFILE VERSION="9.1.0.0">
   <STMTPROFILE ID="PMR35104">
   <STMTKEY >
   <![CDATA[
   SELECT TRANSACTIONID FROM RMTRANSACTIONS WHERE 
   (( OBJ_LIBRARYID = ? AND OBJ_ITEMID = ? AND OBJ_VERSION = ? AND 
   OBJ_COLLID = ? ) OR ( OBJ_TMP_ITEMID = ? AND OBJ_TMP_VERSION = ? AND
   OBJ_TMP_COLLID = ? )) AND TRANSACTIONID<>?
   ]]>
   </STMTKEY>
   <OPTGUIDELINES><IXOR TABID="Q1"/></OPTGUIDELINES>
   </STMTPROFILE>
   </OPTPROFILE>

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

   vi profiledata
   "PMR35104","PROF1","PMR35104.PROF1.xml"

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

   import from profiledata of del modified by lobsinfile replace into systools.opt_profile;

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

   --RMADMIN 用户登录系统：
   db2stop force
   db2start
   db2 connect to rmdb
   db2 set current optimization profile PMR35104.PROF1
   db2 "set current explain mode explain"
   db2 "SELECT TRANSACTIONID FROM RMTRANSACTIONS WHERE((OBJ_LIBRARYID = ? AND OBJ_ITEMID =
   ? AND OBJ_VERSION = ? AND OBJ_COLLID = ?) OR (OBJ_TMP_ITEMID = ? AND OBJ_TMP_VERSION
   = ? AND OBJ_TMP_COLLID = ?)) AND TRANSACTIONID<>?"
   db2 "set current explain mode no"
   db2exfmt -d rmdb1 -1 -o db2exfmt_alan_exfmt_opt.out

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

清单 3. 调优后访问计划

 Rows 
 RETURN
 ( 1)
 Cost 
 I/O 
 |
 0 
 FETCH 
 ( 2)
 0.0326346 
 0 
 /----+----\
 0 0 
 RIDSCN TABLE: RM1ADMIN
 ( 3) RMTRANSACTIONS
 0.0322871 Q1
 0 
 /------+------\
 0 0 
 SORT SORT 
 ( 4) ( 6)
 0.0164133 0.0164133 
 0 0 
 | |
 0 0 
 IXSCAN IXSCAN
 ( 5) ( 7)
 0.0153824 0.0153824 
 0 0 
 | |
 0 0 
 INDEX: SYSIBM INDEX: RM1ADMIN
 SQL130130132712470 TRAN_TMP_ID_X0
 Q1 Q1

从清单 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 的具体修改如下：

1. 修改 IHS 的配置文件 plugin-cfg.xml，将其中的 ServerIOTimeout="60" 、PostBufferSize="64"修改为 ServerIOTimeout="300" 、PostBufferSize="0"。这样设置表示，IHS 上的请求在 300 秒内没有收到 WAS 的响应，不会自动进行转发，会报超时错误。
2. 修改 WAS 应用服务器的 ServerIOTimeout 参数（读/写超时）的值为 0，即读写超时时不转发请求。

   图 2. WAS 修改读写超时

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

结论：通过优化后的性能测试验证，该设置起效，CM 多线程并发装载再没有出现脏数据。

小结

通过本文我们可以了解 CM 高吞吐高并发实例系统中几个特殊疑难问题的分析和解决方法。