CRSD自動重啟和產生CORE DUMP的故障處理

一套執行在AIX 5.3，HACMP 5.4上的雙節點RAC資料庫,CRS和資料庫的版本均為10.2.0.3；CRSD.BIN自動重啟，併產生很多的CORE DUMP。
進入$ORA_CRS_HOME/log//crsd目錄下，檢視crsd日誌檔案，可以看到CRSD在重啟時的日誌如下：

2009-03-13 13:59:49.692: [ OCRRAW][11400]proprdc: backend_ctx->prop_sctx=[0x1017ed10]
2009-03-13 13:59:49.692: [ OCRRAW][11400]proprdc: backend_ctx->prop_sltsmx=[0x0]
2009-03-13 13:59:49.692: [ OCRRAW][11400]proprdc: backend_ctx->prop_sclsctx=[0x10365848]
2009-03-13 13:59:49.692: [ OCRRAW][11400]proprdc: backend_ctx->prop_ctx_ocrctx=[0x10362940]
2009-03-13 13:59:49.692: [ OCRSRV][11400]th_snap:8:failed to take backup prop_retval=26
2009-03-13 13:59:51.480: [ CRSOCR][11240]32OCR api procr_open_key failed for key CRS.CUR.ora!wydb3!ons. OCR error code = 3 OCR error msg:
2009-03-13 13:59:51.480: [ CRSOCR][11240][PANIC]32Failed to open key: CRS.CUR.ora!wydb3!ons(File: caaocr.cpp, line: 319)

2009-03-13 14:00:06.282: [ default][1][ENTER]32
Oracle Database 10g CRS Release 10.2.0.3.0 Production Copyright 1996, 2004, Oracle. All rights reserved
2009-03-13 14:00:06.282: [ default][1]32CRS Daemon Starting
2009-03-13 14:00:06.282: [ CRSMAIN][1]32Checking the OCR device
2009-03-13 14:00:06.285: [ CRSMAIN][1]32Connecting to the CSS Daemon
2009-03-13 14:00:06.705: [ CRSD][1]32Daemon Version: 10.2.0.3.0 Active Version: 10.2.0.3.0
2009-03-13 14:00:06.705: [ CRSD][1]32Active Version and Software Version are same
2009-03-13 14:00:06.705: [ CRSMAIN][1]32Initializing OCR
2009-03-13 14:00:06.713: [ OCRRAW][1]proprioo: for disk 0 (/dev/rwbsdb_ocr1_128m), id match (1), my id set (550012785,1028247821) total id sets (1), 1st set (550012785,1028247821), 2nd set (0,0) my votes (2), total votes (2)
2009-03-13 14:00:06.809: [ CRSD][1]32ENV Logging level for Module: allcomp 0

列出目錄中的所有檔案可以看到，最近幾天都有core dump檔案。仔細檢視可以發現，每個core dump檔案的間隔週期為固定的8.5小時。這是一個週期性的現象。

仔細檢視上面的日誌，”紅色字型“的部分，引起了我的注意。這個錯誤，表明是在做某個東西的備份的時候報了錯。應該是在備份OCR。core dump產生的週期和crsd自動重啟的週期，都是固定的，這跟CRS會自動週期性地備份OCR比較吻合。

在METALINK上一番搜尋，找到了BUG 5893629與這個故障現象比較符合。METALINK對這個BUG的描述稱，CRS在備份OCR時，會在$ORA_CRS_HOME/cdata/目錄下生成一個temp.ocr，如果這個檔案之前已經存在，會試圖刪除這個檔案，而如果這個檔案由於不是root使用者所有，則就會導致crsd crash。這個BUG要在10.2.0.4才會修復。

根據對這個BUG的描述，進入到$ORA_CRS_HOME/cdata目錄，這個目錄下面有兩個目錄，一個是“crs”，另一個是”localhost“，一般來說，crs就是CRS叢集的名稱。進入這個目錄，沒有發現任何檔案，看許可權，root使用者也可以建立檔案。

問題在哪裡呢？換一個角度思考，既然BUG描述中稱不能刪除舊的temp.ocr檔案會導致crsd crash，那要是沒有$ORA_CRS_HOME/cdata/這個目錄會怎麼樣，一樣不能建立temp.ocr這個檔案，那這種情況也會不會crash？這裡$ORA_CRS_HOME/cdata目錄下只有crs和localhost目錄，如果按這種推理，如果cluster_name不是通常的”crs“呢？

不過當時有其他事情，離開了現場，不能得到CRS叢集名字。不過幸運的是，我在日誌檔案中，在上面貼出的那段資訊的前面，經過了一大段一大段的無用的資訊之後，找到了下面的日誌：

2009-03-13 13:59:49.391: [ OCRRAW][11400]rbkp:1: could not create the temp backup file [/oracle/crs/cdata/wydb_crs/temp.ocr]
2009-03-13 13:59:49.391: [ OCRRAW][11400]proprseterror: Error in accessing physical storage [26] Marking context invalid.

這裡的日誌就更明顯了，就是不能建立”/oracle/crs/cdata/wydb_crs/temp.oc“這個檔案。而前面的推斷卻不幸言中，CRS叢集名字真的不是預設的”crs”，/oracle/crs/cdata這個目錄下也的確沒有wydb_crs這個目錄。

讓資料庫維護人員在/oracle/crs/cdata目錄中新建一個目錄wydb_crs，經過一段時間的觀察，故障不再出現，問題解決。

從這個故障中，我們得到一個教訓，CRS有時真的很傻，為什麼在備份時像這種不能建立檔案的錯誤，不是寫個日誌忽略過去而是直接將程式crash了，並且還產生了core dump？為什麼在安裝CRS時，安裝軟體不自動建好這個目錄，而只是按預設的”crs”名字建立目錄？看來安裝ORACLE軟體的時候，CRS叢集名字取預設值就行了。嚴重懷疑那個BUG是不是真的會解決這個問題（根據METALINK的描述，在備份時會隨機生成一個檔名，而不再是固定的temp.ocr，但如果像這個案例中的故障，仍然會得不到解決。）

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