Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
今天在做一个问题排查的时候碰到了另外一个有些“奇怪的”问题。 我们在测试库中已经禁用了SGA自动存储管理,结果在spfile文件里丢掉了shared_pool_size的配置 测试环境的参数类似下面的样子 sga_max_size ...
在sql解析器中,在生成执行计划的时候,会在多个执行计划中选择最优的计划,在这个过程中,查询转换就是一个很重要的过程。 虽然最终的执行结果没有变化,但是从优化器的角度来看,查询转换的结果会更好。
今天和大家简单分享几个实用的sql小技巧。还有一些还在整理中,会不断的分享出来。 有些其实也不算是sql的技巧,可能大家在写sql语句的时候没有意识到我们可以通过一条sql语句实现一些貌似复杂的功能。
在之前的章节中讨论了关于修改表分区的一些准备工作和操作细则,这个问题的来由有必要说一下。 通过分区键值发现性能问题 http://blog.itpub.net/23718752/viewspace-1263068/ 当时是在做数据迁移的时候发现了一些表,导入数据比较慢,尽管做了分区的并行切分,速度还是很慢,最后查看数据的分布时,发现90%左右的数据都分布到了一个表分区上。
生产环境中有一些sql语句是不定时炸弹,不声不响的运行着,可能相关的表很大,运行时间达数小时甚至数天. 上周在生产环境中发现一条sql语句,运行时间几乎是按照天来计算的。
ash是在10g以来一个很有用的特性,能够作为awr的补充,对于排查一些历史的问题能够提供更加详细和针对性的数据。 当然个人在使用ash的时候感觉最慢的地方就是在于输入时间戳了,每次输入侧时候都得一边看着样例,一边按照格式,一份ash的报告,至少20%以上的时间耗在这个时间戳上了。
大家在做性能问题诊断的时候,awr是不可或缺的工具,使用?/rdbms/admin/awrrpt.sql可能大家使用的多了,可能有时候感觉输入参数还是有些太繁琐了。
早上来到公司,照例进行了简单的检查,发现系统负载不高,就开始计划一些sql tuning的工作,但是过了一会,在通过shell命令查找一些sql信息的时候,发现系统的反应有些慢,当时也没在意,当我查看v$session都开始慢的时候,感觉哪里出了什么问题了,最直观的感受就是一些命令的运行都很缓慢了。
在第一篇中介绍了关于纯文本和特殊字符在正则表达式中的应用,来看看其它的一些相关的点。--关于锚定 锚定就跟大家在开发网页的时候使用的锚定是一个意思,其实就是给一段字符做个标识。
正则表达式在编程语言中,数据库中,linux中都有着广泛的应用,一说起正则表达式就有些高深晦涩的味道,正则表达式精炼而重要,在Linux中有着举足轻重的作用,也是学好sed,awk的一个基本门槛。
在开始学习数据库的时候,总是尝试手动创建数据库,安装完成之后需要运行一些脚本,总是看到屏幕上闪个不停,可以看到大多数的存储过程代码都是一堆乱码,最开始还以为是乱码了。
在java中,有方法重写,方法重载,重载的一个典型例子就是类中的构造函数,可以根据自己的需求定义多个构造函数,默认是一个无参数的空函数。 重写是基于父类子类之间的多态性体现上,父类的一个方法,在子类中可以重写. oracle中也可以有重载的实现。
在之前的博文中,讨论过一个根据分区键值发现性能问题的案例。90%以上的数据都分布在了一个分区上,其它的分区要么没有数据要么数据很少,这是很明显的分区问题。当然这个过程中也发现了分区的划分从开发角度和数据角度还是存在很大的差别,导致了分区的问题。
有时候开发人员写sql语句的时候,接触的性能问题越多,可能对sql语句的结构,性能考虑会多一些,这也是一件好事,不过如果考虑不当,本来原本想做的的一些优化却使得问题变得更加严重。
生产环境中的sql语句执行时间是很关键的性能指标,如果某个sql语句执行几个小时,优化以后几分钟,几十秒的话。会有很大的成就感,同时如果某个sql语句执行10秒,能够优化到1秒,感觉提升的幅度不是很大,但是如果这条语句执行极为频繁的话,那这种调优还是更有成就感的。
vmstat一直以来就是linux/unix中进行性能监控的利器,相比top来说它的监控更加系统级,更侧重于系统整体的情况。 今天在学习vmstat的时候,突然想看看数据库中的并行对于系统级的影响到底有多紧密,自己简单测试了一下。
在生产环境的数据迁移中,发生误操作真是很不愿意看到,今天自己总结了一下,从个人的经验来看有以下的几种操作或者是失误导致的问题。有一些错误自己已经犯过。外键 不管是使用imp/impdp,sqlldr还是使用Insert append的方式导入数据,如果存在外键的约束,在数据导入前最好都设置为disable,要不数据导入的时候很可能发生冲突,因为批量的数据导入很可能开启多个并发进程,如果你不能完全控制导入的先后顺序,最好还是disable掉。
在生产环境中的数据迁移还是很惊心动魄的,毕竟生产的数据不容许有任何潜在的问题,很小的问题也可能导致业务的终端,这个时候dba的角色是很重要的,如果dba犯了一个很细小的问题,在海量数据迁移中可能会导致灾难性的结果,所以今天和大家讨论一下关于由vi误操作导致的问题及总结。
可能在一些分布式环境中,有一些数据访问都需要用到db link。从某种程度上来说dblink是很方便,但是从性能上来说还是有一些的隐患。如果两个环境之间的网络情况不好,也会无形中给系统带来更多的等待。
今天在解决一个问题的时候,发现自己的数学水平严重下降,现在是光有思路没有答案,自己简单算了几个答案,还是不太满意。 最后尝试写了一个简单的pl/sql就解决了。 问题是这样的,一个系统的处理结果会提供两个参数,用这个参数来衡量系统的情况,一个我们设为pass_ratio,另一个设为fail_ratio. 我们假设需要投入时间分别设为x,y 就是返回pass_ratio需要的时间为x,返回fail_ratio的时间为y 需要从x,y中得到一个最优组合。
在性能调优的时候,会发现很多类型的问题,有些问题可能通过使用隐含参数就能够解决,不过这种变更需要特别注意,因为做隐含参数的变更无形中会影响到其它的sql语句运行。
在使用并行的时候,总能看到进程中出现一些ora_p这样的进程。有时候查看问题的时候只看到并行进程在运行,却没有思路去查找倒底是哪些session在干些什么,下面简单分析一下。
在写pl/sql的时候,很多时候都会用比较经典的模式,定义一个游标cursor,然后循环从游标中取值进行处理。 类似下面的格式 declare cursor xxxx is xxxxx; begin loop cur in xxxxx loop xxxxx end loop; end; / 如果cursor中包含的数据太多的时候,可能会有性能问题,性能的考虑主要在于pl/sql引擎和sql引擎的切换,和编程中的上下文环境是类似的。
pl/sql中对于错误的处理是很重要的一个部分,就跟写程序中对于异常的处理一样。可能程序中正常的流程实现部分不是很复杂,但是对于各种可能发生的异常情况都需要面面俱到的处理要占一半以上的代码量。
关于pl/sql,可能大家熟悉而又陌生,熟悉是因为大家在工作中老是写sql,如果稍微改动一些,加入begin,end和控制结构,就是pl/sql了。:) 今天和大家简单讨论一下pl/sql。
在生产环境中,作为dba需要对系统的负载有一个很清晰的认识。能够在很快的时间内能够发现系统潜在的问题,并且及时定位问题,高效的响应和处理问题。 比如说对于生产环境的session leak问题,这个部分是awr都很难捕捉到的信息,如果问题比较隐蔽,连ash也很难定位。
在生产环境中有一条sql语句,查看执行计划来看,效果还是可以接受的。 sql语句类似下面的样子,可以看到里面还使用了比较纠结的外连接。从执行计划来说,默认是走nested loop join,数据的查取中会走索引,从oracle的分析来说这样的效果要好一些。
在平时的工作中,经常会有一些开发人员提出一些数据库相关的一些问题。可能问的最多的就是sql语句了。 按照一个标准的流程,开发提交的sql语句在完成一系列测试之后,在生产部署前,还需要dba来进行审核。
一般来说一条sql语句执行个4秒钟是可以接受的,没有什么问题,但是如果应该执行1秒,却执行了4秒,问题就挺大的了。 今天查看数据库负载,发现在中午12:00 到1点之间,数据库的负载急剧增加,负载达到了百倍。
最近这一周以来,生产环境像是得了重病的病人一样,小问题没有修好,大问题不断。IO的等待极为严重。数据库的负载达到了几十倍,上百倍。 weblogic和tuxedo在很大程度上都受到了影响,导致业务响应极为缓慢。
关于session的诊断,可以基于动态性能视图,ash,awr.. 自己也写过一些简单的脚本,在平时的工作中也能够完成一些基本的工作。今天在看taner分享的脚本snapper的时候,让自己眼前一亮,也发现自己存在着很多的不足的地方。
目前在生产环境中有一个sql语句执行时间长达7分钟,而且执行频率极高。 其中PROC_INST中有将近6千万的数据。其中STEP_INST是一个物化视图,里面还有5千多条数据。
...
现在生产环境中目前有一个很大的中继表,作为多个流程的数据流动所用,数据量很大。里面有clob字段,加上庞大的数据量,表就显得很臃肿了。 目前在做大批量的数据处理的时候发现了一些问题,事物数在不断增加的情况下,数据的处理速度也在不断的降低。
很多的东西在工作中用到的时候才能理解深刻,有些东西停留在理论层面而不去实践,就不会真正理解。 昨天写了一个很简单的trigger,但是中间也费了一些周折。 系统中碰到一个很严重的问题,一个数据处理引擎是基于表驱动设计的,里面的一个表中已经pending了很多的事务信息,对系统造成了严重的影响,为了第一时间排查这个问题,同事为了避免对目前的事务处理的进一步影响。
今天在生产环境中查看alert日志,发现了如下的一段错误。这个错误确实没有太多需要解释的。很明显就是因为session leak的经典问题。 ORA-00020: maximum number of processes 5000 exceeded ORA-2...
在数据库中,我们可以使用如下的3个脚本来查看表空间的使用情况,表空间的增长情况,表未使用的空间情况等等。 showunused.sh 可以查看未使用的空间情况 sqlplus -s n1/n1 prompt ------- $1.
在工作中使用并行可以极大的提高工作效率。可以Object,session.hint级别引入并行。可以使大量的数据处理更加高效。 比如现在有一个表 t 有1000万行,如果想以这个表为基础,把数据选择性的插入另外一个表t2, 使用Insert into t2 select *from t; 使用并行来处理也没有问题,但是如果使用dbms_parallel_execute也是一种很不错的选择。
在数据迁移完成之后,开始了例行的后期数据库维护,早上一来就发现了一个sql执行时间很长了。达到了37279秒。最后在改进调优之后执行速度在1分钟以内。 这个速度是毫无疑问的性能问题,但是是否是因为数据迁移直接导致的呢,通过简单的脚本分析,得出了如下的图表。
有时候限于工作环境的情况,大多数开发人员只得到了一个权限收到限制的数据库用户。 可能你都不知道你所拥有的数据库用户都能查到哪些你想象不到的数据库信息,其实你知道还是不知道,哪些东西就在那儿:) 假定现在给你一台机器,让你在一个已经登录的sqlplus环境下自己探索一把,在短时间内完成下面的工作,你心里有底吗? 得到当前的用户名和所用的os账户名称 得到当前的用户创建的时间,默认的表空间是哪一个,是否是dba账户 查看当前数据库的表空间大体情况。
有时候在工作中,可以使用exp/imp得到表的创建语句。 如果想得到关于table,index,constraint的语句,可以考虑使用dbms_metadata来实现。
平时查看v$session的时候要定位一个session,需要sid,serial#这个两个值,其实更多时候我们关注更多的是sid,对于serial#却不太了解。
在平时的数据导出中使用exp/expdp能够满足绝大部分的数据导出任务。如果有一些表的数据不多,但是查询条件要复杂一些,使用exp/expdp就很吃力了。 或者在和外部系统的交互中,使用xml或者文本文件是一个很兼容的选择,这个时候使用exp/expdp也满足不了要求。
在平时的工作中,可能很多环境都有自己的内网环境,如果发生一些问题的时候,可以通过内网环境发送邮件到指定的邮箱中。这种略显智能的方式可能在很多工作场景中使用,一般都需要设置对应的网络配置,邮件设置等等,本文仅通过简单的Linux命令来发送一些比较简单的邮件。
在数据迁移的时候,需要根据用户量来评估需要在表空间理添加的空间大小。比如迁移5百万的用户和迁移200万,两者需要添加的数据量差别很大,在资源有限的情况下,需要一些比较合理的估算,毕竟在生产环境中做数据加载的时候报了空间不足的问题就是准备太不充分了,稍后的数据修复任务就难上加难。
今天数据迁移的小组找到我,希望我能够重新构建一些测试环境,其中测试环境中的一些分区表都需要去掉分区,转换成普通表的形式,因为他们在做一些工作的时候碰到了问题,而且希望必要的约束等都保留,这个需求听起来倒不复杂,很清晰,我看了下需要转换的表,一看有将近100多个,而且重构好几套环境,想想都头疼。
生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时间有1,2分钟左右,但是sql语句本身有潜在的性能问题,通过awr是定位不到的,ash尽管能够查到,但是我们在未知的情况下怎么知道问题发生的精确时间点,通过sql monitor能够查到一些实时的性能问题,但是还是需要按照自己的情况和要求来不间断地进行性能的监控。
关于分区表的move操作还是很值得深究的一个问题。如果分区表中含有lob字段,难度还会加大。 对于普通的表而言,做move操作室理所当然,oracle提供的方式很直接快捷。
在数据库的存储结构中,我们知道一般来说一个表都存储在对应的数据文件里,数据文件可以分为多个段,一般来说一个表会对应一个数据段,单纯考虑数据段的时候,数据段又可以分为多个区,每个区都可以分为若干个数据块,在操作系统层面,有对应的数据块和数据库层面的数据块有一个映射...
在查看undo的使用率的时候,在Undo_management为auto的时候,经常会看到undo自己在不断的伸缩扩展,自我调节。 有时候看到Undo收缩的很紧,就想知道哪些sql语句在运行,可能有哪些潜在的问题。