4.当前大小(是否已经很大)
select value/1024/1024 cache_size from v$parameter where name='db_cache_size';
5.top等待事件分析(Db file scatered read的比率是否大)
select event ,total_waits,suml from (select event,total_waits,round(total_waits/sumt*100,2)||'%' suml from (select event,total_waits from v$system_event ), (select sum(total_waits) sumt from v$system_event) order by total_waits desc) where rownum<6 and event not like 'rdbms%' and event not like 'pmon%' and event not like 'SQL*Net%' and event not like 'smon%';
6.db_cache_advice建议值(9i后的新特性,可以根据它更好的调整cache_size)
select block_size,size_for_estimate,size_factor,estd_physical_reads from v$db_cache_advice;
说明分析:
缓冲区命中率(低于90的命中率就算比较低的).
没有free不一定说明需要增加,还要结合当前cache_size的大小(我们是否还可以再增大,是否有需要增加硬件,增加开销),
空闲缓冲区等待说明进程找不到空闲缓冲区，并通过写出灰缓冲区，来加速数据库写入器生成空闲缓冲区，当DBWn将块写入磁盘后，灰数据缓冲区将被释放，以便重新使用.产生这种原因主要是:
1.DBWn可能跟不上写入灰缓冲区：i/0系统较慢，尽量将文件均匀的分布于所有设备，
2.缓冲区过小或过大。
3.可以增加db_writer_processes数量。
4.可能有很大的一个事物，或者连续的大事物
我们需要长期观察这个事件是否长期存在并数值一直在增大,如果一直在增大,则说明需要增大db_cache大小，或优化sql。
数据分散读等待,通常表现存在着与全表扫描相关的等待，逻辑读时，在内存中进行的全表扫描一般是零散地，而并非连续的被分散到缓冲区的各个部分，可能有索引丢失，或被仰制索引的存在。该等待时间在数据库会话等待多块io读取结束的时候产生，并把指定的块数离散的分布在数据缓冲区。这意味这全表扫描过多，或者io不足或争用，
存在这个事件,多数都是问题的,这说明大量的全部扫描而未采用索引。
db_cache_advice对我们调整db_cache_size大小有一定的帮助,但这只是一个参考，不一定很精确。
通过上面6种情况的综合分析,判断是否需要增加大cache_size. 或者把常用的(小)表放到keep区。
但多数的时候做这些不会解决质的问题,而真正的问题主要是对sql语句的优化(如:是否存在大量的全表扫描等)索引是在不需要改变程序的情况下,对数据库性能，sql语句提高的最实用的方法.
我在生产中遇到过类似的问题,200M的cache_size,命中率很低21%,但通过对sql语句的优化(添加索引,避免全表扫描),命中率增加到96%,程序运行时间由原来的2小时减少到不到10分钟.
这就提到了怎么定位高消耗的sql问题.全表扫描的问题,在这里不做细致的解说,这里只说明方法,我会在相关的章节专门介绍怎么使用这些工具
1.sql_trace跟踪session.用tkprof 分别输出磁盘读,逻辑读,运行时间长的sql进行优化.这些高消耗的sql一般都伴随着全表扫描.
2.statspack分析.在系统繁忙时期进行时间点的统计分析,产看TOP事件是否有Db file scatered read.并查看TOP sql语句是否存在问题等.
还要说一句：当然在硬件允许的情况下，尽量增大db_cache_size 减少磁盘读，但并不是越大越好，一定要根据自己的库数据量的程度来调节，因为大的db_cache_size同样会增大数据库管理的开销，当然可能开销并不会明显的影响数据库的性能，硬件价格也越来越低，这就需要我们具体问题具体分析了，在我看来物尽其用就最好了，尽量不要浪费，找到问题的本质，调优是一件很艺术的事。
+---------------------------Oracle数据库缓冲区命中率-------------------------+
1、查看Oracle数据库缓冲区命中率
select a.value + b.value "logical_reads", c.value "phys_reads", round(100 * ((a.value+b.value)-c.value) / (a.value+b.value)) "BUFFER HIT RATIO" from v$sysstat a, v$sysstat b, v$sysstat c where a.statistic# = 40 and b.statistic# = 41 and c.statistic# = 42;
2、Tags: oracle
数据库缓冲区命中率：
sql>select value from v$sysstat where name ='physical reads'; value 3714179 sql>select value from v$sysstat where name ='physical reads direct'; value 0 sql>select value from v$sysstat where name ='physical reads direct(lob)'; value 0 sql>select value from v$sysstat where name ='consistent gets'; value 856309623 sql>select value from v$sysstat where name ='db block gets'; value 19847790
这里命中率的计算应该是
令x=physical reads direct + physical reads direct(lob)
命中率=100-(physical reads -x)/(consistent gets +db block gets -x)*100
通常如果发现命中率低于90%，则应该调整应用可以考虑是否增大数据加
共享池的命中率
sql> select sum(pinhits)/sum(pins)*100 "hit radio" from v$librarycache;
如果共享池的命中率低于95%就要考虑调整应用(通常是没应用bind var)或者增加内存。
关于排序部分
sql> select name,value from v$sysstat where name like '%sort%';
如果我们发现sorts(disk)/(sorts(memory)+sorts(disk))的比例过高，则通常意味着sort_area_size部分内存教较小，可考虑调整相应的参数。
关于log_buffer