一个普通数据库用户所能查到的"意料之外"的信息
有时候限于工作环境的情况,大多数开发人员只得到了一个权限收到限制的数据库用户。可能你都不知道你所拥有的数据库用户都能查到哪些你想象不到的数据库信息,其实你知道还是不知道,哪些东西就在那儿:)假定现在给你一台机器,让你在一个已经登录的sqlplus环境下自己探索一把,在短时间内完成下面的工作,你心里有底吗?...
生产环境sql语句调优实战第七篇
在数据迁移完成之后,开始了例行的后期数据库维护,早上一来就发现了一个sql执行时间很长了。达到了37279秒。最后在改进调优之后执行速度在1分钟以内。这个速度是毫无疑问的性能问题,但是是否是因为数据迁移直接导致的呢,通过简单的脚本分析,得出了如下的图表。显示了同样的sql语句在7月份至今的执行情况,还真是奇怪...
使用dbms_parallel_execute来完成DML的并行
在工作中使用并行可以极大的提高工作效率。可以Object,session.hint级别引入并行。可以使大量的数据处理更加高效。比如现在有一个表 t 有1000万行,如果想以这个表为基础,把数据选择性的插入另外一个表t2,使用Insert into t2 select *from t;使用并行来处理也没有问题,但是如果使用dbms_parallel_execute也是一种...
查看空间使用情况的脚本
在数据库中,我们可以使用如下的3个脚本来查看表空间的使用情况,表空间的增长情况,表未使用的空间情况等等。showunused.sh 可以查看未使用的空间情况sqlplus -s n1/n1 <<EOFprompt ------- $1.$2 prompt .set serveroutput onset feedback offvariable total_blocks number; variable total_bytes num...
关于ORA-00020问题的反思
今天在生产环境中查看alert日志,发现了如下的一段错误。这个错误确实没有太多需要解释的。很明显就是因为session leak的经典问题。ORA-00020: maximum number of processes 5000 exceededORA-20 errors will not be written to the alert log for the next minute. Please look at trace files to see all ...
融会贯通学习trigger
很多的东西在工作中用到的时候才能理解深刻,有些东西停留在理论层面而不去实践,就不会真正理解。昨天写了一个很简单的trigger,但是中间也费了一些周折。系统中碰到一个很严重的问题,一个数据处理引擎是基于表驱动设计的,里面的一个表中已经pending了很多的事务信息,对系统造成了严重的影响,为了第一时间排查这个问...
关于纠结的recycle pool的设置
现在生产环境中目前有一个很大的中继表,作为多个流程的数据流动所用,数据量很大。里面有clob字段,加上庞大的数据量,表就显得很臃肿了。目前在做大批量的数据处理的时候发现了一些问题,事物数在不断增加的情况下,数据的处理速度也在不断的降低。最后出现了一些资源的问题。在抓取了awr和同事的分析之后,产品部门...
关于查看文件的几个小命令
关于分页查询的优化思路
目前在生产环境中有一个sql语句执行时间长达7分钟,而且执行频率极高。其中PROC_INST中有将近6千万的数据。其中STEP_INST是一个物化视图,里面还有5千多条数据。可以看到这个语句已经有了一些调优的痕迹,可以从里面的子查询和hint能够看出一些信息。SELECT PROC_INST.OBJID, PROC_INST.CREATION_TIME FROM PROC_...
关于抓取session信息的一个脚本
关于session的诊断,可以基于动态性能视图,ash,awr..自己也写过一些简单的脚本,在平时的工作中也能够完成一些基本的工作。今天在看taner分享的脚本snapper的时候,让自己眼前一亮,也发现自己存在着很多的不足的地方。可以从脚本中看到他孜孜不倦的分享着自己的心得,而且自己也写了一些更加深入的一些工具集来解析orac...
性能下降的不定时炸弹_过旧的sql_profile
最近这一周以来,生产环境像是得了重病的病人一样,小问题没有修好,大问题不断。IO的等待极为严重。数据库的负载达到了几十倍,上百倍。weblogic和tuxedo在很大程度上都受到了影响,导致业务响应极为缓慢。在排查了中间件部门,数据库,存储,网络,操作系统等各个层面,也发现了存储的一些小问题,问题比较大的就是数...
一条执行4秒的sql语句导致的系统问题
一般来说一条sql语句执行个4秒钟是可以接受的,没有什么问题,但是如果应该执行1秒,却执行了4秒,问题就挺大的了。今天查看数据库负载,发现在中午12:00 到1点之间,数据库的负载急剧增加,负载达到了百倍。Snap IdSnap TimeSessionsCursors/Session...
关于评审开发人员的sql语句
在平时的工作中,经常会有一些开发人员提出一些数据库相关的一些问题。可能问的最多的就是sql语句了。按照一个标准的流程,开发提交的sql语句在完成一系列测试之后,在生产部署前,还需要dba来进行审核。如果是紧急的补丁,也一定不要漏了这个问题。有时候是开发嫌麻烦,要不是开发嫌dba麻烦,这个review的过程还是很必要...
执行计划的偏差导致的性能问题
在生产环境中哟一条sql语句,查看执行计划来看,效果还是可以接受的。sql语句类似下面的样子,可以看到里面还使用了比较纠结的外连接。从执行计划来说,默认是走nested loop join,数据的查取中会走索引,从oracle的分析来说这样的效果要好一些。 SELECT /*+ leading(cyc_cust,cyc_pay) */ CUST....
关于session leak的问题分析
在生产环境中,作为dba需要对系统的负载有一个很清晰的认识。能够在很快的时间内能够发现系统潜在的问题,并且及时定位问题,高效的响应和处理问题。比如说对于生产环境的session leak问题,这个部分是awr都很难捕捉到的信息,如果问题比较隐蔽,连ash也很难定位。比如说在早上9点的时候某个程序出现了session leak的问题...
浅谈pl/sql
关于pl/sql,可能大家熟悉而又陌生,熟悉是因为大家在工作中老是写sql,如果稍微改动一些,加入begin,end和控制结构,就是pl/sql了。:) 今天和大家简单讨论一下pl/sql。不谈技术细节,泛泛而谈。 我自己在以前的总结中提出了以下几个问题,自己来按照这个思路来解答一下,可能大家印象中的pl/sql和sql还是有很大的差...
pl/sql中错误的异常处理
pl/sql中对于错误的处理是很重要的一个部分,就跟写程序中对于异常的处理一样。可能程序中正常的流程实现部分不是很复杂,但是对于各种可能发生的异常情况都需要面面俱到的处理要占一半以上的代码量。首先Pl/sql中的异常处理需要重视,但是异常的处理绝大多数的人写pl/sql的时候都不够重视,通常在数据处理完之后对于异常...
多行数据的批处理之bulk collect
在写pl/sql的时候,很多时候都会用比较经典的模式,定义一个游标cursor,然后循环从游标中取值进行处理。类似下面的格式declarecursor xxxx is xxxxx;beginloop cur in xxxxx loopxxxxxend loop;end;/如果cursor中包含的数据太多的时候,可能会有性能问题,性能的考虑主要在于pl/sql引擎和sql引擎的切换,和编...
查看并行进程的一些简单信息
在使用并行的时候,总能看到进程中出现一些ora_p这样的进程。SQL> !ps -ef|grep ora_p|grep TESTDBtestdbuser 17422 1 0 Aug29 ? 00:04:56 ora_pmon_TESTDBtestdbuser 17425 1 0 Aug29 ? 00:01:12 ora_psp0_TESTDBtest...
关于修改数据库参数的测试
在性能调优的时候,会发现很多类型的问题,有些问题可能通过使用隐含参数就能够解决,不过这种变更需要特别注意,因为做隐含参数的变更无形中会影响到其它的sql语句运行。如果为了个别的问题而做了变更,导致了整个系统问题,那就得不偿失了,这中变更一定得经过测试,至少在测试环境中部署测试过,而且解决的问题可能是...