“In the latest release 10.2 Oracle changed these default values. The memory allocated to a single SQL operator (_smm_max_size) is limited to:
for P_A_T <= 500MB the parameter _smm_max_size = 20% of P_A_T
for P_A_T between 500MB and 1000MB the parameter _smm_max_size = 100M
for P_A_T betweeen 1001MB and 2560MB (2.5GB) the parameter _smm_max_size = 10% of P_A_T
I have seen even cases when these values were even bigger after the instance was restarted with P_A_T set at 4GB.
The maximum value for parallel operations changed from 30% to 50% PGA_AGGREGATE_TARGET/DOP. Also the DOP changed. When DOP <=5 then _smm_max_size is used, otherwise _smm_px_max_size/DOP limits the maximum memory usage. . .
轉載:http://www.1to2.us/ORACLE-a117737.htm
oracle中SGA的設置
關鍵詞： sga
關於SGA設置的一點總結
本總結不針對特例，僅對服務器只存在OS + ORACLE 為例，如果存在其他應用請酌情考慮
寫這個也是因為近來這種重復性的問題發生的太多所導致的
首先不要迷信STS,SG,OCP,EXPERT 等給出的任何建議、內存百分比的說法
基本掌握的原則是， data buffer 通常可以盡可能的大，shared_pool_size 要適度，log_buffer 通常大到幾百K到1M就差不多了
設置之前，首先要明確2個問題
1： 除去OS和一些其他開銷，能給ORACLE使用的內存有多大
2：oracle是64bit or 32 bit,32bit 通常 SGA有 1.7G 的限制(某些OS的處理或者WINDOWS上有特定設定可以支持到2G以上甚至達到3.7G，本人無這方面經驗)
下面是我的windows2000下的oracle :
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
SQL>
windows上存在32bit的限制，如AIX、HP UNIX 等有明確的64BIT OS and ORACLE的版本，32bit oracle可以裝在64bit os 上，64 bit oracle不能裝在32 bit OS上
不管oracle是32 bit ORACLE還是 64 bit 的,假定應用存在沒有很好的使用bind var 的情況，也不能設置 shared_pool_size 過大，通常應該控制在200M--300M,如果是 ORACLE ERP 一類的使用了很多存儲過程函數、包 ，或者很大的系統，可以考慮增大shared_pool_size ,但是如果超過500M可能是危險的，達到1G可能會造成CPU的嚴重負擔，系統甚至癱瘓。所以shared_pool_size 如果超過300M還命中率不高，那麼應該從應用上找原因而不是一味的增加內存，shared_pool_size 過大主要增加了管理負擔和latch 的開銷。
log_buffer : 128K ---- 1M 之間通常問題不大，不應該太大
large_pool_size :如果不設置MTS，通常在 RMAN 、OPQ 會使用到，但是在10M --- 50M 應該差不多了。假如設置 MTS,則由於 UGA 放到large_pool_size 的緣故，這個時候依據 session最大數量和 sort_ares_size 等參數設置，必須增大large_pool_size 的設置，可以考慮為 session * (sort_area_size + 2M)。這裡要提醒一點，不是必須使用MTS，我們都不主張使用MTS，尤其同時在線用戶數小於500的情況下。
java_pool_size : 若不使用java，給30M通常就夠了
data buffer ,在做了前面的設置後，凡可以提供給oracle的內存，都應該給data buffer = (db_block_size * db_block_buffers)
在9i 中可以是 db_cache_size
還有2個重要參數我們需要注意
sort_area_size and hash_area_size
這兩個參數在非MTS下都是屬於PGA ，不屬於SGA,是為每個session單獨分配的，在我們的服務器上除了OS + SGA,一定要考慮這兩部分
(****) : OS 使用內存+ SGA + session*(sort_area_size + hash_area_size + 2M) < 總物理RAM 為好
這樣歸結過來，假定oracle是 32 bit ,服務器RAM大於2G ，注意你的PGA的情況，,則建議
shared_pool_size + data buffer +large_pool_size + java_pool_size < 1.6G
再具體化，注意滿足上面(****) 的原則的基礎上可以參考如下設置
如果512M RAM
建議 shared_pool_size = 50M, data buffer = 200M
如果1G RAM
shared_pool_size = 100M , data buffer = 500M
如果2G
shared_pool_size = 150M ,data buffer = 1.2G
物理內存再大已經跟參數沒有關系了
假定64 bit ORACLE
內存4G
shared_pool_size = 200M , data buffer = 2.5G
內存8G
shared_pool_size = 300M , data buffer = 5G
內存 12G
shared_pool_size = 300M-----800M , data buffer = 8G
以上僅為參考值，不同系統可能差異比較大，需要根據具體情況調整。建議在設置參數的同時，init中使用 lock_sga ，在不同的平台上可能有不同的方式，使得SGA鎖定在物理內存中而不被放入 SWAP 中，這樣對效率有好處關於內存的設置，要再進行細致的調整，起的作用不大，但可根據statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息來考慮微調
pga設置
hash_area_size用於在內存中進行排序的區域
hash_value不會影響PGA，他是系統自動計算HASH運算，以定位內存地址。
增大hash_area_size,可以減少物理磁盤的排序，所以提高排序的速度。
9I管理PGA有兩種方式，同時影響到hash_area_size
自動配置PGA
手動配置PGA
如果設置了auto，那麼sort area, hash area自動分配大小，pga_aggregate_target參數被使用。
如果設置為 manual，那麼參數sort area, hash area參數被使用，對於某些特別耗資源的可以指定manual，然後設置合理的sort area,hash area。
設置10104事件來判斷hash_area_size是否要增大，如果Number of rows left to be
iterated over的值為非0，表示讀了臨時表，要兩階段不能在內存中一次完成
在Oracle9i之前，PGA的計算和控制都是比較復雜的事情，從Oracle9i開始，Oracle提供了一種SQL內存管理的新方法：自動化SQL執行內存管理（Automated SQL Execution Memory Management），使用這個新特性，Oracle可以自動調整S Q L內存區，而不用關閉數據庫，這一改進大大簡化了DBA的工作，同時也提高了Oracle數據庫的性能。
為實現自動的PGA管理，Oracle引入了幾個新的初始化參數：
1．PGA_AGGREGATE_TARGET-此參數用來指定所有session總計可以使用最大PGA內存。這個參數可以被動態的更改,取值范圍從10M -- （4096G-1 ）bytes。
2。WORKAREA_SIZE_POLICY-此參數用於開關PGA內存自動管理功能，該參數有兩個選項：AUTO 和 MANUAL，當設置為AUTO時，數據庫使用Oracle9i提供的自動PGA管理功能，當設置為MANUAL時，則仍然使用Oracle9i前手工管理的方式。
缺省的，Oracle9i中WORKAREA_SIZE_POLICY被設置為AUTO。
需要注意的是，在Oracle9i中，PGA_AGGREGATE_TARGET參數僅對專用服務器模式下（Dedicated Server）的專屬連接有效，但是對共享服務器（Shared Server）連接無效；從Oracle10g開始PGA_AGGREGATE_TARGET對專用服務器連接和共享服務器連接同時生效。
PGA_AGGREGATE_TARGET 參數同時限制全局PGA分配和私有工作區內存分配：
1．對於串行操作，單個SQL操作能夠使用的PGA內存按照以下原則分配：
MIN（5% PGA_AGGREGATE_TARGET，100MB）
2．對於並行操作
30% PGA_AGGREGATE_TARGET /DOP （DOP=Degree Of Parallelism 並行度）
要理解PGA的自動調整，還需要區分可調整內存（TUNABLE MEMORY SIZE）與不可調整內存（UNTUNABLE MEMORY SIZE）。可調整內存是由SQL工作區使用的，其余部分是不可調整內存。
啟用了自動PGA調整之後， Oracle仍然需要遵循以下原則：
UNTUNABLE MEMORY SIZE + TUNABLE MEMORY SIZE <= PGA_AGGREGATE_TARGET
數據庫系統只能控制可調整部分的內存分配，如果可調整的部分過小，則Oracle永遠也不會強制啟用這個等式。
另外，PGA_AGGREGATE_TARGET參數在CBO優化器模式下，對於SQL的執行計劃會產生影響。Oracle在評估執行計劃時會根據PGA_AGGREGATE_TARGET參數評估在Sort，HASH-JOIN或Bitmap操作時能夠使用的最大或最小內存，從而選擇最優的執行計劃。
對於PGA_AGGREGATE_TARGET參數的設置，Oracle提供這樣一個建議方案
1．對於OLTP系統
PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 20%
2．對於DSS系統
PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 50%
也就是說，對於一個單純的數據庫服務器，通常我們需要保留20%的物理內存給操作系統使用，剩余80%可以分配給Oracle使用。Oracle使用的內存分為兩部分SGA和PGA，那麼PGA可以占用Oracle消耗總內存的20%（OLTP系統）至50%（DSS系統）。
這只是一個建議設置，更進一步的我們應該根據數據庫的具體性能指標來調整和優化PGA的使用。
對於PGA_AGGREGATE_TARGET參數的設置，Oracle提供這樣一個建議方案
1．對於OLTP系統
PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 20%
2．對於DSS系統
PGA_AGGREGATE_TARGET = (<Total Physical Memory > * 80%) * 50%
也就是說，對於一個單純的數據庫服務器，通常我們需要保留20%的物理內存給操作系統使用，剩余80%可以分配給Oracle使用。Oracle使用的內存分為兩部分SGA和PGA，那麼PGA可以占用Oracle消耗總內存的20%（OLTP系統）至50%（DSS系統）。
Oracle9i數據庫在內部特性方面有著非常大的增強，其中一個最令Oracle DBA興奮的莫過於可以動態設置全部的Oracle SGA控制參數。與8i不同的是，原來都將初始化參數放到一個文本文件中，並且在數據庫啟動的時候讀取，Oracle9i卻可以通過ALTER DATABASE和ALTER SYSTEM命令復位全部的Oracle參數。
在9i前，如果想對Oracle數據庫的處理模式作一些改變的話，Oracle管理員必須關閉數據庫並且重新設置INIT.ORA文件中的參數，然後重新啟動數據庫。對於白天使用OLTP模式運作，晚上切換到數據倉庫模式的Oracle數據庫來說，這種重新設置是經常做的。
對於需要停止和重新啟動Oracle數據庫來修改參數來說，Oracle9i在這方面有明顯的加強，它令實現數據庫連續可用的目標變得更加簡單。
這種可以在Oracle SGA中動態增加和縮小不同區域的能力為Oracle數據庫管理員提供了一些令人激動的新特性。SGA每個區域的數據庫活動都可以獨立地被監視，而且也可以在Oracle數據庫中，根據使用的模式分配和取回資源。
我們首先來看以下Oracle9i數據庫和Oracle8i數據庫的一些區別。Oracle9i的一個最重要的加強是對於連接到Oracle數據庫的全部專用連接，都無需要擁有一個獨立的PGA空間。在Oracle8i中，對於專用的Oracle連接，我們都需要在內存中分配一個獨立的區域，稱為Program Global Area或者PGA。PGA空間中包含有SORT_AREA_SIZE和額外的RAM控制結構以用來維護連接任務的狀態。在Oracle9i中，PGA空間已經被Oracle SGA中的一個新內存空間代替，它是通過PGA_AGGREGATE_TARGET參數來設置的
由於全部的內存使用都在Oracle SGA中分配，所以Oracle數據庫管理員可以將分配給Oracle服務器的內存加大，可以分配至直到Orace服務器全部內存的80%。Oracle建議將服務器其余的20%內存保留給操作系統的任務。
當用戶連接到Oracle9i數據庫時，排序工作所需要的內存將會在Oracle9i的PGA_AGGREGATE_TARGET區域中分配。這可以令Oracle9i比Oracle8i跑得更快，這是由於內存只在需要的期間才分配，並且在完成後就可以馬上釋放給其它連接的Oracle任務使用。
動態修改SGA區域
由於Oracle管理員現在可以增加和減少SGA的全部區域，因此我們可以快速地查看一下SGA區域是怎樣的，這樣我們就可以知道Oracle DBA如何監視這些區域的使用並且為Oracle數據庫更有效地重新分配內存。SGA的區域可以分為以下的部分。
數據緩沖（Data buffers）--Oracle9i擁有多達7個獨立的數據緩沖來保存磁盤送來的數據塊。這些包含有傳統的KEEP pool，RECYCLE pool和DEFAULT pool，還有為每個Oracle數據庫支持的塊大小(2K, 4K, 8K, 16K和32K) 而建立的獨立數據緩沖池
我們可以監視這7個數據緩沖區域的命中率，如果緩沖的命中率保持在百分之九十以上，我們可以減少分配給這些數據緩沖的內存，並且將它們重新分配給其它Oracle實例中需要額外內存的地方。
當數據緩沖的命中率（DBHR）下降時，我們可以將內存由一個數據緩沖中分離出來，並且將它重新分配給其它的數據緩沖
共享池（Shared pool）--Oracle9i的共享池有一個很重要的作用是分析和執行Oracle SQL語句。低的library cache命中率表示分配給library cache的內存不足，當shared pool需要對SQL語句進行大量的分析和執行時，Oracle9i的數據庫管理員可以使用ALTER SYSTEM來為shared pool加入額外的內存。
PGA區域--分配給PGA_AGGREGATE_TARGET的內存是用來讓Oracle連接維護與連接相關的信息（例如游標的狀態），並且對SQL的結果集進行排序。
Log buffer--對於Oracle redo log緩沖是否有大量活動，我們可以在log switch（日志轉換）的頻率上看出來。Oracle管理員可以監視redo log區域的活動，並且在Oracle數據庫需要額外的內存為原始的緩沖區域服務時，動態地增加內存。
現在就讓我們來仔細看以下這些內存區域之間是如何作用的。
改變PGA的內存分配
當以下的其中一個條件是真時，我們將需要動態地修改PGA_AGGREGATE_TARGET參數。
。當V$SYSSTAT中對"estimated PGA memory for one-pass" 的統計值超出PGA_AGGREGATE_TARGET時，我們就需要增加PGA_AGGREGATE_TARGET的值。
。當V$SYSSTAT中對"workarea executions - multipass" 的統計值超過百分之一時，數據庫將會由更多的內存中得到好處
。你可能過高地估計了PGA內存的空間，當V$SYSSTAT中"workarea executions - optimal"的值一直是100%時，可以考慮減少PGA_AGGREGATE_TARGET的值。
我們可以通過一個簡單的腳本來查看shared pool是否需要更多的內存。
量度Library Cache的丟失率
set lines 80;
set pages 999;
column mydate heading 'Yr. Mo Dy Hr.' format a16
column c1 heading "execs" format 9,999,999
column c2 heading "Cache Misses|While Executing" format 9,999,999
column c3 heading "Library Cache|Miss Ratio" format 999.99999
break on mydate skip 2;
select
to_char(snap_time,'yyyy-mm-dd HH24') mydate,
sum(new.pins-old.pins) c1,
sum(new.reloads-old.reloads) c2,
sum(new.reloads-old.reloads)/
sum(new.pins-old.pins) library_cache_miss_ratio
from
stats$librarycache old,
stats$librarycache new,
stats$snapshot sn
where
new.snap_id = sn.snap_id
and
old.snap_id = new.snap_id-1
and
old.namespace = new.namespace
group by
to_char(snap_time,'yyyy-mm-dd HH24')
Cache Misses
Yr. Mo Dy Hr. execs While Executing LIBRARY_CACHE_MISS_RATIO
---------------- ---------- --------------- ------------------------
2001-12-11 10 10,338 3 .00029
2001-12-12 10 182,477 134 .00073
2001-12-14 10 190,707 202 .00106
2001-12-16 10 2,803 11 .00392
由上面的例子看到，在每天的9：00AM到10：AM之間，shared pool明顯缺少內存。我們就可以在這段期間動態地重新設置shared_pool參數以由db_cache_size中分配額外的內存。
SGA的閥值摘要
由下面的表一可以看到，在監視SGA的內存使用時，有幾個明顯的閥值可以利用。我們可以寫一些腳本並在其中集成一些智能，這樣就可以在處理的需求變化時重新設置SGA。
RAM Area Too-small Condition Too-Large Condition
Shared pool Library cache misses No misses
Data buffer cache Hit ratio < 90% Hit ratio > 95%
PGA aggregate high multi-pass executions 100% optimal executions
表1：SGA中的異常條件指示
查看SGA內存區域的負載
Oracle9i使用了一些新的內部視圖或者在現有的視圖中加入新的列來幫助查看Oracle9i中的內部內存分配情況。以下的新V$視圖可以幫助監視Oracle9i連接的內存使用。
V$PROCESS -在Oracle9i中加入了三個新的列以監視PGA內存的使用，新列的名字是pga_used_mem, pga_alloc_mem 和pga_max_mem。
V$SYSSTAT -加入了很多新的統計行，包括有area statistics for optimal, one-pass和multi-pass。
V$PGASTAT -該新視圖展示了全部後台進程和專用連接的PGA內存使用
V$SQL_PLAN--這個新視圖包含了全部當前執行的SQL的執行計劃信息。對於需要最優化的SQL語句的性能調整專家來說這是非常吸引人的。
V$WORKAREA -這個新視圖提供了Oracle9i連接的累積內存統計的詳細信息。
V$WORKAREA_ACTIVE - 這個新的視圖提供了當前全部正在執行的SQL語句的內部內存使用信息。
它們的目的是通過這些V$視圖來監視SGA中的內存使用，然後根據Oracle實例的處理要求，通過ALTER SYSTEM命令重新分配內存。我們以下來看一些這些新的Oracle9i特性和腳本，它可以幫助我們查看詳細的內存使用。
當然我們不可能在這裡詳述所有的技術，以下就讓我們看一個簡單的例子，它通過使用V$SYSSTAT視圖來決定何時重新設置PGA_AGGREGATE_TARGET參數。
以下的查詢可以得到自數據庫實例啟動後work areas被執行的全部數目和百分比。
work_area.sql
select
name profile,
cnt,
decode(total, 0, 0, round(cnt*100/total)) percentage
from
(
select
name,
value cnt,
(sum(value) over ()) total
from
v$sysstat
where
name like 'workarea exec%'
);
這個查詢的輸出可能如下：
PROFILE CNT PERCENTAGE
----------------------------------- ---------- ----------
workarea executions - optimal 5395 95
workarea executions - onepass 284 5
workarea executions - multipass 0 0
這個查詢的輸出是用來告訴DBA何時動態調整PGA_AGGREGATE_TARGET參數。在通常的情況下，如果multi-pass的執行大於0，就需要增加PGA_AGGREGATE_TARGET的值，並且在optimal executions是100%時減少它的值。
我們還可以使用V$PGASTAT視圖來決定我們的Oracle實例的內存使用。V$PGASTAT視圖提供了PGA使用和自動內存管理的實例級摘要統計信息。以下的腳本提供了全部Oracle9i連接的整體內存使用的統計信息。
以下是一個用來檢測Oracle9i中PGA內存使用的簡單腳本。
check_pga.sql
column name format a30
column value format 999,999,999
select
name,
value
from
v$pgastat
The output of this query might look like the following:
NAME VALUE
------------------------------------------------------ ----------
aggregate PGA auto target 736,052,224
global memory bound 21,200
total expected memory 141,144
total PGA inuse 22,234,736
total PGA allocated 55,327,872
maximum PGA allocated 23,970,624
total PGA used for auto workareas 262,144
maximum PGA used for auto workareas 7,333,032
total PGA used for manual workareas 0
maximum PGA used for manual workareas 0
estimated PGA memory for optimal 141,395
maximum PGA memory for optimal 500,123,520
estimated PGA memory for one-pass 534,144
maximum PGA memory for one-pass
在上面的v$pgastat顯示中我們可以看到以下的統計。
Aggregate PGA auto target -該列給出了可用於Oracle9i連接的全部內存。我們已經提過，這個值是由PGA_AGGREGATE_TARGET設置的。
Global memory bound -該統計表示work area的最大值，Oracle建議在該統計值下降到1M時，你應該增加PGA_AGGREGATE_TARGET的值。
Total PGA allocated - 這個統計顯示了數據庫中全部PGA內存使用的高水位線。當使用增加時，你應該看到這個值接近PGA_AGGREGATE_TARGET的值。
Total PGA used for auto workareas - 這個統計監視內存的使用或者全部運行在自動內存模式中的全部連接。要記住的是，並不是全部的內部進程使用自動內存特性。例如，Java和PL/SQL 將分配內存，但是這部分將不會統計到這個值中。因此我們可使用整體PGA的值來減去該值，以得到連接和Java and PL/SQL使用的內存。
Estimated PGA memory for optimal/one-pass - 該統計估計optimal模式下執行全部的連接任務所需要的內存。要記住的是，如果Oracle9i遇到內存不足時，它就會調用multi-pass操作。這個統計對於監視Oracle9i中的內存使用是非常重要的，大多數的Oracle DBA將會增加PGA_AGGREGATE_TARGET到這個值。
現在我們已經了解了這個概念，以下就讓我們來看一下自動重新配置SGA有哪些方法。
總述
在一個UNIX環境中，在處理需求改變時通過定時任務來修改內存配置是非常簡單的。例如，許多Oracle數據庫在一般的工作時間以OLTP模式運作，在晚上的時候則運行對內存需求很大的批量報告。
我們知道在一個OLTP數據庫中應該將DB_CACHE_SIZE設置為一個較大的值，而在需求內存很大的批量任務中則需要給PGA_AGGREGATE_TARGET分配額外的內存。
以下的UNIX腳本可以用來重新設置OLTP和DSS的SGA值而無需將實例停下來。在這個例子中，我們假定有一個孤立的帶有8GB內存的的Oracle服務器。我們還假定保留20%的內存供UNIX使用，而剩下的6GB內存則用作Oracle和Oracle連接。這些腳本是在HP/UX或者Solaris中使用的，並且接受$ORACLE_SID作為一個參數。
DSS_CONFIG.KSH腳本將在每晚的6：00 p.m運行，以重新設置Oracle在晚上運行對內存需求很大的批量任務。
dss_config.ksh
#!/bin/ksh
# First, we must set the environment . . . .
ORACLE_SID=$1
export ORACLE_SID
ORACLE_HOME=`cat /etc/oratab|grep ^$ORACLE_SID:|cut -f2 -d':'`
#ORACLE_HOME=`cat /var/opt/oracle/oratab|grep ^$ORACLE_SID:|cut -f2 -d':'`
export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$PATH
export PATH
$ORACLE_HOME/bin/sqlplus -s /nologin<
connect system/manager as sysdba;
ALTER SYSTEM set db_cache_size=1500m;
ALTER SYSTEM set shared_pool_size=500m;
ALTER SYSTEM set pga_aggregate_target=400m;
exit
!
現在我們已經知道了一個常見的方式來修改Oracle的配置，我們也很容易地看到可以很簡單地開發一個技術來連續地監控Oracle的處理需求，並且根據現有的數據庫需求來使用ALTER SYSTEM作修改。
結論
雖然Oracle9i中的內存管理仍然需要很多的手工操作，不過大部分的Oracle管理員可以使用工具來連續地監控Oracle SGA中的內存使用，並且可以根據Oracle instance中現在的使用情況來自動地重新分配內存。這樣就可以令Oracle 管理員根據系統的變化來靈活地重新設置他們的系統。
