Oracle內存參數配置及版本問題

      Oracle的內存配置與Oracle性能息息相關。從總體上講，可以分為兩大塊：共享部分（主要是SGA）和進程獨享部分（主要是PGA）。在 32 位操作系統下 的Oracle版本，不時有項目反饋關於內存的錯誤（如ORA-04030、04031錯誤）都是十分令人頭疼的問題。查閱資料了解到，ORA-04030的問題一般是PGA過度分配造成的（對應的操作是sort/hash_join）。在Oracle中pga_aggregate_target指定了所有session總共使用的最大PGA上限。經測試驗證，32位Oracle版本使用的物理內存保持在 1.6G以下為佳(SGA+PGA)，超過 1.7G左右系統開始不穩定，推薦的內存配置為：SGA=1200M，PGA=360M；

調整內存參數的命令示例如下：

alter system set sga_max_size=1200M scope=spfile;
alter system set sga_target=1200M scope=spfile;
alter system set pga_aggregate_target=360M scope=spfile;

 

附，調整sharepool、buffer cache

-- 設置內存自動調整
alter system set memory_max_target=48G scope=spfile;
alter system set memory_target=48G scope=spfile;
alter system set sga_target=0 scope=spfile;
alter system set pga_aggregate_target=0 scope=spfile;

-- 設置buffer cache和shared pool的值（在自動內存管理的情況下，這個值會作為最小值），解決shared pool過大和SGA Resizing引發的性能問題
alter system set sga_max_size=36G scope=spfile;
alter system set sga_target=36G scope=both;
alter system set pga_aggregate_target=12G scope=spfile;
alter system set db_cache_size=25G scope=both;
alter system set shared_pool_size=5G scope=both;
alter system set "_memory_broker_stat_interval"=900 scope=both;  -- 設置resize的頻率不低於15分鍾

-- 保留的共享池空間與游標共享 ？？
alter system set shared_pool_reserved_size=500M scope=both;  --缺省值為shared_pool_size的5%，可以改為10~20%
alter system set cursor_sharing='SIMILAR'; -- 共享游標(EXACT/SIMILAR/FORCE)，缺省為EXACT

-- 設置日志緩沖等 ？？ 
alter system set log_buffer=134217728 scope=spfile; --128M ??? 
alter system set db_cache_size=25G scope=both sid='*'; --RAC 
alter system set lock_sga=true scope=spfile; -- 鎖定內存

 

Oracle支持自動和手工混合的內存參數管理方式，如果同時設置了Memory_target、SGA_target、db_cache_size，Oracle的處理方式是每個部件不會低於指定的內存大小，但可以根據需要調整到超過指定值的內存。這種自動和傳統手工管理相結合的方式，更能適應復雜多變的系統需求。

       完全使用SGA自動管理有一個缺陷就是，如果應用系統綁定變量做得不好，或者由於BUG，child cursor過多，導致shared pool會變得很大，甚至超過10G，嚴重的比buffer cache還大，另一方面，在buffer cache和shared pool之間頻繁地調整大小，可能會導致嚴重的解析問題和其他性能問題。針對這個問題，通常有2種解決辦法：一種就是關閉SGA自動管理，即將SGA_TARGET設置為0，以9i的方式來設置shared_pool_size,db_cache_size這些參數，來手動管理SGA；第二種就是sga_target仍然大於0，即自動管理SGA，但是通過設置shared_pool_size，db_cache_size等參數限制這些內存組件的最小大小，而只留給系統極少的自動調整空間。   

 

 

      建議使用的Oracle版本：10.2.0.5、11.2.0.3/4；對於64位版本，建議先把20%的內存留給操作系統，剩余80%分配給Oracle（其中SGA=物理內存*80%*80%，PGA=物理內存*80%*20%，db_cache_size=SGA*80%，shared_pool_size=SGA*15%）。

 

      曾經在多個項目上發現過奇怪的現象，一個較復雜的SQL，直接執行或查看執行計划，操作系統中可以看到CPU立刻飆到99%，而且即使等待很長時間（比如2分鍾，對於一個各表數據量小於10K的查詢，哪怕都走全表掃描也應該執行完的，2分鍾實在是太久了），CPU也不會降下來，SQL命令也無法正常結束，只能強制終止該會話或Oracle進程。該SQL訪問的所有表的數據量都不是很大（小於10K），更新統計信息等都沒有效果。我分別在Windows和Linux平台下的測試環境驗證過，問題都能夠重現，當然如果將SQL腳本簡化也能解決，但沒有明顯的規律、規則，感覺應該是Oracle的bug，最后都是通過升級到最新版本解決的。

 

如分頁SQL腳本（MV_118_CTLIST_03為視圖）：

SELECT MV_118_CTLIST_03."CTLIST_Name"
    , MV_118_CTLIST_03."CTLIST_Depart_LSBMZD_BMMC"
    , MV_118_CTLIST_03."CTLIST_Value"
    , MV_118_CTLIST_03."CTLIST_Handler_LSZGZD_ZGXM"
    , QRY_WORKITEM.STARTEDDATE
    , QRY_WORKITEM.COMPLETEDDATE
    , QRY_WORKITEM.PROCESSINSTANCEID
    , QRY_WORKITEM.ACTIVITYDEFINITIONID
    , QRY_WORKITEM.PROCESSDEFINITIONID
    , QRY_WORKITEM.ActivityInstanceId
    , QRY_WORKITEM.WORKITEMID
    , QRY_WORKITEM.WORKTYPE
FROM QRY_WORKITEM 
    JOIN MV_118_CTLIST_03 ON ROOTPROCINSTID = MV_118_CTLIST_03."CTLIST_SPID"
    JOIN (SELECT PK
          FROM (SELECT PK, rownum rowNumber
                FROM (SELECT WORKITEMID AS PK
                      FROM QRY_WORKITEM
                          JOIN MV_118_CTLIST_03 ON ROOTPROCINSTID = MV_118_CTLIST_03."CTLIST_SPID"
                      WHERE QRY_WORKITEM.Participant = '5b181b7c-8ea8-45a5-b35d-a90aed0725dc' 
                        AND QRY_WORKITEM.State = '2' 
                        AND QRY_WORKITEM.BIZPROCID = '0fad699e-a787-4fb6-bbff-8d3382f6d37f'
                      ORDER BY STARTEDDATE)
                WHERE rownum <= 20)
          WHERE rowNumber >= 1) tblPK ON workitemid = tblPK.PK
WHERE QRY_WORKITEM.Participant = '5b181b7c-8ea8-45a5-b35d-a90aed0725dc' 
    AND QRY_WORKITEM.State = '2' 
    AND QRY_WORKITEM.BIZPROCID = '0fad699e-a787-4fb6-bbff-8d3382f6d37f' 
ORDER BY STARTEDDATE