oracle--sql内部处理机制

发布时间:2016-12-7 0:04:30 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"oracle--sql内部处理机制",主要涉及到oracle--sql内部处理机制方面的内容,对于oracle--sql内部处理机制感兴趣的同学可以参考一下。

1:连接到oracle服务器 方式: (1)thin:即瘦客户端。对于thin方式,多见于现在很多的B/S结构,用于jdbc连接。 (2)oci:通过客户端连接,包括sqlplus和工具(pl/sql developer),和EM。 这两种连接的方式,最主要的区别就是需不需要安装oracle客户端。 2:sql处理机制 处理步骤: (1)parsing--解析:包括语法校验、语义校验、权限校验等,生成解析树; 其实我们发出select或者DML操作时,都是由oracle的服务器进程(server process)来完成的。 (2)optimizer--优化:基于CBO的优化模式下,oracle会在成百上千种可能的执行计划中,选择一个最优的执行计划。CBO在这一步的主要工作有sql转换,确定访问路径,确定表与表的关联方法以及表间的关联次序。最后,生成最有效的执行计划,所谓最有效,oracle考虑的因素主要是IO和CPU的消耗。 CBO在一步的工作,就好象是汽车上的导航,比如我从西单到大兴,会有很多种走法,导航经过对距离和时间的计算,会产生出最优的路线,然后推荐出来。试想一下,假如今天的天气非常不好,雾霾+京开高速严重堵车。可是导航不知道啊,这时,它还告诉我让我走京开。这种走法就不行了吧?。。 CBO也一样,它要想准确,严重依赖于表和索引的统计信息,如果统计信息缺失或不准确,CBO给出的执行计划也一样不准确。。 在10g以及11g中,oracle默认都是在周一到周五晚上10点,周六日全天,通过job的形式进行统计信息收集。对于不同业务系统,我们可以根据情况进行定期收集,通过dbms-stats包就可以做到。 (2.1)bind--绑定:在OLTP系统中,很多时候都会用到绑定变量代替直接变量。绑定变量的好处是可以固定执行计划,将sql缓存到shared pool中的library cache中。当有相同的sql执行时,oracle就不会再在上千种执行计划中计算了,而是直接用到library中缓存过的执行计划,这将大大减少时间。 说到固定执行计划,问题自然就出来了:绑定变量一定好么?答案是否定的。。原因是绑定变量会固定执行计划,如果随着数据不断的被更形,数据发生了极大的扭曲,那么,以前适合走索引的列,现在也许适合走全表扫描了。。这时再用以前的执行计划,是不是就不够合理了? 其实oracle早就想到这一点了,oracle根据绑定窥视技术,采用了相同的执行计划,但是,根据统计信息,oracle认识到之前的执行计划可能已经不适合了,所以它采用了一种叫做自适应游标的技术,产生了此语句的子执行计划。可以通过查看v$sql中的is_bind_sensitive值,此值如果为Y,则表示绑定变量会根据不同值,产生了新的执行计划。 (3)execute--执行:有了执行计划,oracle就可以按照计划去查找数据了。如果在data buffer中,则从中找oracle块,如果不在,则走IO,去文件中查找。 (4)fetch--取操作:如果是select语句,则server process将结果返回给用户;如果是DML,则会返回用户更新完毕的提示。 3:CBO 刚才已经说过CBO了,它的优点就是总是查找最优的执行计划,通常比RBO的效率要好。但是,它的缺点也很明显,就是严重依赖于统计信息。当缺乏统计信息时,oracle也不是不能完成查询,CBO会采用动态采样,辅助完成查询。 4:访问路径+表连接方式+表连接次序 访问路径: (1)full table scan(FTS)全表扫描; (2)table access by rowid:当通过索引时,会根据索引中的rowid去查找表中数据。 (3)index unique scan:通过唯一性约束索引或者主键的唯一索引返回一条结果时,就通过这种方式访问索引; (4)index range scan:范围扫描,当发出>、<、between等操作时,采用这种方式访问索引; (5)index fast full scan:select  filing_no from T where filing_no like '2012%';类似于这种语句,filing_no是索引列,同时至查找filing_no时,只需快速扫描索引就可以了。。 表连接方式: nested-loop,sort-merge join,hash join,我之前的博客有写。 http://space.itpub.net/26511146/viewspace-745511 5:执行计划 获取执行计划的方法: (1)explain plan:需要创建plan_table表,通过DBCA已自动运行脚本了。  (2)autotrace:sqlplus中执行的命令,可以查看执行计划可统计信息。 (3)sqltrace+tkprof:跟踪session,将结格式化后,可以看到执行计划和统计信息。 (4)工具:sql/plus developer中“F5”,或者EM中查看。 查看执行计划方法:先访问缩进量最深的;如果存在缩进量相同的,就从上边的开始查看。 6:浅谈“慢” 其实慢这个说法,不够标准。也就是说,我们需要知道慢在哪里,什么时候开始慢。。。 这里有一些处理“慢”的方便方法: (1)识别问题语句:可以通过v$sql,或者AWR中top sql或者通过10046事件来查找有问题的sql; (2)定位低效资源:通过查看执行计划,看看是否有低效的全表扫描;是否存在索引,如果存在,是否使用了索引;是否使用了正确的表连接方法和次序;是否有在后面的选择操作等等。 (3)调优sql:找到了问题所在,可以运行sql access advisor来查看索引的建议。通过创建索引,或者使用hints来优化sql。 (4)比较性能 通过ADDM、sql tuning advisor等工具来比较一下前后的性能差异。如果达到了预期,则调优结束。。 ----------------------------------------------------------- 结束语 -----------------------------------------------------------

上一篇:在使用eclipse 运行 maven install的时候,出现这个错误:Unable to locate the Javac Compiler in:...
下一篇:行转列方法,decode()与wmsys.wm_concat()

相关文章

相关评论