问题描述:

工作流出现流程卡、流程走不下去、工作流操作慢。

解决方案:

原因分析：                                                                       

1. 收集数据库awr报告，发现Top 10 Foreground Events by Total Wait Time中enq: HW - contention的等待事件平均等待时间很长（10几毫秒以上），主要是因出性能问题时并发工作流业务较大，存在对工作流表数据进行UPDATE更新操作，导致工作流的表处于热表状态，产生对表插入数据达到HW高水位，工作流的表扩大空间来不及。

收集数据库ASH报告，发现往T_WFR_PROFILE表中插入数据出现了高水位（enq:HW-contention），如下所示：

解决方法：

减少高水位HW锁争用。

1、停止EAS集群或服务后对T_WFR_PROFILE表进行高水位处理 （大对象字段FMESSAGE），执行语句：

alter table T_WFR_PROFILE move lob(FMESSAGE) store as securefile(compress) ;

2、执行后，如果T_WFR_PROFILE表上有索引，索引会失效，需重建失效的索引：

查找失效的索引：

select  OWNER,INDEX_NAME,INDEX_TYPE,STATUS,TABLE_OWNER, TABLE_NAME from dba_indexes where status not in('VALID','N/A');

如有发现失效索引，执行以下语句重建索引：

alter index 索引名称 rebuild;

附：其它工作流表出现高水位处理方法

T_WFR_PROCINSTDATA和T_WFR_RUNTIME这两个表中有存在LOB或CLOB大字段，频繁的更新会造成高水位。

停止EAS集群或服务：

1、执行T_WFR_PROCINSTDATA表的高水位处理的语句：

alter table T_WFR_PROCINSTDATA move lob(FDATAVALUE) store as securefile(compress) ;

2、T_WFR_PROCINSTDATA表所有索引会失效，执行以下语句重建索引：

alter index PK_WFR_PIDPROC rebuild;

3、执行T_WFR_RUNTIME表的高水位处理的语句：

alter table T_WFR_RUNTIME move lob(FCONTEXT) store as securefile(compress) ;

4、 PK_WFR_RUNTIME表所有索引会失效，执行以下语句重建索引：

alter index PK_WFR_RUNTIME rebuild;

Oracle数据库awr、ash报告收集方法：

收集Oracle数据库awr报告实操演练:https://vip.kingdee.com/school/87572971782356736

收集Oracle数据库ash报告实操演练:https://vip.kingdee.com/school/87572609847475968