首先確定下面的查詢結果:
1,緩衝區命中率的查詢(是否低於90%):
select round((1 - sum(decode(name,'physical reads',value,0)) /
(sum(decode(name,'db block gets',value,0)) + sum(decode(name,'consistent gets',value,0))) ),4) *100 || '%' chitrati
from v$sysstat;
2,使用率的查詢(有無free狀態的資料快.):
select count(*), status from v$bh group by status ;
3,相關等待事件的查詢(是否有相關等待事件)
select event,total_waits from v$system_event where event in ('free buffer waits');
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 資料庫緩衝區命中率
oracle 資料庫緩衝區命中率 作業系統 hp ux 和 aix 資料庫版本 10.2.0.5.0 sql select value from v sysstat where name physical reads sql select value from v sysstat where nam...
mysql索引的命中率
轉於 首先明確 為什麼要用聯合索引？對於查詢語句 select e.from e where e.e1 1 and e.e3 2 涉及到兩列，這個時候我們一般採用乙個聯合索引 e1,e3 而不用兩個單列索引，這是因為一條查詢語句往往應為mysql優化器的關係只用乙個索引，就算你有兩個索引，他也只用乙...
Oracle資料庫的快取命中率
資料庫快取 block buffer 對於oracle資料庫的運轉和效能起著非常關鍵的作用，它佔據oracle資料庫sga 系統共享記憶體區 的主要部分。oracle資料庫通過使用lru演算法，將最近訪問的資料塊存放到快取中，從而使對磁碟資料的訪問效率最大優化到接近於記憶體訪問的速度。由於資料庫應用...