节点2上crsd无法启动,数据库和监听无法自动启动,比如ocrconfig、ocrcheck以及srvct...

在Oracle 11g RAC环境中,CRSD进程的角色已发生变化,不再是集群启动的关键进程。OHASD进程成为新的核心,解决了OCR和VOT文件存储于ASM中的依赖问题。即使CRSD未启动,也可手动启动数据库。

CRSD进程在11g中的变化


在11.2中,CRSD进程不再是RAC中最关键的进程之一。

如果对10g RAC比较熟悉,应该清楚CRSD进程的重要性,Oracle在操作系统启动后,就是通过启动这个进程然后启动整个CLUSTER以及数据库的。

在11.2的RAC中,Oracle调整了ASM,使得OCR和VOT可以存储在ASM磁盘组中。ASM是CLUSTER所支持的一个组件,而CLUSTER启动所需的OCR和VOT却要放在ASM中,这其实要解决一个先有鸡还是先有蛋的问题。最终Oracle通过OHASD进程的方式解决了这个问题,而整个CLUSTER和ASM的架构也发生了重大的变化,OHASD进程取代了CRSD进程变成了RAC环境中最关键的进程。

而CRSD进程的重要性已经低到难以置信的地步,前两天在一个客户的11.2 RAC环境中发现,即使一个节点的CRSD进程没有启动,仍然可以手工启动数据库,且数据库可以正常访问。

导致的问题原因应该是节点2上访问OCR和VOT所在的磁盘组出现了错误,导致CRSD在多次尝试获取OCR中存储的信息失败后自动退出,从而使得节点2无法正常的启动。不过这时节点2上除了CRSD进程外,其他的CLUSTER进程已经完全启动,ASM实例也可以启动,这时可以手工启动节点2上的数据库。

  

节点2上ASM的alert有如下的错误信息:



  • 1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    Tue Jun 13 10:59:17 2017
    Reconfiguration started (old inc 10, new inc 12)
    List of instances:
     1 2 (myinst: 1) 
     Global Resource Directory frozen
     Communication channels reestablished
     Master broadcasted resource hash value bitmaps
     Non-local Process blocks cleaned out
    Tue Jun 13 10:59:17 2017
     LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
     Set master node info 
     Submitted all remote-enqueue requests
     Dwn-cvts replayed, VALBLKs dubious
     All grantable enqueues granted
     Submitted all GCS remote-cache requests
     Fix write in gcs resources
    Reconfiguration complete
    Tue Jun 13 11:03:01 2017
    IPC Send timeout detected. Sender: ospid 3173 [oracle@rac1 (PING)]
    Receiver: inst 2 binc 429480538 ospid 3190
    Tue Jun 13 12:12:38 2017
    NOTE: [ocrcheck.bin@rac1 (TNS V1-V3) 21461] opening OCR file
    Tue Jun 13 12:12:38 2017
    NOTE: [ocrcheck.bin@rac1 (TNS V1-V3) 21461] opening OCR file
    Tue Jun 13 13:38:34 2017
    MEMORY_TARGET defaulting to 1128267776.
    * instance_number obtained from CSS = 1, checking for the existence of node 0... 
    * node 0 does not exist. instance_number = 1 
    Starting ORACLE instance (normal)
    Tue Jun 13 13:42:20 2017
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 1.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 1.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 2.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 2.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 3.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 3.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 4.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 4.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 5.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 5.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 6.
    WARNING: Waited 15 secs for write IO to PST disk 0 in group 6.

       

          


 

应该就是这个原因导致ocrd进程报错并退出。数据库可以正常打开,节点2上数据库和监听无法自动启动,vip也存在问题。此外节点2上需要ocr信息的工具都无法使用,比如ocrconfig、ocrcheck以及srvctl等。

        目前还是没有解决,如有遇到的朋友可以 





         

                     














本文转自xiaocao1314051CTO博客,原文链接: http://blog.51cto.com/xiaocao13140/1935102,如需转载请自行联系原作者



<think>好的,用户遇到了Oracle 11g RAC节点2启动CRS时出现CRS-4544错误的问题。我需要先理解这个错误的具体含义可能的原因。根据引用中的信息,CRS-4535CRS-4000等错误可能与OCR(Oracle Cluster Registry)或存储访问有关,但CRS-4544的具体描述可能需要进一步分析。 首先,CRS-4544通常表示节点无法加入集群,可能的原因包括网络配置问题、节点间通信故障、OCR或表决磁盘的访问问题,或者Grid Infrastructure服务未正确启动。需要检查以下几个方面: 1. **网络连通性**:确保节点间的公网私网网络通信正常,检查/etc/hosts文件中的配置是否正确,确认VIP配置无误。 2. **OCR表决磁盘**:检查OCR表决磁盘的存储是否可访问,权限是否正确。例如,使用dd命令测试存储设备的读写是否正常。 3. **Clusterware服务状态**:确认节点1的CRS服务是否正常运行,节点2是否能够与节点1通信。 4. **日志分析**:查看Grid Infrastructure的日志文件,如alert.logcrsd.log,定位具体错误信息。 5. **重新配置或启动服务**:可能需要停止节点2CRS服务,清理缓存,然后重新加入集群。 另外,引用中提到OCR初始化问题可能导致类似错误,因此需要验证OCR的完整性。使用ocrcheck命令检查OCR的状态,以及使用crsctl命令检查集群配置是否正确。如果OCR损坏,可能需要从备份恢复。 用户提供的引用中,引用[4]提到无法访问物理存储导致CRS-4535,引用[5]提到磁盘分配问题导致安装错误,这可能与存储配置有关。因此,在解决CRS-4544时,需要确保存储设备正确配置且所有节点均可访问。 总结可能的解决步骤包括检查网络、存储权限、OCR状态,查看详细日志,必要时重新配置或启动CRS服务。需要一步步排除可能的原因,确保每个环节都正确无误。</think>### Oracle 11g RAC节点2启动CRS报错CRS-4544解决方案 #### 错误分析 CRS-4544错误表明节点2无法加入集群,通常与以下原因相关: 1. 节点间通信故障(网络配置异常或VIP未生效)[^1] 2. OCR/Voting Disk存储访问权限或路径问题[^4] 3. 集群配置文件损坏(OLR或OCR) 4. Grid Infrastructure服务未正确同步 --- #### 分步解决方案 1. **检查基础环境** ```bash # 验证网络连通性(节点间执行) ping <节点1私有IP> ping <节点1公共IP> oifcfg getif ``` 确保`/etc/hosts`中所有节点IP主机名配置正确,特别是VIP配置[^2]。 2. **验证存储配置** ```bash # 检查OCR/Voting Disk权限(需grid用户可读写) ls -l /dev/asm* dd if=/dev/asm-disk1 of=/dev/null count=1 ``` 若出现`Permission denied`,需调整udev规则或ASM磁盘权限。 3. **检查集群服务状态** ```bash # 在节点1执行 crsctl check cluster -all srvctl status nodeapps -n <节点2主机名> ``` 若节点1显示节点2为`OFFLINE`,需强制同步配置[^3]。 4. **清理缓存并重启服务** ```bash # 在节点2执行 crsctl stop crs rm -rf $GRID_HOME/crs/init/* crsctl start crs -wait ``` 观察启动过程中是否出现`CRS-2676`等关联错误。 5. **检查日志定位根源** ```bash # 关键日志路径 $GRID_HOME/log/<节点2主机名>/crsd/crsd.log $GRID_HOME/log/<节点2主机名>/alert.log ``` 若日志出现`PROC-26`错误,需重新初始化OCR[^4]。 --- #### 高级修复操作(需停机) ```bash # 若确认OCR损坏,从备份恢复(需在所有节点执行) ocrconfig -restore <备份路径> # 重新加入集群 crsctl add node -n <节点2主机名> ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值