老熊的三分地-Oracle及数据恢复

一套运行在AIX 5.3，HACMP 5.4上的双节点RAC数据库,CRS和数据库的版本均为10.2.0.3；CRSD.BIN自动重启，并产生很多的CORE DUMP。
进入$ORA_CRS_HOME/log/<nodename>/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/<cluster_name>目录下生成一个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/<cluster_name>这个目录会怎么样，一样不能建立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，但如果像这个案例中的故障，仍然会得不到解决。）