一次 read by other session 的处理过程

??

一个哥们给我打电话。他说系统中一直出现等待事件 read by other session 。而且该等待都是同一个sql引起的。比較紧急,请我帮忙远程看看。

远程过去之后,用脚本把 等待事件给抓出来

从图中看到 read by other session 是在执行同一个SQL , sql_id 是  1svyhsn0g56qd

于是查看执行计划

该SQL走的是 ILMCU 这个列的索引,过滤条件有4个列,可是仅仅走了一个列的索引。

先别管执行计划,先来看一下等待事件 read by other session 到底是被哪些进程堵塞,这些进程又在跑什么SQL

最后发现, 还是同一个SQL。 然后细致问了一下业务。原来该系统是一个 沙发厂的 ERP 系统。

前台的用户点击某个button。等了半天没响应,然后就一直点,一直点 就导致这个 SQL 一直反复的执行,

可是呢。这个SQL 跑不出结果,所以就产生大量的 read by other session

所以呢。终于优化这个SQL就能够解决该问题,跑的SQL 例如以下:

SELECT *  FROM PRODDTA.F4111 WHERE ((ILDCT = :1   AND ILFRTO = :2   AND ILMCU = :3   AND ILDOC = :4  )) ORDER BY ILUKID ASC

走的索引是 ILMCU 这个列的索引。首先看一下这个表一共同拥有多少行

一共同拥有250w行,那这个表事实上不大啊,搞多了数据仓库,一个表没有几十亿数据那还真不算大。如今来看一下 ILMCU 这个列数据分布

同志们想一下 为啥我要用 full 这个hint?

由于如今 有 n 个进程 在跑 刚才的 SQL,而且就是 ILMCU 这个列的索引

要是这个时候我不加 full hint , 万一又走了 ILMCU 这个列的 索引,那不是火上浇油吗

而且 这个表一共才 250w条数据,走全表也没啥的,而且我不仅仅要看这个列数据分布,还要看其余3个列。那必须走全表了

终于发现 ILMCU 这个列分布 太他妈不均衡了, 问了一下 那哥们,如今的业务是不是做的 SF10 。他回答说是的 。

从250w里面去选142w ,走索引, 卧槽,那肯定死啦死啦的 ,肯定产生大量的 db file sequen read 等待 ,

说白了。 表统计信息有问题,没收集直方图。哎。懒得管统计信息了,帮他搞定再说

于是又连续查看剩下的过滤列的数据分布

然后看了一下他的的数据库版本号,11gR2 。跑在 IBM 小鸡鸡上面 。 由于是 11g 能够 online 创建 索引, 假设是 10g 不敢 online 创建 (10g 是假的online )

create index idx_F4111_docdctilmcufrto on F4111(ILDOC,ILDCT,ILMCU,ILFRTO) online nologging;

索引创建完之后,前台的用户 立刻就搞定了, 之前是 搞了一天 ,我晕

问题再 总结一下 :

这个 ERP 系统没有dba维护,所以呢 表没收集统计信息。表也缺乏索引, 这个表呢是 系统一直都有的 。而且是一个核心表 ,由于没 dba ,他们不敢乱建立索引

刚開始数据量小,没问题。后来数据量越来越大,问题就来了。我看了一下 他那边全部的业务全都跑得慢。今天这个是跑了一天,没法忍受了才找人帮忙的

我仅仅能说老板太他妈抠门了。招个dba,去干1--2个月,然后找个借口把 dba开除了 不就得了吗哈哈。或者要不来我这里培训一下 哈哈。

??

时间: 2024-11-06 08:12:28

一次 read by other session 的处理过程的相关文章

Session的使用过程中应注意的一个小问题

在学习AllEmpty大神的从零开始编写自己的C#框架系列文章中,发现的问题:在验证码的缓存Session["vcode"]的赋值时,发现Session["vcode"]的值一直为null. 发现原来是在调用验证码生成类给Session["vcode"]赋值时,这个Session["vcode"]还没有创建,所以无法赋值. 1 //生成验证码 2 imgCaptcha.ImageUrl = "Application/

cookie、session、sessionid 与jsessionid

cookie.session.sessionid 与jsessionid,要想明白他们之间的关系,下面来看个有趣的场景来帮你理解. 我们都知道银行,银行的收柜台每天要接待客户存款/取款业务,可以有几种方案: 1. 凭借柜台职员的记忆:由收柜台职员来为每位顾客办理存款/取款业务,单凭职员的记忆力,要记到每位顾客的相貌,并迅速知道顾客当前的存款以及存取的次数,每次存取的金额是多少.---- 这种方式表示协议本身支持状态. 2. 使用存折的方式:职员把每个顾客的存款/取款的信息保存在存折上,然后交给顾

JAVAWEB开发之JSP、EL、及会话技术(Cookie和Session)的使用详解

Servlet的缺点 开发人员要十分熟悉JAVA 不利于页面调试和维护(修改,重新编译) 很难利用网页设计工具进行页面设计(HTML内容导入到servlet中,用PrintWriter的对象进行输出) JSP简介 JSP(Java Server Pages) 与Java Servlet一样,是在服务器端执行的,不同的是JSP先由服务器编译部署成Servlet执行. JSP技术的企业最佳实践(生成HTML内容) 新的JSP2.0规范版本包括新的功能(EL表达式,新增的Simple Tag和Tag

微信公众平台开发教程(八)Session处理

微信公众平台开发教程(八)Session处理 在微信窗口,输入的信息有限,我们需要将一些信息分多次请求. 比如:在进行用户绑定时,我们需要输入用户的相关信息,比如:用户名.密码,或者姓名.电话号码,服务端验证通过,即可将系统用户与微信用户绑定. 然后,此微信账户就有一定的功能权限了,可以查积分,消费记录等.服务号:招商银行信用卡,就有很多功能. 微信客户端无法缓存信息,而且输入信息有限,需要进行多次请求,在服务端保存当前会话状态.这就需要Session. 本文以用户认证,绑定账号为例,来说明具体

Shiro源码分析之两种Session的方式

1.Shiro默认的Session处理方式 <!-- 定义 Shiro 主要业务对象 --> <bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager"> <!-- <property name="sessionManager" ref="sessionManager" />

利用Node.js实现模拟Session验证的登陆

1.身份验证和用户登陆 在一般的Web应用上,如果要实现用户登陆,最常用,也是最简单的方法就是使用Session,基本的思路是在Session中保留一些用户身份信息,然后每次在Session中取,如果信息不正确或不存在,那么身份验证失败,正确则成功. Session和Cookie是两个很相似的东西,都是字符串,只不过Session是保存在服务器上的,而Cookie是保存在本地的,所以Cookie是不能用作身份验证的.Session故名思议,肯定和客户端与服务器间建立的会话相关,Session的工

记录关于使用ADO.NET 连接池连接Oracle时Session信息不更新的坑

最近的一个项目中,由于界面查询的数据量比较大,关联的表比较多,有些数据查出来需要临时保存起来供后面的查询使用,于是想到了用oracle的临时表来实现这个需求.大家都知道,oracle的临时表有两种:事务级别临时表和会话级别临时表,我这里使用的是会话级别的临时表.当时把功能时候后就以为万事大吉了,没想到就在这里买下了一个坑.  坑的浮现:之后在为系统加调试日志时偶然发现了临时表的数据没有像oracle临时表的定义那样“不同会话独享临时表,临时表的数据在会话结束后被自动清空”.首先看第一次查询的日志

Cookie与Session详解

来源:<PHP核心技术与最佳实践> 列旭松 陈文 著 Cookie与Session详解读书笔记,从概念.操作.应用.注意事项以及区别等几方面详细阐述两者的基础知识,它们都是针对HTTP协议的局限性而提出的一种保持客户端和服务器间保持会话连接状态的机制.. 一.Cookie详解 Cookie在远程浏览器端存储数据并以此跟踪和识别用户的机制.从实现上说,Cookie是存储在客户端上的一小段数据,浏览器(即客户端)通过HTTP协议和服务器端进行Cookie交互. Cooke独立于语言存在,严格地说,

SQLServer中使用扩展事件获取Session级别的等待信息以及SQLServer 2016中Session级别等待信息的增强

本文出处:http://www.cnblogs.com/wy123/p/6835939.html 什么是等待 简单说明一下什么是等待:当应用程序对SQL Server发起一个Session请求的时候,这个Session请求在数据库中执行的过程中会申请其所需要的资源,比如可能会申请内存资源,表上的锁资源,物理IO资源,网络资源等等,如果当前Session运行过程中需要申请的某些资源无法立即得到满足,就会产生等待.SQL Server会以不用的方式来展现这个等待信息,比活动Session的等待信息,