模板
教程
环境
性能
功能
管理
关于SQL优化的一些知识
关于SQL优化我提提几点总结，这里没有具体的实例，如果大家有兴趣，可以把他贴上来
1.除非写频率很低，否则不要用RAID5，但是对于cache能够减少RAID5的负荷
2.对于一个chained fetch ratio的，建议需要用一个高的pctfree来rebuild table
3.如果你有一个很高的磁盘排序率，那么建议修改sort_area_size,将其增大
4.buffer busy waits常常是由于很频繁的insert ，需要重建，或者没有充足的回滚段引起的
还应观注一下event这列其他值，这是我们调优的关键一列，下面对常出现的event做以简要的说明：
free buffer waits这个参数所标识是dbwr是否够用的问题，与IO很大相关的，
当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，
不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，
它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下：
a.1增加写进程，同时要调整 db_block_lru_latches 参数
示例：修改或添加如下两个参数
db_writer_processes=4
db_block_lru_latches=8
a.2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
5.递归SQL
为了决定所有表和列在SQL中的名字是否正确，ORACLE必须通过数据字典检查有效性，这些信息通常在内存中（ROW CACHE）
找到了，但是如果在内存中找不到，那么就需要要进行递归SQL
6.在不改变源代码的前提下，可以通过两个参数调整来减少解析
cursor_sharing
session_cached_cursors
7.open cursor通常意义上仅是得到一个handle,但在某些情况下不是。
open cursor只是简单的定位首记录的指针
8.创建新表后，高水位为第5块
9.hash join
如果整个hash表能够填充到内存，将很好，否则就需要临时表来进行分配。
所以hash join常常对于两个不同大小的表进行连接，也可以在并行模式和反向连接中工作的很好
10.存储概要能够帮助从一个低版本移植到高版本，也可以将RULE移植到COST
11.OR常常可以利用union来实现索引的使用，当然ORACLE优化器有时也会自动进行转换
12.经常被> <等操作的列都要在可能的情况下使用索引
13.叶块包含了上一块和下一块的指针，所以允许对于索引过的列，使用order by和使用> <等操作进行利用
另外，对于索引扫描，即使没有任何记录，也会有3-4个IO，因为有纵向SCAN
对于大表，深度为4（1个都块，2级分支块和叶块），但是常常头块和分支块通常都会在内存，所以只会有1到2个物理读块
14.索引键值分离是很昂贵的，对于使用插入增量序列的值，可以避免索引分离
15.不能压缩分区索引和位图索引
16.唯一索引或者主键常常是很好的hash key，因为hash key不适合区域扫描
17.由于普通的B树索引，仍然消耗了很大磁盘空间，并且insert update delete也同样有很大的负载，所以考虑采用IOT，这样就没有表了，索引本身就是表，但是结构可是索引结构。主键将和所有列存储在叶节点，这样就造成了可能对索引结构的性能下降，所以可以通过设置including 来将某些不常用的大字段列放到益出段，对于想BOLB字段，可以采用disable storage in row使得分离不常查询的BOLB字段分离到别的段和表空间
18.query+current为逻辑读
autotrace没有每一步的row count,也不包括cpu or elapsed times
19.对于绑定变量与直方图的选择
条件 绑定 直方图
---------------------------- ------------------- -----------------------
搜索值不变 不需要 可能需要
range scan 不需要 需要
执行精确查找，
但有些值分布很少 不需要 需要
这个SQL执行很频繁，
期望快速执行 需要 不需要
用户特定使用的
复杂的SQL 可能不需要，因为最终 需要
用户可能不喜欢
20.对于有null值的列要建立索引，那么最好使用default(where改成默认值)，并设置not null
[1]
