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

-----------------------------------------------------------

结束语

-----------------------------------------------------------