接手Oracle 19c RAC集群之后头一个月我基本都在干同一件事巡检。但说句实话查状态谁都会crsctl stat res -t一敲、绿灯一堆很多人就觉得集群没问题了。真正的风险往往不在这些绿灯里而在私网丢包、时钟偏差、OCR一致性、ASM可用空间这些“平时看不见、出事就要命”的角落里。这篇文章把我这几年做19c集群巡检的完整套路记录下来。从GI层、ASM层到数据库层命令怎么敲、输出怎么读、哪些参数要看、哪些坑我亲自踩过都会讲到。无论你是刚从单实例转到集群的DBA还是已经管了一段时间集群想补全体检项的兄弟照着这套思路走一遍基本能把这个集群的家底摸清楚。1. 先想清楚巡检什么19c集群巡检的整体思路1.1 为什么巡检不能只盯数据库很多从单实例转过来的DBA巡检的习惯还停留在“看数据库alert log、查表空间、查归档”这三板斧。单实例这套够用但RAC集群不行。集群的故障面比单实例宽太多节点之间的私网心跳、CSS daemon的存活、OCR和voting disk的可用性、SCAN监听的状态、ASM磁盘组的冗余度哪一环出问题都可能把整个集群拖下水。我遇到过的最典型例子就是数据库层面一切正常alert log干净得像新买的白纸但集群里的某个节点已经被踢出集群两次了。原因在私网网卡的丢包率数据库层根本看不到这个指标。所以集群巡检必须分层、成体系地做数据库只是最后一层不是唯一一层。1.2 巡检的分层与核心检查对象我把19c集群巡检分成三个层级每个层级各有各的检查对象和命令集层级检查对象核心命令/工具GI层Grid InfrastructureCRS资源状态、CSS健康、OCR/voting disk、网络资源、CTSS/GNS、MGMTDBcrsctl、ocrcheck、cluvfy、srvctlASM层磁盘组空间、冗余状态、rebalance进程、ASM告警日志asmcmd、v$asm_diskgroup、v$asm_operation数据库层实例存活、组件状态、监听、归档、备份、安全基线srvctl、sqlplus、lsnrctl、opatch这个分层不是随手分的它对应的是19c集群的进程依赖关系。GI层是底座GI不稳定ASM和数据库全是空中楼阁ASM层管的是所有数据文件的家磁盘组满了谁也跑不了数据库层才是业务真正感知的地方。巡检顺序严格按这个层级从上往下走一旦某一层发现异常先解决下层再处理上层。1.3 巡检频率和场景怎么定巡检不能搞“想起来就查一下忘了就拉倒”。我的习惯是按三个频率来日常巡检每天或隔天看CRS资源状态、数据库alert log有无明显报错、归档目录和ASM磁盘组空间、监听是否正常。耗时10分钟以内主要抓急性问题。深度巡检每周或每两周OCR校验、投票盘状态、私网丢包测试、时钟同步、补丁一致性检查、备份日志核对。这一步才是真正的“体检”。专项巡检重大变更前、故障恢复后、业务大促前做一次全量检查包括节点peer对比、资源依赖关系梳理、历史告警回顾输出的结论要能支撑“可不可以做变更”的判断。2. 集群层面巡检状态、资源与一致性2.1 集群健康状态快照crsctl三板斧集群层面的第一件事是给整个集群拍一张“状态快照”。我固定用三个命令# 1. 整个集群的健康状态汇总 crsctl check cluster -all # 2. 所有资源的详细状态树形展示 crsctl status resource -t # 3. CRS核心组件CSS、CRS、EVMD等的状态 crsctl check crscrsctl check cluster -all的输出会按节点列出集群是否在线。如果某节点从结果里消失了或者显示OFFLINE那基本不用往后查了先把节点拉起来再说。crsctl status resource -t是日常看得最多的输出。这里有个容易被忽略的细节不仅要看STATE是不是ONLINE还要看TARGET是不是ONLINE。TARGET代表这个资源期望处于什么状态STATE代表它实际处于什么状态。如果TARGETONLINE但STATEOFFLINE说明资源该起来但没起来CRS可能正在重启它也可能已经放弃了如果TARGET和STATE都是OFFLINE那一般是被人为停掉的得先确认是不是有意的。注意看到资源OFFLINE先别急着start先看日志搞清楚它为什么OFFLINE。盲目crsctl start resource可能掩盖根本原因导致资源反复起起落落。2.2 OCR与Voting Disk巡检OCROracle Cluster Registry是集群的“大脑”里面存着所有资源、配置、依赖关系。voting disk是投票盘用来在脑裂时判断节点生死。这两个东西坏了比数据库文件坏还麻烦。# OCR一致性和完整性检查 ocrcheck # 查看voting disk配置 crsctl query css votediskocrcheck的输出主要看两处一是“Total size”和“Available size”如果可用空间异常变小说明OCR碎片在膨胀二是每个OCR设备的“status”必须是ONLINE如果有设备显示不是ONLINE赶紧检查对应的ASM磁盘组或块设备。OCR还需要定期备份。默认集群会每4小时自动备份到OCR的备份目录但我的建议是一周至少手动做一次备份并挪到集群之外的存储上ocrconfig -manualbackup ocrconfig -showbackup这个习惯平时不起眼但OCR损坏时能救命。我在一次硬件故障中碰上过OCR所在磁盘组全部丢失的情况就靠两周前的离线备份恢复了集群重建的话至少多花一天时间。2.3 资源与故障转移机制验证资源状态巡检不是只看单进程还要确认整个故障转移链路的逻辑是通的。重点看几类资源# 数据库资源状态 srvctl status database -d orcl # 监听、VIP、SCAN资源状态 srvctl status listener srvctl status vip -n node1 srvctl status scan srvctl status scan_listenerSCAN这里特别说一下。19c集群的SCAN VIP是客户端连接的入口如果只有部分SCAN IP在线应用连接时可能出现“一会儿能连一会儿连不上”的诡异现象。查看crsctl stat res -t时要把ora.net1.network、ora.scan1.vip、ora.scan1.listeners、各节点的ora.nodeN.vip串起来看一遍确认它们分布合理。关于故障转移我不建议在日常巡检里做破坏性测试比如拔私网或者kill CSS进程风险太高。我更倾向于通过查询历史记录来确认集群的reconfiguration是否正常# 查看crsd日志中的reconfiguration记录 grep Reconfiguration $GI_HOME/log/$(hostname)/crsd/crsd.log | tail -20集群发生节点加入、离开、资源漂移时都会留下reconfiguration记录。如果日志里频繁出现“reconfiguration”且间隔很短说明集群的成员关系不稳定这通常预示着私网或存储有问题值得顺着往下查。3. ASM与数据库层面巡检空间、负载与告警3.1 ASM磁盘组空间与均衡检查ASM磁盘组满导致数据库实例hang是我见过的集群故障里最冤的一种。空间问题预警周期长、可控性强但就是容易被忽略——因为数据库层的表空间没满大家就以为存储没问题。实际上ASM磁盘组可能已经快撑爆了。# 查看所有磁盘组的空间和冗余信息 asmcmd lsdglsdg输出里我重点盯这几列FREE_MB空闲空间太直白不多说。REQUIRED_MIRROR_FREE_MB保证冗余级别所需的最小空闲空间。这一列如果是0或接近0说明磁盘组已经没有冗余保护了任何一块盘损坏都会导致数据丢失。USABLE_FILE_MB考虑冗余后真正可以使用的空间。日常观察这个值的变化趋势比看FREE_MB更有参考价值。有个很实用的估算方法ASM可用空间至少能撑过“归档保留周期 数据增长周期 一次rebalance余量”。如果磁盘组冗余级别是NORMAL两份数据可用空间的计算大致是总空间减去已用空间的一半。所以不要看到FREE_MB还有几个T就放心要按USABLE_FILE_MB来规划。另外还要检查ASM的rebalance状态SELECT operation, power, state, sofar, est_minutes FROM v$asm_operation;如果返回了行说明有rebalance正在跑。长期挂着不结束的rebalance会占IO也会影响磁盘组性能。小技巧检查一下asm_power_limit参数生产环境一般建议2-4太高容易IO风暴。3.2 数据库实例与组件健康检查数据库层的巡检我习惯从两个视角同时看实例视角和组件视角。-- 集群中所有实例的信息 SELECT inst_id, instance_name, status, archiver, database_status, instance_role FROM gv$instance ORDER BY inst_id;正常状态应该是每行statusOPEN、database_statusACTIVE。如果某个实例显示STARTED还没open或者状态反复在OPEN和STARTED之间跳动说明实例有问题顺着数据库alert log查下去。组件视角要检查数据库内核组件有没有失效SELECT comp_id, comp_name, version, status FROM dba_registry ORDER BY comp_id;status列的标准答案应该是VALID。有INVALID或UPGRADED状态的组件意味着数据库在补丁或升级过程中留下了尾巴会影响后续安装PSU/RU甚至某些功能不正常。还有一个不起眼但很重要的项无效对象数量。SELECT owner, object_type, COUNT(*) cnt FROM dba_objects WHERE status INVALID GROUP BY owner, object_type ORDER BY cnt DESC;正常情况下无效对象数量应该稳定在一个基线值附近。如果巡检时发现某个表的无效对象数量突然暴涨多半是业务DDL失败或者补丁没跑完整需要追查而不是清掉或者重建对象了事。3.3 日志与告警集群和数据库的“黑匣子”日志是巡检里永远绕不开的部分。19c的日志比较多我一般按优先级看这几个CRS alert log$GI_HOME/log/$(hostname)/alert$(hostname).log看集群层面的重大事件。CSS日志$GI_HOME/log/$(hostname)/cssd/ocssd.log重点搜timeout、evict、lost这类关键词。crsd日志$GI_HOME/log/$(hostname)/crsd/crsd.log资源启停和故障转移的记录都在这里。数据库alert log$ORACLE_BASE/diag/rdbms/dbname/inst/trace/alert_inst.log重点搜ORA-600、ORA-07445、ORA-4030、ORA-15041这类内核错误。我不建议纯靠肉眼翻日志量大且容易漏。最简单可靠的方式是用grep配合时间和关键词# 查最近24小时内的ORA-600等严重错误 grep -E ORA-00600|ORA-07445|ORA-04031|ORA-01555 \ $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log | \ awk $1 last last$(date -d yesterday %Y-%m-%d)如果这些Ora error出现频率突然升高哪怕只是ORA-600的一个内部错误也建议开启SQL Trace或者直接提单分析。集群环境里“偶发”的ORA-600经常是硬件或驱动问题的先兆。3.4 安全基线里的“等保”巡检项现在不少系统都有等保要求Oracle这些检查项做起来并不复杂但很容易被遗漏。我把最简单的几个写在这里定期跑一遍就能覆盖大部分合规检查-- 审计是否开启 SHOW PARAMETER audit_trail; -- 密码策略密码长度、复杂度、尝试次数等 SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_type PASSWORD ORDER BY profile, resource_name; -- 是否有长期处于OPEN状态的账号 SELECT username, account_status, lock_date FROM dba_users ORDER BY account_status, username; -- 默认口令的风险账号检查 SELECT username FROM dba_users_with_defpwd;等保巡检的核心思路就两条该记的审计记没记审计策略、不该开的账号开没开账号与口令策略。剩下那些细碎的安全配置项可以整理成一个checklist脚本定期跑。4. 网络与互连层面巡检监听、私网与时钟4.1 SCAN监听与VIP资源检查应用连不上数据库一半以上是监听层面的问题。RAC环境里的监听比单实例复杂因为有多个SCAN监听分布在节点间。# 查看SCAN和监听的分布状态 srvctl status scan srvctl status scan_listener srvctl status listener # 逐个看监听器的实际状态 lsnrctl status LISTENER看监听有几个细节要注意监听里注册的实例lsnrctl status会显示“Instance”列表。如果某个实例没有出现在任何监听里客户端访问就会间歇性报错。可以用lsnrctl service查看每个实例的详细信息。监听日志增长监听日志如果疯狂增长说明有大量连接请求在反复失败。定位方式很简单看日志里的报错码就知道是连接拒绝还是超时。端口占用如果lsnrctl status卡住先检查netstat -tlnp | grep 1521确认进程还在不在端口是否被占用。注意19c默认的监听记录日志路径是$GI_HOME/network/log/日志文件可能会非常大。巡检时顺手看一眼监听日志的大小超出几个G就考虑配置log trimming或定期轮转。4.2 私网互联健康检查丢包、错包与心跳超时私网是集群的生命线。私网断了或者丢包严重集群会以为是节点挂了直接触发驱逐。节点的网卡硬件一般不会坏但交换机端口、网线、虚拟化宿主机的物理网卡都可能出问题。所以这块必须测。# 查看私网IPcluster_interconnects sqlplus -S / as sysdba EOF SELECT * FROM v$cluster_interconnects; EOF知道私网IP之后用源IP指定网卡做ping测试ping -I 172.16.1.101 -i 0.2 -c 500 172.16.1.102-i 0.2代表每0.2秒发一个包500个包跑下来大约100秒。这个测试的关键是看丢包率和最大延迟。丢包哪怕只有0.1%都值得警惕因为集群心跳是高频小包丢包率在集群层面的影响会被放大很多倍。最大延迟如果超过100ms也要查长时间抖动可能导致CSS误判。对虚拟化环境我还多一步检查# 查看CPU是否有严重的steal时间虚拟机被宿主机抢占CPU top -b -n 1 | grep -i st,st列偏高意味着虚机i在竞抢物理CPU。节点一旦在心跳窗口内抢不到CPUCSS心跳来不及发照样可能被驱逐。这个问题在资源超售的虚拟集群里非常常见巡检时一定要看。4.3 时钟同步NTP/CTSS/chrony集群节点之间的时钟偏差是另一个“低调但致命”的因素。时钟偏差太大CSS无法判断心跳超时的原因很容易触发脑裂保护。# 查看集群使用的时钟同步服务 crsctl stat res -t | grep -i ctss # 如果用的是NTP/chrony检查同步状态 timedatectl ntpstat chronyc tracking如果集群启用了CTSSCluster Time Synchronization Service那就不需要也不能同时配NTP。19c里如果两个都有会出现时间同步冲突。我的建议是如果环境里有可用的NTP源优先用NTP只有无法接入NTP时才依赖CTSS。配置NTP时保险起见还是停掉CTSS资源crsctl modify res ora.ctssd -attr AUTO_STARTnever crsctl stop res ora.ctssd时钟这块还有一个容易踩的坑修改了系统时间或时区之后集群的CRS和数据库日志时间对不上排查问题时线索全乱。每次改完系统时间至少要检查一下数据库时间的偏移SELECT systimestamp, current_timestamp FROM dual; select * from v$cluster_interconnects;5. 巡检中的高频问题与排查实录5.1 节点被驱逐Node Eviction节点被驱逐是RAC集群最闹心的问题之一。现象就是某个节点突然从集群成员里消失然后重启应用连接断开有时候整个集群都受影响。我在巡检中总结过19c集群的驱逐大致能追溯到这几类原因诱因日志关键字排查方向私网丢包/中断ocssd.log中的“network heartbeat lost”网卡、交换机、虚拟化网络时钟偏差过大CSS日志中的时间戳跳变NTP/chrony/CTSS配置IO hang或存储超时ASM日志中的I/O timeout存储链路、控制器、多路径内存压力/进程OOM/var/log/messages中的OOM大事务、共享内存设置CPU steal过高虚拟化宿主机负载虚机CPU超售定位驱逐原因的标准动作是先打开ocssd.log找驱逐决策前后的日志再用crsctl status resource -t看被驱逐节点上的资源状态最后去/var/log/messages里找内核层面的线索。预防和规避的经验核心就三条私网做好物理冗余双网卡、虚拟机不做过度超售、NTP稳定可靠。这三条守住驱逐事件能减少80%。5.2 监听器“假死”或连接不进去有一类问题特别讨厌lsnrctl status看着正常但就是连不进库。应用报的是ORA-12541: TNS: no listener或ORA-12537: TNS: connection closed。我的排查顺序是这样的第一步确认监听进程本身还活着ps -ef | grep tns_lsnr第二步确认监听资源在CRS里的状态srvctl status listener第三步查监听日志里的具体报错tail -100 $GI_HOME/network/log/listener_$(hostname)/listener.log日志里如果出现大量“connect timeout”或no longer listening多半是监听的进程数不够了检查一下sga_target和监听进程的processes配置。如果日志文件本身太大几GB也可能会导致监听读写异常。这种情况我的处理方式是先停监听、轮转日志文件、再启动监听。注意lsnrctl reload可以动态加载配置但处理监听异常时我不建议只做reload应该做完整的stop/start让CRS重新管理这个资源。5.3 ASM空间不足引发的连锁故障ASM磁盘组空间不足的报警其实会提前很多出现但很多人没当真。等真的满了表现就是数据库后台写盘报错严重的话实例直接中止。经典错误码是ORA-15041: diskgroup space exhaustedORA-01114: IO error writing block to file紧急情况下处理顺序要冷静先删归档释放空间前提是归档已经安全备份并满足保留策略。如果有备份把过期的备份文件从磁盘清除RMAN的delete obsolete。再考虑加盘给磁盘组添加新成员盘。如果以上都来不及只能迁移部分数据文件到其他磁盘组用DBMS_FILE_TRANSFER。日常巡检防患于未然的经验每次巡检记录USABLE_FILE_MB按周的粒度观察趋势低于某个阈值比如磁盘组容量预警线就提前安排加盘。等到告警邮件出来再动手往往已经晚了。5.4 配置漂移与补丁不一致集群环境最怕“各节点长得不一样”。两个节点一个打了补丁一个没打、一个改了参数一个没改表面上都活着踩雷只是时间问题。检查命令是# 节点间配置一致性检查 cluvfy comp peer -n node1,node2 -verbose # 补丁列表对比 opatch lspatches opatch lsinventory -detailcluvfy comp peer会对比节点之间的OS设置、GI配置、用户环境等。补丁不一致导致的典型症状是一个节点资源能正常on另一个节点资源一启动就报错或者两个节点的sqlplus版本行为不一致。我踩过的一次坑是两个节点的Oracle Home补丁版本差了整整一个RU一个节点上跑ALTER SYSTEM和DDL都正常另一个节点上同样的命令偶发报ORA-600。后来对照opatch lspatches结果才发现RU版本差了。补丁统一之后问题彻底消失。19c的补丁RU版本是所有节点必须严格一致的这是铁律。6. 巡检的结果整理与跟踪6.1 把巡检结果整理成可执行的问题清单巡检做完不输出结果等于白做。我自己习惯用一张固定格式的问题清单来记录把“看起来正常”的状态翻译成“有什么风险”的描述。问题描述风险等级整改建议责任人截止时间ASM DATA磁盘组USABLE_FILE_MB仅剩120G高两周内需加盘或清理归档张三2025-05-10node2私网丢包率0.2%高检查交换机端口及网卡协商李四2025-04-30SCAN2监听日志已达3.2G中配置日志轮转张三2025-05-05node1与node2的RU版本相差一个版本中统一补丁至同一RU王五2025-05-15无效对象数量较基线增加127个低核对业务变更清理无效对象赵六2025-05-20问题清单的价值不在于“记录”而在于“跟踪”。每次巡检完翻一下上一次的清单确认整改项闭环了没有没闭环的推一下进度这种循环跑起来集群才会越来越稳。6.2 几条实战心得最后聊几句心得体会。巡检命令可以写成脚本但解读输出这件事脚本替代不了人。有一次我自动巡检脚本显示所有资源ONLINE但客户端还是报连接失败——后来发现SCAN vip和域名解析对应不上脚本刚好没检查这一项。所以巡检脚本要定期更新把踩过的坑变成新检查项。另一个经验是巡检记录一定要留档。别嫌麻烦把每次巡检的核心指标比如OCR可用空间、ASM可用空间、各节点丢包率、时钟偏差值、补丁版本、无效对象数量记到一个简单的表格里。持续一个月你就能看到趋势——有的参数是线性下降的比如磁盘空间有的参数是波动式的比如丢包率。趋势比绝对值更能说明问题。还有一个小技巧巡检时留意一下crsctl stat res -t里的RESTART_COUNT列。这个列记录资源被重启的次数。如果某个资源的重启次数在一个周期内持续增长哪怕它当前状态是ONLINE也要认真查这说明它正在“隐性病发”总有一天会彻底起不来。19c集群的巡检说到底就是在和“潜伏问题”抢时间。多花十分钟做一次深度检查可能就少熬一次半夜三四点的故障。希望这套方法对你有所帮助。