一家醫院的Oracle 內存性能調整案例

 北京一家規模不大的醫院,使用了IBM的P550小型機,在業務高峯期性能急劇降低.

1.在業務高峯期，系統沒法登陸 。
2.性能降低很明顯，部分業務沒法正常開展。

3.在alertSID.log文件中,出現了鏈接超時的錯誤,醫院已經加大procesess參數,未見明顯好轉.

4.在下午等非高峯時段,性能也不理想.

下面時採集的awr報告臺頭:

 

  WORKLOAD REPOSITORY report for 
  DB Name DB Id Instance Inst num Release RAC Host 
  ORCL 1247897117 orcl 1 10.2.0.4.0 NO HISDB01

  Snap Id Snap Time Sessions  Cursors/Session 
 Begin Snap: 13055 22-Nov-11 08:00:03 212 99.1 
 End Snap:   13056 22-Nov-11 09:00:03 245 101.5 
 Elapsed:   59.99 (mins)     
 DB Time:   2,377.04 (mins)     
  從awr來看db time是間隔時間的近40倍，性能確實沒法接受了。
3.cpu佔用率不高。

分析：
  1.load profile部分:
  Instance Efficiency Percentages (Target 100%)

 Buffer Nowait %: 100.00       Redo NoWait %: 99.99 
 Buffer Hit %: 97.75         In-memory Sort %: 100.00 
 Library Hit %: 98.62         Soft Parse %: 97.15 
 Execute to Parse %: 69.23      Latch Hit %: 99.73 
 Parse CPU to Parse Elapsd %: 0.68 % Non-Parse CPU: 95.96 
  主要的問題在於Parse CPU to Parse Elapsd只有0.68%，說明大多數的時間花費在了sql的解析上了。
  2.Top 5 Events部分：
  Top 5 Timed Events

 Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class 
 latch: library cache 499,350 139,280 279 97.7 Concurrency 
 latch free 282,082 82,252 292 57.7 Other 
 latch: shared pool 136,826 33,818 247 23.7 Concurrency 
 latch: session allocation 37,423 10,858 290 7.6 Other 
 db file sequential read 289,996 4,273 15 3.0 User I/O
 再次映證了load profile部分，相關的latch很是嚴重；問題就出在共享池上。
 
3.看相關的參數,發現了幾個參數通過了一些調整，經詢問客戶，原來是他們先前已經請過Oracle維保的工程師作了一些調整：
    session_cached_cursors 1000 
    open_cursors 3000
  session_cached_cursors控制pga/uga中緩存的cursor數量，sql能夠不用到共享池進行parse，可減輕共享池的壓力;但1000這個值相對ZLHIS過高了；
  Open_cursors控制session同時打開的cursors數;這位工程師也認爲問題是出在sql parse上。但不幸的是，調整基本沒有效果。
  
4.os相關的分析，經過vmstat發現有必定的swap in /out的發生，服務器只有16g的內存，而sga的設置達到13g；這樣os的佔用與pga部分頗有可能使用到swap,
sga特別是共享池被swap到交換分區，對性能是很是大的損失。同時，查看到了一下aix中vmo的設置，發現相關的設置也有問題，將大量的內存做爲文件系統
緩存;須要作一些調整。 通常的數據庫服務器，文件型內存能夠使用較少的空間，由於文件型內存並不主動釋放，可能形成內存資源的短缺及Paging Space使用率太高，因此數據庫服務器上maxclient、maxperm、minperm的值不宜過大，典型值以下：
     maxclient% = 8      
     maxperm% = 12   
     minperm% = 5     
   如何更改這三個參數呢，  在AIX5.3上，能夠使用 vmo 命令，此命令設置或顯示全部虛擬內存管理器調整參數的當前值或下一個引導值。還能夠用此命令進行永久性更改，或將更改推遲到下一次從新引導以後生效。此命令是設置參數仍是顯示參數，要由所帶標誌來決定。帶 -o 標誌的話，兩個操做都執行。同時須要注意AIX5.3與AIX6.1的差別.在AIX6下,部分VMO參數變成了固定參數,須要加F開關才能修改.

  

5.經過查詢v$sga_resize_ops視圖在高峯期間，也有resize的狀況；這就須要關閉sga自動管理。

 

調整的過程：

--調整vmo參數
vmo -p -o minperm%=3
vmo -p -o maxperm%=90
vmo -p -o maxclient%=90     
vmo -p -o strict_maxperm=0
vmo -p -o strict_maxclient=1
vmo -p -o lru_file_repage=0
vmo -p -o page_steal_method=1

--參數
alter system set processes=1000 scope=spfile;
alter system set sessions=1200 scope=spfile;
alter system set open_cursors=300 scope=spfile;
alter system set session_cached_cursors=100 scope=spfile;
alter system set pga_aggregate_target=4g scope=spfile;
alter system set shared_pool_size=4g scope=spfile;
alter system set db_cache_size=3g scope=spfile;
alter system set sga_max_size=8g scope=spfile;
alter system set sga_target=0 scope=spfile;
alter system set large_pool_size=300m scope=spfile;
alter system set java_pool_size=100m scope=spfile;
alter system set log_buffer=16777216 scope=spfile;
alter system set "_library_cache_advice"=false scope=spfile;
alter system set cursor_sharing=exact scope=spfile;

--重啓db生效。

經過上述調整，性能恢復正常,下面調整後awr報告的load profile:

Begin Snap:	13424	07-12月-11 10:00:13	297	98.2
End Snap:	13425	07-12月-11 11:00:59	297	99.9
Elapsed:		60.77 (mins)
DB Time:		175.39 (mins

 

   能夠看到,dbtime有大幅的降低.這個案例說明在Oracle中,共享池是最重要的內存區域,重要性超過了SGA中的其餘區域,一量共享池出現問題,對性質的影響將是致命的,在給Oracle配置內存時,首先應該考慮知足共享池的須要,同時要注意共享池"抖動"對性能的影響,也說明部分Oracle自動管理特性不是包打天下的良方.