一SQL优化思路
一个真实具体的SQL优化思路
一般都看预估的执行计划，比如遇到一个sql执行计划很长，很复杂，从计划中没有看到返回行数多，cost高或连接方式错误的地方，没有明显瓶颈，但整体逻辑读很高，运行很慢。这时就可以去看真实的执行计划，并查看真实计划里逻辑读cr最多的步骤。可以做个10046。根据逻辑读最多的步骤判断对应连接方式，比如这里nest loop 的cr最大，且对应俩大结果集。显然有问题。于是再根据预估的执行计划判断俩表的连接方式。预估计划是164 ：1结果集，那根据对应查询条件，发现查询条件上使用了trunc函数，导致优化器用默认选择度估计返回行数较少就用全表扫描做驱动表了。
二 AWR分析思路
根据awr分析
1 数据库IO 大 概要指标，物理读
负载很高，概要中发现物理读很高；进一步发现等待事件中跟io等待相关的事件很多；
于是先去wait class小结看到IO等待占比到70%以上，再看 time model中再发现sql执行占db time比例很大，可见总体sql执行时间长，IO等待占用大量消耗，说明是大量IO等待高的sql导致物理读，于是就根据具体哪个维度查看sql性能，综上判断跟sql 的io等待有关所以查看按io wait排序的top sql
2 dbcpu 消耗大 概要指标，dbcpu
dbcpu指标值和逻辑cpu近似 ，判断小号在dbcpu的时间多，进一步根据host指标判断busy cpu比例也很大，判断dbcpu上运行时间很长，
首先根据cpu维度查找top sql， 找出慢sql优化。优化的sql是查询条件里使用了or，这点可根据执行计划里的实际时间判断具体慢的计划步骤，
然后对sql改写成union方式，具体union还是union all 根据select查询出的字段是否有唯一所以判断查询字段中没有重复数据，所以用
union all不会排重，也不会排序，简单合并结果后就返回
3 概要指标 redo size
根据redo size 可以判断是redo日志太小，还是dml操作过多
如果redo size到 2M/s 那一分钟120M 20分钟就是2400M，而现在一个日志文件50M ，50M/2M 半分钟就慢了，所以可以跑个ADDM ，
根据建议把redoSize设置到2G。
参考 性能调优之redo切换频率
4 逻辑读和物理读几乎一致
判读是直接绕过SGA，读数据到PGA了，等待事件发现有direct path read，根据问题现象发现用户用8条sql做并行测试，因此db判断
每个进程各读各的不在共享一个SGA，其他内存里读数据，因此性能变慢
也有类似逻辑读和物理读差不多的时候，但那就是逻辑读慢，执行时间长，且大部分时间在db cpu上，跟HASH 连接算法有关，
使某个桶内的数据太过多，早成每个块上的数据每次都要在桶内比较很长时间，造成逻辑读很低，hash表都缓存在内存，但每次比较
都要从磁盘读数据和桶里数据比较
http://blog.itpub.net/26736162/viewspace-2137141/ Oracle数据库服务器IO高的分析方案和案例探讨
http://www.talkwithtrend.com/Article/177951 我和数据中心的故事-分享批量时快时慢的场景