oracle自動共享內存管理(ASMM)
從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 comp;
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 comp;
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 comp;
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 comp;
COMPONENT SIZE_MB
---------------------------------- -----------
shared pool 138412032
large pool 4194304
java pool 4194304
streams pool 0
DEF***T 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所覆蓋。
比如，假設某個系統，白天屬於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 comp;
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 comp;
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 comp;
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 comp;
COMPONENT SIZE_MB
---------------------------------- -----------
shared pool 138412032
large pool 4194304
java pool 4194304
streams pool 0
DEF***T 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所覆蓋。