Oracle備份時出現AIX系統的3D32B80D錯誤

環境：

資料庫: AIX5.3下的64位Oracle 10.2.0.1.0

TSM5.4：Windows2003

帶庫： IBM3100

問題描述：

 

1、  aix系統出現3D32B80D錯誤。如下：

JTXXDBS01:> errpt |more

IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION

3D32B80D   0203175210 P S topsvcs        NIM thread blocked

3D32B80D   0203175110 P S topsvcs        NIM thread blocked

3D32B80D   0203175110 P S topsvcs        NIM thread blocked

3D32B80D   0203175110 P S topsvcs        NIM thread blocked

3D32B80D   0203174810 P S topsvcs        NIM thread blocked

3D32B80D   0203174810 P S topsvcs        NIM thread blocked

 

 

JTXXDBS01:> errpt -aj 3D32B80D|more

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

LABEL:          TS_NIM_ERROR_STUCK_

IDENTIFIER:     3D32B80D

 

Date/Time:       Wed Feb  3 17:52:06 BEIST 2010

Sequence Number: 114902

Machine Id:      0005807BD600

Node Id:         JTXXDBS01

Class:           S

Type:            PERM

Resource Name:   topsvcs

 

Description

NIM thread blocked

 

Probable Causes

A thread in a Topology Services Network Interface Module (NIM) process

was blocked

Topology Services NIM process cannot get timely access to CPU

User Causes

Excessive memory consumption is causing high memory contention

Excessive disk I/O is causing high memory contention

 

        Recommended Actions

        Examine I/O and memory activity on the system

        Reduce load on the system

        Tune virtual memory parameters

        Call IBM Service if problem persists

 

Failure Causes

Excessive virtual memory activity prevents NIM from making progress

Excessive disk I/O traffic is interfering with paging I/O

 

        Recommended Actions

        Examine I/O and memory activity on the system

        Reduce load on the system

        Tune virtual memory parameters

        Call IBM Service if problem persists

 

 

3D32B80D錯誤主要是由於整個系統的負載很高，從而導致HA的心跳不能正常通訊造成的。

 

 

2、  在備份時，磁碟IO的頻繁主要體現在Hdisk0和Hdisk1

從圖中看出來比較忙的磁碟IO為hdisk1和hdisk0，記憶體比較忙的為nocomp（非計算記憶體）。

 

 

用lsps –s 看，

再看下圖：

主要比較忙的hdisk1和hdisk0 物理卷AIX的交換空間。但交換空間的使用率卻為不足30% 。

 

這裡主要說明了AIX的paging space足夠，但paging space還是交換很頻繁。注意到記憶體中的nocomp（非計算記憶體）長達76%。 這裡的記憶體長期不釋放，導致comp（計算記憶體）不足，從而頻繁的使用paging space

 

 

3、  AIX的NMON監控圖形

 

備份時的記憶體嚴重不足。

 

AIX的paging space頻繁交換。

 

 

具體原因：

這是由於每天22:00 資料庫進行rman備份，磁碟的IO很頻繁，AIX系統的IO分別磁碟的輸入、輸出和Paging Space（交換空間）的輸入、輸出，這裡備份主要體現在paging space的頻繁操作。其中非計算記憶體達到76%，長期不釋放記憶體。根本原因是非計算記憶體長期不釋放，AIX記憶體缺少，導致了Paging Space交換頻繁。從而導致系統的負載比較高。

 

限制AIX的nocomp（非計算）記憶體最大值。

把AIX的

minperm% = 20

maxclient% = 80

maxperm% = 80

 

調整更低。

 

解決步驟：

檢視原來的AIX的minperm%、maxclient% 、maxperm%的值。如下：

Root使用者檢視：

>vmo –a

 

minperm% = 20

maxclient% = 80

maxperm% = 80

 

把minperm%設定成10，maxclient%設定成20，maxperm%設定成20

 

用root命令列執行：

1、

vmo -o minperm%=10

2、

vmo -o maxclient%=20

3、

vmo -o maxperm%=20

 

 

改變maxperm%為20，再次備份時，不再發生3D32B80D錯誤。

 

 

 

備註：

 

minperm 和 maxperm 引數的值

作業系統透過把在曾經讀寫的記憶體頁留在實記憶體一滿足不同要求。如果檔案頁面在它們的頁幀被重新分配前被請求，那就節省了輸入輸出操作。該檔案頁面可以來自本地的或遠端的（如 NFS）系統。

頁幀使用的檔案相對用於計算的（工作或程式文字）段的檔案的比例是鬆散地受控於 minperm 和 maxperm 的值的：

如果 RAM 中檔案頁面所佔的百分比高於 maxperm，頁面替換的竊取只用於檔案頁。 

如果 RAM 中檔案頁面所佔的百分比低於 minperm，頁面替換的竊取同時用於檔案頁和計算頁。 

如果 RAM 中檔案頁面所佔的百分比介於 minperm 和 maxperm之間，頁面替換隻竊取檔案頁，除非檔案頁的重調入數量大於計算頁數。

其中Noncomp在20％－80％之間，此時記憶體頁交換演算法通常只交換檔案快取頁，但如果檔案快取頁的交換率大於程式頁時，程式頁也同樣被交換。由於SGA屬於Comp頁，資料檔案快取屬於Noncomp頁，而在資料大量訪問時，檔案快取頁的交換率大於程式頁（SGA），因此大量的SGA頁面被交換；為避免大量SGA頁被交換，需要降低maxperm%值到35％以下，這樣就只有檔案快取頁面被交換，減少了SGA交換的次數。

5)結論

調整maxperm%和minperm%的值，可以將MINPERM和MAXPERM分別設為5%和20%甚至更小，從而使記憶體更多地被用於Oracle的SGA而不是系統的檔案快取。

具體命令：# vmo -o minperm%=5 -o maxperm%=20 

注意：加-p引數可以永久更改系統的配置，否則只改動當前的系統配置，重新啟動後則失效。