【案例13】应用系统异常卡顿处理流程

问题现象

系统卡顿,很多操作耗时都比较长,通过nmc监控,线程耗时主要集中在数据库上。

问题分析

毫无疑问,首先是对数据库服务器资源使用情况进行监控,CPU、内存使用正常,没有达到峰值。

监控磁盘IO情况,发现磁盘最长活动时间持续达到100%,说明系统磁盘io负载较高。

生成卡顿时段awr报告1:

Sqlplus / as sysdba
@?/rdbms/admin/awrrpt.sql //生成awr报告

可以看到2小时的awr报告DB Time达到7805mins,非常高。

用户IO为主要等待时间,占比57%。

进一步查看数据库参数配置:

select * from v$parameter order by name ;

96G内存的数据库服务器,oracle最大内存只分配了6.7G,调整数据库内存参数

alter system set memory_max_target=66560M scope=spfile;
alter system set memory_target=66560M scope=spfile;
alter system set sga_max_size=66560M scope=spfile;

调整后业务依然很慢,nmc监控仍然在数据库端,再次生成一个卡顿时段的awr报告:

可以看到1小时的awr报告DB Time达到2739mins,依然很高。

等待事件不再是IO,而是latch free

查看数据库上事件为latch free的会话,发现闩锁ID为559。

select * from v$session_wait where event like 'latch free';

查看559对应的latch name,为Result Cache: RC Latch

select * from v$latchname where latch#=599;

解决方案

通过Oracle官方支持网站mos查询问题,发现跟oracle12c新特性有关。

可通过如下隐含参数解决:

alter system set "_optimizer_skip_scan_enabled"=FALSE scope=spfile;

修改后系统正常。

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值