客户有个环境是10g的RAC，由于一次偶尔的需求，需要将一个11g的数据库临时在上面启动，当我们mount了11g的软件卷和datafile 卷之后，11g的数据库能正常启动，但是当11g的数据库shutdown时，导致了10g的crsd进程重启。
在10g的crsd的log中，可以看到：
|
1 2 3 4 5 |
2011-10-16 11:35:35.827: [ OCRAPI][267]procr_open_key: Invalid keyname [CRS.CUR.]. Component too big. 2011-10-16 11:35:35.827: [ CRSOCR][267] OCR api procr_open_key failed for key CRS.CUR.. OCR error code = 8 OCR error msg: PROC-8: Cannot perform cluster registry operation because one of the parameters is invalid. 2011-10-16 11:35:35.828: [ CRSOCR][267][PANIC] Failed to open key: CRS.CUR.(File: caaocr.cpp, line: 358) 2011-10-16 11:35:35.828: [ CRSD][267][PANIC] CRSD Exiting. OCR Failed 2011-10-16 11:35:35.828: [ CRSD][267] Done. |
问题不是很大，2分钟后，crsd自动重启，恢复正常。期间数据库对外的服务不受影响。
原因：
|
1 2 3 |
This is caused by Bug:13263017 - 11GR2 DATABASE SHUTDOWN CAUSING THE 10G CRS TO PANIC From 11.2 onwards, database is designed to talk to local CRSD to notify its state changes. This change is incompatible with 10g CRSD causing the 10g CRSD to panic. |
解决方法：
|
1 2 3 4 |
The bug has not been fixed yet, but the workaround is available: Set "_notify_crs=FALSE" in pfile or spfile for 11gR2 database and restart the instance. This should avoid pre-11gR2 CRSD panic. |
参考文档：11gR2 Single Instance Database Shutdown Cause Pre-11gR2 CRSD Panic (Doc ID 1491095.1)