这个操作我做过不止一次每次做完都出一身汗。Oracle 19c RAC 环境下OCR和votedisk同时丢失、而且没有任何可用备份听起来像是DBA的末日场景——实际上没有备份不代表没救只要你脑子里的知识还热乎集群底层的运行态信息还活着这条路完全可以走通。这篇文章把我真实操作的流程、判断逻辑、踩过的坑全部拆开讲清楚适合正在面对类似故障、或者想在测试环境提前演练一遍的同行参考。1. 故障全景OCR和votedisk各司其职同时丢失意味着什么1.1 OCR是集群的“注册表”OCR全称Oracle Cluster Registry它存的是整个集群的核心配置信息——节点列表、集群资源定义、ASM实例配置、RAC数据库的注册信息、网络配置、GNS配置等等。可以把它理解成Windows注册表在Oracle集群里的亲戚所有组件启动时都要读它任何配置变更都要写它。OCR在正常部署时会有三份副本分布在不同的存储路径上任何一份坏了另外两份还能顶上。但问题恰恰出在“同时丢失”上存储阵列逻辑损坏、误格式化、人为删除文件、或者底层LUN映射错乱都可能把三份副本一锅端。这个时候你连集群都起不来更别提数据库。1.2 votedisk是集群的“投票箱”votedisk解决的是脑裂判定问题。集群里每个节点通过votedisk进行心跳仲裁当网络心跳中断、节点间无法通信时votedisk的票数决定哪部分节点继续存活、哪部分节点被逐出集群。votedisk在ASM环境下同样需要多个副本默认配置三份分布在不同的failgroup里。它丢失之后的直接后果是CSS进程无法确定集群法定人数所有节点都不敢贸然启动集群彻底瘫痪。1.3 “无备份”场景到底是怎么发生的很多人以为无备份就是没做备份策略其实我遇到的情况往往更复杂ocrconfig -showbackup能显示备份文件但文件本身损坏ocrconfig -restore恢复失败备份文件存放在本地盘而本地盘恰好跟OCR所在存储一起被误操作清掉了cdata目录权限被改、文件被手工挪走、或者备份目录所在文件系统损坏更常见的是存储级别的误操作——快照删除、卷回收、LUN重新映射导致OCR、votedisk和自动备份全部消失。所以“无备份”不一定是你没做备份而是备份和原件一起阵亡了。这种时候千万别慌着重新初始化集群一旦你执行了root.sh或者重装GI那才是真的万劫不复——所有节点信息和配置痕迹都可能被覆盖掉。2. 无备份恢复的真正思路不依赖归档靠运行态和GPNP2.1 常规思路为什么走不通正常情况下OCR恢复就两条路ocrconfig -restore从自动备份恢复或者从另一节点的副本同步。无备份场景下这两条路全部堵死但很多人忽略了一个关键事实集群没死透的时候OCR内容仍然残留在CSS进程的内存缓存里。即便集群因为votedisk问题无法正常启动节点本地的GPNP ProfileGrid Plug and Play Profile文件仍然保存了集群的关键元数据包括集群名称、OCR存储位置、ASM磁盘组信息等。GPNP相当于身份证CSS启动时即使读不到OCR也能通过GPNP拿到最基本的指纹信息。2.2 三个恢复路径的前提判断无备份重建不是一条路走到黑先要判断现状属于哪种情况现状可用的恢复思路节点仍在运行集群资源部分存活直接尝试ocrconfig -repair甚至可以从内存导出OCR信息集群已宕但ASM磁盘组完好以排他模式启动手动拉起ASM挂载磁盘组再重建OCR和votediskASM磁盘组本身也丢失/损坏先恢复ASM磁盘组这通常是另一个独立的大型恢复项目不在本文范围内这三个判断直接影响操作路径。我最怕的就是一上来就乱执行命令把还有机会利用的运行态信息搞丢。2.3 选定方案-repair 重建votedisk的路线图我这次要重点讲的方案适用于第二种情况集群已宕但ASM层和存储层完好丢失的只是ASM里的OCR文件与votedisk文件。整体路线是在其中一个节点以排他模式启动CRS跳过OCR读取手动拉起ASM实例挂载包含OCR的磁盘组使用ocrconfig -repair -add重新注册OCR位置恢复正常模式启动让集群从GPNP和内存信息中自动构建OCR内容使用crsctl replace votedisk重建votedisk验证集群资源和RAC数据库回归。这个方案不依赖任何备份文件核心逻辑是“让集群自己重新生成配置文件”。3. 动手前的环境盘点与信息锁定3.1 节点清单与GI_HOME核对动刀之前先把家底盘清楚。我习惯列一个清单逐项确认集群节点数量与主机名比如node1、node2每个节点的GI_HOME路径通常是/u01/app/grid/19.0.0/gridOracle用户和OSDBA组通常grid用户安装GI集群名称可以从/etc/oracle/olr.loc或者GPNP profile中读取。排他模式只能在单节点执行其他节点必须全部处于停止状态。如果你不确定其他节点的状态先通过ssh过去检查CRS进程是否存在必要时手动执行crsctl stop crs -f。3.2 关键参数锁定这个环节是我在多次事故中总结出来的必备动作千万别省。需要锁定的参数有# 查看OLR位置OLR是每个节点本地的OCR独立于共享OCR cat /etc/oracle/olr.loc # 查看GI版本信息 $GRID_HOME/bin/crsctl query crs softwareversion # 查看集群名称如果GPNP还能读 $GRID_HOME/bin/gpnptool get # 尝试查看自动备份情况确认无备份的结论 $GRID_HOME/bin/ocrconfig -showbackup如果ocrconfig -showbackup报错或者显示无备份文件那就坐实了无备份的判断。OLR文件如果完好至少说明这个节点还有本地身份信息排他模式启动时成功率会高很多。3.3 存储层面核验这一步很多人容易忽略。OCR和votedisk都存放在ASM磁盘组里所以必须先确认ASM磁盘组的状态。你需要用asmcmd或者通过ASM实例查询# 确认ASM实例的状态如果还能起来 ps -ef | grep asm_pmon # 用ASM用户进入检查磁盘组 sqlplus / as sysasm SQL select name, state, type, total_mb, free_mb from v$asm_diskgroup;重点确认磁盘组是否处于MOUNTED状态磁盘组可用空间是否够建OCR和votedisk。OCR对空间要求不大几百MB就够votedisk单副本也就几百MB但磁盘组本身必须健康。另外要记录下磁盘组名称和冗余模式。比如OCR放在DATA这个磁盘组冗余方式是NORMAL那votedisk也会放在同一个组里ASM会自动管理多副本。4. 重建OCR的完整执行步骤从维护模式到ocrconfig -repair4.1 先让CSS在排他模式下起来这一步是整个恢复的地基。排他模式exclusive mode可以让CSS不读取OCR和votedisk就直接启动相当于给了一个“无证驾驶”的入口。在node1上执行# 先确保本节点CRS进程是停止状态 crsctl stop crs -f # 以排他模式启动跳过OCR和CRSD crsctl start crs -excl -nocrs-excl表示排他模式-nocrs表示不启动CRSD资源守护进程。执行后观察集群日志确认CSS进程正常起来了tail -f $GRID_HOME/log/$(hostname)/cssd/ocssd.log正常情况下能看到CSS启动成功并进入“clustered”状态。如果CSS起不来多半是OLR损坏或者网络心跳配置丢失那就需要先处理这些前置问题。4.2 手动拉起ASM实例并挂载磁盘组排他模式下CRSD没有运行ASM资源不会自动启动需要手动拉起来# 切换到grid用户 su - grid # 启动ASM实例 export ORACLE_SIDASM1 sqlplus / as sysasm SQL startup nomount;如果ASM的spfile本身就在OCR磁盘组里startup nomount可能会报错找不到spfile。这时候需要手动指定参数文件SQL startup nomount pfile/tmp/asm_pfile.ora;有了实例之后手动挂载磁盘组SQL alter diskgroup DATA mount; SQL select name, state from v$asm_diskgroup;这一步如果执行失败说明ASM磁盘组本身也有问题。我遇到过磁盘组因为OCR丢失而处于“FORCED MOUNTING”状态直接alter diskgroup DATA mount会卡住。这种情况下需要先检查磁盘头asmcmd lsdsk -k -p如果磁盘组实在无法挂载那就得先用kfed修复磁盘头或从存储快照恢复磁盘组属于另一个战场本文暂不展开。4.3 用ocrconfig -repair -add写入新OCR位置手动拉起ASM并挂载磁盘组后核心操作就是ocrconfig -repair命令。这个命令的特殊之处在于它不依赖备份文件而是基于节点本地的GPNP信息和运行态信息直接修改OCR注册位置。# 查询当前OCR注册情况此时应该为空或全部失效 ocrconfig -repair -show # 添加新的OCR位置这里以DATA为例 ocrconfig -repair -add DATA执行成功后可以验证ocrcheck如果返回结果里能看到DATA设备并且显示Device/file integrity check succeeded说明OCR位置已经注册成功。-repair和-replace的区别要注意-repair是告诉集群“这个位置作为OCR”即使旧位置已经不可读也能强制执行-replace则是先读旧位置再换成新位置旧位置彻底不可读时可能失败。所以无备份场景下优先使用-repair -add。4.4 退出排他模式恢复正常启动新OCR位置注册完成之后需要退出排他模式让集群以正常模式重新启动# 回到root用户 exit # 停止排他模式下的CRS crsctl stop crs -f # 正常启动CRS crsctl start crs等CRS启动完成后重点检查CRSD是否正常接管crsctl stat res -t这时你可能会看到很多资源处于INTERMEDIATE或OFFLINE状态这正常因为集群刚恢复很多东西还在重建。关键的检查点是ocrcheck输出里应当能看到Status of Oracle Cluster Registry is as follows : Version : 3 Total space (kbytes) : 262144 Used space (kbytes) : 2048 Device/File Name : DATA Device/File integrity check succeeded看到“Device/File integrity check succeeded”就说明OCR已经在正常工作了。集群在启动过程中会自动将内存中保留的配置信息写入新OCR文件不需要你手动导入任何东西。5. 重建votedisk与集群回归验证5.1 判断votedisk是否真的需要重建OCR重建只是第一步votedisk如果不处理集群依然无法稳定运行。先用下面命令查看votedisk状态crsctl query css votedisk正常输出长这样## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 5e4e2e... /dev/sdb DATA 2. ONLINE 8c1a2f... /dev/sdc DATA 3. ONLINE a3d5e7... /dev/sdd DATA如果输出里全是LOST、OFFLINE、或者根本没有记录那就需要重建。还有一种容易被忽略的情况OCR重建后集群虽然能启动但votedisk文件内容已经被破坏CSS在运行时会持续报心跳错误。这种情况下即使votedisk显示ONLINE也要强制重写。5.2 替换votedisk的具体命令确认需要重建后使用crsctl replace votedisk命令完成替换。这里要注意该命令要在CSS正常运行状态下执行同时要确保有足够的权限通常需要root或grid用户。# 把所有votedisk重写到DATA磁盘组 crsctl replace votedisk DATA这个命令的执行逻辑是先检查目标磁盘组可用性然后在磁盘组内创建新的votedisk副本再把集群的votedisk指向切过去。执行完成后再验证crsctl query css votedisk看到所有条目都是ONLINE状态第一步就成功了。接下来重启一次CRS确认votedisk信息保存正常crsctl stop crs -f crsctl start crs5.3 验证集群资源和RAC数据库回归集群起来之后光看OCR和votedisk还不够必须把整个栈验一遍# 检查集群整体状态 crsctl check crs # 查看所有资源状态 crsctl stat res -t # 检查ASM实例状态 crsctl stat res ora.asm -t # 检查数据库实例和监听状态 crsctl stat res ora.db -tRAC数据库通常会在CRS启动后自动注册并启动。如果数据库没有自动启动可以手动执行srvctl start database -d ORACLEDB然后验证数据库实例在多个节点上都处于OPEN状态sqlplus / as sysdba SQL select inst_id, instance_name, status from gv$instance;我还建议做一次数据库层面的快速验证——执行一个简单的查询、切换一次日志、或者跑一个AWR报告快照确认集群和数据库不是“表面活、内里死”。6. 这些坑我帮你踩过了6.1 最容易栽跟头的地方第一个坑排他模式启动顺序搞错。必须先在所有节点停掉CRS再在单节点执行crsctl start crs -excl -nocrs。如果其他节点还在运行排他模式根本起不来报错也不够直观容易让人误判是OCR损坏之外的问题。第二个坑ASM spfile放在OCR磁盘组里。当OCR磁盘组丢失时ASM实例可能也起不来因为spfile也在这个磁盘组里。这时候要提前准备好pfile。我习惯在正常环境的/tmp下保留一份ASM pfile备份这次就派上了大用场。第三个坑执行ocrconfig -repair -add之前没有检查磁盘组空间。虽然OCR占空间不大但如果磁盘组本身已经满了命令会一直卡住日志里也不会报明确错误。先执行磁盘组空间检查是最稳妥的。第四个坑votedisk重建后忘记重启CSS验证。crsctl replace votedisk返回成功不代表重启后依然有效。有些人重建完直接以为完事了结果下一次节点重启又起不来。必须完成一次完整的CRS停止再启动验证。第五个坑手滑执行了不必要的初始化。在无备份场景下任何类似$GRID_HOME/root.sh、cluvfy、或者修改GPNP的命令都可能覆盖掉当前存活的指纹信息让本来能恢复的局面变得不可恢复。操作前多想三秒。6.2 日常维护建议经历过这次事故之后我把OCR/votedisk的日常检查固化到了运维脚本里检查项命令频率OCR状态ocrcheck每天OCR自动备份ocrconfig -showbackup每周votedisk状态crsctl query css votedisk每天磁盘组空间asmcmd lsdg每周集群日志错误grep -i error $GRID_HOME/log/$(hostname)/crsd/crsd.log每天自动备份虽然叫“自动”但它依赖本地cdata目录这个目录既不在OCR磁盘组里也不在共享存储上很容易被忽略。我建议把cdata目录也纳入定时备份最好复制到独立于数据库存储之外的备份服务器。另外既然都走到重建这一步了顺手做一次OCR配置的导出留档也不亏ocrconfig -export /backup/ocr_export_$(date %Y%m%d).dat这个导出文件虽然不算正式备份但至少包含当前OCR里的全部配置后面如果要查某个资源参数、核对集群配置就不用去翻日志了。这次操作最大的体会是无备份不等于无解但能活着从这种故障里走出来靠的是平时把这些配置文件的结构、运行机制、恢复入口记在脑子里。真正到了存储阵列一锅端的那天手边没有文档、没有同事、没有互联网你能依赖的就是这些底层认知和肌肉记忆。希望各位永远用不上这篇文章但需要的时候它能帮你少走很多弯路。
这个操作我做过不止一次每次做完都出一身汗。Oracle 19c RAC 环境下OCR和votedisk同时丢失、而且没有任何可用备份听起来像是DBA的末日场景——实际上没有备份不代表没救只要你脑子里的知识还热乎集群底层的运行态信息还活着这条路完全可以走通。这篇文章把我真实操作的流程、判断逻辑、踩过的坑全部拆开讲清楚适合正在面对类似故障、或者想在测试环境提前演练一遍的同行参考。1. 故障全景OCR和votedisk各司其职同时丢失意味着什么1.1 OCR是集群的“注册表”OCR全称Oracle Cluster Registry它存的是整个集群的核心配置信息——节点列表、集群资源定义、ASM实例配置、RAC数据库的注册信息、网络配置、GNS配置等等。可以把它理解成Windows注册表在Oracle集群里的亲戚所有组件启动时都要读它任何配置变更都要写它。OCR在正常部署时会有三份副本分布在不同的存储路径上任何一份坏了另外两份还能顶上。但问题恰恰出在“同时丢失”上存储阵列逻辑损坏、误格式化、人为删除文件、或者底层LUN映射错乱都可能把三份副本一锅端。这个时候你连集群都起不来更别提数据库。1.2 votedisk是集群的“投票箱”votedisk解决的是脑裂判定问题。集群里每个节点通过votedisk进行心跳仲裁当网络心跳中断、节点间无法通信时votedisk的票数决定哪部分节点继续存活、哪部分节点被逐出集群。votedisk在ASM环境下同样需要多个副本默认配置三份分布在不同的failgroup里。它丢失之后的直接后果是CSS进程无法确定集群法定人数所有节点都不敢贸然启动集群彻底瘫痪。1.3 “无备份”场景到底是怎么发生的很多人以为无备份就是没做备份策略其实我遇到的情况往往更复杂ocrconfig -showbackup能显示备份文件但文件本身损坏ocrconfig -restore恢复失败备份文件存放在本地盘而本地盘恰好跟OCR所在存储一起被误操作清掉了cdata目录权限被改、文件被手工挪走、或者备份目录所在文件系统损坏更常见的是存储级别的误操作——快照删除、卷回收、LUN重新映射导致OCR、votedisk和自动备份全部消失。所以“无备份”不一定是你没做备份而是备份和原件一起阵亡了。这种时候千万别慌着重新初始化集群一旦你执行了root.sh或者重装GI那才是真的万劫不复——所有节点信息和配置痕迹都可能被覆盖掉。2. 无备份恢复的真正思路不依赖归档靠运行态和GPNP2.1 常规思路为什么走不通正常情况下OCR恢复就两条路ocrconfig -restore从自动备份恢复或者从另一节点的副本同步。无备份场景下这两条路全部堵死但很多人忽略了一个关键事实集群没死透的时候OCR内容仍然残留在CSS进程的内存缓存里。即便集群因为votedisk问题无法正常启动节点本地的GPNP ProfileGrid Plug and Play Profile文件仍然保存了集群的关键元数据包括集群名称、OCR存储位置、ASM磁盘组信息等。GPNP相当于身份证CSS启动时即使读不到OCR也能通过GPNP拿到最基本的指纹信息。2.2 三个恢复路径的前提判断无备份重建不是一条路走到黑先要判断现状属于哪种情况现状可用的恢复思路节点仍在运行集群资源部分存活直接尝试ocrconfig -repair甚至可以从内存导出OCR信息集群已宕但ASM磁盘组完好以排他模式启动手动拉起ASM挂载磁盘组再重建OCR和votediskASM磁盘组本身也丢失/损坏先恢复ASM磁盘组这通常是另一个独立的大型恢复项目不在本文范围内这三个判断直接影响操作路径。我最怕的就是一上来就乱执行命令把还有机会利用的运行态信息搞丢。2.3 选定方案-repair 重建votedisk的路线图我这次要重点讲的方案适用于第二种情况集群已宕但ASM层和存储层完好丢失的只是ASM里的OCR文件与votedisk文件。整体路线是在其中一个节点以排他模式启动CRS跳过OCR读取手动拉起ASM实例挂载包含OCR的磁盘组使用ocrconfig -repair -add重新注册OCR位置恢复正常模式启动让集群从GPNP和内存信息中自动构建OCR内容使用crsctl replace votedisk重建votedisk验证集群资源和RAC数据库回归。这个方案不依赖任何备份文件核心逻辑是“让集群自己重新生成配置文件”。3. 动手前的环境盘点与信息锁定3.1 节点清单与GI_HOME核对动刀之前先把家底盘清楚。我习惯列一个清单逐项确认集群节点数量与主机名比如node1、node2每个节点的GI_HOME路径通常是/u01/app/grid/19.0.0/gridOracle用户和OSDBA组通常grid用户安装GI集群名称可以从/etc/oracle/olr.loc或者GPNP profile中读取。排他模式只能在单节点执行其他节点必须全部处于停止状态。如果你不确定其他节点的状态先通过ssh过去检查CRS进程是否存在必要时手动执行crsctl stop crs -f。3.2 关键参数锁定这个环节是我在多次事故中总结出来的必备动作千万别省。需要锁定的参数有# 查看OLR位置OLR是每个节点本地的OCR独立于共享OCR cat /etc/oracle/olr.loc # 查看GI版本信息 $GRID_HOME/bin/crsctl query crs softwareversion # 查看集群名称如果GPNP还能读 $GRID_HOME/bin/gpnptool get # 尝试查看自动备份情况确认无备份的结论 $GRID_HOME/bin/ocrconfig -showbackup如果ocrconfig -showbackup报错或者显示无备份文件那就坐实了无备份的判断。OLR文件如果完好至少说明这个节点还有本地身份信息排他模式启动时成功率会高很多。3.3 存储层面核验这一步很多人容易忽略。OCR和votedisk都存放在ASM磁盘组里所以必须先确认ASM磁盘组的状态。你需要用asmcmd或者通过ASM实例查询# 确认ASM实例的状态如果还能起来 ps -ef | grep asm_pmon # 用ASM用户进入检查磁盘组 sqlplus / as sysasm SQL select name, state, type, total_mb, free_mb from v$asm_diskgroup;重点确认磁盘组是否处于MOUNTED状态磁盘组可用空间是否够建OCR和votedisk。OCR对空间要求不大几百MB就够votedisk单副本也就几百MB但磁盘组本身必须健康。另外要记录下磁盘组名称和冗余模式。比如OCR放在DATA这个磁盘组冗余方式是NORMAL那votedisk也会放在同一个组里ASM会自动管理多副本。4. 重建OCR的完整执行步骤从维护模式到ocrconfig -repair4.1 先让CSS在排他模式下起来这一步是整个恢复的地基。排他模式exclusive mode可以让CSS不读取OCR和votedisk就直接启动相当于给了一个“无证驾驶”的入口。在node1上执行# 先确保本节点CRS进程是停止状态 crsctl stop crs -f # 以排他模式启动跳过OCR和CRSD crsctl start crs -excl -nocrs-excl表示排他模式-nocrs表示不启动CRSD资源守护进程。执行后观察集群日志确认CSS进程正常起来了tail -f $GRID_HOME/log/$(hostname)/cssd/ocssd.log正常情况下能看到CSS启动成功并进入“clustered”状态。如果CSS起不来多半是OLR损坏或者网络心跳配置丢失那就需要先处理这些前置问题。4.2 手动拉起ASM实例并挂载磁盘组排他模式下CRSD没有运行ASM资源不会自动启动需要手动拉起来# 切换到grid用户 su - grid # 启动ASM实例 export ORACLE_SIDASM1 sqlplus / as sysasm SQL startup nomount;如果ASM的spfile本身就在OCR磁盘组里startup nomount可能会报错找不到spfile。这时候需要手动指定参数文件SQL startup nomount pfile/tmp/asm_pfile.ora;有了实例之后手动挂载磁盘组SQL alter diskgroup DATA mount; SQL select name, state from v$asm_diskgroup;这一步如果执行失败说明ASM磁盘组本身也有问题。我遇到过磁盘组因为OCR丢失而处于“FORCED MOUNTING”状态直接alter diskgroup DATA mount会卡住。这种情况下需要先检查磁盘头asmcmd lsdsk -k -p如果磁盘组实在无法挂载那就得先用kfed修复磁盘头或从存储快照恢复磁盘组属于另一个战场本文暂不展开。4.3 用ocrconfig -repair -add写入新OCR位置手动拉起ASM并挂载磁盘组后核心操作就是ocrconfig -repair命令。这个命令的特殊之处在于它不依赖备份文件而是基于节点本地的GPNP信息和运行态信息直接修改OCR注册位置。# 查询当前OCR注册情况此时应该为空或全部失效 ocrconfig -repair -show # 添加新的OCR位置这里以DATA为例 ocrconfig -repair -add DATA执行成功后可以验证ocrcheck如果返回结果里能看到DATA设备并且显示Device/file integrity check succeeded说明OCR位置已经注册成功。-repair和-replace的区别要注意-repair是告诉集群“这个位置作为OCR”即使旧位置已经不可读也能强制执行-replace则是先读旧位置再换成新位置旧位置彻底不可读时可能失败。所以无备份场景下优先使用-repair -add。4.4 退出排他模式恢复正常启动新OCR位置注册完成之后需要退出排他模式让集群以正常模式重新启动# 回到root用户 exit # 停止排他模式下的CRS crsctl stop crs -f # 正常启动CRS crsctl start crs等CRS启动完成后重点检查CRSD是否正常接管crsctl stat res -t这时你可能会看到很多资源处于INTERMEDIATE或OFFLINE状态这正常因为集群刚恢复很多东西还在重建。关键的检查点是ocrcheck输出里应当能看到Status of Oracle Cluster Registry is as follows : Version : 3 Total space (kbytes) : 262144 Used space (kbytes) : 2048 Device/File Name : DATA Device/File integrity check succeeded看到“Device/File integrity check succeeded”就说明OCR已经在正常工作了。集群在启动过程中会自动将内存中保留的配置信息写入新OCR文件不需要你手动导入任何东西。5. 重建votedisk与集群回归验证5.1 判断votedisk是否真的需要重建OCR重建只是第一步votedisk如果不处理集群依然无法稳定运行。先用下面命令查看votedisk状态crsctl query css votedisk正常输出长这样## STATE File Universal Id File Name Disk group -- ----- ----------------- --------- --------- 1. ONLINE 5e4e2e... /dev/sdb DATA 2. ONLINE 8c1a2f... /dev/sdc DATA 3. ONLINE a3d5e7... /dev/sdd DATA如果输出里全是LOST、OFFLINE、或者根本没有记录那就需要重建。还有一种容易被忽略的情况OCR重建后集群虽然能启动但votedisk文件内容已经被破坏CSS在运行时会持续报心跳错误。这种情况下即使votedisk显示ONLINE也要强制重写。5.2 替换votedisk的具体命令确认需要重建后使用crsctl replace votedisk命令完成替换。这里要注意该命令要在CSS正常运行状态下执行同时要确保有足够的权限通常需要root或grid用户。# 把所有votedisk重写到DATA磁盘组 crsctl replace votedisk DATA这个命令的执行逻辑是先检查目标磁盘组可用性然后在磁盘组内创建新的votedisk副本再把集群的votedisk指向切过去。执行完成后再验证crsctl query css votedisk看到所有条目都是ONLINE状态第一步就成功了。接下来重启一次CRS确认votedisk信息保存正常crsctl stop crs -f crsctl start crs5.3 验证集群资源和RAC数据库回归集群起来之后光看OCR和votedisk还不够必须把整个栈验一遍# 检查集群整体状态 crsctl check crs # 查看所有资源状态 crsctl stat res -t # 检查ASM实例状态 crsctl stat res ora.asm -t # 检查数据库实例和监听状态 crsctl stat res ora.db -tRAC数据库通常会在CRS启动后自动注册并启动。如果数据库没有自动启动可以手动执行srvctl start database -d ORACLEDB然后验证数据库实例在多个节点上都处于OPEN状态sqlplus / as sysdba SQL select inst_id, instance_name, status from gv$instance;我还建议做一次数据库层面的快速验证——执行一个简单的查询、切换一次日志、或者跑一个AWR报告快照确认集群和数据库不是“表面活、内里死”。6. 这些坑我帮你踩过了6.1 最容易栽跟头的地方第一个坑排他模式启动顺序搞错。必须先在所有节点停掉CRS再在单节点执行crsctl start crs -excl -nocrs。如果其他节点还在运行排他模式根本起不来报错也不够直观容易让人误判是OCR损坏之外的问题。第二个坑ASM spfile放在OCR磁盘组里。当OCR磁盘组丢失时ASM实例可能也起不来因为spfile也在这个磁盘组里。这时候要提前准备好pfile。我习惯在正常环境的/tmp下保留一份ASM pfile备份这次就派上了大用场。第三个坑执行ocrconfig -repair -add之前没有检查磁盘组空间。虽然OCR占空间不大但如果磁盘组本身已经满了命令会一直卡住日志里也不会报明确错误。先执行磁盘组空间检查是最稳妥的。第四个坑votedisk重建后忘记重启CSS验证。crsctl replace votedisk返回成功不代表重启后依然有效。有些人重建完直接以为完事了结果下一次节点重启又起不来。必须完成一次完整的CRS停止再启动验证。第五个坑手滑执行了不必要的初始化。在无备份场景下任何类似$GRID_HOME/root.sh、cluvfy、或者修改GPNP的命令都可能覆盖掉当前存活的指纹信息让本来能恢复的局面变得不可恢复。操作前多想三秒。6.2 日常维护建议经历过这次事故之后我把OCR/votedisk的日常检查固化到了运维脚本里检查项命令频率OCR状态ocrcheck每天OCR自动备份ocrconfig -showbackup每周votedisk状态crsctl query css votedisk每天磁盘组空间asmcmd lsdg每周集群日志错误grep -i error $GRID_HOME/log/$(hostname)/crsd/crsd.log每天自动备份虽然叫“自动”但它依赖本地cdata目录这个目录既不在OCR磁盘组里也不在共享存储上很容易被忽略。我建议把cdata目录也纳入定时备份最好复制到独立于数据库存储之外的备份服务器。另外既然都走到重建这一步了顺手做一次OCR配置的导出留档也不亏ocrconfig -export /backup/ocr_export_$(date %Y%m%d).dat这个导出文件虽然不算正式备份但至少包含当前OCR里的全部配置后面如果要查某个资源参数、核对集群配置就不用去翻日志了。这次操作最大的体会是无备份不等于无解但能活着从这种故障里走出来靠的是平时把这些配置文件的结构、运行机制、恢复入口记在脑子里。真正到了存储阵列一锅端的那天手边没有文档、没有同事、没有互联网你能依赖的就是这些底层认知和肌肉记忆。希望各位永远用不上这篇文章但需要的时候它能帮你少走很多弯路。
