Oracle 19c RAC集群的日常巡检一直是DBA工作里最考验耐心和细心的活儿。这东西不像单机出了问题往往不是单一节点的事牵一发动全身。我这些年巡检过的19c集群少说也有几十套从两节点的入门配置到多节点的大规模生产环境都碰过。今天就把我实际巡检过程中常用的思路、命令、排查套路和踩过的坑一次性梳理出来给正在跟19c集群打交道的朋友做个参考。这篇内容不是教科书式的功能罗列而是我基于实际环境操作总结的经验集合。不管你是刚接手19c RAC的新人还是已经有一定经验想查漏补缺的DBA都应该能从里面找到用得上的东西。我会按照从集群整体到数据库内部、从硬件层到应用层的顺序来拆解这个顺序本身也是我推荐的巡检顺序能最大程度避免漏检和误判。1. 巡检前的准备工作与整体框架1.1 巡检清单和工具准备很多朋友一上来就敲命令敲到哪算哪最后巡检报告写得七零八落。我在实际工作中习惯先把巡检维度固定下来再按清单逐项执行。一份成熟的19c RAC巡检清单至少应该覆盖以下六个维度集群层面CRS状态、节点成员、资源状态、OCR与Voting Disk健康度数据库层面实例状态、监听服务、负载分布、告警日志ASM层面磁盘组空间使用率、磁盘状态、ASM实例告警性能层面AWR报告关键指标、等待事件、TOP SQL、会话状态日志层面alert日志、GI日志、Clusterware日志中的ORA错误与IPC通信问题补丁与配置基线OPatch版本、PSU/RU版本、参数文件差异对比这个清单虽然看着多但真正执行起来也就三十到四十分钟。关键在于形成习惯每次巡检都按这个框架走就不会东一榔头西一棒子。1.2 连接环境与权限准备巡检之前得先确认手上的账号权限够用。我一般建议准备三个层面的账号操作系统层面oracle用户和grid用户用于执行crsctl、asmcmd、cluvfy等命令数据库层面具备SYSDBA权限的账号用于查询数据字典和动态性能视图ASM层面具备SYSASM权限的账号用于检查磁盘组和ASM实例状态这里有个实操细节很多新手会忽略巡检前先确认ORACLE_HOME和ORACLE_SID的环境变量是否正确。特别是GI和DB用在不同目录的环境里环境变量一旦搞错命令执行结果完全没有参考价值。我习惯把每个节点都单独ssh上去确认环境而不是图省事在一台机器上远程执行。远程执行容易漏掉节点级差异比如某节点的时间同步问题、私网网卡状态这些只有在本机上才能真实反映出来。2. 集群层巡检实操从CRS状态到OCR健康检查2.1 集群健康状态必须看的几个命令集群层是整个RAC的骨架这层出了问题数据库再正常也白搭。我巡检时最先跑的是集群健康检查命令因为它的输出最直接地反映了集群底座是否稳固。执行crsctl status resource -t是我每次巡检的固定动作。这个命令会列出所有集群资源的状态包括ora.asm、ora.LISTENER.lsnr、ora.ohs、ora.proxy_advs等。这里有个判断技巧资源状态只看是不是ONLINE是不够的关键要检查STATE列的状态是否在所有节点上都是ONLINE同时检查TARGET列是否有状态漂移。比如某个资源显示TARGET是OFFLINE但STATE是ONLINE说明有人手动停过这个资源这种不一致状态最容易埋雷。另外crsctl check cluster -all这个命令能一次性检查所有节点的CRS状态输出格式比较简洁适合快速判断整体状况。但注意这个命令返回的是“CRS is healthy”这种笼统信息不要只依赖这一个命令得出结论。我见过明明是资源异常但这条命令依然返回healthy的情况原因是它只检查了CRS后台进程是否活着并没有深入检查资源依赖关系。2.2 OCR和Voting Disk的体检方法OCR和Voting Disk是集群的大脑和表决器这两个东西出问题往往直接导致节点驱逐。日常巡检中我用以下命令做深度检查# 检查OCR的完整性 ocrcheck # 检查Voting Disk状态 crsctl query css votedisk # 检查OCR的自动备份 ocrconfig -showbackupocrcheck输出的每一行都要细看。重点关注Total size是否正常、Healthy标记是否为YES。如果出现OCR is not healthy或者某个Device的Status不是Available那基本可以断定OCR有损坏或者冗余丢失需要立刻处理。crsctl query css votedisk的输出中每个磁盘的Status字段为1表示正常在线。如果出现状态为0或者PROCESSED的磁盘说明该Voting Disk有问题可能引发脑裂风险。我在一次巡检中发现过三个Voting Disk中有一个状态为0当时数据库还能正常运行但只要这个节点的公网通信稍有抖动整个节点就可能被驱逐出集群。这种情况必须尽快用crsctl replace votedisk命令替换损坏的Voting Disk。OCR备份检查也别忘了。ocrconfig -showbackup会列出最近的OCR自动备份文件。这个备份每天自动执行保留最近几次的备份记录。如果这里显示的备份时间很久远说明OCR备份机制异常一旦OCR损坏你会发现自己根本没有可用的恢复点。这里我通常会顺手验证一下备份文件的大小是否合理一个只有几KB的备份文件基本等于没有备份。2.3 节点成员与网络心跳检查节点通信靠的是私有网络的心跳心跳断了就容易发生脑裂。19c集群对私网质量的要求非常高所以巡检时私网状态是必须检查的项。# 查看集群节点成员状态 olsnodes -n -s -i # 查看私网网卡状态 crsctl stat res -t -init | grep -E ora.cluster_interconnect|network # 检查集群通信状态 cluvfy comp nodecon -n all -verboseolsnodes -n -s -i输出中每个节点的编号、状态和虚拟IP信息都要核对。节点状态为Active是正常的如果出现Inactive或者Unknown说明节点间的通信已经出了问题。我在实际巡检中遇到过一种隐蔽情况私网网卡速率协商不一致。比如节点1的私网是10GE节点2的私网因为网线或交换端口问题协商成了1GE这种速率不匹配平时看不出问题但一旦流量激增心跳超时的概率会大幅上升。这种问题通过ethtool命令就能发现巡检时可以顺手执行ethtool 私网网卡名看看Speed字段是否一致。检查这两个节点的Speed字段是不是同一量级是我在私网巡检中必做的一步。3. 数据库层与ASM层巡检重点3.1 实例状态和监听服务怎么查最靠谱当集群层没有异常后开始进入数据库层面的巡检。实例和监听是数据库对外服务的窗口这两个状态检查相对简单但依然有细节。-- 查看RAC实例状态 SELECT inst_id, instance_name, status, database_status, instance_role FROM gv$instance ORDER BY inst_id; -- 查看服务在实例上的分布 SELECT inst_id, name, pdb, network_name, creation_date FROM gv$active_services ORDER BY inst_id, name;实例状态为OPEN、NORMAL、PRIMARY是标准健康状态。如果看到MOUNTED状态说明这个实例没有正常打开数据库通常是资源异常或者有人执行了startup mount。如果看到READY状态说明实例还在启动过程中可能卡在某个环节了。监听服务的检查用lsnrctl status命令。这里有个需要留意的地方19c默认会创建LISTENER和LISTENER_SCAN两种监听巡检时要分别检查。SCAN监听出问题不会直接导致连接失败但会导致客户端连接时在不同的节点上负载不均甚至是间歇性连接超时。SCAN监听的注册状态要特别关注REGISTERED的实例列表如果某个节点上的实例没有出现在注册列表里那客户端连接就有可能被路由到状态异常的节点。3.2 ASM磁盘组空间与磁盘状态深度检查ASM是Oracle集群的存储底座磁盘组空间不足或者磁盘故障对数据库的影响往往在几秒内就会爆发。ASM巡检我用SQL和asmcmd结合着来。-- 查磁盘组空间使用 SELECT name, state, type, total_mb, free_mb, usable_file_mb, ROUND((total_mb - free_mb) * 100 / total_mb, 2) AS usage_pct FROM v$asm_diskgroup ORDER BY name; -- 查磁盘状态和故障盘 SELECT group_number, disk_number, name, path, state, mode_status, total_mb, free_mb FROM v$asm_disk WHERE state NORMAL ORDER BY group_number, disk_number;磁盘组的使用率判断标准我这里给出参考值DATA磁盘组通常保持60%以下比较安全FRA磁盘组可以放宽到80%因为FRA会自动清理过期备份。但注意19c的USABLE_FILE_MB字段已经考虑了冗余策略比直接用free_mb判断更准确。我见过有同行只看free_mb结果在NORMAL冗余下实际可用空间只有free_mb的一半最终导致空间告警时措手不及。对于磁盘状态我最关注的是MODE_STATUS是否为ONLINE。如果出现OFFLINE状态的磁盘需要马上检查原因可能是链路故障、磁盘故障或者误操作。在ASM中一个磁盘offline之后ASM会自动触发rebalance但如果这个offline磁盘长时间不恢复整个磁盘组的冗余度会下降再次出现磁盘故障时数据安全会面临直接威胁。asmcmd命令里我常用asmcmd lsdg来查看磁盘组的明细信息这个命令的输出比SQL更直观包含了故障组信息。另外asmcmd ls -l可以查看ASM文件目录下的文件情况当数据库某个表空间报错找不到数据文件时这个命令能帮你在ASM层面快速定位文件是否存在。3.3 参数文件与配置差异检查RAC环境的参数文件管理有一个常见的坑各节点参数不一致。我用以下SQL来对比各节点的参数差异SELECT inst_id, name, value FROM gv$parameter WHERE isdefault FALSE ORDER BY name, inst_id;把输出结果按参数名分组比对重点看memong_size、sga_max_size、pga_aggregate_target、processes、session_cached_cursors等这些关键参数在各节点上是否一致。如果发现某个参数在不同节点的值不一样赶紧查是不是有人单独改过某节点的参数文件。RAC环境最讲究配置的一致性参数不一致会在故障切换时引发诡异问题。此外spfile参数文件的路径也要检查。19c默认使用DATA/ORCL/PARAMETERFILE/spfile.ora这种ASM路径如果发现某个节点还在用init.ora那这个节点的启动参数可能与实际配置脱节排查问题时容易产生误导。执行show parameter spfile就能看到当前节点使用的参数文件来源。4. 性能体检与日志诊断的关键方法4.1 AWR报告里那些真正值得关注的指标说实话做RAC巡检AWR报告是最容易让人头晕的部分指标太多反而不知道该看什么。我通常不看全量指标直接抓几个RAC特有的关键点来看问题。RAC相关的等待事件是巡检的重中之重。你需要在AWR的Top 5 Timed Events中重点关注以下几类gc buffer busy/gc buffer acquire说明跨节点数据访问竞争严重可能是数据库设计的热块问题也可能是应用的数据分布不合理global cache cr request/global cache grant request如果占比超过5%说明集群内部数据请求频率过高可能需要调整应用逻辑或者增加缓存DFS lock handle这个是队列锁等待往往是DDL操作和DML操作冲突的体现IPC send/recv timeout如果这个事件排在前面多半是私网网络质量有问题要回到集群层排查网络除了等待事件Interconnect Traffic Volume也值得关注。这个指标如果持续很高说明节点间的数据交换量巨大一方面可能是应用SQL带来的正常需求另一方面可能是SQL没写好导致大量数据跨节点传输。我见过一个典型的案例某系统一个看似简单的查询因为缺少必要条件导致每次执行要把一个百万行级别的表数据从节点1传到节点2Interconnect Traffic直接飙到几十GB每小时应用整体延迟翻了十倍。4.2 活动会话和TOP SQL怎么查才不遗漏动态性能视图是日常巡检最常用的诊断工具下面这几个查询帮我排查过大量问题。-- 查看活动会话及其等待事件 SELECT inst_id, sid, sql_id, event, wait_class, seconds_in_wait, blocking_session FROM gv$session WHERE status ACTIVE AND type USER ORDER BY seconds_in_wait DESC; -- 查看TOP SQL按CPU时间排序 SELECT * FROM ( SELECT sql_id, plan_hash_value, executions, cpu_time/1000000 cpu_sec, elapsed_time/1000000 elap_sec, buffer_gets, disk_reads FROM gv$sqlarea WHERE inst_id (SELECT MIN(inst_id) FROM gv$instance) ORDER BY cpu_time DESC ) WHERE ROWNUM 20;注意活动会话查询中BLOCKING_SESSION字段很容易被忽略。这个字段如果非空说明存在会话阻塞链需要顺着阻塞链找到源头。我处理过很多次数据库“假死”问题其实源头就是某个会话持有锁没提交后面所有会话越积越多整个系统看起来像死锁一样。通过这个查询找到最早的阻塞会话然后确认它在执行什么操作往往几分钟就能定位问题。TOP SQL的查询虽然简单但要注意过滤掉系统内部的递归SQL。方法是在SQL文本中排除SYS开头的用户执行语句或者直接在v$sqlarea的parsing_user_id关联dba_users过滤系统用户。否则你会看到一大片DBMS_STATS内部调用干扰判断。4.3 日志巡检alert、GI日志和ASM日志日志是RAC巡检中最诚实的记录者但也是最枯燥的检查项。我推荐的检查路径是按照日志类型分层排查数据库alert日志路径在$ORACLE_BASE/diag/rdbms/dbname/inst_name/trace/alert_inst_name.log检查内容主要看ORA-错误。重点关注ORA-600、ORA-07445这类内部错误以及ORA-3113、ORA-3135这类通信类错误。通信类错误出现往往意味着网络或节点异常需要跟集群日志联动分析。GI alert日志路径在$GRID_HOME/log/hostname/alerthostname.log这里面记录的是集群资源状态变化、节点驱逐、网络心跳丢失等底层事件。GI日志中如果出现GIPCD相关错误或者LOST ALL EVIDENCE OF HEARTBEAT说明私网通信已经出现严重问题节点驱逐往往紧随其后。ASM实例alert日志路径在$GRID_HOME/log/hostname/asm_alert.log具体路径可能因环境而异主要关注磁盘offline事件和rebalance操作记录。日志巡检有一个我自己的土办法用grep -i ora-\|error\|fatal过滤出错误关键字然后把过滤结果按时间排序看看是否有周期性规律。比如某个错误每两小时出现一次那就很可能对应某个定时任务或者备份作业需要进一步追踪。5. 常见问题速查与避坑经验分享5.1 巡检过程中经常遇到的几个典型问题我把自己和同行在实际巡检中高频遇到的19c RAC问题整理成了速查表方便对照排查节点频繁被驱逐出集群CRS报错The Oracle Clusterware is down根因通常是私网网络心跳超时。排查步骤是先检查私网网卡状态、速率协商是否一致、网线/光模块是否松动再检查防火墙是否拦截了私网网段通信。经验之谈是这类问题首先查网络而不是重装集群。SCAN监听注册失败或者部分实例未注册执行lsnrctl status LISTENER_SCAN查看注册列表如果某个实例未注册先检查该节点的remote_listener参数是否设置为SCAN监听地址再检查监听日志看是否有注册失败的记录。注册失败往往与DNS解析或hosts文件配置有关。alter日志出现IPC Send timeout但集群仍正常运行这种情况通常是间歇性网络抖动但绝不能掉以轻心。建议检查私网交换机是否有错误包计数增长、网卡是否有错包丢弃同时查看crsctl get log记录中是否有对应时间段的GIPCD告警。如果只是偶发一次可以先观察如果频繁出现需要尽早介入排查。磁盘组使用率告警但v$asm_diskgroup.free_mb仍有较多剩余要复查usable_file_mb和冗余策略。在NORMAL冗余下可用空间需要扣除镜像开销如果磁盘组有很多offline磁盘可用空间会进一步缩小。不要只凭free_mb做判断。5.2 巡检脚本化与报告输出经验巡检的价值不只在于发现问题还在于积累趋势数据。这就要说一个实操中的心得巡检一定要定期执行并归档报告形成历史对比。我通常会每月做一次完整巡检每次巡检的结果保存为文本文件并按日期命名。这样一旦某个指标突然变化比如磁盘使用率一个月从30%飙到55%我可以快速定位变化发生的时间窗口再配合AWR和日志去查原因。对于巡检脚本我倾向于直接使用Oracle自带的工具而不是费劲写复杂脚本来包一层。常用的自动化组合是cluvfy集群验证工具负责硬件层和网络层检查crsctl状态检查负责集群资源层检查SQL脚本负责数据库内部检查可以配合sqlplus -S静默执行并输出到文件diagcollection.pl位于$GRID_HOME/bin负责收集集群诊断信息在遇到复杂故障时能一次性收集全面的日志包报告的输出格式我习惯用纯文本结合表格方便直接粘贴进邮件或者工单。核心内容包含巡检时间、巡检节点、各维度结论、发现的问题列表、建议动作和优先级。每次巡检完我还会把发现的问题追加到一份长期跟踪清单中这样能确保之前遗留的问题不会被遗忘。5.3 巡检后需要重点跟进的隐患清单最后结合我自己的巡检经验给大家整理一张需要重点跟进的隐患清单碰到这些情况即使系统还能正常运行也应该尽快安排处理crsctl status resource -t中有资源频繁RESTART记录OCR备份时间超过48小时没有更新集群节点时间偏差超过50毫秒19c对时间同步要求很严格任一节点的私网网卡错误包计数持续增长ASM磁盘组中有offline磁盘未恢复数据库alert日志在最近7天内出现超过3次ORA-错误某个节点的gc buffer busy等待时间占比趋势上升这七条是我判断一个19c RAC集群是否处于“亚健康”状态的核心依据。任何一条命中都意味着集群可能正在小步迈向故障早处理一定比等故障爆发再救火要省力得多。Oracle 19c RAC集群的巡检说到底是把不确定变成确定的过程。通过固定清单、定期执行、持续归档你会发现很多潜在问题在真正影响业务之前就已经被处理掉了。这套巡检体系我用了很久实测下来对保障集群稳定运行非常有效。如果你在巡检中碰到什么奇怪的案例不妨按照上面这几个维度再去检查一遍大概率能找到线索。