1. 理解ASH与System State Dump的核心价值当Oracle数据库出现系统级挂起HANG时传统的AWR报告往往难以捕捉瞬时状态而ASHActive Session History和System State Dump的组合分析就像给数据库做了一次急诊CT扫描。ASH以每秒一次的频率采样活动会话记录等待事件和SQL执行细节System State Dump则是挂起时刻的完整内存快照包含所有进程的调用栈和资源争用情况。两者结合使用时ASH提供时间线上的异常趋势System State Dump则锁定具体阻塞点——这好比用ASH发现病人何时开始发烧再用System State Dump定位哪个器官在发炎。实际案例中我曾遇到一个生产库每小时发生3-5分钟的全局卡顿。单独看ASH报告只能看到enq: TX - row lock contention等待事件激增但结合System State Dump分析后发现是某个批处理作业未提交事务导致锁链式阻塞。这种组合诊断方式将问题定位时间从平均4小时缩短到20分钟。2. 采集诊断数据的实战操作2.1 触发System State Dump的标准方法当数据库无响应时通过oradebug命令获取System State Dump是最可靠的方式。具体操作步骤如下-- 使用sysdba连接数据库 sqlplus / as sysdba -- 设置跟踪文件标识便于后续查找 oradebug setmypid oradebug unlimit oradebug dump systemstate 266 oradebug dump systemstate 266 -- 连续执行两次确保完整 oradebug tracefile_name -- 获取生成的trace文件路径注意266是Oracle内部的事件编号代表生成包含所有进程状态的完整dump。在RAC环境中需要对所有节点执行该操作。2.2 智能捕获ASH数据的技巧理想的ASH数据应覆盖挂起前后各15分钟。如果数据库尚未完全挂死可通过以下SQL提取关键时段数据-- 查询最近1小时ASH数据 SELECT sample_time, session_id, session_serial#, program, event, blocking_session, sql_id FROM v$active_session_history WHERE sample_time BETWEEN SYSDATE-1/24 AND SYSDATE ORDER BY sample_time;对于已挂死的数据库需要依赖MMNL进程自动写入磁盘的ASH数据默认位于$ORACLE_BASE/diag/rdbms/DB_NAME/trace/目录下。关键参数_ash_size控制内存中保留的ASH记录数建议生产环境设置为4MB以上。3. 深度解析诊断数据的四步法3.1 关联ASH与System State Dump的时间线首先在ASH报告中定位性能劣化的精确时间点。例如下图显示10:15:23开始出现大量latch free等待SAMPLE_TIME | EVENT | COUNT(*) ------------------|---------------|--------- 10:15:20 | db file read | 12 10:15:23 | latch free | 87然后在System State Dump中搜索对应时间戳附近的进程状态。使用grep命令快速定位关键信息grep -A 20 PROCESS pid systemstate_12345.trc3.2 分析阻塞链Blocking Chain在System State Dump中查找BLOCKED状态进程典型模式如下PROCESS 25: status: BLOCKED wait_event: enq: TX - row lock contention call_stack: kslgetl()128 ksqcmi()317 ksqgtlctx()239此时需要向上追踪blocking_session字段直到找到根阻塞进程。ASH报告的Blocking Sessions部分可直接显示这种关系。3.3 检查闩锁Latch争用当ASH显示latch free等待时在System State Dump中搜索LATCH关键字LATCH #123: cache buffers chains Holder: PROCESS 18 Waiters: PROCESS 25, PROCESS 31配合v$latch_children查询可定位热点缓冲区链SELECT child#, gets, sleeps FROM v$latch_children WHERE name cache buffers chains ORDER BY sleeps DESC;3.4 识别SQL语句与执行计划从ASH中提取高频SQL_ID结合System State Dump中的调用栈分析SELECT sql_text FROM v$sql WHERE sql_id g8v7j9h5q3k2m;对于长时间运行的SQL检查其执行计划是否发生变化SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(g8v7j9h5q3k2m));4. 典型故障场景的破解之道4.1 案例一TX锁级联阻塞现象ASH显示enq: TX等待激增System State Dump发现多个BLOCKED进程。根因分析查找持有TX锁最久的进程ASH的blocking_session历时图检查该进程的SQL是否为未提交的DML操作确认事务隔离级别READ COMMITTED vs SERIALIZABLE解决方案-- 查询阻塞会话详情 SELECT sid, serial#, username, osuser, machine, program FROM v$session WHERE sid IN (SELECT blocking_session FROM v$session WHERE statusACTIVE); -- 必要时终止阻塞进程 ALTER SYSTEM KILL SESSION sid,serial# IMMEDIATE;4.2 案例二共享池争用现象ASH显示library cache lock等待System State Dump中大量进程卡在kglpnc()调用。根因分析检查硬解析率AWR报告的Load Profile确认是否存在SQL未使用绑定变量检查共享池大小是否合理解决方案-- 扩容共享池 ALTER SYSTEM SET shared_pool_size2G SCOPEBOTH; -- 查找未绑定变量SQL SELECT sql_text, executions FROM v$sql WHERE executions1 ORDER BY last_active_time DESC;5. 高级技巧与工具链整合5.1 使用HANGANALYZE增强诊断在Oracle 11g及以上版本HANGANALYZE命令能自动生成更结构化的挂起分析报告oradebug setmypid oradebug unlimit oradebug hanganalyze 3 -- 级别3包含详细进程依赖 oradebug tracefile_name报告中的Chain Graph部分会可视化显示阻塞关系例如Chain 1: Oracle process 25 (PID 12345) - waits for enq: TX held by process 18 - which waits for db file scattered read5.2 自动化诊断脚本开发以下脚本可自动提取关键诊断信息#!/bin/bash # 抓取ASH数据 sqlplus -S / as sysdba EOF spool ash_report.html ?/rdbms/admin/ashrpt.sql spool off EOF # 分析System State Dump grep -E BLOCKED|WAITING|HOLDER $TRACE_FILE | awk /PROCESS/ {pid$2} /BLOCKED/ {print pid is blocked by $NF} /HOLDER/ {print pid holds resource needed by others} 5.3 诊断仓库的建立建议定期归档ASH数据以便历史分析-- 创建ASH历史表 CREATE TABLE ash_history AS SELECT * FROM v$active_session_history WHERE 10; -- 设置定时任务每小时归档 BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name ARCHIVE_ASH, job_type PLSQL_BLOCK, job_action INSERT INTO ash_history SELECT * FROM v$active_session_history WHERE sample_time SYSDATE-1/24, repeat_interval FREQHOURLY, enabled TRUE); END;我在实际运维中总结出一个经验法则当ASH报告显示超过10%的会话处于非空闲等待状态就应该立即触发System State Dump采集。这就像汽车的机油压力警告灯——等到数据库完全挂死再处理恢复成本会呈指数级增长。 
长河君 · 2026/10/26 10:47:25 · 阅读 1.2k Oracle数据库HANG分析：ASH与System State Dump实战指南
1. 理解ASH与System State Dump的核心价值当Oracle数据库出现系统级挂起HANG时传统的AWR报告往往难以捕捉瞬时状态而ASHActive Session History和System State Dump的组合分析就像给数据库做了一次急诊CT扫描。ASH以每秒一次的频率采样活动会话记录等待事件和SQL执行细节System State Dump则是挂起时刻的完整内存快照包含所有进程的调用栈和资源争用情况。两者结合使用时ASH提供时间线上的异常趋势System State Dump则锁定具体阻塞点——这好比用ASH发现病人何时开始发烧再用System State Dump定位哪个器官在发炎。实际案例中我曾遇到一个生产库每小时发生3-5分钟的全局卡顿。单独看ASH报告只能看到enq: TX - row lock contention等待事件激增但结合System State Dump分析后发现是某个批处理作业未提交事务导致锁链式阻塞。这种组合诊断方式将问题定位时间从平均4小时缩短到20分钟。2. 采集诊断数据的实战操作2.1 触发System State Dump的标准方法当数据库无响应时通过oradebug命令获取System State Dump是最可靠的方式。具体操作步骤如下-- 使用sysdba连接数据库 sqlplus / as sysdba -- 设置跟踪文件标识便于后续查找 oradebug setmypid oradebug unlimit oradebug dump systemstate 266 oradebug dump systemstate 266 -- 连续执行两次确保完整 oradebug tracefile_name -- 获取生成的trace文件路径注意266是Oracle内部的事件编号代表生成包含所有进程状态的完整dump。在RAC环境中需要对所有节点执行该操作。2.2 智能捕获ASH数据的技巧理想的ASH数据应覆盖挂起前后各15分钟。如果数据库尚未完全挂死可通过以下SQL提取关键时段数据-- 查询最近1小时ASH数据 SELECT sample_time, session_id, session_serial#, program, event, blocking_session, sql_id FROM v$active_session_history WHERE sample_time BETWEEN SYSDATE-1/24 AND SYSDATE ORDER BY sample_time;对于已挂死的数据库需要依赖MMNL进程自动写入磁盘的ASH数据默认位于$ORACLE_BASE/diag/rdbms/DB_NAME/trace/目录下。关键参数_ash_size控制内存中保留的ASH记录数建议生产环境设置为4MB以上。3. 深度解析诊断数据的四步法3.1 关联ASH与System State Dump的时间线首先在ASH报告中定位性能劣化的精确时间点。例如下图显示10:15:23开始出现大量latch free等待SAMPLE_TIME | EVENT | COUNT(*) ------------------|---------------|--------- 10:15:20 | db file read | 12 10:15:23 | latch free | 87然后在System State Dump中搜索对应时间戳附近的进程状态。使用grep命令快速定位关键信息grep -A 20 PROCESS pid systemstate_12345.trc3.2 分析阻塞链Blocking Chain在System State Dump中查找BLOCKED状态进程典型模式如下PROCESS 25: status: BLOCKED wait_event: enq: TX - row lock contention call_stack: kslgetl()128 ksqcmi()317 ksqgtlctx()239此时需要向上追踪blocking_session字段直到找到根阻塞进程。ASH报告的Blocking Sessions部分可直接显示这种关系。3.3 检查闩锁Latch争用当ASH显示latch free等待时在System State Dump中搜索LATCH关键字LATCH #123: cache buffers chains Holder: PROCESS 18 Waiters: PROCESS 25, PROCESS 31配合v$latch_children查询可定位热点缓冲区链SELECT child#, gets, sleeps FROM v$latch_children WHERE name cache buffers chains ORDER BY sleeps DESC;3.4 识别SQL语句与执行计划从ASH中提取高频SQL_ID结合System State Dump中的调用栈分析SELECT sql_text FROM v$sql WHERE sql_id g8v7j9h5q3k2m;对于长时间运行的SQL检查其执行计划是否发生变化SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(g8v7j9h5q3k2m));4. 典型故障场景的破解之道4.1 案例一TX锁级联阻塞现象ASH显示enq: TX等待激增System State Dump发现多个BLOCKED进程。根因分析查找持有TX锁最久的进程ASH的blocking_session历时图检查该进程的SQL是否为未提交的DML操作确认事务隔离级别READ COMMITTED vs SERIALIZABLE解决方案-- 查询阻塞会话详情 SELECT sid, serial#, username, osuser, machine, program FROM v$session WHERE sid IN (SELECT blocking_session FROM v$session WHERE statusACTIVE); -- 必要时终止阻塞进程 ALTER SYSTEM KILL SESSION sid,serial# IMMEDIATE;4.2 案例二共享池争用现象ASH显示library cache lock等待System State Dump中大量进程卡在kglpnc()调用。根因分析检查硬解析率AWR报告的Load Profile确认是否存在SQL未使用绑定变量检查共享池大小是否合理解决方案-- 扩容共享池 ALTER SYSTEM SET shared_pool_size2G SCOPEBOTH; -- 查找未绑定变量SQL SELECT sql_text, executions FROM v$sql WHERE executions1 ORDER BY last_active_time DESC;5. 高级技巧与工具链整合5.1 使用HANGANALYZE增强诊断在Oracle 11g及以上版本HANGANALYZE命令能自动生成更结构化的挂起分析报告oradebug setmypid oradebug unlimit oradebug hanganalyze 3 -- 级别3包含详细进程依赖 oradebug tracefile_name报告中的Chain Graph部分会可视化显示阻塞关系例如Chain 1: Oracle process 25 (PID 12345) - waits for enq: TX held by process 18 - which waits for db file scattered read5.2 自动化诊断脚本开发以下脚本可自动提取关键诊断信息#!/bin/bash # 抓取ASH数据 sqlplus -S / as sysdba EOF spool ash_report.html ?/rdbms/admin/ashrpt.sql spool off EOF # 分析System State Dump grep -E BLOCKED|WAITING|HOLDER $TRACE_FILE | awk /PROCESS/ {pid$2} /BLOCKED/ {print pid is blocked by $NF} /HOLDER/ {print pid holds resource needed by others} 5.3 诊断仓库的建立建议定期归档ASH数据以便历史分析-- 创建ASH历史表 CREATE TABLE ash_history AS SELECT * FROM v$active_session_history WHERE 10; -- 设置定时任务每小时归档 BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name ARCHIVE_ASH, job_type PLSQL_BLOCK, job_action INSERT INTO ash_history SELECT * FROM v$active_session_history WHERE sample_time SYSDATE-1/24, repeat_interval FREQHOURLY, enabled TRUE); END;我在实际运维中总结出一个经验法则当ASH报告显示超过10%的会话处于非空闲等待状态就应该立即触发System State Dump采集。这就像汽车的机油压力警告灯——等到数据库完全挂死再处理恢复成本会呈指数级增长。