memory_target設定不當導致資料庫無法啟動的問題

今天在做一個問題排查的時候碰到了另外一個有些“奇怪的”問題。
我們在測試庫中已經禁用了SGA自動儲存管理,結果在spfile檔案裡丟掉了shared_pool_size的配置
測試環境的引數類似下面的樣子
sga_max_size                         big integer 12000M
sga_target                             big integer 0
shared_pool_size                     big integer 0
db_cache_size                        big integer 6G
pga_aggregate_target                 big integer 3147483648

這種配置應該是有問題的,把shared_pool_size的部分給丟掉了。結果檢視當前測試庫的情況，發現shared_pool多多少少的給了2G。

COMPONENT                       CURRENT_M      MIN_M      MAX_M SPECCIFIED_M LAST_OPER LAST_OPER_TYP  GRANULE_M
------------------------------ ---------- ---------- ---------- ------------ --------- ------------- ----------
shared pool                          2000        992       2000         2000 MANUAL    GROW                  16
large pool                            304        304        512          304 DEFERRED  SHRINK                16
java pool                             512        512        512          304           STATIC                16
streams pool                            0          0          0            0           STATIC                16
DEFAULT buffer cache                 6224       6144       6352         6144 MANUAL    SHRINK                16
KEEP buffer cache                       0          0          0            0           STATIC                16
RECYCLE buffer cache                    0          0          0            0           STATIC                16
DEFAULT 2K buffer cache                 0          0          0            0           STATIC                16
DEFAULT 4K buffer cache                 0          0          0            0           STATIC                16
DEFAULT 8K buffer cache                 0          0          0            0           STATIC                16
DEFAULT 16K buffer cache                0          0          0            0           STATIC                16
DEFAULT 32K buffer cache                0          0          0            0           STATIC                16
Shared IO Pool                          0          0          0            0           STATIC                16
如果問題到這裡，可能就告一段落了。
但是我又認真看了一下，發現還是有問題。SGA有12G左右，分給shared_pool 2G,buffer_cache 6G，加上large_pool,java_pool的還不到9G，剩下的部分到哪去了?

從總體的sga的概覽來看
SQL> show sga
Total System Global Area 1.1742E+10 bytes
Fixed Size                  2251264 bytes
Variable Size            5200938496 bytes  --這個部分還是有很大的差別。按照目前的shared_pool+large_pool+java_pool+stream_pool<3G,剩下的2G可能就是最後的可能，沒有分配的記憶體空間。
Database Buffers         6526337024 bytes  
Redo Buffers               12193792 bytes

帶著這種疑問來查問題，可能你看到很多細節都是潛在的問題。
首先來看程式的情況。結果就發現按照常理程式的owner應該顯示是使用者名稱，但是現在卻是程式號。
xxxxxx    6545 25419  0 12:44 pts/7    00:00:00 grep smon
3068     21040     1  0 Oct22 ?        00:01:21 ora_smon_TESTCUS1
最後確認了下，原來如果使用者名稱超出8位的時候就會顯示為程式號,不是問題。

最後在spfile中先寫入shared_pool_size=4G,然後重啟資料庫的時候，就報錯了。
SQL> startup
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 13920M
SQL> 

從開始查問題的時候就沒有注意到這個引數，memory_target是在11g引入的。算是sga自動儲存管理的加強版本，能夠自動管理sga和pga。
如果大體瞭解了memory_target和報錯的部分，可能一下子就明朗了。
因為當前的Memory_target的值就是12G和sga_max_size是一致的。
這個時候memory_target是12G，而同時pga是3G,那麼分配給sga的部分就只有不到9G,這樣的情況就相當於設定了sga_max_size=9G

這個時候重新分析下報錯資訊。我們把shared_pool從2G調整到了4G。這樣的話memory_target的大小按照配置應該需要
shared_pool_size(4G）+db_cache(6G)+stream pool(0)+large_pool(300M）+java_pool(300M)+pga(3G)=13600M左右，和報錯的部分基本符合。所以到此為止就可以判定是memory_target的設定不當導致了這個問題。
memory_target的設定還是需要重啟資料庫例項的。重啟後檢視就沒有問題了。
看來很多問題都在一些細節上注意，這個memory_target從一開始就沒有注意到，根據客戶dba的反饋，他們是直接使用dbca來建的庫，可能就是這個時候引入了這個新特性，然後在後期做了buffer size的變更。才發現這個很潛在的問題。