Oracle 記憶體自動管理--關閉自動管理

dbhelper發表於2015-01-29

Oracle 記憶體自動管理

Oracle 記憶體自動管理

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

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

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

ASMM只能自動調整5個記憶體池的大小,它們是:shared poolbuffer cachelarge pooljava poolstream pool我們不再需要設定shared_pool_sizedb_cache_sizelarge_pool_sizejava_pool_sizestreams_pool_size這五個初始化引數。而其他的記憶體池,比如log bufferkeep buffer cache等仍然需要DBA手工進行調整。

舉例來說,假設我們將sga_target設定為500MB,表示SGA總容量為500MB。但是如果我們需要配置100MBkeep buffer cache,則必須手工設定引數db_keep_cache_size100MB。同時如果設定引數log_buffer3MB,那麼shared poolbuffer cache等可以調整的5個部分的總容量就是397MB500-100-3=397)。

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

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

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

實際上,為了使用ASMMOracle為這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_sizedb_cache_size對應等。這種以“_”開頭的引數我們叫做隱藏引數。所謂隱藏引數,就是沒有官方文件對其含義進行說明的引數。這種引數會根據版本的不同而發生改變。5個隱藏引數(比如__shared_pool_size)由MMAN程式負責修改,而與之相對應的其他引數(比如shared_pool_size)則由DBA進行設定。因此,當我們啟動資料庫時,資料庫核心會在初始化引數__shared_pool_sizeshared_pool_size之間進行比較。如果shared_pool_size沒有設定,或設定為0,或設定的值比__shared_pool_size小,則以MMAN自動調整的值來設定記憶體池的尺寸。否則,以DBA設定的值來設定記憶體池的尺寸。

如果我們在資料庫執行過程中,修改了某個可自動調整的記憶體池的大小,這時會怎麼樣?如果我們設定的值比MMAN自動調整出來的值要大,則該記憶體池立即調整為設定的值的大小,同時我們所設定的值作為MMAN新的、自動調整的最小值;反之,如果設定的值比MMAN自動調整出來的值要小,則該記憶體池的大小不會變化,而我們所設定的值則只作為自動調整的最小值存在。比如,當前MMAN自動調整出來的shared pool大小為150MB,也就是__shared_pool_size150MB,同時shared_pool_size60MB。這時,如果我們將引數shared_pool_size60MB設定為100MB的話,則shared pool的大小仍然為150MB,但是新設定的100MB將作為自動調整時的下限;如果我們將引數shared_pool_size60MB設定為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 poolDBA指定以外(因為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_sizedb_cache_size等)。同時我們也可以注意到,shared_pool_size的值也不再是DBA當時指定的96468992,而是被ASMM自動調整出來的138412032所覆蓋。

 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8494287/viewspace-1419656/,如需轉載,請註明出處,否則將追究法律責任。

相關文章