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  

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值