memory_target設定不當導致資料庫無法啟動解決

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的變更。才發現這個很潛在的問題。

在CentOS 6.4下安裝Oracle 11gR2(x64)

Oracle 11gR2 在VMWare虛擬機器中安裝步驟

Debian 下 安裝 Oracle 11g XE R2