ITPub博客

在生产环境中有一些sql语句出现问题，大多是一些很紧急的问题，可能有些sql语句出现了执行计划的问题，通过hint能够做很大的改进，但是如果想让变更尽快生效，可以使用sql_profile来实现。说起sql_profile的创建有两种方式，一种是自动，通过sql tuning的功能能够得到一些建议，会自动生成sql_profile，只需要启用即可，如...

今天到公司以后，照例查看了数据库的负载情况，发现有一些异常。11点开始到12点的时候，数据库的负载格外的高。按照平时的经验，这个时间段内不会有太多的高峰业务在运行，为了简单验证，自己抓取了近几天的数据库负载情况。自己抓取了2月1号，1月30号的负载情况，发现在这个时间段内数据库的负载其实不高。...

今天在对生产系统做监控的时候，发现一个process的cpu消耗很高，抓取了对应的session和执行的sql语句。发现是一个简单的update语句，这样一条如果CPU消耗较大，很可能是由于全表扫描的。UPDATECOMM_ACTIVITY SET COMM_ACTIVITY.EXTRACT_STATUS = NVL(:1 ,EXTRACT_STATUS), COMM_ACTIVITY.SOURCE_TYPE = NVL(:2 , SOURCE...

昨天开发的同事找到我说，生产有个job处理数据的速度很慢，想让我帮忙看看是怎么回事，最近碰到这种问题相对比较多了，但是问题的原因也是五花八门。我还是大体找他们了解了下情况，说有一个Job是处理文件传输的，但是从目前的运行情况来看，处理速度很慢，基本没什么进展，我向他们确认这几天是否有数据变更的操作，他们说...

昨天开发的一个同事找到我，说写了一条sql语句，但是执行了半个小时还没有执行完，想让我帮忙看看是怎么回事。他大体上给我讲了下逻辑，表bl1_rc_rates是千万级数据量的表，autsu_subscriber 是个临时表，里面只有三百多条数据，bl1_activity_history 表的数据量略小，是百万级的。   select distinct hist.ent...

在平时的调优工作中,在11g中的新特性sql monitor可以极大的简化性能监控的工作，对于执行时间超过5秒的sql语句都会记入v$sql_monitor中。但是如果某个sql语句还没有执行，或者执行时间已经是几天前了，等发现性能问题进行调优的话就会比较困难，采用dbms_advisor.quick_tune是一个不错的选择。如果sql语句比较庞大，比较迷...

数组在各种编程语言中都是很重要的数据结构实现，在oracle中也有自己的一席之地。自己简单做了几个实验，发现很多东西还是眼高手低，真实去做的时候，里面还是有不少的细节的。首先数组大体可以有以下几种。固定长度的数组变长数组多维数组如果说实现方式，就有varray,嵌套表,record等等。我们从varray来开始。比如实...

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

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

在上一篇http://blog.itpub.net/23718752/viewspace-1364914/ 中我们大体介绍了下问题的情况，已经初步根据awr能够抓取到存在问题的sql语句。这条sql语句执行很频繁，目前平均执行时间在0.5秒。开发部门希望我们能不能做点优化，他们也在同时想办法从业务上来优化这个问题。从0.5秒的情况下，能够再提高很多，是得费很大力...

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

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

今天发现系统在下午1点左右的时候负载比较高,就抓取了一个最新的awr报告.Snap IdSnap TimeSessionsCursors/SessionBegin Snap:2089226-Nov-14 13:20:1736235.4...

关于dual表的破坏性测试，既然是破坏性测试，就需要确定这个测试仅限于测试或者个人学习所用，可能有些sql看似极为简单，但是一旦运行就会导致整个业务系统崩溃。比如说我们拿dual表开刀，这个表是一个dummy表，里面的内容没有特定的意义，就是为了存在而存在。但是一旦这个表出现问题，所有相关的基础操作都会受到影响，...

今天查看awr报告的时候，发现一条sql语句异常。Elapsed Time (s)Executions Elapsed Time per Exec (s) %Total%CPU%IOSQL Id...

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

生产环境中有一些sql语句是不定时炸弹，不声不响的运行着，可能相关的表很大，运行时间达数小时。上周在生产环境中发现一条sql语句，运行时间几乎是按照天来计算的。看到这种sql语句，就希望能够马上能够找到立竿见影的效果，不过欲速则不达，需要做不少工作。一定要反复验证可行。sql语句的运行情况如下:SQL Execution ...

生产环境中的sql语句执行时间是很关键的性能指标,如果某个sql语句执行几个小时,优化以后几分钟，几十秒的话。会有很大的成就感，同时如果某个sql语句执行10秒，能够优化到1秒，感觉提升的幅度不是很大，但是如果这条语句执行极为频繁的话，那这种调优还是更有成就感的。执行时间是sql调优的一把标尺，但是同时也需要考虑到...

在性能调优的时候，会发现很多类型的问题，有些问题可能通过使用隐含参数就能够解决，不过这种变更需要特别注意，因为做隐含参数的变更无形中会影响到其它的sql语句运行。如果为了个别的问题而做了变更，导致了整个系统问题，那就得不偿失了，这中变更一定得经过测试，至少在测试环境中部署测试过，而且解决的问题可能是...

在生产环境中，作为dba需要对系统的负载有一个很清晰的认识。能够在很快的时间内能够发现系统潜在的问题，并且及时定位问题，高效的响应和处理问题。比如说对于生产环境的session leak问题，这个部分是awr都很难捕捉到的信息，如果问题比较隐蔽，连ash也很难定位。比如说在早上9点的时候某个程序出现了session leak的问题...