gimr在oracle 19c rac中默认随gi自动创建并由ora.crf资源管理，状态异常表现为ora.crf反复offline、crsctl stat res -t显示intermediate/unknown，需通过crsctl、srvctl、asm磁盘组空间、日志及ocr争抢等多维度验证。
确认GIMR是否真的在运行且状态异常
GIMR（Grid Infrastructure Management Repository）是Oracle 19c RAC中用于存放集群健康数据、AWR快照、CHM（Cluster Health Monitor）历史的轻量级数据库，它默认随GI安装自动创建。但很多人误以为“没手动建GIMR就不存在”，其实只要GI版本≥12.1.0.2，GIMR就已内置——哪怕你删过，crsctl start res ora.crf也会拉起一个精简实例。卡顿若发生在集群负载不高但ora.crf资源反复offline、或crsctl stat res -t显示其状态为INTERMEDIATE或UNKNOWN，就要优先怀疑GIMR。
实操建议：
- 执行
crsctl stat res ora.crf -p | grep -E "(STATE|ENABLED|AUTO_START)"，确认资源是否启用且自动启动；若AUTO_START=never，说明曾被人为禁用，需crsctl modify res ora.crf -attr "AUTO_START=always" - 查GIMR实例日志：
tail -50 $ORACLE_BASE/diag/rdbms/_mgmtdb/-MGMTDB/trace/mgmtdb_ora_*.trc，重点搜ORA-01114（写临时文件失败）、ORA-1653（表空间无法扩展）、ORA-00600（内部错误） - 用
srvctl status mgmtdb看实例是否UP；若报PRCR-1079 : Failed to start resource ora.mgmtdb，再查$GRID_HOME/log/<hostname>/agent/ohasd/oraagent_oracle.log</hostname>里是否有ORA-01034: ORACLE not available或共享内存段冲突
检查GIMR所在磁盘组空间与I/O压力
GIMR默认使用+MGMTDB磁盘组，该磁盘组通常只含1~3块盘，容量小、无冗余（外部冗余居多），极易因CHM采样频率高+AWR保留策略未调而撑爆。一旦+MGMTDB使用率超95%，GIMR会频繁触发checkpoint not complete、log file switch (archiving needed)等等待，拖慢整个ora.crf服务响应，进而让crsd.bin和ohasd进程卡在健康检查环节——表现为crsctl check crs变慢、节点间心跳延迟升高、甚至cluvfy comp clocksync失败。
实操建议：
- 登录任意节点，执行
asmcmd lsdg，确认+MGMTDB的Usable_file_MB是否接近0；若低于500MB，立刻清理：sqlplus / as sysasm "alter diskgroup MGMTDB drop file '+MGMTDB/_MGMTDB/ARCHIVELOG/2026_09_27/*';" - 查GIMR AWR保留期：
sqlplus / as sysdba @?/rdbms/admin/awrinfo.sql，看DBA_HIST_WR_CONTROL中RETENTION值；19c默认8天，建议压到3天：exec dbms_workload_repository.modify_snapshot_settings(retention=>4320);（单位分钟） - 禁用非必要CHM采样：
crsctl modify resource "ora.crf" -attr "CHECK_INTERVAL=60,RESTART_ATTEMPTS=3"，避免每5秒一次全量采集把I/O打满
验证GIMR是否引发OCR/Voting Disk争抢
GIMR实例虽小，但它和OCR/Voting Disk共享同一套ASM实例路径与底层存储栈。当+MGMTDB磁盘组物理位置与OCR磁盘组重叠（比如都建在/dev/mapper/mpathb上），或ASM磁盘头残留ASMLib干扰（见知识库“ASMLib已被弃用”条目），GIMR的高频率redo写入会直接冲击OCR读取路径，导致ocrcheck超时、crsctl query css votedisk返回no voting files available——此时集群看似“卡”，实则是CSS守护进程在反复重试OCR访问，CPU集中在ocssd.bin而非数据库进程。
实操建议：
- 运行
ocrcheck -config和crsctl query css votedisk，若耗时>5秒或报错，立即查$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>中是否有clsc_send_msg: send failed或IO error on device - 确认
+MGMTDB与OCR磁盘组物理分离：asmcmd lsdsk -k输出中，两者的PATH列应指向不同设备（如/dev/mapper/mpathbvs/dev/mapper/mpathc）；若相同，必须重建+MGMTDB到独立LUN - 用
kfed read /dev/mapper/mpathb | head -10确认无ASMLib签名（如AFD_DISK或ORCLDISK字样），有则按知识库“清理ASMLib”流程彻底清除
绕过GIMR快速验证是否为根因
停GIMR不是最终解法，但它是最快锁定问题的手段：如果停掉ora.crf后集群卡顿消失、crsctl check crs恢复毫秒级响应、top -H -p $(pgrep -f "ocssd")中线程CPU回落，那基本可断定GIMR是当前瓶颈源。注意：停GIMR不影响数据库实例运行，仅丢失最近CHM/ASH数据，不伤OCR或业务。
实操建议：
- 临时停用：
crsctl stop res ora.crf -f（所有节点执行）；观察5分钟，若卡顿缓解，说明GIMR配置或存储层有问题 - 不要直接删GIMR：执行
srvctl remove mgmtdb -f会清空+MGMTDB，但OCR可能仍引用该磁盘组路径，导致下次crsctl start res -all失败 - 若必须重建GIMR，先备份：
asmcmd cp +MGMTDB/_MGMTDB/DATAFILE/system.256.123456789 /tmp/system.bak；再用srvctl remove mgmtdb -f && srvctl add mgmtdb，最后手动调整db_create_file_dest指向新磁盘组
CKPT: waiting for archivelog，却能让整个集群心跳失步。排查时别只盯ora.mgmtdb进程是否存在，得顺着ora.crf资源依赖链，一层层查到底层存储和ASM驱动状态。
