Oracle RAC如何通过Systemstate dump分析解决节点间挂起问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计822个文字，预计阅读时间需要4分钟。
相关专题
oracle rac节点间挂起（hang）不能靠重启硬扛，必须用 systemstate dump 定位跨实例的锁等待链和全局缓存争用点——但直接跑 level 266 或 level 267 在老版本（≤11.2.0.2）rac上极易引发数据库级 hang 或 crash。
为什么 RAC 必须用 -g all 而不是单实例执行 systemstate dump
单实例 dump 只能看到本节点进程状态，而 RAC 挂起本质是跨实例的资源死锁或 GC（Global Cache）阻塞，比如实例1在等实例2持有的 block，实例2又在等实例1的 TX 锁。不同时采集所有实例的快照，就拼不出完整等待图。
用 oradebug -g all dump systemstate 258 才能保证各实例 trace 文件时间戳基本一致，后续用 ass109.awk 等工具分析时才不会漏掉关键跳转。
level 258 是 RAC 挂起诊断的“安全档位”
老版本 RAC（≤11.2.0.2）用 level 10、266、267 容易触发 Bug 导致数据库 hang；level 258 是折中方案：
• 比 level 10 多收集 short stack（能看出函数调用栈深度）
• 比 level 266 少 dump lock element data（避免 trace 文件过大、写入卡住）
• 不含 global cache detail（level 256+ 才有），规避了高并发下 GC latch 争用导致的 dump 卡死
• 在 11.2.0.3+ 已修复该问题，但生产环境仍建议默认用 258，除非明确需要 GC 细节
必须搭配 hanganalyze 3 使用
systemstate dump 提供静态快照，hanganalyze 则给出动态等待关系拓扑：
• hanganalyze 3 会输出类似 “PROCESS 1234: waiting for 'gc current block 2-way'” 的链条，直接标出谁在等谁、等什么资源
• 单独看 systemstate 很难快速定位 root blocker，但 hanganalyze 的 summary section 会高亮 top blocker 进程号
• RAC 下必须同样用 oradebug -g all dump hanganalyze 3，否则跨实例等待关系无法关联
• 注意：两次 hanganalyze 间隔至少 60 秒，太快会导致结果失真
连接不上数据库时，sqlplus -prelim / as sysdba 是唯一入口
普通 sqlplus / as sysdba 会尝试建立完整会话，hang 时必然失败；-prelim 模式绕过 SGA 初始化和 session 创建，直连 Oracle 内核：
• 成功后只能执行 oradebug 相关命令，不能查表、不能运行 PL/SQL
• 如果连 -prelim 都失败，说明 instance 已完全 hang 死，需考虑 OS 层 dbx attach 进程调用 ksudss(10)
• set _prelim on 是 SQL*Plus 12c+ 的替代语法，但兼容性不如 -prelim 参数稳定，建议始终用后者
真正难的是从几百MB的 trace 文件里识别出那个反复出现的 gc cr block busy 或 enq: TX - row lock contention 模式——这需要结合 v$lock、gv$session 和 gv$ges_blocking_enqueue 交叉验证，而不是只盯着 dump 本身。
本文共计822个文字，预计阅读时间需要4分钟。
相关专题
oracle rac节点间挂起（hang）不能靠重启硬扛，必须用 systemstate dump 定位跨实例的锁等待链和全局缓存争用点——但直接跑 level 266 或 level 267 在老版本（≤11.2.0.2）rac上极易引发数据库级 hang 或 crash。
为什么 RAC 必须用 -g all 而不是单实例执行 systemstate dump
单实例 dump 只能看到本节点进程状态，而 RAC 挂起本质是跨实例的资源死锁或 GC（Global Cache）阻塞，比如实例1在等实例2持有的 block，实例2又在等实例1的 TX 锁。不同时采集所有实例的快照，就拼不出完整等待图。
用 oradebug -g all dump systemstate 258 才能保证各实例 trace 文件时间戳基本一致，后续用 ass109.awk 等工具分析时才不会漏掉关键跳转。
level 258 是 RAC 挂起诊断的“安全档位”
老版本 RAC（≤11.2.0.2）用 level 10、266、267 容易触发 Bug 导致数据库 hang；level 258 是折中方案：
• 比 level 10 多收集 short stack（能看出函数调用栈深度）
• 比 level 266 少 dump lock element data（避免 trace 文件过大、写入卡住）
• 不含 global cache detail（level 256+ 才有），规避了高并发下 GC latch 争用导致的 dump 卡死
• 在 11.2.0.3+ 已修复该问题，但生产环境仍建议默认用 258，除非明确需要 GC 细节
必须搭配 hanganalyze 3 使用
systemstate dump 提供静态快照，hanganalyze 则给出动态等待关系拓扑：
• hanganalyze 3 会输出类似 “PROCESS 1234: waiting for 'gc current block 2-way'” 的链条，直接标出谁在等谁、等什么资源
• 单独看 systemstate 很难快速定位 root blocker，但 hanganalyze 的 summary section 会高亮 top blocker 进程号
• RAC 下必须同样用 oradebug -g all dump hanganalyze 3，否则跨实例等待关系无法关联
• 注意：两次 hanganalyze 间隔至少 60 秒，太快会导致结果失真
连接不上数据库时，sqlplus -prelim / as sysdba 是唯一入口
普通 sqlplus / as sysdba 会尝试建立完整会话，hang 时必然失败；-prelim 模式绕过 SGA 初始化和 session 创建，直连 Oracle 内核：
• 成功后只能执行 oradebug 相关命令，不能查表、不能运行 PL/SQL
• 如果连 -prelim 都失败，说明 instance 已完全 hang 死，需考虑 OS 层 dbx attach 进程调用 ksudss(10)
• set _prelim on 是 SQL*Plus 12c+ 的替代语法，但兼容性不如 -prelim 参数稳定，建议始终用后者
真正难的是从几百MB的 trace 文件里识别出那个反复出现的 gc cr block busy 或 enq: TX - row lock contention 模式——这需要结合 v$lock、gv$session 和 gv$ges_blocking_enqueue 交叉验证，而不是只盯着 dump 本身。