健康檢查彙總

健康巡檢實戰

一 RAC環境上的健康巡檢需要的事項和解決方法

1 檢查Vip-Vip不是正常relocate
適用環境： Only 10gR2 10.2.0.5 ~11gR1
檢查方法：
os>cat $ORA_CRS_HOME/bin/racgvip |grep "PING_TIMEOUT="|awk -F"-w " '{print $2}'|awk '{print $1}'

[Note]
"CRS_HOME/log/node02" 下的VIP trace file中出現以下message，意味著由於VIP ping在1秒之內沒有返回應答資訊而發生錯誤。

2011-02-18 15:3OK:39.48NR: [ RACG][1] [4587556][1][ora.node02.vip]: Fri Feb 18 15:3OK:37 GMT+08:00 2011 [ 8257768 ] About to execute command: /usr/sbin/ping -S 192.168.220.36 -c 1 -w 1 192.168.220.33
Fri Feb 18 15:3OK:39 GMT+08:00 2011 [ 8257768 ] IsIfAlive: RX packets checked if=en1 failed

檢查結果和處理方法：
[症狀] VIP檢測超時時間（timeout）設成1秒
[問題] 由於系統存在負荷導致無法在指定的timeout時間內檢測到狀態，VIP會被relocate
[改進方案] 修改VIP檢查指令碼中的timeout時間，1秒改為3秒
具體步驟 :
1. 根本的問題是需要提高網路效能,
2, 在racgvip檔案中把VIP ping timeout的值從1秒改為3秒，作為vip在1秒之內沒有得到響應而relocate的變通方案

# $GRID_HOME/bin/racgvip 確認並修改
# timeout of ping in number of loops (1 sec)
PINO_TIMEOUT=" -c 1 -w 1"
改成==>
# timeout of ping in number of loops (3 sec)
PINO_TIMEOUT=" -c 1 -w 3"
srvctl start nodeapps -n <hostname>

2 確認Default OS TimeZone和 oracle user 環境變數TZ是否一致
檢查方法：env | grep TZ
Oracle user(包括CRS)和 root user的 TZ環境變數或者OS default timezone一致
檢查結果和處理方法：
[症狀] OS Default Timezone 不一致
[問題] DB啟動的時候參照的Timezone和OS User環境變數不一致，導致系統日誌等內容中的Timezone各不同
[改進方案] 統一OS Default Timezone(/etc/default/tz)

3 CRS 版本和DB 版本要一致
檢查方法：
crsctl query crs activeversion
crsctl query crs softwareversion

檢查結果和處理方法：
"[症狀] CRS版本低於DB版本
[問題] CRS版本應高於或者等於DB版本
[改進方案] 升級CRS版本"

4內網連線採用switch連線
檢查結果和處理方法：
"[症狀] CRS interconnect連線方式為直連，通過Cross Cable直連
[問題] Oracle 不支援interconnect的直連.
       特別是當網路卡發生故障不能用interconnect通訊時，CRS無法判斷哪個伺服器的網路卡有故障
[改進方案] 利用Switch實現internaconnect連線

[參考]
Oracle釋出公文表示，Interconnect Network只允許通過switch連線的方式，不支援直連"

5 設定巨幀jumbo frame
"[症狀] Interconnect Network的MTU設定1500
[問題] DB block範圍是8k, 16k, 32k等，這些資料塊在傳輸時按照MTU的大小切碎成若干塊再合併，這會影響效能
[改進方案] 如果使用專用交換機，則修改MTU為9000,以提高效能
具體步驟
interconnect network中設定jumbo frame (MTU 9000): default MTU 1500
(HP) netstat -in (其它) ifconfig -a

[參考] 如果網路支援jumbo frame，如果有必要提高internode traffic效能時可以考慮。已上線的系統不需要考慮，新系統可以考慮。"

6 設定CRS 自動啟動
[症狀]  CRS 開啟了自動啟動
[問題] 在OS的Cluster資源未正常啟動之前試圖先啟動CRS的話，會造成CRS的資源無法正常啟動
[改進方案] 關閉CRS Auto Start功能
HP/Solaris): cat /var/opt/oracle/scls_scr/$host/root/crsstart，確認內容是否為disable
IBM/Linux) : cat /etc/oracle/scls_scr/`hostname`/root/crsstart，確認內容是否為disable
如果是自動啟動 crsctl disable crs
(11gR2開始放在ohasdstr裡而不是crsstart)

7 檢查Voting Disk個數 - ASM除外
[症狀] Voting Disk沒有映象
[問題] 在Voting File損壞時服務不再繼續
[改進方案] Voting File做映象(如果條件允許，請放在不同的Volume)"
具體步驟
os>crsctl query css votedisk
設定 Voting Disk 個數為3個或5個

8 Vote Disk Member 是否分開放到不同F/S [ASM 除外]
"[症狀] 所有Voting File在相同的目錄下
[問題] 未分開存放的Voting File會增加同時損壞的可能性
[改進方案] 把Voting File分開不同目錄存放
          (如果可以，建議單獨建立F/S分開)"
具體步驟
os>crsctl query css votedisk

9檢查OCR disk個數
[症狀] OCR Disk未做映象
[問題] OCR Disk損壞時，不能提供服務
[改進方案] 映象OCR (如果可以，建議分開不同FS存放)"
具體步驟
os>ocrcheck

10 OCR Disk Member 是否分開不同F/S存放
[症狀] 所有OCR檔案在相同的目錄下
[問題] 未分開存放的OCR檔案會增加同時損壞的可能性
[改進方案] 把OCR檔案分開不同目錄存放，或者ASM Diskgroup
          (如果可以，建議單獨建立F/S分開)
具體步驟
os>ocrcheck

11 檢查 CRS網路心跳是否有丟失
[症狀] css misscount的值未設成建議值 200 以下
[問題] False Detection 或者需要很長的等待時間
[改進方案] 把css misscount值設成200以下的值。或者, Vendor Cluster的配置能在200秒以內檢測Interconnect故障.
default: 10g : CRS Only : 30 (linux： 60), Vendor Cluster : 600
         11g : CRS Only : 30, Vendor Cluster : 600
Steps To Change CSS Misscount, Reboottime and Disktimeout [ID 284752.1]
具體步驟
$ crsctl get css misscount

12 CRS diagwait 檢查故障時，日誌生成時間
[症狀] 使用CRS Logging 引數的預設值
[問題] CRS故障導致伺服器重啟時由於沒有日誌對分析工作帶來限制
[改進方案] 把diagwait值從0改為13
具體步驟
 從11gR2版本不需要設定[ID 559365.1]
(設定方法)
/ora_crs/bin/crsctl stop crs (一定要先關閉CRS之後操作)
/ora_crs/bin/crsctl get css diagwait  發生故障時，確保Trace生成的時間以便事後做分析
/ora_crs/bin/crsctl set css diagwait 13  -force  <- 設成13秒
確認
/ora_crs/bin/crsctl get css diagwait

** 不能線上修改,Not ROLLABLE

[參考] 對於2臺DB伺服器，需要同時關閉CRS之後修改
假如其他節點中有CRS相關程式，會發生OCRCorruption，所以不能以ROLL方式修改

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/750077/viewspace-2152617/，如需轉載，請註明出處，否則將追究法律責任。