cuxiong8996

ibm bpm开发手册_使用IBM DB2示例解决IBM BPM性能问题

ibm bpm开发手册

本系列重点介绍您可以从IBM®Business Process Manager（BPM）中的BPMDB数据库中学到什么，以防止出现问题并解决问题。本系列的前两部分重点介绍IBM DB2。第1部分描述了用于Linux®，UNIX®和Windows®的IBMDB2®的数据库维护，统计和分析的技巧。现在，第2部分展示了使用IBM BPM和使用IBM DB2 for Linux，UNIX和Windows的BPMDB数据库的常见故障排除方案的七个示例。第3部分重点介绍数据库维护，统计信息和分析技巧，以对IBM BPM和使用Oracle的BPMDB数据库进行故障排除。

在第1部分中，您了解了用于Linux，UNIX和Windows的IBM BPM和IBM DB2的数据库维护和统计信息，系统中的流程实例数，系统任务，存储的快照数，JDBC驱动程序版本，硬件和环境。限制和相关性能测试，详细的故障排除分析，以及调试BPMDB数据库问题所需的数据摘要。默认情况下，存储与业务流程定义（BPD）处理相关联的运行时数据的数据库称为BPMDB。本系列介绍BPMDB数据库，但不介绍同样属于IBM BPM的CMNDB（消息传递和BPEL处理）和PDWDB（性能数据仓库）数据库。

通过适当的计划，可以防止影响性能的问题被流程参与者和其他最终用户报告。第2部分显示了一些常见情况的七个示例，以便您可以防止问题并解决IBM BPM和使用IBM DB2 for Linux，UNIX和Windows的BPMDB数据库的问题。您可以查看解决常见问题的有用过程示例。在许多情况下，这些示例中的步骤足以获得对问题所在位置的充分了解并真正解决问题。

示例1：数据库查询的性能降低

通常，当管理员发现数据库查询的性能降低时，他们会怀疑数据库方面存在延迟。但是，当您初次调查时，性能问题的根源并不总是很清楚。有时，Process Portal用户登录并且该页面无法长时间构建。这种性能问题是由数据库中的大量条目，浏览器问题，IBM BPM系统上的高负载还是其他原因引起的？

如果您认为问题可能与数据库有关，则最好的方法是涵盖IBM BPM和数据库方面。在最坏的情况下，您可能会花一些时间徒劳地收集一些数据。但是，与客户合作的IBM团队看到的场景仅集中在一侧，并且故障排除工作持续了数周之久。基于这种经验，值得您花时间收集大量数据，以便快速找到解决问题的方法。

以下跟踪设置可以帮助您发现IBM BPM产品和数据库系统之间的大多数问题： WLE.*=all:com.ibm.bpm.*=all:WAS.clientinfopluslogging=all:org.springframework.jdbc.*=all

如果已经确定了运行缓慢的查询，则可以使用db2exfmt选项运行db2support命令。如下例所示，可以将运行缓慢的查询作为sql_file运行db2support命令：

db2support output_directory -d database_name -sf sql_file -cl 1

指定-cl 1启用收集db2exfmt信息。请参阅“ 收集DB2编译器问题的数据”支持文档。

db2support命令在运行时收集其他背景信息，这可能非常有用。

例如，从db2exfmt输出中，您可以看到执行了表扫描而不是索引访问。并非每个表扫描都不好。如果您几乎需要表中的所有数据，则表扫描比索引访问要有效得多。但是，您的方法取决于情况。在大多数情况下，如果应用程序设计良好，则索引访问很有用。图1中的db2exfmt输出示例显示了优化程序用于查询LSW_BPD_INSTANCE_DATA表的访问路径。

图1. db2exfmt输出示例

如果仍然不清楚是什么导致系统变慢，请考虑使用软件包高速缓存或快照信息将问题缩小到IBM BPM产品或数据库系统，这将在以下各节中进行介绍。

考虑使用索引的其他警告和注意事项。 IBM BPM包含多个索引。您可能看不到产品随附的特定索引的好处，但是您可能看不到使用它们的将来方案。从支持的角度来看，产品随附的所有索引都应已准备就绪。删除任何默认索引都会导致性能问题，这将使组织花费不必要的时间来意识到已删除索引，将它们取回并进行系统调优。

为了提高特定业务案例的性能，可能有必要创建更多的自定义索引。 IBM BPM在几种不同的场景中使用，并且在一种场景中引入的索引可能不适用于另一种场景。因此，由组织来决定什么是最适合在产品附带的索引上应用的。 IBM不能在所有情况下都包含所有索引，因为尽管索引可以改善读取访问权限，但是每个其他索引都会在更新条目时带来额外的延迟。

要确定可能丢失的索引，请使用DB2 Design Advisor（ db2advis命令），如以下示例所示。 db2advis命令可以提供索引建议。在示例中，给出了数据库（ -d ），带有SQL语句（ -i ）和5分钟时间限制（ -t ）的文件。删除索引时要特别小心。 db2advis命令集中于作为输入提供的查询。可能还会使用其他显示延迟的查询，因为由于db2advis命令的建议而删除了索引。删除索引之前，请彻底检查这些查询。

以下示例显示了如何运行db2advis命令以获取索引建议：

db2advis -d BPMDB -i MySQLstatement.txt -t 5

重要的是要了解IBM BPM包含内部结构，例如“选择更新”，以防止对相应行进行任何修改。在某些情况下，长时间运行的“选择更新”表示流程设计中的某些功能未按预期工作。例如，您同步调用一个外部服务，并且该服务的响应时间很长，这可以使该语句保持不变，直到可以运行最终提交为止。在这种情况下，在数据库服务器上运行explain命令找不到任何进一步的信息，因此请检查IBM BPM跟踪以了解实际触发了什么。

示例2：在数据库上锁定争用

存在许多可能导致数据库系统上的锁争用的方案。要关联在IBM BPM系统和数据库服务器上完成的活动，您需要跟踪双方。

IBM DB2提供了锁定事件监视器，该监视器很好地概述了锁定争用涉及哪些语句。为了简化IBM BPM和DB2之间的匹配，请将该选项与历史记录和值一起使用，以便捕获传递的参数。在Linux，UNIX和Windows的DB2的锁定事件，第3部分 developerWorks教程中描述了如何设置DB2锁定事件监视器。

图2中显示了示例输出。锁事件监视器的输出示例显示了锁持有者和请求者。关于运行的语句的更多详细信息显示在图2所示的输出下方。在某些情况下，所涉及的语句可以帮助您确定根本原因。

图2.锁定事件监视器的输出示例

从IBM BPM系统方面，具有以下设置的跟踪可以洞悉触发了哪些操作：

WLE.*=all:com.ibm.bpm.*=all:WAS.clientinfopluslogging=all:org.springframework.jdbc.*=all

使用IBM BPM产品跟踪，可以将数据库操作与IBM BPM服务器上的活动相关联。因为重点放在IBM BPM中的BPMDB数据库上，所以这些示例不涉及BPEL应用程序的详细信息。但是，当您寻找BPEL应用程序的锁争用时，以下跟踪设置可能会有所帮助：

*=info:org.springframework.jdbc.*=all:WAS.clientinfopluslogging=all:com.ibm.bpe.*=all: com.ibm.task.*=all

常见的锁定事件监视器错误情形是针对BPMDB数据库中的IBM BPM产品数据库表运行的定制查询。由于查询非常复杂，因此会长时间阻塞相应的表。 IBM BPM产品跟踪不涵盖这种查询，但是它显示在锁定事件监视器数据收集中。看到方程式的两面总是好事。

请注意，不支持也不建议对IBM BPM产品数据库表运行定制查询，除非IBM支持团队出于诊断原因而请求它。 本教程系列中作为示例提供的示例语句仅用于诊断目的。使用示例可以更好地理解数据分布。示例语句通常不会对系统性能产生重大影响，但是为了防止锁争用，请以uncommitted read隔离级别运行语句（在语句末尾提供with UR参数）。 uncommitted read将读取尚未uncommitted read条目，这具有以下优点：该语句不会导致所选行的锁定。未提交的行的结果集中稍有差异，这些行随后被吊销，这与调查无关。

示例3：从网络问题或数据库响应缓慢读取超时

当您将IBM BPM系统连接到数据库时，通常还涉及网络。由于IBM BPM与IBM DB2支持团队之间的通信通常很紧密，因此考虑这两个系统可以轻松识别网络层中的问题。如果部门之间存在结构性障碍，或者使用了不同的数据库供应商，请考虑以下方法来确定网络层中的问题。

由于任何事情都可能是潜在的问题，因此建议您对所有方面进行跟踪，尤其是因为问题会随着时间而变化，并且不一定总是具有相同的根本原因。网络跟踪可以帮助识别请求是发送还是接收。有几种产品是用于捕获和分析网络跟踪的有用工具，包括Wireshark。

考虑图3中的一个示例，其中出于安全目的发送了网络数据包并且混淆了目标地址。 Wireshark跟踪可以显示是否发送了数据包。对于生产系统，数据量可能会变得很大，并且相应的筛选可以帮助限制合格数据。您可以过滤可能阻碍成功完成数据库操作的已知问题，例如，重新提交数据包。

了解系统拓扑非常重要，因为IBM BPM系统和数据库系统之间的所有内容都是导致性能问题的潜在根本原因。防火墙，网络交换机和防病毒软件是三个容易被忽视的组件。另外，请考虑硬件问题，例如有故障的网络适配器或电缆损坏。

图3. Wireshark跟踪示例，显示了发送的传输控制协议（TCP）请求

示例4：包高速缓存信息和DB2快照

您可以使用DB2数据库包高速缓存信息来分析性能问题并确定有问题的语句，而不会对系统造成重大影响。 developerWorks文章Ember Crooks撰写的在Linux，DB2和Windows版DB2中为问题SQL挖掘程序包缓存提供了一些示例查询，这些查询可用于识别瓶颈。

对于本教程，请略微调整Ember Crooks文章中示例的master query #1 。使用substr(SQL_TEXT,1,20)表示法时，仅打印SQL语句的前20个字符，这对于IBM BPM系统而言可能不够用，因此仅将字符串替换为SQL_TEXT列名。

这种方法对于识别最常导致性能问题SQL语句至关重要。

在图4所示的示例中，没有重大延迟，因为平均执行时间少于2秒。当然，还有一些改进的空间。在现实世界中大多数性能至关重要的情况下，数字都大得多。

图4. DB2控制中心中的包缓存语句的示例输出

使用包高速缓存的一种替代方法是使用DB2快照信息。

请参阅IBM知识中心上的IBM DB2文档中的GET SNAPSHOT命令主题，以获取有关DB2快照的详细信息。

您可以使用以下示例步骤创建数据库快照，这对于故障排除非常有用。完成以下步骤，收集数据库快照以标识长时间运行的查询。必须启用计时，这是默认设置。

使用以下DB2命令启用监视开关并重置监视数据：

db2 update monitor switches using timestamp on
db2 update monitor switches using lock on
db2 update monitor switches using bufferpool on
db2 update monitor switches using sort on
db2 update monitor switches using statement on
db2 reset monitor all for DB BPMDB

让您正在调查的问题发生。通常，此过程需要几个小时才能完成。由于没有记录大量数据，因此影响不大。
在问题结束时，请通过运行以下命令将快照复制到文件中：
db2 get snapshot for all on BPMDB > snapshot-for-all.txt
db2 "SELECT * FROM SYSIBMADM.TOP_DYNAMIC_SQL ORDER BY AVERAGE_EXECUTION_TIME_S DESC FETCH FIRST 20 ROWS ONLY" > top20sqls.txt
使用以下命令再次关闭监视器开关：

db2 update monitor switches using timestamp off
db2 update monitor switches using lock off
db2 update monitor switches using bufferpool off
db2 update monitor switches using sort off
db2 update monitor switches using statement off

数据库快照信息通常提供足够的数据以标识长时间运行的查询。如果有任何迹象表明数据库延迟，请与数据库管理员讨论进一步的步骤。在某些情况下，索引可以提供帮助。在其他情况下，也有必要检查数据分布或相关查询。例如，IBM BPM应用程序中的流程参与者无法监视从数据库请求的2000万个数据集，因此查询那么多数据集没有任何意义。如果修改查询，则可以减少对数据库系统和IBM BPM的影响，后者需要处理从查询返回的数据。

快照收集示例中隐含了SYSIBMADM.TOP_DYNAMIC_SQL数据库管理员视图。还有更多视图可以帮助您分析问题。请参阅IBM DB2文档中支持的管理SQL例程和视图。

示例5：DB2内存中监视

DB2 Linux版，UNIX版和Windows V9.7版引入了新的内存中监视概念，以取代传统的快照生成。几个配置参数会影响行为。本教程简要概述了这些功能，但是您可以在IBM DB2文档中看到更多信息。

您可以使用以下两个SQL语句来查询内存中的监视：

db2“ call monreport.dbsummary（300）”，它是300秒监视间隔的数据库摘要
db2“ call monreport.pkgcache（30）”，它是对最近30分钟内更新的所有动态和静态SQL语句的查询

图5显示了空闲系统的dbsummary报告的一部分。该示例输出仅针对从IO，缓冲池和锁定部分提取的最近300秒的dbsummary用于内存中的监视调用。

图5.示例dbsummary报告

优点是您只需要运行一个命令即可获得有关系统使用输入和输出，缓冲池，锁定以及示例中未显示的其他参数的完整概述。运行命令非常简单，并且对于一些系统问题（包括数据库硬件的限制或锁定行为）特别有用。

这是来自现实世界的例子。 IBM团队与一家组织合作，观察到一条有问题SQL语句，该语句很容易在内存中的报告中标识出来，并且在多次执行期间select t0.USER_ID,t0.USER_NAME,t0.FULL_NAME,t0.PROVIDER from LSW_USR_XREF t0 where UPPER(USER_NAME) = UPPER(?)了整个DB2服务器CPU时间的60％： select t0.USER_ID,t0.USER_NAME,t0.FULL_NAME,t0.PROVIDER from LSW_USR_XREF t0 where UPPER(USER_NAME) = UPPER(?)

查询的主要问题是UPPER()函数，该函数需要进行表扫描。在这种特定情况下，可以在表中创建可由索引访问的生成的列。（请注意，在此过程中无法访问数据库表。）要解决该示例问题，请首先备份数据库，然后运行以下命令：

db2 "reorg table LSW_USR_XREF use tempspace1"
db2 "set integrity for LSW_USR_XREF OFF NO ACCESS CASCADE IMMEDIATE"
db2 "alter table LSW_USR_XREF add column USER_NAME_UP VARCHAR(256) generated always as (UPPER(USER_NAME)) NOT NULL"
db2 "set integrity for LSW_USR_XREF immediate checked FORCE GENERATED"
db2 "create index username_up_idx ON LSW_USR_XREF (USER_NAME_UP)"

运行命令后，查询将使用索引扫描而不是上一个示例中使用的表扫描。

确认更改很重要。在某些情况下，您可能需要在其他表上运行完整性检查，以便不阻止这些表，这将阻止受影响表上SQL语句成功运行。

请参阅针对JR51631的 IBM BPM修复程序，该修复程序可以减少查询的执行次数。

示例6：IBM Performance Analysis Suite

IBM Performance Analysis Suite工具可以帮助您更好地了解有关配置和运行时数据的数据库相关信息。工具并不需要消除理解性能故障排除的基础，但可以帮助您更快地发现潜在的问题区域。有多个选项可分析数据库产品设置。本教程重点介绍两个简单的示例。

以下示例使用SQL语句读取程序包缓存信息，查询程序包缓存信息以进行IBM Performance Analysis Suite分析：
select * from table(mon_get_pkg_cache_stmt('d',null,null,-2)) as t where t.num_exec_with_metrics <> 0

该输出可以导入到IBM Performance Analysis Suite中，并且输出如图6所示。它显示了IBM Performance Analysis Suite窗口，该窗口随包缓存语句的输出一起加载。标记了平均索引逻辑读取的临界值。这些值可以很好地指示索引缺失或索引使用方式不佳。

对于已捕获的语句之一，读取的行的字段标记为红色。使用此标记，可以轻松查看大型结果集，然后再根据原因进行更深入的研究。在某些情况下，不需要大型结果集，但是由于没有明确考虑它们而出现。您可以看到，与IBM BPM上下文中的典型查询相比，该语句的执行时间也很大。

图6. IBM Performance Analysis Suite中的输出包缓存语句示例

下一个示例显示IBM Performance Analysis Suite如何连接到数据库系统并检查相应的设置（请参见图7）和对象信息（请参见图8）。在对象信息示例中，未收集LSW_SYSTEM_SCHEMA的统计信息。缺少的统计信息以红色标记。

图7.连接到数据库系统并检查IBM Performance Analysis Suite中的配置

图8.连接到数据库系统并在IBM Performance Analysis Suite中读取表信息

示例7：检测日志

检测日志是另一个可帮助您解决性能问题的工具。 IBM支持文档＃1613989描述了如何使用检测日志。

图9中的示例显示了长期运行的数据库查询，这些查询由Andy Fedotov编写的IBM BPM仪器日志报告工具（IRLT）可视化，从而简化了仪器日志数据的解释。标识特定的语句可能仍需要跟踪。在IRLT工具的示例输出中，您可以看到几个数据库请求使用的总时间最多。需要确定（例如，通过跟踪）为什么有这么多请求，或者是否可以提高特定语句的性能。

图9. IRLT工具的示例输出以及本教程中的示例数据

结论

您回顾了七个对IBM BPM中的BPMDB数据库进行故障排除的示例。几乎所有这些示例都可以在其他情况下使用。

本系列中的声明适用于通过IBM BPM V8.5.6发布的当前版本的所有IBM BPM版本。尽管预计不会有重大变化，但将来的发行版可能需要对SQL语句进行调整。

要了解有关在具有Oracle数据库的环境中进行故障排除的信息，请参阅第3部分。

致谢

作者要感谢Richard Metzger和Torsten Wilms对本教程的评论和建议。任何包含的错误仅是作者的错。

作者还感谢Ember Crooks的工作，他为Linux，UNIX和Windows的DB2中的问题SQL编写了Mining your package cache ，以及为IBM BPM编写了Instrumentation Log Report Tool的 Andy Fedotov。

翻译自: https://www.ibm.com/developerworks/bpm/bpmjournal/1509_volz2-trs/1509_volz2.html