環境：

Redhat LINUX 6U5 64位+ORACLE 12.1.2.0 64位

描述：

安裝了臺測試庫12.1.2.0 ， 記憶體256GB，設定資料庫memory_max_target、memory_target、sga_max_size 引數是 236GB，在使用inmemory功能時設定 "alter system set inmemory_size=200G scope=spfile"  後，重啟庫 報“ORA-04031: unable to allocate 4984 bytes of shared memory ("shared pool","unknown object","sga heap(2,0)","I/O stat latches")”  

分析:

從報錯資訊來看是沒有記憶體可以分析給資料庫使用，但是已經分配了236G給資料庫使用，為什麼還報沒有記憶體分配呢？很是疑問

1), 通過錯誤資訊在metalink上找到如下相關問題：

連結如下：

https://support.oracle.com/epmos/faces/CommunityDisplay?resultUrl=https%3A%2F%2Fcommunity.oracle.com%2Fthread%2F3601868&_afrLoop=7034941515679&resultTitle=12c+and+inmemory_size+togheter+with+memory_target+gives+ORA-04031&commId=3601868&displayIndex=2&_afrWindowMode=0&_adf.ctrl-state=16pvs6tsxv_329

理解的大致意思是減少inmemroy_size的大小，inmemory_size 引數的大小是 memory_target大小的 的一半左右 ，執行“ alter system set inmemory_size=130G scope=spfile”  啟庫後一切正常。

2),但覺得既然記憶體這麼大就要發揮它的最大效率，經過ITPUB網友指點最終解決了這個問題，原來inmemory_size不屬於AMM管理，啟用AMM管理記憶體導致SGA和inmemory_size的大小超過伺服器的記憶體大小。

詳見：http://www.itpub.net/thread-1931524-1-1.html 

解決方法:

1),啟用ASMM

alter system set memory_max_target=0 scope=spfile;
alter system set memory_target=0 scope=spfile;
alter system set sga_max_size=236G scope=spfile;
alter system set sga_target=236G scope=spfile;
alter system set inmemory_size=226G scope=spfile;

2),配置huge_page

a, 檢視記憶體大小

[[email protected] ~]$ free -t
                    total              used               free            shared    buffers     cached
Mem:     264633004  252983532   11649472          0      55148    1318184
-/+ buffers/cache:     251610200      13022804
Swap:     32767992          0               32767992
Total:      297400996  252983532   44417464

b,將檢視的記憶體總大小增加到limits.conf檔案中

[[email protected] ~]# cat /etc/security/limits.conf 
#在最後端增加兩行
oracle soft memlock  264633004
oracle hard memlock 264633004

c,執行在MOS 401749.1中下載的指令碼hugepages_settings.sh

注意：執行指令碼，注意這個過程中要求Oracle所有例項，包括資料庫和ASM都啟動、AMM關閉，以及SGA大小超過100M。

得出推薦結果

Press Enter to proceed...
 
Recommended setting: vm.nr_hugepages = 120836

d,將結果新增到sysctl.conf 結尾

[[email protected] ~]# tail -n 1  /etc/sysctl.conf

vm.nr_hugepages = 120836

e, 使用sysctl –p生效設定

f, 關閉資料庫，重啟伺服器

g, HugePage啟動檢驗, HugePages_Total 不等於HugePages_Free說明生效了

[[email protected] ~]# grep Huge /proc/meminfo

AnonHugePages:    145408 kB
HugePages_Total:   120836
HugePages_Free:        3
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:          2048 kB

總結：

導致這個問題的原因是使用了AMM，由於SGA和PGA自動分配，有可能自動分配不合理，比如：PGA或其它pool 分配過大，導致在啟庫時不能分配足夠多的記憶體空間給其它的pool，從而導致報4031錯誤，當然這是猜測並沒有論證，事實真相還有待高手揭密。

參考來自： http://blog.itpub.net/17203031/viewspace-774843/