Oracle数据库Session飙升和行锁也飙升问题解决方法

背景：

性能测试现在压力和瓶颈都体现在OM系统上，张同学尝试了很多种方案，解决结果不是很理想。

表象就是：Oracle 数据库Session飙升厉害，当Session达到最大配置后系统会由于很多应用请求得不到可用Session而超时。

Oracle数据库大部分Session被OM锁占用。同时在此期间，数据库表行锁也飙升，最近一次甚至飙升到了40K。

处理过程方法：

结合AWR和ADDM报告分析定位排查，及模型结构和并发量综合分析，本次的问题处理思路如下：

1、解决处理数据库ITL等待事件处理，此类事件产生的原因由于表的ITL的设置不能够满足并发事务的需求而导致的等待。

1.1）、对OM系统几张带有BLOB类型大表结构做了优化参数调整initrans=1改成10，同时对缓存表改成不生成日志模式。

--并发事物初始化参数调整

alter table SG_PRODUCTINST_PROATTR pctfree 10 initrans 10;
alter table SG_SERVICEORDERTICKET pctfree 10 initrans 10;     
alter table SG_CUSTOMER pctfree 10 initrans 10;      
alter table SG_CUSTOMERINFO pctfree 10 initrans 10;
alter table SG_PRODUCTINFO pctfree 10 initrans 10;

--缓存表调整

alter table SG_CRMDISPACHXML initrans 10 nologging;
alter table sg_imsystemxml initrans 10 nologging;
alter table sg_amsystemxml initrans 10 nologging;
alter table sg_wfmsystemxml initrans 10 nologging;

1.2）、对其中几张频繁读取次数高的索引，进行并发事物初始化参数调整到10

alter index IDX_ORDERTICKET_PARENTID rebuild PCTFREE 10 INITRANS 10;

alter index SYS_C0011847 rebuild PCTFREE 10 INITRANS 10;
alter index SYS_C0011853 rebuild PCTFREE 10 INITRANS 10;
alter index SYS_C0011958 rebuild PCTFREE 10 INITRANS 10;

2、解决处理HW-connection等待事件，此类事件产生主要是由于SG_WORKTICKETATTRVALUE瞬间并发插入事物大导致的。

将该表有针对性改造成hash分区，避免热点资源争用等待。

3、把数据库配置参数还原成19号值：

 open_cursor=1000 和 filesystemio_options=NONE

4、经OSS预集成同事压测后结果如下：

19号测试情况： 总共发单8小时3分钟，发单总量114322，平均每秒发单3.96。 全部完单用时8小时49分，平均每秒完单3.6

23号测试情况： 总共发单8小时9分钟，发单总量129400，平均每秒发单4.3。 全部完单用时9小时8分，平均每秒完单3.8