由一条sql语句导致的系统IO问题
早上来到公司,照例进行了简单的检查,发现系统负载不高,就开始计划一些sql tuning的工作,但是过了一会,在通过shell命令查找一些sql信息的时候,发现系统的反应有些慢,当时也没在意,当我查看v$session都开始慢的时候,感觉哪里出了什么问题了,最直观的感受就是一些命令的运行都很缓慢了。首先查看了一下数据库的负载...
由一条日志警告所做的调优分析
这个案例发生有段时间了,但是今天无意中看到当时的邮件,感觉还是收益匪浅,看来还是细节决定成败啊。从一些日志或trace 文件中的警告信息中我们可以发掘出潜在的问题。当时系统中的用户数很小,所以每天都能抽时间看看日志记录,看有没有明显的问题。结果在grep的时候发现trace文件中有一些警告记录。当时的库是10gR2的库...
关于生产系统锁问题的排查
今天生产系统中的一个daemon出现了严重的数据处理延迟,客户需要我们立即给出处理的方案。在综合评估之后,为了不保证在线业务延迟,开发部门给出了临时的解决意见。先停掉了一个应用,然后重启之后那个daemon就没有问题了。等我连上系统,这个问题已经不存在了,但是还是要提供一些更加详细的信息来进一步诊断这个问题。...
使用shell脚本查看数据库负载情况(第二篇)
在之前写了一个shell脚本,能够得到一个基于时间点的数据库负载报告。使用shell脚本查看数据库负载情况 http://blog.itpub.net/23718752/viewspace-1168027/在生产环境中快照的生成频率可能10分钟或者半个小时就会生成,频率要快些,使用原先的脚本执行起来会有一定的延时。想查看在快照的时间间隔内数据库的负载...
使用shell脚本查看数据库负载情况
平时在查看数据库的问题时,会有种迷茫的感觉,如果没有任何人反馈问题,基本上没有主动查找问题的方向,awr,ash都是在得知问题发生的时间段或者一些时间戳来从历史记录中查找相关的信息,个人整理了如下的脚本,能够显示当天的时间段内数据库的负载信息,能够很好掌握数据库的忙闲情况。 来看一个简单的例子,比如我要查...
一条执行4秒的sql语句导致的系统问题
一般来说一条sql语句执行个4秒钟是可以接受的,没有什么问题,但是如果应该执行1秒,却执行了4秒,问题就挺大的了。今天查看数据库负载,发现在中午12:00 到1点之间,数据库的负载急剧增加,负载达到了百倍。Snap IdSnap TimeSessionsCursors/Session...
关于纠结的recycle pool的设置
现在生产环境中目前有一个很大的中继表,作为多个流程的数据流动所用,数据量很大。里面有clob字段,加上庞大的数据量,表就显得很臃肿了。目前在做大批量的数据处理的时候发现了一些问题,事物数在不断增加的情况下,数据的处理速度也在不断的降低。最后出现了一些资源的问题。在抓取了awr和同事的分析之后,产品部门...
一条sql语句导致的数据库宕机问题及分析
之前分享过一篇博文,是一条sql语句"导致"的数据库宕机,上次是另有原因,这次真碰到一个案例,而且是在重要的环境上,希望大家引以为戒。数据库是基于Linux64的版本,版本是11.2.0.2.0,已经打了最新的psu.数据库的访问用户数大约在1000左右,当时查看服务器的cpu已经是100%了,有大约10个进程都是cpu 100%,数据库逻辑读...
impdp/expdp 并行时出现wait for unread message on broadcast channel等待事件
昨晚有个朋友说加班在IMPDP数据, 在导入中途突然没有了进展,挂在那里不动了,impdp 窗口也没有报错, 一直等了1个多小时,说是impdp使用了parallel,怀疑是parallel参数出了问题, 最终其实原因很简单。这里只是简单的描述遇到这类问题时的处理思路。 set lines 150 pages 100 numwidth 7 col program...
通过shell脚本监控oracle session
最近数据库碰到了连接紧张的问题,想通过一个脚本对数据库的session情况一目了然。以下是自己写的脚本。实现的效果如下。对session的总体情况,那些program主要在占用,每个用户所拥有的session(active,inactive,killed,sniped...)都能够一目了然。STATUS CNT-------- ----------...
提升自己oracle分析能力一些思考及方法论
sql version count引发cursor:pin s wait x及library cache latch library cache lock
背景 某Q友在其生产系统AWR发现library cache latch及library cache lock及cursor:pin s wait x等待事件非常严重,经排查发生某些底层SQL的多版本现象非常严重,最高达到4000多左右结论 1,oracle为了控制某个SQL的子游标个数不止过高过多,采用绑定变量分级机制,即绑定变量的长度(字节)在...