oracle 10g 自動共享記憶體管理

從Oracle 10g開始，Oracle提供了自動SGA的管理（簡稱ASMM，即Automatic Shared Memory Management）新特性。
所謂ASMM，就是指我們不再需要手工設定shared pool、buffer pool等若干記憶體池的大小，而是為SGA設定一個總的大小尺寸即可。
Oracle 10g資料庫會根據系統負載的變化，自動調整各個元件的大小，從而使得記憶體始終能夠流向最需要它的地方。

比如，假設某個系統，白天屬於OLTP應用，因此會需要較多的buffer cache。
而該系統在晚上屬於DSS應用。對於DSS應用，很多的SQL語句由於都是進行全表掃描，因此都會採取並行方式完成。
我們知道，並行時需要靠若干的從屬程式完成工作，而從屬程式會從large pool中進行分配。
於是，晚上會需要較多的large pool。如果我們啟用了ASMM，則資料庫會根據負載的變化而自動的對記憶體大小進行調整，就不需要DBA進行手工調整了。

Oracle 10g提供了一個新的初始化引數：sga_target來啟動ASMM，該引數定義了整個SGA的總容量。
同時，初始化引數statistics_level必須設定為typical或all才能啟動ASMM，否則如果設定為basic，則關閉ASMM。

ASMM只能自動調整5個記憶體池的大小，它們是：shared pool、buffer cache、large pool、java pool和stream pool。
我們不再需要設定shared_pool_size、db_cache_size、large_pool_size、java_pool_size、streams_pool_size這五個初始化引數。
而其他的記憶體池，比如log buffer、keep buffer cache等仍然需要DBA手工進行調整。

舉例來說，假設我們將sga_target設定為500MB，表示SGA總容量為500MB。
但是如果我們需要配置100MB的keep buffer cache，則必須手工設定引數db_keep_cache_size為100MB。
同時如果設定引數log_buffer為3MB，那麼shared pool、buffer cache等可以調整的5個部分的總容量就是397MB（500-100-3=397）。

Oracle 10g還提供了另一個初始化引數sga_max_size。
sga_target的值不能超過sga_max_size的值，修改sga_max_size時，必須重啟例項才能生效，而sga_target則可以線上修改，立即生效，無須重啟例項。

為了實現ASMM，Oracle新引入了一個名為MMAN（Memory Manager）的後臺程式。
每隔很短的一段時間，MMAN程式就會啟動，然後去詢問一下Oracle提供的各個記憶體元件顧問，比如有buffer cache顧問，
也有shared pool顧問，由這些顧問根據當前的負載情況，將這5個可以自動調整的記憶體池的、建議的大小尺寸，返回給MMAN。
於是，MMAN程式就會根據該返回的值，來設定各個記憶體池。同時，如果我們使用了spfile，還會將這些顧問得出的建議值寫入spfile裡。
這樣，下次啟動例項時，就可以直接把顧問得出的建議值拿來作為啟動記憶體池的依據了。

如果我們啟用了ASMM，同時又手工設定了可以自動調整大小的記憶體池的尺寸，比如設定了引數shared_pool_size為一個非0值的時候，會怎麼樣？
對於Oracle 10g來說，我們為自動調整大小的記憶體元件設定了值，則會以我們設定的值作為自動調整的最小值。
也就是說，假設sga_target為4GB，而我們將shared_pool_size設定為600MB，則MMAN在進行自動調整時，永遠不會將shared pool設定為600MB以下。

實際上，為了使用ASMM，Oracle為這5個可自動調整的元件又提供了5個控制它們大小尺寸的引數，以“__”（兩個下畫線開頭）。我們把當前的spfile匯出到pfile裡。

SQL> create pfile='/u01/init.ora' from spfile;
SQL> !vi /u01/init.ora

開啟該pfile以後，我們會發現檔案的前5行，會顯示如下的內容（具體值可能不一樣）：

ora10g.__db_cache_size=134217728
ora10g.__java_pool_size=4194304
ora10g.__large_pool_size=4194304
ora10g.__shared_pool_size=62914560
ora10g.__streams_pool_size=0

可以看到，這5個初始化引數都以“__”開頭，後面的部分與我們手工設定記憶體池大小的引數相同。
比如__db_cache_size與db_cache_size對應等。這種以“_”開頭的引數我們叫做隱藏引數。
所謂隱藏引數，就是沒有官方文件對其含義進行說明的引數。這種引數會根據版本的不同而發生改變。
這5個隱藏引數（比如__shared_pool_size）由MMAN程式負責修改，而與之相對應的其他引數（比如shared_pool_size）則由DBA進行設定。
因此，當我們啟動資料庫時，資料庫核心會在初始化引數__shared_pool_size與shared_pool_size之間進行比較。
如果shared_pool_size沒有設定，或設定為0，或設定的值比__shared_pool_size小，則以MMAN自動調整的值來設定記憶體池的尺寸。
否則，以DBA設定的值來設定記憶體池的尺寸。

如果我們在資料庫執行過程中，修改了某個可自動調整的記憶體池的大小，這時會怎麼樣？
如果我們設定的值比MMAN自動調整出來的值要大，則該記憶體池立即調整為設定的值的大小，
同時我們所設定的值作為MMAN新的、自動調整的最小值；反之，如果設定的值比MMAN自動調整出來的值要小，
則該記憶體池的大小不會變化，而我們所設定的值則只作為自動調整的最小值存在。
比如，當前MMAN自動調整出來的shared pool大小為150MB，也就是__shared_pool_size為150MB，同時shared_pool_size為60MB。
這時，如果我們將引數shared_pool_size從60MB設定為100MB的話，則shared pool的大小仍然為150MB，
但是新設定的100MB將作為自動調整時的下限；如果我們將引數shared_pool_size從60MB設定為200MB，則shared pool立即擴張，
從150MB擴張到200MB，同時200MB也將作為自動調整的新的下限。

我們來驗證一下。檢視v$sga_dynamic_components裡記錄了能夠動態調整的各個記憶體池的大小。

SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where component='
shared pool';
COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 80

當前MMAN自動調整出來的shared pool大小為80MB。

SQL> alter system set shared_pool_size=70M;
SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where component='
shared pool';
COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 80

我們將shared_pool_size設定為70MB，小於自動調整出來的值。可以看到，shared pool沒有縮小，仍然是80MB。我們再將其從80MB擴大到100MB。

SQL> alter system set shared_pool_size=100M;
SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where component='
shared pool';
COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 100

顯然，只要我們設定的值比自動調整出來的值大，就會立即生效。

同時，如果當前我們啟用了ASMM，同時並沒有為這5個可以自動調整的記憶體池引數指定具體的值。
當資料庫在ASMM狀態下執行一段時間以後，我們再禁用ASMM，會發生什麼？我們來看下面的試驗。

SQL> select name,value from v$parameter
2 where name in('shared_pool_size','db_cache_size','
java_pool_size','large_pool_size',' streams_pool_size');
NAME VALUE
-------------------- --------------
shared_pool_size 96468992
large_pool_size 0
java_pool_size 0
streams_pool_size 0
db_cache_size 0

可以看到，除了shared pool為DBA指定以外（因為shared_pool_size大於0），其他的記憶體池都由ASMM指定。

SQL> select component, current_size FROM v$sga_dynamic_
components 2 where component like '%pool' or component=
'DEFAULT buffer cache';
COMPONENT SIZE_MB
---------------------------------- -----------
shared pool 138412032
large pool 4194304
java pool 4194304
streams pool 0
DEFAULT buffer cache 373293056

我們看到，ASMM根據當前的負載情況，為這5個記憶體池指定了大小。

SQL> alter system set sga_target=0;
SQL> select name,value from v$parameter
2 where name in('shared_pool_size','db_cache_size','
java_pool_size','large_pool_size',' streams_pool_size');
NAME VALUE
-------------------- --------------
shared_pool_size 138412032
large_pool_size 4194304
java_pool_size 4194304
streams_pool_size 0
db_cache_size 373293056

當我們將sga_target設定為0，從而禁用ASMM時，會發現，Oracle會自動將當前記憶體池的大小賦給對應的初始化引數（shared_pool_size、db_cache_size等）。
同時我們也可以注意到，shared_pool_size的值也不再是DBA當時指定的96468992，而是被ASMM自動調整出來的138412032所覆蓋。

[@more@]