ORACLE profile 優化配置

kingsql發表於2014-01-08

關於Oracle中各個命中率的計算以及相關的調優

1)Library Cache的命中率 :

.計算公式 :Library Cache Hit Ratio = sum(pinhits) / sum(pins)

SQL>SELECT SUM(pinhits)/sum(pins)  

     FROM V$LIBRARYCACHE;

通常在 98%以上,否則,需要要考慮加大共享池,繫結變數,修改 cursor_sharing等引數。

 

2)計算共享池記憶體使用率 :

SQL>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%間,太小浪費記憶體,太大則記憶體不足。

查詢空閒的共享池記憶體 :

SQL>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)]

SQL>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的命中率

SQL>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)資料緩衝區命中率:

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)共享池的命中率:

SQL> select sum(pinhits-reloads)/sum(pins)*100 "hit radio" from v$librarycache;

假如共享池的命中率低於 95%,就要考慮調整應用(通常是沒使用 bind var )或者增加記憶體

 

6)計算在記憶體中排序的比率 :

SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (memory)'; —查詢記憶體排序數

SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (disk)'; —查詢磁碟排序數

--caculate sort in memory ratio

SQL>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

SQL>SELECT * FROM V$PGASTAT WHERE NAME='cache hit percentage';

或者從 OEM的圖形介面中檢視

我們可以檢視一個檢視以獲取 Oracle的建議值 :

SQL>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:

SQL>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

SQL>select sum(gets-getmisses-usage-fixed)/sum(gets)

   from v$rowcache;

 

9)資料快取記憶體區命中率

計算公式: 1-(physical reads / (db block gets + consistent gets))

命中率應大於 0.90最好

SQL>select name,value

   from v$sysstat

   where name in ('physical reads','db block gets','consistent gets');

  

10)共享區庫快取區命中率

計算公式: SUM(pins - reloads) / SUM(pins)

命中率應大於 0.99

SQL>select sum(pins-reloads)/sum(pins)

   from v$librarycache;

11)檢測回滾段的爭用

SUM(waits)值應小於 SUM(gets)值的 1%

SQL>select sum(gets),sum(waits),sum(waits)/sum(gets)

   from v$rollstat;

  

12)檢測回滾段收縮次數

SQL>select name,shrinks

   from v$rollstat, v$rollname

   where v$rollstat.usn = v$rollname.usn;

-----------------------------------------------------------------------------

 

幾個常用的檢查語句

1. 查詢排序最多的 SQL:

SQL>SELECT HASH_VALUE, SQL_TEXT, SORTS, EXECUTIONS

    FROM V$SQLAREA

    ORDER BY SORTS DESC;

 

2.查詢磁碟讀寫最多的 SQL:

 

SQL>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(實際上也是按磁碟讀寫來排序的 ):

SQL>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,sys.v_$sqltext p

   where s.ranking <= 5 and p.address = s.address

   order by 1, s.address, p.piece;

 

4. 用下列 SQL工具找出低效 SQL:

SQL>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

SQL> 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%):

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資料庫緩衝區命中率*****************  

 

 

 

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

sql>select name,value from v$sysstat where name in ('redo entries','redo buffer allocation retries');

假如 redo buffer allocation retries/redo entries的比例超過 1%我們就可以考慮增加 log_buffer.

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28389881/viewspace-1068230/,如需轉載,請註明出處,否則將追究法律責任。

相關文章