本文是關于Oracle數據庫調試與優化方面的文章,主要介紹Oracle數據庫中命中率相關的問題,包括不同的算法之間性能的比對。關于Oracle中各個命中率的計算以及相關的調優 1) Library Cache的命中率: 計算公式:Library Cache Hit Ratio = sum(pinhits) / sum(pi
本文是關于Oracle數據庫調試與優化方面的文章,主要介紹Oracle數據庫中命中率相關的問題,包括不同的算法之間性能的比對。關于Oracle中各個命中率的計算以及相關的調優
1)Library Cache的命中率:計算公式:Library Cache Hit Ratio = sum(pinhits) / sum(pins)
1 |
SELECT SUM (pinhits)/ sum (pins) FROM V$LIBRARYCACHE;
|
通常在98%以上,否則,需要要考慮加大共享池,綁定變量,修改cursor_sharing等參數。
2)計算共享池內存使用率:
1
2 |
SELECT (1 - ROUND(BYTES / (&TSP_IN_M * 1024 * 1024), 2)) * 100 || '%'
FROM V$SGASTAT WHERE NAME = 'free memory' AND POOL = 'shared pool' ;
|
其中: &TSP_IN_M是你的總的共享池的SIZE(M)
共享池內存使用率,應該穩定在75%-90%間,太小浪費內存,太大則內存不足。
查詢空閑的共享池內存:
1
2 |
SELECT * FROM V$SGASTAT WHERE
NAME = 'free memory' AND POOL = 'shared pool' ;
|
3)db buffer cache命中率:計算公式:Hit ratio = 1 - [physical reads/(block gets + consistent gets)]
1
2
3 |
SELECT NAME , PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS))
"Hit Ratio" FROM V$BUFFER_POOL_STATISTICS WHERE NAME = 'DEFAULT' ;
|
通常應在90%以上,否則,需要調整,加大DB_CACHE_SIZE
外一種計算命中率的方法(摘自ORACLE官方文檔<<數據庫性能優化>>):
命中率的計算公式為:
Hit Ratio = 1 - ((physical reads - physical reads direct - physical reads direct (lob)) / (db block gets + consistent gets - physical reads direct - physical reads direct (lob))
分別代入上一查詢中的結果值,就得出了Buffer cache的命中率
1
2
3
4 |
SELECT NAME , VALUE FROM V$SYSSTAT WHERE NAME IN (
'session logical reads' , 'physical reads' ,
'physical reads direct' , 'physical reads direct (lob)' ,
'db block gets' , 'consistent gets' );
|
4)數據緩沖區命中率:
1
2
3
4
5 |
SQL> select value from v$sysstat where name = 'physical reads' ;
SQL> select value from v$sysstat where name = 'physical reads direct' ;
SQL> select value from v$sysstat where name = 'physical reads direct (lob)' ;
SQL> select value from v$sysstat where name = 'consistent gets' ;
SQL> select value from v$sysstat where name = 'db block gets' ;
|
這里命中率的計算應該是令 x = physical reads direct + physical reads direct (lob),命中率 =100 - ( physical reads - x) / (consistent gets + db block gets - x)*100,通常如果發現命中率低于90%,則應該調整應用可可以考慮是否增大數據緩沖區
5)共享池的命中率:
1
2 |
select sum (pinhits-reloads)/ sum (pins)*100 "hit radio"
from v$librarycache;
|
假如共享池的命中率低于95%,就要考慮調整應用(通常是沒使用bind var )或者增加內存
6)計算在內存中排序的比率:
1 |
SELECT * FROM v$sysstat t WHERE NAME = 'sorts (memory)' ;
|
查詢內存排序數
1 |
SELECT * FROM v$sysstat t WHERE NAME = 'sorts (disk)' ;
|
查詢磁盤排序數caculate sort in memory ratio
1 |
SELECT round(&sort_in_memory/(&sort_in_memory+&sort_in_disk),4)*100|| '%' FROM dual;
|
此比率越大越好,太小整要考慮調整,加大PGA
7)PGA的命中率:
計算公式:BP x 100 / (BP + EBP)
BP: bytes processed
EBP: extra bytes read/written
1 |
SELECT * FROM V$PGASTAT WHERE NAME = 'cache hit percentage' ;
|
或者從OEM的圖形界面中查看
我們可以查看一個視圖以獲取Oracle的建議值:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 |
SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb,
ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc, ESTD_OVERALLOC_COUNT
FROM V$PGA_TARGET_ADVICE;
The output of this query might look like the following:
TARGET_MB CACHE_HIT_PERC ESTD_OVERALLOC_COUNT
63 23 367
125 24 30
250 30 3
375 39 0
500 58 0
600 59 0
700 59 0
800 60 0
900 60 0
|
在此例中:PGA至少要分配375M
我個人認為PGA命中率不應該低于50%
以下的SQL統計sql語句執行在三種模式的次數: optimal memory size, one-pass memory size, multi-pass memory size:
1
2
3 |
SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total,4))
percentage FROM ( SELECT name , value cnt, ( sum (value) over ())
total FROM V$SYSSTAT WHERE name like 'workarea exec%' );
|
8)共享區字典緩存區命中率
計算公式:SUM(gets - getmisses - usage -fixed) / SUM(gets)
命中率應大于0.85
1 |
select sum (gets-getmisses-usage-fixed)/ sum (gets) from v$rowcache;
|
9)數據高速緩存區命中率
計算公式:1-(physical reads / (db block gets + consistent gets))
命中率應大于0.90最好
1 |
select name ,value from v$sysstat where name in ( 'physical reads' , 'db block gets' , 'consistent gets' );
|
10)共享區庫緩存區命中率
計算公式:SUM(pins - reloads) / SUM(pins)
命中率應大于0.99
1 |
select sum (pins-reloads)/ sum (pins) from v$librarycache;
|
11)檢測回滾段的爭用
SUM(waits)值應小于SUM(gets)值的1%
1 |
select sum (gets), sum (waits), sum (waits)/ sum (gets) from v$rollstat;
|
12)檢測回滾段收縮次數
1
2 |
select name ,shrinks from v$rollstat, v$rollname
where v$rollstat.usn = v$rollname.usn;
|
幾個常用的檢查語句
1. 查找排序最多的SQL:
1
2 |
SELECT HASH_VALUE, SQL_TEXT, SORTS, EXECUTIONS
FROM V$SQLAREA ORDER BY SORTS DESC ;
|
2.查找磁盤讀寫最多的SQL:
1
2
3
4 |
SELECT * FROM ( SELECT sql_text,disk_reads "total disk" ,
executions "total exec" ,disk_reads/executions "disk/exec"
FROM v$sql WHERE executions>0 and is_obsolete= 'N' ORDER BY
4 desc ) WHERE ROWNUM<11 ;
|
3.查找工作量最大的SQL(實際上也是按磁盤讀寫來排序的):
1
2
3
4
5
6
7
8 |
select substr(to_char(s.pct, '99.00' ), 2) || '%' load ,
s.executions executes,p.sql_text from ( select address,disk_reads,executions,pct,rank() over
( order by disk_reads desc ) ranking from ( select
address,disk_reads,executions,100 * ratio_to_report
(disk_reads) over () pct from sys.v_$sql where
command_type != 47) where disk_reads > 50 * executions) s,
ys.v_$sqltext p where s.ranking <= 5 and p.address = s.address
order by 1, s.address, p.piece;
|
4. 用下列SQL工具找出低效SQL:
1
2
3
4
5 |
select executions,disk_reads,buffer_gets,round((buffer_gets-
disk_reads)/buffer_gets,2) Hit_radio,round(disk_reads/executions,2)
reads_per_run,sql_text From v$sqlarea Where executions>0 and
buffer_gets >0 and (buffer_gets-disk_reads)/buffer_gets<0.8
Order by 4 desc ;
|
5、根據sid查看對應連接正在運行的sql
1
2
3
4
5
6
7 |
select /*+ push_subq */command_type,sql_text,sharable_mem,persistent_mem,
runtime_mem,sorts,version_count,loaded_versions,open_versions,
users_opening,executions,users_executing,loads,first_load_time,
invalidations,parse_calls,disk_reads,buffer_gets,rows_processed,
sysdate start_time,sysdate finish_time,’>’||address
sql_address,’N’status From v$sqlarea Where address=
( select sql_address from v$session where sid=&sid);
|
***************Oracle 緩沖區命中率低的分析及解決辦法******************
首先確定下面的查詢結果:
1,緩沖區命中率的查詢(是否低于90%):
1
2
3 |
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狀態的數據快.):
1 |
select count (*), status from v$bh group by status ;
|
3,相關等待事件的查詢(是否有相關等待事件)
1
2 |
select event,total_waits from v$system_event where event
in ( 'free buffer waits' );
|
4,當前大小(是否已經很大)
1
2 |
select value/1024/1024 cache_size from v$parameter
where name = 'db_cache_size'
|
5,top等待事件分析(Db file scatered read的比率是否大)
1
2
3
4
5
6
7 |
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)
1
2 |
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數據庫緩沖區命中率
1
2
3
4 |
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
數據庫緩沖區命中率:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 |
select value from v$sysstat where name = 'physical reads' ;
value 3714179
select value from v$sysstat where name = 'physical reads direct' ;
value 0
select value from v$sysstat where name = 'physical reads direct(lob)' ;
value 0
select value from v$sysstat where name = 'consistent gets' ;
value 856309623
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%,則應該調整應用可以考慮是否增大數據加
共享池的命中率
1 |
select sum (pinhits)/ sum (pins)*100 "hit radio" from v$librarycache;
|
如果共享池的命中率低于95%就要考慮調整應用(通常是沒應用bind var)或者增加內存。
關于排序部分
1 |
select name ,value from v$sysstat where name like '%sort%' ;
|
如果我們發現sorts(disk)/(sorts(memory)+sorts(disk))的比例過高,則通常意味著sort_area_size部分內存教較小,可考慮調整相應的參數。
關于log_buffer
1
2 |
select name ,value from v$sysstat where name
in ( 'redo entries' , 'redo buffer allocation retries' );
|
假如redo buffer allocation retries/redo entries的比例超過1%我們就可以考慮增加log_buffer.