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,我之前的博客有写。
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等工具来比较一下前后的性能差异。如果达到了预期,则调优结束。。
-----------------------------------------------------------
结束语
-----------------------------------------------------------