原題：Oracle數據庫重啟(內存參數numperm_global相關)

故障描述

Oracle數據庫發生重啟。

系統環境

AIX 6100-07-05-1228

Oracle 11g

故障分析

首先請DBA團隊分析oracle數據庫的日志，經DBA分析得知數據庫有兩個控制數據庫資源的進程在20:06時hang了大概幾十秒，oracle出于數據保護的機制便重啟了數據庫。

然后從操作系統層面分析在20:06時操作系統的資源使用情況。

從nmon的數據中可以得知CPU在全天使用率都很低，都低于30%，可見CPU使用情況正常。

分析內存的數據可知全天內存使用率并不高，基本穩定在80%以內，在20:06之前的一段時間，有計算內存增長情況，這和當時處理的業務相關。（注：nmon采樣點是6分鐘采一個點并取平均值）

再分析內存的換頁，從圖可以見看到，在20:06時產生了大量的換頁，當瞬間產生大量換頁時說明有應用程序在短時間內申請了大量的內存，同時內存不足并啟動lrud進程進行換頁，換頁帶來的問題就是會影響系統的性能。

由于nmon采樣的顆粒度比較粗，而oswatcher監控的采樣間隔是20秒，因此分析oswatcher的數據，主要分析vmstat的輸出，從vmstat的輸出可以看到當時free還有3103118個內存頁面(每個頁面4KB)，即12GB內存，而此時有746個pi和16989個po。因此可見在內存有剩余的情況下產生了換頁。

下面分析在內存有剩余的情況下產生換頁的原因，AIX的內存管理機制是把內存分為多個內存池(memory pool)，這個系統有90GB內存，120個邏輯CPU。AIX會按8個邏輯CPU分一個內存池的劃分機制，把內池劃分為多個內存池。即這個系統它的內存池有15個：

為了優化內存的管理，在AIX 6.1時引入了numperm_global參數，這個參數設置為0時代表在換頁時以內存池為單位去判斷是否把計算內存換出，這個參數設置為1時代表在換頁時以全局為單位去判讀是否把計算內存換出。

在AIX特定版本下（6100-06-sp7 / 6100-06-sp8 / 6100-06-sp9 / 6100-07-sp4 / 6100-07-sp5）numperm_global這個參數設置為1會觸發操作系統的bug，即當系統的PIN住的64KB頁面達到maxpin%(80%)時，換頁程序在換取4KB頁面時，即使有文件系統緩存剩余(大于minperm，缺省為物理內存的3%)的情況下，也只換取計算內存頁面，而計算內存頁面被換出會對性能有很大的影響并有可能導致應用程序緩慢或者數據庫掛起。

一般來說，大量PIN 64KB內存頁面應用程序并不多，但是Oracle數據庫出于提高性能的原因，一般都會將SGA和PGA PIN在內存里。如果SGA和PGA加起來接近maxpin%，那么在numperm_global設置為1的時候就有很大的可能觸發上面提到的bug，導致early paging問題。

經檢查發現numperm_global這個參數設置的為1，因此在oracle有大量64KB頁面申請時，64KB頁面達到maxpin%(80%)，這時即使有12GB剩余的內存，此時也只會把計算內存換出去，這樣導致系統在20:06左右操作系統出現性能問題。

故障建議

基于上面分析，建議如下：

方案1：作為規避方案，把numperm_global修改為0，并重啟生效。

方案2：為了徹底解決early paging的問題，IBM在AIX 6.1 TL09 SP01版本中發布了補丁IV44998。在此種情況下，建議升級操作系統并啟用numperm_global參數來達到優化內存的分配機制的目的。

方案3：將Oracle SGA使用的內存指定為16MB頁面，從而避免大量的64KB 頁面被PIN。

方案4：將Oracle的LOCK_SGA參數改為FALSE，使其不PIN內存頁面。