ITPub博客

       这是一辆性能优异的宝马汽车，轻松在时速100KM上稳定运行，没有任何拖沓。也许我们没有注意，宝马汽车的时速降低到了95KM，宝马汽车就是好呀。慢慢的，我们发现了问题，这么越来越慢了，...

    Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE</w:LidThemeComplexScript. ...

今天凌晨，又被电话叫醒了，说是有1个sql，现在跑的很慢。问题已经挺严重了，想让我看看，能不能做点什么。首先就是和他们确认最近有什么改动，他们说这个是用了很久的sql语句了，没有任何的改动，再听他们说，之前也没有任何的问题。然后就和他们确认之前这个jobl处理大概多长时间，那个哥们说他也是最近才进的这个项目...

今天客户说有一个job跑的特别慢。想看看到底是不是数据库这边有什么问题了。使用top来查看，io wait奖金30%，已经算是负载比较重的了。和客户确认从什么时候发现速度开始变慢的，他们说大概是从中午以后。使用sar来看一下，确实是从iowait从:1:00开始有了大量的io 10:40:01AM     &...

top命令在linux环境维护中很实用，虽然功能缺失不够sar那么全面。今天和大家分享一个通过top命令来抓取性能sql的案例。通过top命令抓取了如下的信息。pid是3585的进程对应的sql 之前已经确定是性能问题导致的了，所以先放过，可以看看pid是8879的这个进程，出现的不是很“稳定”。可能通过ash,awr不一定能够及时的抓...

最近因为测试需要对一些数据文件做压缩，腾出更多的空间来为其他环境做准备，压缩数据文件，最开始采用了如下的sqlcol name for a40col resizecmd for a80select a.file#,a.name,a.bytes/1024/1024 CurrentMB,       ceil(HWM * a.block_size)/1024/1024 ResizeTo,   ...

在生产系统中，会发现一些潜在的sql问题，为了能够及时和准确的定位，我们可以借助sql_monitor来做性能sql的查找。可以在后台启用一个job不定时的去查找。毕竟大半夜的我们去监控也是有难度的，我们希望一切都能很自然的处理，结果我在一个指定的目录下每隔10分钟去查找一次性能sql，如果当天已经有生成报告就不重新生成...

通过v$sql_monitor能够实时采集可能存在的sql性能问题，但是每次问题发生的时候采取采取措施就有点“晚”了，我们需要防患于未然，把一些潜在问题提前发现，并加以解决。如果有些sql执行很频繁，我们需要得到一个执行的报告，但是因为sql执行很频繁，每次都生成一个报告就显得有些过于消耗资源了。现在想达到的目标就是...

今天查看数据库负载没有发现问题，但是当我使用top命令的时候，发现有一个进程占用了大量的cpu资源而且已经执行很长时间了。这一下子引起了我的注意。  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           ...

早上来到公司，照例进行了简单的检查，发现系统负载不高，就开始计划一些sql tuning的工作，但是过了一会,在通过shell命令查找一些sql信息的时候，发现系统的反应有些慢，当时也没在意，当我查看v$session都开始慢的时候，感觉哪里出了什么问题了，最直观的感受就是一些命令的运行都很缓慢了。首先查看了一下数据库的负载...

这个案例发生有段时间了，但是今天无意中看到当时的邮件，感觉还是收益匪浅，看来还是细节决定成败啊。从一些日志或trace 文件中的警告信息中我们可以发掘出潜在的问题。当时系统中的用户数很小,所以每天都能抽时间看看日志记录,看有没有明显的问题。结果在grep的时候发现trace文件中有一些警告记录。当时的库是10gR2的库...

对于awr，里面涵盖的内容比较杂，有时候看报告的时候总是不知道该怎么下手。时间长了，可能会有一些阅读习惯或者心得。今天在看大师chris lawson的一篇博文对于awr的一些心得(http://www.oraclemagician.com/white_papers/10awr.pdf )，还是蛮有收获，赶紧按照这个方子来细细品味一番。首先是查看等待事件，这个也是...

在日常的工作中，空值总是有特殊的身份，对于它的处理有时候也是比较纠结。有时候创建索引的时候会因为空值出现一些奇怪的结果。有时候一个简单的查询因为空值却走不了索引。有时候却因为空值而能走索引。我们来简单的模拟一下这些问题。首先创建一个空表，注意对于id列我们是加了not null的约束的。SQL> crea...

一般在生产环境中，如果某个查询中涉及一个大表，走索引扫描是显然是最值得推荐的方式，但是索引扫描有unique index scan, range scan,skip scan, full scan, fast full scan,这些索引扫描看起来好像很繁杂，但是如果掌握得当，却能够在索引扫描的基础上极速提升性能。关于索引扫描的方式，可以参考。http://blog.itpub.net...

今天生产系统中的一个daemon出现了严重的数据处理延迟，客户需要我们立即给出处理的方案。在综合评估之后，为了不保证在线业务延迟，开发部门给出了临时的解决意见。先停掉了一个应用，然后重启之后那个daemon就没有问题了。等我连上系统，这个问题已经不存在了，但是还是要提供一些更加详细的信息来进一步诊断这个问题。...

索引的使用对于一些庞大的sql语句来说，大多数的调优场景中有种雪中送炭的感觉，如果几百万,几千万的数据筛查，全表扫描将会是一个极度消耗资源的过程，但是如果走了索引扫描，可能性能会提升成百上千倍。索引的访问模式有以下几种，其实有些时候对有些细节还是不太注意。对不同的使用场景可以有一定的针对性，效率也许更...

在之前写了一个shell脚本，能够得到一个基于时间点的数据库负载报告。使用shell脚本查看数据库负载情况 http://blog.itpub.net/23718752/viewspace-1168027/在生产环境中快照的生成频率可能10分钟或者半个小时就会生成，频率要快些，使用原先的脚本执行起来会有一定的延时。想查看在快照的时间间隔内数据库的负载...

平时在查看数据库的问题时，会有种迷茫的感觉，如果没有任何人反馈问题，基本上没有主动查找问题的方向，awr,ash都是在得知问题发生的时间段或者一些时间戳来从历史记录中查找相关的信息，个人整理了如下的脚本，能够显示当天的时间段内数据库的负载信息，能够很好掌握数据库的忙闲情况。 来看一个简单的例子，比如我要查...

一般来说一条sql语句执行个4秒钟是可以接受的，没有什么问题，但是如果应该执行1秒，却执行了4秒，问题就挺大的了。今天查看数据库负载，发现在中午12:00 到1点之间，数据库的负载急剧增加，负载达到了百倍。Snap IdSnap TimeSessionsCursors/Session...

现在生产环境中目前有一个很大的中继表，作为多个流程的数据流动所用，数据量很大。里面有clob字段，加上庞大的数据量，表就显得很臃肿了。目前在做大批量的数据处理的时候发现了一些问题，事物数在不断增加的情况下，数据的处理速度也在不断的降低。最后出现了一些资源的问题。在抓取了awr和同事的分析之后，产品部门...