oracle bpm
IBM®Business Process Manager（BPM）是用于处理和编排企业业务任务的平台。 通过适当的计划，您可以防止过程应用程序的最终用户报告性能问题。 本文重点介绍可从IBM BPM中的BPMDB数据库中学到的BPMDB ，以防止问题发生并在出现问题时进行故障排除。
本系列的前两部分重点介绍IBM DB2。 第1部分描述了用于Linux®，UNIX®和Windows®的IBMDB2®的数据库维护，统计和分析的技巧。 第2部分显示了七个常见的故障排除方案示例，这些示例涉及IBM BPM和使用IBM DB2 for Linux，UNIX和Windows的BPMDB数据库。
现在，第3部分将重点介绍Oracle。 了解有关数据库维护，统计信息和分析的技巧，以对IBM BPM和使用Oracle的BPMDB数据库进行故障排除。 为了方便起见，总结了本系列前面部分的一些信息。
数据库维护和统计信息
在对与数据库有关的问题进行故障排除时，首要重点应该放在数据库本身上。 Oracle提供了几种自动工具，可以帮助您创建和维护性能良好的系统。 Oracle包含一个自动工具来收集数据库统计信息。 不幸的是，某些组织的团队禁用了Oracle工具，而没有实施手动方式来收集数据库统计信息。
下面的代码示例显示了两个SQL语句，您可以使用它们快速了解数据库中实际存储的内容。
清单1.查询数据库目录SQL语句
select substr(table_name,1,35) as table_name,
substr(tablespace_name,1,20) as tablespace_name, num_rows,
blocks, empty_blocks, avg_space, chain_cnt, avg_row_len,
last_analyzed from USER_TABLES ;
select substr(ui.index_name,1,35) as index_name,
substr(ui.table_name,1,35) as table_name,
substr(ui.tablespace_name,1,30) as tablespace_name,
substr(uic.column_name,1,35) as column_name,
uic.column_position, ui.status, ui.clustering_factor,
ui.last_analyzed from USER_INDEXES ui, USER_IND_COLUMNS uic
where ui.index_name = uic.index_name order by
ui.index_name, uic.column_position; 这些语句并非特定于IBM BPM，可以在所有情况下与Oracle数据库一起使用。 该语句适用于IBM BPM数据库用户（例如，作为IBM BPM数据源用户，并且SQL *Plus®连接到BPMDB数据库并运行SQL语句）。 存在诸如DBA_TABLES类的其他视图，供数据库管理员使用相应的过滤器查询相同的信息。
以下两个屏幕截图显示了输出。
除了table name ，还请检查last_analyzed列，该列显示上一次为数据库表收集统计信息的时间戳。 如果该条目是视图，或者没有针对数据库表收集任何统计信息，则该列为空。
当前的统计数据对于获得良好的性能至关重要，因为Oracle优化器基于这些数字进行访问路径计算。 错误的统计信息可能会导致错误的执行路径，这需要很长时间才能完成。 除非关闭Oracle优化器，否则统计更新通常由Oracle完成。 有关更多信息，请参阅自动统计信息收集作业和GATHER_SCHEMA_STATS之间的差异 。
SQL语句输出还提供有关所有表的行数和块数的有用信息。 尤其是大量的数据，可能会指出一些性能问题。 在上一个屏幕截图的示例中，您看到了最近设置的系统。 因此，诸如LSW_PO_VERSIONS类的一些表可能具有生产系统的数百万个条目。 检查问题区域以了解问题是否由大量不需要的数据引起。
CHAIN_CNT列（从一个数据块链接到另一数据块的表中的行数）表示如果表号不同于0，则需要重组表空间（这种情况很少见）。
除了表统计信息之外，您还可以查看索引统计信息。 通过索引统计信息查询，您可以查看统计信息，存在哪些索引，包括哪些列以及按什么顺序。
运行诸如收缩或压缩之类的存储空间操作可能导致无效索引。 如下面的屏幕截图所示，输出还列出了索引的状态（某些列已被跳过）。
如果索引处于UNUSABLE状态，则数据库管理员需要重建索引。 索引缺失或不可用会严重影响性能。 在具有一百万行的表中，如果找不到匹配的索引，则可能需要全表扫描。 因此，如果列出的东西不可用，请确保将其直接修复。
还请记住，Oracle提供了基于函数的索引，当SQL语句包含诸如UPPER()类的函数以防止全表扫描时（例如，与IBM BPM一起使用时， UPPER(username) ，这将非常有用。 为了提高性能，您可以要求并创建其他自定义索引，但不要修改产品随附的索引！
要处理多个环境，请实施变更管理约定。 您可以轻松地跟踪不同系统上应使用的自定义设置和索引。 当将新应用程序推广到生产环境时，这种方法还可以防止意外情况，因为在多个环境中索引是不同的。
配置参数
Oracle数据库具有几个影响系统行为的配置参数，包括基于卷的设置（例如分配的内存）和更改事务行为的参数。 对于IBM BPM运行参数，使用默认设置更改了交易行为，该默认设置已在产品上进行了测试。 基于卷的设置取决于业务工作量，因此可能需要进行调整。
以下代码示例显示了一条SQL语句，以概述参数及其当前活动值。 （您必须具有数据库管理员权限才能执行该语句。）
清单2.查询Oracle配置参数的语句
select * from V$SYSTEM_PARAMETER ;以下屏幕截图显示了运行SQL语句的输出示例提取：
上一个截屏中显示的一个有趣的参数是distributed_lock_timeout参数，默认值为60秒。 在某些情况下，您可能会在某些表上观察到锁争用。 尽管经常考虑，但是增加此值通常不是一个好选择，因为它掩盖了事务长时间持有锁的原始问题。
通过增加distributed_lock_timeout值，您只需等待更长的时间来阻止阻塞的锁，与此同时，您可能会获得更多未释放的锁，从而阻塞了其他事务。 主要的问题实际上是事务，该事务不会首先释放您要获取的锁。 这个问题是需要解决的。
提出以下问题：为什么事务将锁保持60秒以上？
答案可能与应用程序有关（例如，同步调用Web服务，其行为就像它永远不会返回一样），与容量有关（例如，表中有8000万条记录，将近99.9％与完成有关）。流程实例），或与有限的基础架构（例如，服务器中的慢速磁盘）有关。
系统中流程实例的数量
完成的流程实例的内务处理问题是一个常见问题。 IBM BPM是运行时产品，不用于归档。 因此，当流程实例完成时，应尽快将其从系统中删除。 如果不对硬件，数据库和系统其他部分进行大量投资，则无法在IBM BPM系统中保留多年的业务数据并保持良好的性能。
本系列的第1部分讨论了SQL语句，这些语句使您可以BPMDB数据库中当前存储的BPMDB 。 有关解释的更多详细信息，请参见第1部分 。
对于SQL语句的Oracle版本，请参见以下示例。 您可以从Github下载示例代码，网址为http://github.com/stephan-volz/database-scripts/blob/master/Oracle_ProcessInstances_Tasks.txt 。
以下SQL示例对数据库中的流程实例和任务进行计数，并按状态和名称对它们进行分组：
清单3.用于查询按快照ID和状态排序的流程实例和任务SQL语句
-- Provides process instances grouped by process instances state
select snap.name as "name",
bpd.snapshot_id as "snapshot id",
code.NAME as "status",
count(bpd.EXECUTION_STATUS) as "number of instances"
from LSW_BPD_INSTANCE bpd
left outer join lsw_bpd_status_codes code on
code.STATUS_ID = bpd.execution_status
left outer join lsw_snapshot snap on
bpd.snapshot_id = snap.snapshot_id
group by snap.name, bpd.snapshot_id, code.NAME
order by snap.name, bpd.snapshot_id, code.NAME ;
-- Provides task states grouped by task steps
select snap.name as "snapshot name",
t.SNAPSHOT_ID,
t.SUBJECT as "subject",
code.NAME as "status",
COUNT(t.STATUS) as "number"
from lsw_task t
left outer join LSW_TASK_STATUS_CODES code on
code.STATUS_VALUE = t.STATUS
left outer join LSW_SNAPSHOT snap on t.snapshot_id =
snap.snapshot_id
group by snap.name, t.SNAPSHOT_ID, t.SUBJECT, code.NAME
order by snap.name, t.SNAPSHOT_ID, t.SUBJECT;下列SQL语句显示了流程实例和关闭的任务之间的联系。 以下SQL语句提供了完整的流程实例和关联的任务。
清单4.用于查询流程实例和相关任务SQL语句（按快照ID和状态排序）
-- Provides completed process instances and associated tasks
select snap.name as "snapshot name",
bpd.snapshot_id as "snapshot id",
count(distinct bpd.bpd_instance_id) as "number
completed PI",
count(ta.status) as "number of closed tasks"
from LSW_BPD_INSTANCE bpd
left outer join lsw_snapshot snap on
bpd.snapshot_id = snap.snapshot_id
left outer join lsw_task ta on bpd.bpd_instance_id
= ta.bpd_instance_id
where bpd.bpd_instance_id = ta.bpd_instance_id and
bpd.execution_status = 2
group by snap.name, bpd.snapshot_id;
– Provides active process instances and associated closed tasks
select snap.name as "snapshot name",
bpd.snapshot_id as "snapshot id",
count(distinct bpd.bpd_instance_id) as "number
running PI",
count(ta.status) as "number of closed tasks"
from LSW_BPD_INSTANCE bpd
left outer join lsw_snapshot snap
on bpd.snapshot_id = snap.snapshot_id
left outer join lsw_task ta on bpd.bpd_instance_id
= ta.bpd_instance_id
where bpd.bpd_instance_id = ta.bpd_instance_id and
bpd.execution_status = 1 and ta.status = 32
group by snap.name, bpd.snapshot_id;如果需要清除已完成的流程实例，则结果可以很好地表明已完成和正在运行的流程实例之间的比率。 始终检查完成的流程实例，以防止性能问题或高端硬件的额外成本。
已用存储空间量
IBM BPM使用二进制大对象（BLOB）来存储更大的对象信息。 数据库系统并不总是释放您删除的流程实例所使用的空间。 此问题可能导致表的大小过大，而内部没有任何实际信息（例如，近空的表为30 GB）。 如果发生这种情况，则需要重新组织数据。 如果您使用的是Oracle安全文件，则重组会变得更加复杂。 对于安全文件，没有公开的BLOB压缩（减少BLOB数据使用的空间）。 数据需要导出，删除和导入。 有关使用内部软件包完成压缩的方法，请与Oracle支持团队联系。
要验证实际使用了多少空间，请参见以下屏幕截图中的语句：
您可以以红色（325 GB）看到分段使用的空间，以绿色看到所需的空间（大约3.7 GB）。 这是一个很大的差异，这是由数据库侧的BLOB处理引起的。 在这种情况下，减少BLOB数据使用的空间无疑是有意义的。
该LSW_STORED_SYMBOL_TABLE中的LSW_STORED_SYMBOL_TABLE是一个有趣的表。 它在处理期间存储变量值。 根据在流程设计中使用局部变量的方式，可以在LSW_STORED_SYMBOL_TABLE和执行上下文表上创建竞争。 确保减少应用程序代码中使用的tw.local变量的数量，因为每次您反映任何更改时，您都访问LSW_STORED_SYMBOL_TABLE和执行上下文。
对于您JavaScript代码，请阅读所需的tw.local变量，并将其分配给JavaScript代码中用于操作的变量。 然后，将值写回到tw.local变量。 如果处理中涉及循环，则此方法特别重要。
系统任务
除人工任务外，IBM BPM还具有直接由系统运行的系统任务。 该行为受系统任务的“ Delete task on completion属性的影响，如以下屏幕截图所示。
该设置将在系统任务完成后立即删除它们，而不是在删除流程实例时在流程生命周期结束时删除它们。 在某些情况下，这些完成的系统任务条目占LSW_TASK表中存储数据的40％以上。 从IBM BPM V8.5开始，默认情况下启用该设置。
当您意识到不再需要大量已完成的系统任务时，可以更改应用程序并慢慢删除现有的系统任务。 要标识受影响的数据库条目，请使用以下语句。
清单5.用于识别潜在系统任务及其状态SQL语句
select user_id, activity_name, status, count(*)
from LSW_TASK group by user_id, activity_name, status;快照数量
瓶颈的另一个潜在领域是系统中存储的快照数量。 （确保检查经常被忽略的工具包快照。）在这种情况下，您可以看到为什么在IBM BPM Process Server而不是IBM BPM Process Center上最好的生产系统负载。 在Process Center上，所连接的应用程序开发人员经常进行应用程序更改，可能会导致系统上出现大量快照。
还应注意快照上下文缓存和分支上下文缓存的调优。 这些高速缓存的缺省值为64。如果活动快照或分支的数量大于64，请遵循IBM Business Process Manager中调整分支和快照高速缓存大小中的建议。
最好的策略是避免任何不需要的数据。 在删除快照之前，请检查IBM Business Process Manager（BPM）支持文档中的BPMDeleteSnapshot和BPMSnapshotCleanup命令问题 。
JDBC驱动程序版本
JDBC驱动程序尽管很少用于故障排除，但对于数据库故障排除可能很重要。 Oracle提供了两种不同版本的JDBC驱动程序，但是只有以_g.jar结尾的驱动程序_g.jar包含在Java虚拟机（JVM）跟踪过程中提供驱动程序信息的调试代码。
在文件系统上添加调试驱动程序并将WebSphere配置设置更改为使用新的驱动程序文件（JDBC提供程序设置）之后，可以使用两种跟踪设置来启用JDBC驱动程序日志记录： WAS.Database=all或com.ibm.ws.oracle.logwriter=all 。
另外，您还必须启用JVM设置，如如何在WebSphere Application Server中启用Oracle JDBC驱动程序跟踪和在WebSphere Application Server中 收集JDBC驱动程序跟踪中所述 。
在某些情况下，驱动程序版本本身就是一个问题。 确保使用最新版本和与数据库服务器相同的驱动程序版本。 检查IBM BPM系统要求和Oracle规范，以了解支持的驱动程序。
硬件，环境限制和性能测试
与IBM客户一起工作的团队通常会发现没有系统扩展或负载测试的系统。 生产系统必须监视总体系统性能，包括CPU，内存，磁盘I / O和网络吞吐量。 有几种工具可用于系统扩展和负载测试。 要在Unix系统上进行故障排除，请考虑使用nmon工具。
有关更多指南，请参阅以下IBM Redbooks出版物： IBM Business Process Manager V8.5性能调整和最佳实践 。
监视不是一次性事件。 它必须永久存在，团队成员必须定期检查数据。 否则，就没有真正的价值或问题预防措施。 来自监视的数据可以使故障排除更加容易。 通过定期监视，您的团队可以预测系统使用情况和潜在的瓶颈（例如，硬盘已满或负载增加）。 例如，今天的系统可能会完美扩展，但是下个月可能会有一个新的批处理作业，其中包含500万个新流程实例。
当不同的团队使用IBM BPM，数据库或网络时，至关重要的是，所有团队都必须了解所需服务的可用性。 当整个系统被阻止时，请验证数据库是否已启动，可以从IBM BPM服务器调用轻型目录访问协议（LDAP）服务器，并且可以访问任何所需的后端系统。 端口更改或防火墙更新之类的小更改可能会阻止处理。 不要依赖问题单系统。 确保一切都在系统上正常工作。
与IBM BPM客户一起工作的IBM团队经常会看到开发团队，如果他们只执行了这些监视步骤，这些团队本来可以解决问题。
当与数据库的连接无法正常工作，或者建立了大量的连接，并且处理速度很慢时，您可能会遇到内存不足的情况。 当连接池完全用完时，也会发生这些问题。 数据库连接显示在堆内存转储和Java核心文件中，但是您仍然必须确定问题的根源。
IBM BPM端的大量内存使用可能是由于不精确的应用程序查询导致将数百万行作为结果集而引起的。 IBM BPM产品生命周期的改进限制了该产品在IBM BPM系统与数据库之间传输的数据。 确保您使用的是最新版本的IBM BPM，以从最新改进中受益。
还请考虑连接池的大小。 如果在应用程序或系统上运行负载测试并且连接用完，则可能需要将连接池大小更改为更大的值。 有关起始值的宝贵提示，请参阅《 IBM Business Process Manager V8.5性能调整和最佳实践》 。
对于性能良好的数据库系统，数据库的事务日志存储的I / O速度很重要。 考虑使用固态驱动器（SSD）。
如果遵循所有先前的信息，则可以解决IBM BPM和Oracle数据库的大多数性能问题。 在某些情况下，您可能需要收集更多数据。 以下各节描述了Oracle数据库和IBM BPM方面通常需要的数据，并提供了常见故障排除用例的示例。
详细分析：解决Oracle数据库的性能问题
在Oracle数据库系统上，用于解决性能问题的最主要工具是“自动工作量存储库（AWR）”报告。 此报告基于自动收集的数据库快照，默认情况下每小时捕获一次，并保留8天。 （不要将在Oracle数据库上拍摄的快照与来自IBM BPM系统的快照混淆。）在创建AWR报告之前，必须完成自动收集的数据库快照。
由于AWR报告需要额外的许可证，因此Oracle数据库标准版中包含一个名为StatsPack的备用报告。 以下各节描述了AWR报告，因为它们是使用Oracle的IBM BPM系统的最常见报告。 但是，您可以通过共享Oracle Statspack报告而不是AWR报告来使用StatsPack创建类似的报告。
Oracle示例1：AWR报告
AWR报告中的某些部分与您的IBM BPM环境特别相关。 Oracle数据库具有广泛的调优领域，但是本教程仅关注IBM BPM环境中最常见的问题。 逐案考虑其他领域。
查看AWR报告时，请确保涵盖的时间段也与IBM BPM系统中发生问题的时间相匹配。 AWR报告是基于至少两个快照生成的。 在大多数情况下，一个小时的时间段最适合分析特定性能问题的需求。 请始终在AWR报告的顶部检查生成的报告的时间段。 确保它与问题发生的时间匹配，并将观察结果与时间段相关联。 例如，如果看到5000条SQL语句，则此数字在5分钟内可能很大，但在一个工作日的10小时内正常。
以下屏幕截图显示了一个示例，其中包含一个小时的时间段的AWR报告。
实例效率和紧急等待事件信息
与早期的缓冲池命中率信息相比，新的Oracle等待界面为您提供了更详细和更好的理解。 但是，您还可以查看AWR报告中列出的“ 缓冲区命中率”，如以下屏幕截图所示。
好的比例高于90％，更好的比例高于95％。 重新启动后，需要填充缓冲区，因此重新启动后该比率不好。 即使比率很高，您在系统上仍然会遇到问题，因此请分析Oracle等待界面。
利用Oracle中的等待统计信息，很容易看到数据库系统如何花费大部分时间。 首先， 按“总等待时间”部分检查“ 前十大前景事件”和“ 总等待时间”部分的“ 等待类别” 。 与客户合作的IBM团队已经看到情况，用5位数字表示的AWR报告涵盖了一个小时，可以Swift显示问题所在。
上一个屏幕截图还显示，大部分时间都花在等待CPU上。 相应的数据表明，在最终用户注意到问题之前，监视系统资源以了解诸如CPU争用之类的问题非常重要。
Oracle等待接口部分中的几乎所有等待类，例如Wait Classes by Total Wait Time都可以使用。 因此，AWR报告是首先要检查的基本报告，尤其是当IBM BPM或数据库方面的性能问题时。 在某些情况下，AWR报告中的查询可能还会提示有关IBM BPM问题的信息。
SQL语句信息
AWR报告中的下一个重要部分是SQL Statistics ，您可以在其中查看SQL语句和所请求数据的执行时间。 执行时间具有不同的单位。 有时，为一条语句的所有执行计算时间，而在其他情况下，则是为一条语句执行计算时间。 在确定结论之前，请检查特定部分中列出的内容。
对于单条SQL语句执行，本节中所有花费超过一秒钟的时间，都需要进一步研究。 在某些情况下，可能需要更长的时间。 例如，您可能会收集也可以在此处列出的大型表的统计信息。 或者，您可以忽略每月仅生成一次的月度报告。 但是，如果看到花费大量时间或要求数百万条记录的语句，并且看到这些语句多次发出，请进行进一步调查并解决问题。
以下屏幕截图显示了示例SQL Statistics部分。
这两个语句每次执行分别花费9.31和2.41秒。 在受影响的系统上检查该区域。 缺少索引和缓慢的I / O均可在此问题中起作用。 只要查询的数据库响应很慢，IBM BPM可能就不会更快。
细分统计信息
AWR报告的“段统计”部分是查找大量物理读写，表扫描和行锁等待的地方。 较低的缓冲池命中率也应反映大量的物理读写。 在这种情况下，物理意味着需要从磁盘中获取数据，这比从内存中获取要昂贵得多。
表扫描将读取整个表。 在某些情况下，这种方法很有意义。 如果表不大，或者您需要大多数表内容，则索引访问没有意义。 进行全表扫描没有错误的原因，但这取决于您的情况。
在某些情况下，全表扫描的执行时间很长，因此检查哪些表受表扫描影响是有意义的。 常见的表索引扫描发生在IDX3_GGMX索引上，这是组管理所必需的。
如果您看到特定的等待类正在使用大量时间，请使用搜索引擎检查有价值的提示。 在大多数情况下，可以通过相应的解决方案找到类似的问题。
用户和组还有进一步的改进。 请参阅《 Business Process Manager V8.5中的团队》教程系列 。
锁超时或行锁等待在Oracle中并不像在DB2中那样常见。 但是，仍然有必要知道哪个表包含锁争用。 出现此问题的两个典型表是LSW_LOCK和LSW_BPD_INSTANCE 。
经常在LSW_LOCK表上看到锁争用，如以下屏幕截图所示。
有关更多信息，请参阅“ 为什么我会看到LSW_LOCK表在BPM上发生锁争用？”的条目。 在dW答案上。
LSW_BPD_INSTANCE表上的锁争用很可能是由应用程序中的并行路径创建的。 调用同步服务可能会在相当长的时间内锁定流程实例，而另一个应用程序活动却无法更改流程实例信息。
此类问题需要进行应用程序审查或跟踪，以识别导致锁定争用的活动（在IBM BPM的故障诊断详细信息部分中进一步描述）。
其他有用的信息
Oracle AWR报告中有更多信息。 本教程涉及三个重要的部分，用于解决与性能相关的几个问题。
AWR报告还包括有关内存大小的建议以及有关等待类和I / O瓶颈的信息。 如果您已经知道延迟是由数据库引起的，请与数据库管理员联系，以查看是否还有其他调优步骤。 在某些情况下，例如如果硬件大小不允许使用更多详细的跟踪方法，则可以咨询数据库管理员以解决IBM BPM问题。 如果适合您的情况，您可以从数据库方面获得更多的见解。
Oracle示例2：Oracle alert.log文件
如果问题与功能而不是性能有关，则AWR报告很可能不足以调试问题。
Oracle还有另一个名为alert.log日志文件，其中记录了较大的问题。 如果存在无法独自解决的功能相关问题，请与IBM支持人员检查并共享此日志。 该日志可能包含影响性能的信息，但AWR报告未涵盖该信息。
Oracle示例3：访问计划输出
如果您已经知道特定SQL语句运行缓慢，则需要访问计划输出以查看花费的时间，例如，使用explain命令，如以下屏幕截图所示。
访问计划的输出可能会受到前面介绍的统计信息的影响。 在大多数情况下，特定语句的性能降低与丢失或无效的索引，大数据量，错误的统计信息以及导致的错误访问计划有关。
Oracle示例4：Oracle 10046或10053跟踪
深入研究Oracle数据库性能问题的一种更强大的措施是10046或10053跟踪。
首先要确定有问题的陈述，AWR报告就足够了。 如果对为什么语句以特定方式运行并解释计划（数据库优化器如何运行SQL语句）有疑问，这些跟踪可以提供进一步的见解。
IBM BPM上下文中出现的一个常见问题是缺少会话，因为IBM BPM使用共享数据库连接池，并且无法识别特定的会话。 您需要在完整的数据库上启用跟踪，这可能会对性能产生重大影响。 仔细考虑使用需求（考虑下班时间）和使用的跟踪级别。
或者，如果您知道AWR报告中的sql_id ，则可以将跟踪限制为该特定语句，以大大降低跟踪对数据库的性能影响，并使查找相应的跟踪文件更加容易。
下表和以下代码示例显示了10046跟踪的可能级别设置，以及如何在系统中启用和禁用它。 10046跟踪的主要目标是确定瓶颈。 10053跟踪将更多精力放在优化器计算上。 两者都可能很有价值，具体取决于您的要求。
表1.可以与10046跟踪一起使用的跟踪级别
| 痕量水平 | 描述 |
| 0 | 没有踪影。 就像关闭sql_trace |
| 2 | 等效于常规sql_trace |
| 4 | 与级别2相同，但具有绑定变量值 |
| 8 | 与级别2相同，但带有等待事件 |
| 12 | 与级别2相同，但具有绑定变量值和等待事件 |
以下代码示例显示了使用绑定变量和等待时间来启用和禁用10046跟踪的命令。 请特别注意考虑性能影响。
清单6.在系统级别启用和禁用具有绑定变量和等待时间（级别12）的10046跟踪的命令
SQL> ALTER SYSTEM SET EVENTS '10046 trace name context
forever, level 12';
<recreate the issue>
SQL> ALTER SYSTEM SET EVENTS '10046 trace name context off'; 也可以将跟踪限制为特定的sql_id ，如下面的代码示例所示。 将sql_id替换为SQL语句的ID。 一次仅使用其中一个命令，并禁用跟踪，如图所示。
清单7.为10046或10053跟踪启用特定于SQL语句的跟踪的命令
SQL> -- SQL Trace (10046)
SQL> ALTER SYSTEM SET EVENTS 'sql_trace [sql:sql_id]
bind=true, wait=true';
SQL> -- SQL Trace (10053)
SQL> ALTER SYSTEM SET EVENTS 'trace[rdbms.SQL_Optimizer.*]
[sql:sql_id]';如果特定的语句引起了问题，请考虑使用这种方法。 使用10053跟踪，您可以洞悉使用的统计信息以及优化程序进行的成本计算。 （有关这些高级步骤，请咨询数据库管理员。）
以下屏幕截图显示了10053跟踪的摘要，其中计算了成本。 根据这些数字，优化器确定全表访问还是索引访问的成本更低。
Oracle示例5：ADDM和ASH报告
除了AWR报告外，Oracle还包括其他两个报告：自动数据库诊断监视器（ADDM）和活动会话历史记录（ASH）。
本教程提供了交互和故障排除的基本背景，并且不涵盖这些报告。 您可以使用与AWR报告类似的方式来使用这些报告。 ADDM提供了有关性能改进的建议。 ASH报告提供会话历史记录信息。
在Oracle Database 12c中，ADDM建议包含在AWR报告中。 有关详细信息，请查看Oracle文档。
这些工具可以为您提供有关所需更改或瓶颈的更多指导。 IBM支持团队可能会要求这些报告来诊断和解决特定问题。
详细分析：跟踪IBM BPM系统
要关联IBM BPM系统发送的内容和在数据库端观察到的内容，您需要进行跟踪以了解正在发生的情况。 有几种不同的跟踪设置可用。
以下基本跟踪介绍了一些基本SQL语句信息：
WAS.clientinfopluslogging=all:org.springframework.jdbc.*=all
The WAS.clientinfopluslogging trace is required to log the SQL statements and transaction boundaries. Sometimes there are different versions of org.springframework.jdbc (for example limitations to org.springframework.jdbc.core ).
If you are using the Java Spring Framework, the core part traces the values that are passed to the SQL statement. The database trace subsection tracks when a connection from the data source is acquired and returned. This is valuable information especially for tracking execution. Always use the org.springframework.jdbc.*=all trace setting.
To include the background from where the statement was originally triggered, you also must add the IBM BPM product tracing: WLE.*=all:com.ibm.bpm.*=all:WAS.clientinfopluslogging=all:org.springframework.jdbc.*=all
(Adding the IBM BPM product tracing might affect performance, but is the only way to analyze problems efficiently.)
It is important to check the number of trace files and the size of each trace file. A good trace should cover more than a few minutes and include the problem in question. If an activity lasts 15 minutes, make sure that the trace covers at least 20 minutes, so the complete navigation history is covered.
In addition, IBM BPM and the database must be tracked at the same time frame. (AWR reports can be only generated after the problem scenario, but the corresponding snapshots are by default kept for 8 days and written every hour.)
In some situations you might need to trace the following additional information:
- Track database connection pool usage with the following additional settings:
WAS.j2c=all:RRA=all:Transaction=all - Security related problems combined with the database are best addressed with the following additional settings of VMM and security traces:
com.ibm.websphere.wim.*=all: com.ibm.ws.wim.*=all:
com.ibm.wsspi.wim.*=all:
com.ibm.ws.security.*=all:You can use different publications that use reduced security trace settings. Evaluate the performance impact compared to the value gained out of the traces and the problem investigated. As a general recommendation, check what is really needed and can be handled by your system. If you are in doubt it's better to collect more data than too little data.
- The following additional trace setting from WebSphere Application Server logs the JDBC Resource adapter code from WebSphere Application Server, which also includes the adapter code and the SQL statement information:
com.ibm.ws.rsadapter.jdbc.*=allThis trace setting collects data that is not frequently required from a IBM BPM perspective.
The reduced set for tracking only prepared SQL statement is a good alternative:
com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.*=allNot all statements must be executed as a prepared statement.
- Enable a deeper analysis with JDBC driver tracing from the IBM BPM server side. For Oracle, enable the JDBC driver trace on the IBM BPM server as previously described.
Nearly all cases of database issues can be solved without such a trace. However, a few very special situations required this kind of tracing, so be aware that it exists.
Data required to debug a BPMDB related issue
This section summarizes the minimum data collections (previously described) to debug a problem.
Consider the following summary of what data is required to debug an issue related to the BPMDB database:
- Output of the SQL statements, which are available in the SQL statement file on Github: http://github.com/stephan-volz/database-scripts/blob/master/Oracle_ProcessInstances_Tasks.txt .
- An AWR or Statspack report from the time you first noticed the problem, in a short timeframe, such as one hour. Your database administrator should be able to advise on the database findings. Share the information with the IBM Support team.
- An explain output or even a database trace (if there is already a performance problem for a specific statement).
- A trace from the IBM BPM side while the problem is recreated.
IBM BPM example 1: Slow performance of database queries
In several cases, when slow performance is observed for database queries, at least there is a suspicion that there is a delay from the database side, but not all cases are clear from the beginning.
Sometimes a process participant logs into the IBM BPM Process Portal and the page does not load for a long time. Is this issue caused by a large number of entries in the database, a browser issue, a high load on the IBM BPM system, or another cause?
If you think the problem might be related to the database, cover the IBM BPM and the database side. In the worst case you might collect some data in vain, but you save time instead of focusing on only one side. From this perspective, it is worth it to collect a larger amount of data to come to a quick conclusion.
The following trace setting should cover most of the problems between the IBM BPM product and a database system, including Oracle:
WLE.*=all:com.ibm.bpm.*=all:WAS.clientinfopluslogging=all:org.springframework.jdbc.*=al
If you already identified a slow running query, you can create an explain output, The Oracle Enterprise Manager Web-based interface of your Oracle database system or the developer tool SQL Developer can help you visualize corresponding execution plans.
Check for Table access full , larger numbers for costs, and use of temp space.
Your database administrator can help on this kind of question.
Not every table scan is bad. If you require nearly all data from a table, a table scan can be much more efficient than an index access.
In some situations, the problem is triggered by the application, for example requesting millions of records that are not needed in the end.
The example in the following screen capture shows a Table access full on 24 entries of the LSW_SNAPSHOT table, which should not be a big concern.
IBM BPM includes several indexes. You might not see a benefit by a specific index included with the product, but you might not be aware of scenarios where you need it.
The IBM Support team expects indexes shipped with IBM products to be in place. Deleting any of these default indexes results in performance issues that cost both your organization and the support engineers an unnecessary waste of time to realize that these indexes are removed, to get them back, and then start to tune the system.
To improve the performance in the specific business case, it can be still necessary to create additional custom indexes.
Oracle provides several tuning tools, depending on your license level. One well known tool to give recommendations is the ADDM report, but there are others like the SQL Tuning Advisor. If you see a slow SQL statement, use the tools to get an idea of what you can improve.
Be aware that SQL statements related to IBM BPM use constructs like select for update to prevent any modifications on corresponding rows during a running transaction. At the end of the transaction, the changes (for example, a single process instance) are committed, and the lock is released. Long running select for update statements indicate that the process design should be improved.
For example, if you are working on a process instance and call an external service synchronously, the service has a long response time. While the service runs, the database keeps the lock for the select for update statement on the LSW_BPD_INSTANCE table. When the processing is completed, the final commit is executed and the lock is released. For this kind of problem, an explain output from the database system does not help, because the processing is blocked by the activities executed by IBM BPM.
IBM BPM example 2: Slow performing saved searches
If you are using searchable variables in your application, you might see performance issues with corresponding search queries.
Take a different approach for a client and a server side view of the problem.
If you are using the responsive Process Portal with IBM BPM V8.5.7 and more recent releases, see the Performance recommendations for the new IBM Business Process Manager V8.5.7.0 Process Portal support document.
If you use saved searches frequently, troubleshooting is simple for the Process Server side. Check that you have implemented search accelerator tables (also called pivot tables) for search optimization with Oracle. Do not take this approach for a Process Center environment. For each change of searchable variables in the deployed applications, the two pivot tables must be dropped and recreated. (It is not sufficient to only call the DataLoad script.)
Use the schemaGenerator and DataLoad scripts, as described in the JR42110 support document and the Saved search acceleration tools documentation.
Because a development environment has frequent changes, maintaining the tables becomes an issue. This approach is more for production, QA, and test environments. You see significant impact, depending on the circumstances of application design, usage, and hardware. In some situations the IBM team saw improvements of a factor 100.
To track the client side, especially the browser, a tool like Fiddler gives you corresponding long calls from a browser perspective. You can map this info to the full IBM BPM trace, which was previously explained. If there is a delay in the server response, you see it quickly. Delays in the browser for issues like JavaScript processing are more difficult to track, but you can see them from the Fiddler time line.
IBM BPM example 3: Instrumentation logs and a large amount of queries
As a last point, which we already covered in the DB2 articles in more detail, instrumentation logging is an option for troubleshooting. See http://www .ibm.com/support/docview.wss?uid=swg21613989 .
The instrumentation logs give insights on the cache usage for IBM BPM. Many of the same SQL statements sent to the database might be caused by a cache on the IBM BPM side that is too small. Instrumentation logs are a good tool to capture the cache misses and hits when there are a large number of the same statements running. Based on the results, you can adjust the size of your caches for your workload.
Make sure you have the latest version of IBM BPM to avoid issues with a large number of queries for the LSW_MANAGED_ASSET table. Check the currently set value and how many assets are expected. The latest IBM BPM releases also print the number of assets as part of the recommended general IBM BPM trace.
结论
You learned about several different tools and approaches to troubleshoot your BPMDB database when you use Oracle with IBM BPM. You can use most of these tools for other database issues, even for scenarios without IBM BPM.
This tutorial addresses IBM BPM releases until IBM BPM 8.5.7. Future releases might require adjustments to the SQL statements, although no major changes are expected.
Now you are equipped with skills to identify potential issues quickly, and you are prepared to troubleshoot issues with your own IBM BPM environment. You can practice by testing the shared examples.
To learn about troubleshooting in environments with IBM DB2, see Part 1 and Part 2 of this series.
致谢
The author thanks Bonnie Brummond and Hendrik Engler for their review and comments. Any included error is the fault of the author only.
翻译自: https://www.ibm.com/developerworks/library/mw-1702-volz-trs/1702-volz.html
oracle bpm
3517
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
