現在的Oracle正在往智慧化方向發展。如果我們現在找一些8i/9i時代的Oracle書籍，怎麼樣配置合適的資料庫各記憶體池大小是非常重要的話題。但是進入10g之後，自動記憶體池調節成為一個重要Oracle特性。

 

在10g時，Oracle推出了ASMM（Automatic Shared Memory Management），實現了Oracle SGA和PGA內部結構的自調節。進入11g之後，AMM（Automatic Memory Management）實現了引數MEMORY_TARGET，將SGA和PGA的規劃全部統籌起來對待。

 

預設情況下，Oracle 11g是使用AMM的。我們在安裝過程中，指定Oracle使用記憶體的百分比，這個取值就作為MEMORY_TARGET和MEMORY_MAX_TARGET的初始取值使用。如果這兩個引數設定為非零取值，那麼Oracle就是採用AMM管理策略的。

 

同時，如果我們設定這兩個引數為0，則AMM自動關閉。對應的SGA_TARGET、PGA_AGGREGATE_TARGET引數取值非零之後，Oracle自動退化使用ASMM特性。

 

本篇簡單介紹一下AMM和ASMM的相互切換。

 

1、實驗環境介紹

 

我們選擇11.2.0.3進行試驗，當前狀態為ASMM。

 

 

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production

PL/SQL Release 11.2.0.3.0 - Production

CORE        11.2.0.3.0         Production

 

 

當前MEMORY_TARGET設定為零，AMM沒有啟用。

 

 

SQL> show parameter target

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

archive_lag_target                   integer     0

db_flashback_retention_target        integer     1440

fast_start_io_target                 integer     0

fast_start_mttr_target               integer     0

memory_max_target                    big integer 0

memory_target                        big integer 0

parallel_servers_target              integer     16

pga_aggregate_target                 big integer 108M

sga_target                           big integer 252M

 

 

2、從ASMM到AMM

 

在11g中，如果使用ASMM，對應的記憶體共享段是真實的共享段。

 

 

[oracle@SimpleLinux ~]$ ipcs -m

 

------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status     

0x00000000 32768      oracle    640        4194304    32                     

0x00000000 65537      oracle    640        260046848  32                     

0x01606d30 98306      oracle    640        4194304    32  

 

 

下面進行引數的調整，這裡筆者有一個建議，很多時候啟動umount階段故障都是由於不當的引數修改造成的。在進行引數修改之前，可以使用create pfile進行一下引數備份，可以加快故障出現時候的系統修復速度。

 

 

SQL> show parameter spfile

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

spfile                               string      /u01/app/oracle/dbs/spfileora11g.ora

 

SQL> create pfile from spfile;

Done

 

 

修改系統引數，將sga和pga的target值設定為0，memory的target設定非0。注意，這個過程很多引數是靜態的引數，可以都在spfile可見性中進行修改，之後重啟伺服器生效。

 

 

SQL> alter system set memory_max_target=360m scope=spfile;

System altered

 

SQL> alter system set memory_target=360m scope=spfile;

System altered

 

SQL> alter system set sga_target=0m scope=spfile;

System altered

 

SQL> alter system set sga_max_size=0 scope=spfile;

System altered

 

SQL> alter system set pga_aggregate_target=0 scope=spfile;

System altered

 

 

重新啟動資料庫伺服器，檢視引數配置。

 

 

SQL> conn / as sysdba

Connected.

SQL> startup force

ORACLE instance started.

 

Total System Global Area  263651328 bytes

Fixed Size                  1344284 bytes

Variable Size             176164068 bytes

Database Buffers           83886080 bytes

Redo Buffers                2256896 bytes

Database mounted.

Database opened.

 

SQL> show parameter target

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

archive_lag_target                   integer     0

db_flashback_retention_target        integer     1440

fast_start_io_target                 integer     0

fast_start_mttr_target               integer     0

memory_max_target                    big integer 360M

memory_target                        big integer 360M

parallel_servers_target              integer     16

pga_aggregate_target                 big integer 0

sga_target                           big integer 0

 

 

AMM啟動之後，系統共享段變為“虛擬”共享段。

 

[oracle@SimpleLinux dbs]$ ipcs -m

 

------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status     

0x00000000 163840     oracle    640        4096       0                      

0x00000000 196609     oracle    640        4096       0                      

0x01606d30 229378     oracle    640        4096       0  

 

 

3、從AMM到ASMM

 

下面是如何從AMM到ASMM。要完全關閉AMM，一定將MEMORY_TARGET和MEMORY_MAX_TARGET都設定為0才行。

 

 

SQL> alter system set memory_max_target=0 scope=spfile;

System altered

 

SQL> alter system set memory_target=0 scope=spfile;

System altered

 

SQL> alter system set pga_aggregate_target=100m scope=spfile;

System altered

 

SQL> alter system set sga_target=260m scope=spfile;

System altered

 

SQL> alter system set sga_max_size=260m scope=spfile;

System altered

 

 

注意，此時如果重新啟動系統，會報錯。

 

 

SQL> startup force

ORA-00843: Parameter not taking MEMORY_MAX_TARGET into account

ORA-00849: SGA_TARGET 272629760 cannot be set to more than MEMORY_MAX_TARGET 0.

SQL>

 

 

這個問題的原因是Oracle啟動過程中對於引數的內部檢查。因為MEMORY_MAX_TARGET被“顯示”的賦值，與SGA_TARGET賦值相沖突。

 

解決的方法就是使用引數預設值。建立出pfile之後，將顯示賦值為0的MEMORY_TARGET和MEMORY_MAX_TARGET記錄行刪除掉。再利用pfile啟動資料庫，重建spfile。

 

 

SQL> create pfile from spfile

  2  ;

 

File created.

 

--修改前

*.db_recovery_file_dest='/u01/app/fast_recovery_area'

*.db_recovery_file_dest_size=10737418240

*.diagnostic_dest='/u01/app'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=ora11gXDB)'

*.log_checkpoints_to_alert=TRUE

*.memory_max_target=0

*.memory_target=0

*.open_cursors=300

*.pga_aggregate_target=104857600

*.processes=150

 

--修改後

*.db_recovery_file_dest='/u01/app/fast_recovery_area'

*.db_recovery_file_dest_size=10737418240

*.diagnostic_dest='/u01/app'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=ora11gXDB)'

*.log_checkpoints_to_alert=TRUE

*.open_cursors=300

*.pga_aggregate_target=104857600

*.processes=150

*.remote_login_passwordfile='EXCLUSIVE'

 

 

使用pfile啟動資料庫，重建spfile。

 

 

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup pfile=/u01/app/oracle/dbs/initora11g.ora

ORACLE instance started.

 

Total System Global Area  272011264 bytes

Fixed Size                  1344372 bytes

Variable Size             176163980 bytes

Database Buffers           88080384 bytes

Redo Buffers                6422528 bytes

Database mounted.

Database opened.

SQL> show parameter target

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

archive_lag_target                   integer     0

db_flashback_retention_target        integer     1440

fast_start_io_target                 integer     0

fast_start_mttr_target               integer     0

memory_max_target                    big integer 0

memory_target                        big integer 0

parallel_servers_target              integer     16

pga_aggregate_target                 big integer 100M

sga_target                           big integer 260M

 

SQL> create spfile from pfile

  2  ;

 

File created.

 

 

重新啟動之後，ASMM切換完成。

 

 

SQL> startup force

ORACLE instance started.

 

Total System Global Area  272011264 bytes

Fixed Size                  1344372 bytes

Variable Size             176163980 bytes

Database Buffers           88080384 bytes

Redo Buffers                6422528 bytes

Database mounted.

Database opened.

 

--真實的共享記憶體段結構

[oracle@SimpleLinux dbs]$ ipcs -m

 

------ Shared Memory Segments --------

key        shmid      owner      perms      bytes      nattch     status     

0x00000000 425984     oracle    640        8388608    25                     

0x00000000 458753     oracle    640        264241152  25                     

0x01606d30 491522     oracle    640        4194304    25 

 

--HugePage使用情況

[oracle@SimpleLinux dbs]$ grep Huge /proc/meminfo

HugePages_Total:    67

HugePages_Free:      1

HugePages_Rsvd:      0

Hugepagesize:     4096 kB

[oracle@SimpleLinux dbs]$

 

 

4、結論

 

AMM和ASMM是我們管理資料庫非常重要的工具，藉助自我調節的機制，我們可以做到資料庫自我管理。11g的AMM應該說是很方便的，但是在一些情況下，如HugePage，我們可能需要切換回ASMM。權當記錄，留需要的朋友待查。

---

---

每一個Oracle的初學者在入門階段都會接觸到SGA/PGA的知識，如果是從10g開始學習那麼會多或少會對ASMM有所瞭解，從使用的角度來說ASMM的出現極大地簡化了Oracle記憶體初始化引數的設定，在ASMM的使用上高階DBA和初學者不會有太大的差別；很多人因此而認為ASMM極大程度地減少了資料庫對於專業DBA的依賴：如果我們有一個足夠智慧的DB，那麼為什麼還要花費金錢僱傭DBA呢？這似乎是時下一種十分流行的想法。當然這種想法我個人是不能苟同的，ASMM一定程度上帶來了便利，更大程度上它是一個黑盒，黑盒裡面藏了很多秘密，這些秘密帶來比手動管理更多的不確定性；在10g release 1和10.2的早期版本中ASMM扮演的角色有點像一個闖禍精，另一個讓使用者對ASMM很不待見的原因是ASMM直接拖慢了startup的速度。一個個人觀點是ASMM也好AMM也罷，都要求產品資料庫DBA掌握更多SGA/PGA相關的知識才能成功”駕馭”這些”有智力”的傢伙，有點誇張的說這個時候的DBA很像一個chemist(需要和一大堆以1個或2個下劃線開頭的奇怪引數打交道)。

為了不辱使命我們真的有必要了解一下ASMM的基本知識，顯然這並不是一件容易的事情……

Oracle的SGA基本記憶體元件從9i開始並沒有非常大的變化，他們包括:

• Buffer Cache 我們常說的資料庫快取記憶體，雖然我一直不明白要冠以高速之名
  • Default Pool                  預設的緩衝池，大小由DB_CACHE_SIZE決定
  • Keep Pool                     持久的緩衝池，大小由DB_KEEP_CACHE_SIZE決定
  • Non standard pool         非標準塊標準池，大小由DB_nK_cache_size決定
  • Recycle pool                 回收池，大小由db_recycle_cache_size決定
• Shared Pool 共享池，大小由shared_pool_size決定
  • Library cache   俗稱的庫快取
  • Row cache      行快取，也叫字典快取
• Java Pool         java池，大小由Java_pool_size決定
• Large Pool       大池，大小由Large_pool_size決定
• Fixed SGA       固定的SGA區域，包含了Oracle內部的資料結構，一般被存放在第一個granule中

在9i中尚未引入ASMM，唯一的選擇是手動管理的SGA，有時候也叫做MSMM。在9i中除去buffer cache的大小可以手動修改外，其餘元件都無法動態修改。因為缺乏一種動態管理的機制，所以在9i中如果有某個記憶體區域有急用，也無法從其他有空閒記憶體的元件中捐獻一些來解燃眉之急。

手動管理SGA的缺點在於:

• 個別元件如shared pool、default buffer pool的大小存在最優值，但元件之間無法交換記憶體
• 在9i中就提供了多種記憶體建議(advisor)，但都要求人工手動干預
• 無法適應工作負載存在變化的環境
• 往往會導致記憶體浪費，沒有用到實處
• 若設定不當，引發著名的ORA-04031錯誤的可能性大大提高

ASMM的優勢在於:

• 全自動的共享記憶體管理
• 無需再配置每一個記憶體元件大小引數
• 僅使用一個引數sga_target驅動
• 有效利用所有可用的記憶體，極大程度上減少記憶體浪費
• 對比MSMM其記憶體管理模式:
  • 更加動態
  • 更加靈活
  • 並具備適應性
• 易於使用
• 一定程度上增強了效能，因為記憶體分配更為合理了
• 當某個元件急需更多記憶體時可以有效提供，因此可以一定程度避免ORA-04031的發生

ASMM主要可以囊括為三個部分：
1.由一個新引數sga_target驅動的管理模式
2.記憶體交換的模型，包括了：記憶體元件(memory component)，記憶體代理(memory broker)和記憶體交換機制(memory mechanism)
3.記憶體建議(memory advisor)

ASMM下一部分引數是自動設定的(Automatically set)，這些引數包括:shared_pool_size、db_cache_size、java_pool_size、large_pool _size和streams_pool_size；而另外一些是需要手動設定的靜態引數，包括了:db_keep_cache_size、db_recycle_cache_size、db_nk_cache_size、log_buffer以及固定SGA記憶體結構等，如果以上沒有手動設定這些引數的話，除去log_buffer和fixed sga其他記憶體元件一般預設大小為零。

透過ASMM使用者僅需要設定一個sga_target引數，其他引數都將由ASMM自行內部控制。但如果使用者依舊設定瞭如db_cache_size、java_pool_size等引數，那麼這些引數被認為是相關記憶體元件的最小限制，同時每個記憶體元件的大小也存在一個最大上限(內部的)。在例項啟動階段，Oracle會將必要的記憶體顆粒(granule，當SGA<1GB時granule大小為4M，當SGA>1GB時granule大小為16M)分配給記憶體元件，多餘沒有分配出去的全都分配給buffer cache，之後隨著系統的不斷活躍更多的記憶體顆粒(granule)將被分配給急需記憶體的元件。我們可以動態地修改sga_target引數，前提是所在的系統平臺支援動態地共享記憶體(dism，主流平臺都支援)。使用ASMM的一個必要條件是初始化引數statistics_level必須設定為typical或ALL，如果設定為BASIC那麼MMON後臺程式(Memory Monitor is a background process that gathers memory statistics (snapshots) stores this information in the AWR (automatic workload repository). MMON is also responsible for issuing alerts for metrics that exceed their thresholds)將無法有效分析記憶體的使用的統計資訊從而驅動ASMM的自動調優，實際上我們不能同時設定sga_target為非零值和statistics_level為BASIC:

SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 2000M
sga_target                           big integer 2000M

SQL> show parameter sga_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_target                           big integer 2000M

SQL> alter system set statistics_level=BASIC;
alter system set statistics_level=BASIC
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00830: cannot set statistics_level to BASIC with auto-tune SGA enabled

如果使用了server parameter file即spfile的話，ASMM會在例項shutdown之前將當前實際的記憶體元件大小(Oracle認為這是最優的，但實際上可能不是)儲存到spfile中，如果你使用strings命令列印過spfile的內容的可以發現一些以雙下劃線開頭的引數，如:

G10R2.__db_cache_size=973078528
G10R2.__java_pool_size=16777216
G10R2.__large_pool_size=16777216
G10R2.__shared_pool_size=1006632960
G10R2.__streams_pool_size=67108864

這些在spfile儲存的元件大小會在下次啟動時被沿用，以達到將已經實踐得出的”最佳值”記住的目的，這樣下次就不用從頭再”學習”了。

在ASMM的記憶體交換模型中存在三類元件

1. 可調優元件(tunable):可調優元件是那些大小可以隨之變化且若過小僅損害少量效能。buffer cache就是一個經典的例子，cache過小的情況下應用程式仍能正常執行，但帶來的代價是更多的 IO。注意可調優元件同時存在一個下限。舉例來說共享池由庫快取Library cache和其他一些 subheap子堆組成，那麼共享池就存在一個下限要保證至少能放下某個一個時刻並行開啟的遊標(open cursors)以及負擔其他共享池client的執行時記憶體分配需求。類似的buffer cache也存在一個下限，該下限至少要大於並行被pin住的buffer的總和(雖然這部分很小)
2. 不可調元件(Un-tunable):不可調元件是那些存在最小下限的記憶體元件，這個最小下限足夠讓應用程式正常執行，超過這個上限並不會帶來額外的效能收益。在這類元件中large pool是一個典型。
3. 固定大小元件(Fixed Size)：自動調優框架之外的元件，一般為固定大小。這些元件的大小僅在手動調整時改變。例如非標準塊大小的高速緩衝池

記憶體交換模型中記憶體大小調整的申請(memory resize request)存在三種不同的模式，它們分別是：

立即記憶體申請(Immediate Request)：這種申請模式一般出現在ASMM管理的某個自動調優元件在無法分配到連續可用記憶體塊(chunk)時，為了避免出現OUT-OF-MEMORY(ORA-04031)的錯誤，系統嘗試從其他候選元件中轉移一個記憶體顆粒(granule)過來。需要注意的是當前可能沒有可用的全空granule，這時就會出現不完整的轉移，在此情形下系統會開始從候選元件中清理記憶體顆粒以滿足記憶體申請，並將一個granule不完整地轉移給急需記憶體的元件。

延遲記憶體申請(Deferred Request)：這種申請一般出現在系統認為存在一種更為合理的記憶體分配時，考慮在元件之間轉移一個或多個granule。用以判定最佳記憶體分配的依據是MMON程式所提供的統計資訊delta.

手動記憶體申請(Manual Request)：這種申請僅發生在使用者使用alter system命令手動調整記憶體元件的大小時。在這種模式下僅允許使用空的記憶體顆粒參與大小調整。如果當時沒有足夠的空granule，那麼針對元件grow操作會返回ORA-4033錯誤，而針對元件shrink操作會返回ORA-4034錯誤。

當ASMM被啟用後，記憶體代理(Memory Broker)定期執行上圖所示的活動。以上操作都處於延遲記憶體申請模式下(Deferred)。其目的是透過自動化的作業來調優自動調優元件(auto-tunable component)的大小以適應不斷改變的工作負載，將記憶體分配到最需要它們的地方。MMON輔助程式會在後臺不斷將統計資訊和記憶體建議定期地捕獲到迴圈使用的記憶體中，並計算不同時期快取資訊之間的差值；MMON還會基於Memory Broker的策略分析這些差值並估算出長期和短期內的趨勢。最後MMON基於以上分析生成一些記憶體元件的大小調整決議並將相應的申請傳送到一個系統申請佇列中(resize request system queue)。MMAN後臺程式(Memory Manager is a background process that manages the dynamic resizing of SGA memory areas as the workload increases or decreases)會定期掃描系統申請佇列並執行記憶體轉移。

在10gR1中Shared Pool的shrink收縮操作存在一些缺陷，造成缺陷的原因是在該版本中Buffer Cache還沒有能力共享使用一個granule，這是因為Buffer Cache的granule的尾部由granule header和Metadata(可能是buffer header或者RAC中的Lock Elements)拼接組成，在其尾部不容許存在空洞。另一個原因是當時的shared pool允許不同生命週期duration(以後會介紹)的chunk存放在同一個granule中，這造成共享池無法完全釋放granule。到10gR2中透過對Buffer Cache Granule結構的修改允許在granule header和buffer及Metadata(buffer header或LE)存在縫隙，同時shared pool中不同duration的chunk將不在共享同一個granule，透過以上改進buffer cache與shared pool間的記憶體交換變得可行。此外在10gr2中streams pool也開始支援記憶體交換(實際根據不同的streams pool duration存在限制)

當某個元件扮演捐獻者(Donor，下面的trace中會看到)角色時，它可能將一個不完整granule轉移給buffer cache，那麼在該granule被使用前需要完成以下步驟:

1. 首先在該granule的尾部生成新的granule header
2. 針對剩下的chunk判定在該granule中是否還有未使用的buffer header
3. 如果有，那麼將chunk中的記憶體轉換為一個資料塊。否則將之轉換為一個metadata塊
4. 重複以2-4步驟，直到該granule被轉換完

接著我們來了解一下記憶體轉移的基本原理，當將buffer cache中的granule轉移給shared pool時，將按照以下步驟:

1. MMAN後臺程式找到一塊屬於buffer cache的合適granule
2. MMAN將看中的granule置入quiesce列表中(Moving 1 granule from inuse to quiesce list of DEFAULT buffer cache for an immediate req)
3. DBWR將負責寫出置入quiesced列表中granule裡面的髒buffer(dirty buffer)
4. MMAN將為shared pool呼叫消費回撥函式(consume callback)，granule中free的chunk都會被shared pool消費(consume)掉，並對共享池新的記憶體分配可用。從這裡開始該granule變成一個shared granule共享記憶體顆粒，注意不要認為這個時候該granule的空間全部屬於共享池了，實際上有部分pin住的buffer及其Metadata(上述的buffer header和LE)的空間仍被buffer cache佔用著
5. 最終該granule將完整的轉移給shared pool，這時此granule不再是一個shared共享的

實際使用中ASMM受到眾多隱藏引數的影響，其中比較主要的引數有:

1. _enabled_shared_pool_duration:該引數控制是否啟用10g中特有的shared pool duration特性，當我們設定sga_target為0時該引數為false；同時在10.2.0.5前若cursor_space_for_time設定為true時該引數也為false，不過在10.2.0.5以後cursor_space_for_time引數被廢棄
2. _memory_broker_shrink_heaps:若該引數設定為0那麼Oracle不會去收縮shared pool或java pool，當該引數大於0，會在shrink request失敗後等待該引數指定秒數時間後再次申請
3. _memory_management_tracing: 該引數控制針對MMON和MMAN後臺程式包括記憶體建議(advisor)和記憶體代理(Memory Broker)決議的相關trace的級別；針對ORA-04031的診斷可以設定為36，設定為8啟用針對啟動期間元件大小的trace，設定為23啟動針對Memory Broker decision的跟蹤，設定為32將轉儲cache resize的細節；該引數的具體級別如下:

Level	Contents
0x01	Enables statistics tracing
0x02	Enables policy tracing
0x04	Enables transfer of granules tracing
0x08	Enables startup tracing
0x10	Enables tuning tracing
0x20	Enables cache tracing

接下來我們透過設定_memory_management_tracing隱藏引數和DUMP_TRANSFER_OPS轉儲來實地瞭解一次完整的記憶體轉移，和不完整的記憶體轉移。以下演示的完整trace檔案可以從這裡下載、。

SQL> alter system set "_memory_management_tracing"=63;
System altered Operation make shared pool grow and buffer cache shrink!!!..............

以下為一個完整granule轉移的過程，包括了對default buffer pool的resize操作:

AUTO SGA: Request 0xdc9c2628 after pre-processing, ret=0

/* 這裡的0xdc9c2628是前臺程式的addr */

AUTO SGA: IMMEDIATE, FG request 0xdc9c2628

/* 這裡可以看到前臺程式的Immediate立即申請  */

AUTO SGA: Receiver of memory is shared pool, size=16, state=3, flg=0

/* 此次申請的收益人是shared pool，共享池，其大小為16個granule，處於grow狀態 */

AUTO SGA: Donor of memory is DEFAULT buffer cache, size=106, state=4, flg=0

/* 此處的捐獻者是Default buffer cache，快取記憶體，其大小為106個granule，處於shrink狀態 */

AUTO SGA: Memory requested=3896, remaining=3896

/* 這裡immeidate request所要求的空間是3896 bytes */

AUTO SGA: Memory received=0, minreq=3896, gransz=16777216

/* 這裡沒有free的granule，所以received為0，gransz為granule的大小 */

AUTO SGA: Request 0xdc9c2628 status is INACTIVE

/* 因為沒有空的記憶體顆粒，先將申請置於inactive狀態 */

AUTO SGA: Init bef rsz for request 0xdc9c2628

/* 為相關申請初始化before-process大小調整  */

AUTO SGA: Set rq dc9c2628 status to PENDING

/* 將request置於pending狀態 */

AUTO SGA: 0xca000000 rem=3896, rcvd=16777216, 105, 16777216, 17

/* 返回起始地址為0xca000000的16M大小granule */

AUTO SGA: Returning 4 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 4, 1, a
AUTO SGA: Resize done for pool DEFAULT, 8192

/* 完成對default pool的resize */

AUTO SGA: Init aft rsz for request 0xdc9c2628
AUTO SGA: Request 0xdc9c2628 after processing
AUTO SGA: IMMEDIATE, FG request 0x7fff917964a0
AUTO SGA: Receiver of memory is shared pool, size=17, state=0, flg=0
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=105, state=0, flg=0
AUTO SGA: Memory requested=3896, remaining=0
AUTO SGA: Memory received=16777216, minreq=3896, gransz=16777216
AUTO SGA: Request 0x7fff917964a0 status is COMPLETE

/* shared pool成功收到16M的granule */

AUTO SGA: activated granule 0xca000000 of shared pool

以下為一個partial granule不完全記憶體顆粒的轉移過程trace:

AUTO SGA: Request 0xdc9c2628 after pre-processing, ret=0
AUTO SGA: IMMEDIATE, FG request 0xdc9c2628

AUTO SGA: Receiver of memory is shared pool, size=82, state=3, flg=1
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=36, state=4, flg=1

/* 此處的受益者仍為shared pool，而捐獻者是default buffer cache */

AUTO SGA: Memory requested=4120, remaining=4120
AUTO SGA: Memory received=0, minreq=4120, gransz=16777216
AUTO SGA: Request 0xdc9c2628 status is INACTIVE
AUTO SGA: Init bef rsz for request 0xdc9c2628
AUTO SGA: Set rq dc9c2628 status to PENDING
AUTO SGA: Moving granule 0x93000000 of DEFAULT buffer cache to activate list
AUTO SGA: Moving 1 granule 0x8c000000 from inuse to quiesce list of DEFAULT buffer cache for an immediate req

/* 以上將buffer cache中起始地址為0x8c000000的granule從使用中列表inuse list，
    移動到靜默列表quiesce list中 */

AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: activated granule 0x93000000 of DEFAULT buffer cache
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000

/ * 等待dbwr寫出0x8c000000 granule中所有的dirty buffer */

AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
......................................... AUTO SGA: Rcv shared pool consuming 8192 from 0x8c000000 in granule 0x8c000000; owner is DEFAULT buffer cache AUTO SGA: Rcv shared pool consuming 90112 from 0x8c002000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 24576 from 0x8c01a000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 65536 from 0x8c022000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 131072 from 0x8c034000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 286720 from 0x8c056000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 98304 from 0x8c09e000 in granule 0x8c000000; owner is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 106496 from 0x8c0b8000 in granule 0x8c000000; owner is DEFAULT buffer cache
.....................

/* 以上shared pool開始消費0x8c000000 granule中的chunk，
    但此granule的owner暫時仍為default buffer cache */

AUTO SGA: Imm xfer 0x8c000000 from quiesce list of DEFAULT buffer cache to partial inuse list of shared pool

/* 以上將0x8c000000 granule從default buffer cache的靜默列表轉移到shared pool的不完整inuse list */

AUTO SGA: Returning 4 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 4, 1, 20a
AUTO SGA: Init aft rsz for request 0xdc9c2628
AUTO SGA: Request 0xdc9c2628 after processing
AUTO SGA: IMMEDIATE, FG request 0x7fffe9bcd0e0
AUTO SGA: Receiver of memory is shared pool, size=83, state=0, flg=1
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=35, state=0, flg=1
AUTO SGA: Memory requested=4120, remaining=0
AUTO SGA: Memory received=14934016, minreq=4120, gransz=16777216
AUTO SGA: Request 0x7fffe9bcd0e0 status is COMPLETE

/* 以上一個partial transfer完成 */

對應於以上partial transfer我們可以透過DUMP_TRANSFER_OPS來了解該0x8c000000 partial granule的實際使用情況，如:

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug dump DUMP_TRANSFER_OPS 1;
Statement processed.

SQL> oradebug tracefile_name;
/s01/admin/G10R2/udump/g10r2_ora_21482.trc

=======================trace content==============================

GRANULE SIZE is 16777216
COMPONENT NAME : shared pool
Number of granules in partially inuse list (listid 4) is 23
Granule addr is 0x8c000000 Granule owner is DEFAULT buffer cache

/* 該0x8c000000 granule在shared pool的partially inuse list，
    但這裡它的owner仍為default buffer cache */

Granule 0x8c000000 dump from owner perspective
gptr = 0x8c000000, num buf hdrs = 1989, num buffers = 156, ghdr = 0x8cffe000

/ * 可以看到該granule的granule header地址位於0x8cffe000，
     其中共有156個buffer block,1989個buffer header */

/* 以下granule中具體的內容，實際既包含了buffer cache也有shared pool chunk */

BH:0x8cf76018 BA:(nil) st:11 flg:20000
BH:0x8cf76128 BA:(nil) st:11 flg:20000
BH:0x8cf76238 BA:(nil) st:11 flg:20000
BH:0x8cf76348 BA:(nil) st:11 flg:20000
BH:0x8cf76458 BA:(nil) st:11 flg:20000
BH:0x8cf76568 BA:(nil) st:11 flg:20000
BH:0x8cf76678 BA:(nil) st:11 flg:20000
BH:0x8cf76788 BA:(nil) st:11 flg:20000
BH:0x8cf76898 BA:(nil) st:11 flg:20000
BH:0x8cf769a8 BA:(nil) st:11 flg:20000
BH:0x8cf76ab8 BA:(nil) st:11 flg:20000
BH:0x8cf76bc8 BA:(nil) st:11 flg:20000
BH:0x8cf76cd8 BA:0x8c018000 st:1 flg:622202
...............

Address 0x8cf30000 to 0x8cf74000 not in cache
Address 0x8cf74000 to 0x8d000000 in cache
Granule 0x8c000000 dump from receivers perspective
Dumping layout

Address 0x8c000000 to 0x8c018000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c018000 to 0x8c01a000 not in this pool
Address 0x8c01a000 to 0x8c020000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c020000 to 0x8c022000 not in this pool
Address 0x8c022000 to 0x8c032000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c032000 to 0x8c034000 not in this pool
Address 0x8c034000 to 0x8c054000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c054000 to 0x8c056000 not in this pool
Address 0x8c056000 to 0x8c09c000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c09c000 to 0x8c09e000 not in this pool
Address 0x8c09e000 to 0x8c0b6000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c0b6000 to 0x8c0b8000 not in this pool
Address 0x8c0b8000 to 0x8c0d2000 in sga heap(1,3) (idx=1, dur=4)

以上可以看到該granule真的是一個shared granule共享記憶體顆粒，其中不僅包含了部分buffer block，還包含了1號shared subpool共享池子池的durtaion為4的chunk，duration=4即execution duration;這類duration的chunk一般有著較短的生命週期，當其extent被置於quiesce list靜默列表時將很有可能變得足夠free。execution duration是共享池中唯一能可靠轉移的，因此唯有該類duration所在的extent(一般來說一個extent佔用一個granule)可以用來收縮。

以下我們列出一些有助於診斷ASMM問題的動態效能檢視，僅供參考:

V$SGAINFO
Displays summary information about the system global area (SGA).

V$SGA
Displays size information about the SGA, including the sizes of different SGA components, the granule size, and free memory.

V$SGASTAT
Displays detailed information about the SGA.

V$SGA_DYNAMIC_COMPONENTS
Displays information about the dynamic SGA components. This view summarizes information based on all completed SGA resize operations since instance startup.

V$SGA_DYNAMIC_FREE_MEMORY
Displays information about the amount of SGA memory available for future dynamic SGA resize operations.

V$SGA_RESIZE_OPS
Displays information about the last 400 completed SGA resize operations.

V$SGA_CURRENT_RESIZE_OPS
Displays information about SGA resize operations that are currently in progress. A resize operation is an enlargement or reduction of a dynamic SGA component.

V$SGA_TARGET_ADVICE
Displays information that helps you tune SGA_TARGET.

近期內會寫一篇介紹shared pool duration的文章，作為對這篇的補充。

---

---

SGA and PGA Management in 11g's Automatic Memory Management (AMM) (文件 ID 1392549.1)

"ipcs -m" Displays Incorrect Shared Memory Segment Sizes in Oracle 11G (文件 ID 731658.1)

---

---

In this Document

Symptoms

Cause

Solution

---

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.1.0.6 and later
Generic Linux

SYMPTOMS

The "ipcs -m" indicates allocated shared memory segments. In Oracle 11G all of the segments are between 808 and 4096 bytes, where as the instance has a 4GB SGA .Output of ipcs -m:

------ Shared Memory Segments -------- 
key shmid owner perms bytes nattch status 
0x00000000 65536 oracle 660 4096 0 
0xd649823c 98305 oracle 660 4096 0 
0x7905c133 131074 oracle 666 808 0 
0xc90e3f3c 196611 oracle 660 4096 0

CAUSE

When Oracle on Linux is configured to use Auto Memory Management (AMM), it utilizes the POSIX implementation of SHM on Linux. The small shared memory segment just contains some metadata for new processes to find the /dev/shm/* files used for the SGA. POSIX shared memory is not reflected by the ipcs utility. 

When AMM is disabled, Oracle falls back to using the System V SHM implementation as seen in earlier versions of Oracle for Linux.

SOLUTION

1. Use PMAP command. PMAP output shows that Oracle 11g uses /dev/shm for shared memory implementation instead. There are many 4MB files mapped to Oracle server processes address space. The total size shows the MEMORY_TARGET size. If MEMORY_TARGET is set to 0 then the shared memory segments will be displayed by the ipcs command.

 

E.g.:

$pmap 6124 

.. .
20001000 4092K rw-s- /dev/shm/ora_ora11g_19693577_0 
20400000 4096K rw-s- /dev/shm/ora_ora11g_19693577_1 
20800000 4096K rw-s- /dev/shm/ora_ora11g_19693577_2 
20c00000 4096K rw-s- /dev/shm/ora_ora11g_19693577_3 
21000000 4096K rw-s- /dev/shm/ora_ora11g_19693577_4 
...

 

2. /dev/shm also shows the shared memory segments in use for this instance.

 

$ ls -l /dev/shm/ |grep ora11g

-rw-r----- 1 oracle oinstall 4194304 Jul 31 10:40 ora_ora11g_19693577_0 
-rw-r----- 1 oracle oinstall 4194304 Jul 31 10:40 ora_ora11g_19693577_1 
-rw-r----- 1 oracle oinstall 4194304 Jul 31 10:40 ora_ora11g_19693577_177 
-rw-r----- 1 oracle oinstall 4194304 Jul 31 10:40 ora_ora11g_19693577_178 
-rw-r----- 1 oracle oinstall 4194304 Jul 31 10:40 ora_ora11g_19693577_179