由上可以看到，该系统为AIX的单实例数据库，采样时长1319.96 分钟，DB time 1532.15分钟。
看一下TOP等待事件:
可以看到有非常高的DB file scattered read等待事件，该等待事件表示将大量的数据块读入到不连续的内存区域，往往预示着大的全表扫描。
在程序运行期间，查看ASH动态视图v$active_session_history，同样可以发现发生着大量的DB file scattered read 等待事件，从该视图的执行计划列可以看到正在发生着 Table Full Scan.
接着我们看TOP sql部分:
我们看到 sql ID 为2yhcj6jcbtvac的sql语句消耗大量的资源， 该sql语句如下:
SELECT MATCH_CLIENT_ID,MATCH_CLIENT_ROLE,DECODE(MATCH_SYS_CODE,‘HKP‘,1,‘UVP‘,2,‘CAS‘,3,‘NB‘,4,‘GP‘,5,‘GLH‘,6,‘GI‘,7,‘MFD‘,8,‘CRC‘,9,10) AS MATCH_POL_ORDER,MATCH_SYS_CODE,MATCH_LOB,MATCH_CONTRACT_NO,MATCH_CERTIFICATE_NO FROM POSSIBLE_CUST_REPORT_SCB WHERE BATCH_DATE = :B3 AND CLIENT_ID = :B2 AND MATCH_CLIENT_ID = :B1
可以看到该语句为一个单表查询，从v$active_session_history也可以看到就是该语句发生着大量的DB file scattered read,查看该表的定义，没有索引，所以初次可以判定，以上的sql语句被多次执行，并且因为没有索引所以在产生全表扫描。
查看AWR的segment部分，更确认了这一点:
该表段上产生最大的逻辑读、物理读和非优化的读取。
所以， 现在完全可以确定，该表上大量的全表扫描是最主要的性能问题，所以需要在该表上添加索引。
在该表上创建索引:
CREATE INDEX idx1_POSSIBLE_CUST_REPORT_SCB ON POSSIBLE_CUST_REPORT_SCB(BATCH_DATE,CLIENT_ID,MATCH_CLIENT_ID);
所以创建完成后，立刻再次查看v$active_session_history，可以看到执行路劲改走索引。最终结果确认，该批处理程序性能提升3倍以上。
