一次db file sequential read 事件处理

一、CASE问题

   同事反馈用系统管理员账号登录查询很快,但是用普通员工的账号登录查询却卡死,SQL语句查询需要5分钟。第一时间接到CASE后摸清情况得知,系统管理员账号是没有数据的。而普通帐号有几十万行数据。

二、解决方法

首选查到这个执行操作的SQL语句执行计划。

执行计划没有发现什么异常。

先debug 跟踪一下sql语句:

alter session set events '10046 trace name context forever, level 12';
query this sql;
alter session set events '10046 trace name context off';

通过tkprof 格式化这个跟踪日志解析一下:

由此我们看到这个NESTED LOOPS 嵌套循环消耗时间异常。于是我把这个索引进行在线重建了一下。发现效果好一点,查询SQL由原来的5分钟变成2分钟左右,但是这个还是不能接受的。于是接着看跟踪日志。

发现主要是db file sequential read 这个等待事件导致了系统查询卡死。

看到这个事件后我立马检查了一下SQL语句代码,发现语句中确实有排序问题。这时基本上可以判断是临时表空间不足了。

我接着查询了临时表空间。结果发现可用空间为0兆。

排查到这里问题就解决了,增加临时表空间。

alter tablespace temp add datafile '/u01/app/oradata/orcl/orcl/temp02.dbf' size 5000m autoextend on next 100m maxsize 25000m;

查询一下业务SQL语句:

最终优化后SQL查询时间0.187秒。

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

fashion186

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值