数据库hang住现象解析与实战解决方案

1. 数据库hang住现象解析

数据库hang住是指数据库系统突然停止响应，无法处理新的请求，但进程仍然存在的一种异常状态。这种情况在实际运维中相当常见，特别是在高并发或复杂业务场景下。根据我多年处理数据库问题的经验，hang住通常表现为以下几种症状：

• 前端应用长时间等待数据库响应
• 数据库管理工具连接超时
• 简单查询也无法返回结果
• 系统监控显示数据库进程CPU占用率异常（可能极高或为零）

1.1 常见hang住原因分析

导致数据库hang住的原因多种多样，但主要可以归纳为以下几类：

锁等待问题：

• 事务锁未释放导致的死锁
• 长时间运行的事务占用关键资源
• 不合理的锁升级（如行锁升级为表锁）

资源耗尽：

• 内存耗尽（特别是SGA/PGA区域）
• 临时表空间不足
• 磁盘I/O达到瓶颈
• CPU资源被长时间占用

系统级问题：

• 操作系统资源限制
• 存储子系统故障
• 网络连接问题

提示：在实际排查时，建议按照"锁等待→资源使用→系统状态"的顺序进行检查，这个顺序符合大多数hang住问题的发生概率。

2. 诊断数据库hang住的实战方法

2.1 基础诊断工具使用

当数据库出现hang住时，首先需要通过系统级工具获取整体状态：

# Linux系统下查看资源使用情况 top -c -d 2 # 重点关注CPU的wa（I/O等待）指标和内存使用情况 # 查看磁盘I/O状态 iostat -x 2

对于Oracle数据库，最常用的诊断视图包括：

-- 查看锁等待情况 SELECT * FROM v$lock WHERE block = 1; -- 查看长时间运行的会话 SELECT s.sid, s.serial#, s.username, s.status, s.seconds_in_wait, s.event, s.sql_id FROM v$session s WHERE s.status = 'ACTIVE' AND s.seconds_in_wait > 60;

2.2 高级诊断技巧

等待事件分析： Oracle数据库的等待事件是诊断性能问题的金钥匙。重点关注以下等待事件：

• enq: TX - row lock contention（行锁争用）
• enq: TM - contention（表锁争用）
• log file sync（日志文件同步）
• db file sequential read（数据文件顺序读）

-- 查看当前等待事件 SELECT event, count(*) FROM v$session_wait WHERE wait_class != 'Idle' GROUP BY event ORDER BY count(*) DESC;

ASH（Active Session History）分析： 对于间歇性hang住问题，ASH数据特别有价值：

-- 查询过去15分钟内最耗资源的SQL SELECT sample_time, session_id, sql_id, event, blocking_session FROM dba_hist_active_sess_history WHERE sample_time > SYSDATE - 15/1440 ORDER BY sample_time DESC;

3. 常见hang住场景的解决方案

3.1 锁等待问题处理

死锁处理流程：

1. 识别被阻塞的会话：

SELECT blocking_session, sid, serial#, wait_class, seconds_in_wait FROM v$session WHERE blocking_session IS NOT NULL;

2. 获取锁详细信息：

SELECT lo.session_id, do.object_name, lo.oracle_username, lo.os_user_name, lo.process, lo.locked_mode FROM v$locked_object lo, dba_objects do WHERE lo.object_id = do.object_id;

3. 终止问题会话：

-- Oracle级别终止会话 ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; -- 系统级别终止（获取OS PID后） SELECT spid FROM v$process WHERE addr = (SELECT paddr FROM v$session WHERE sid = &sid); -- 然后在操作系统执行 kill -9 <spid>

注意：直接kill会话可能导致事务回滚时间过长，在生产环境谨慎使用。建议先尝试联系会话所有者正常结束操作。

3.2 资源耗尽问题处理

内存问题处理：

• 检查SGA/PGA使用情况：

SELECT * FROM v$sga_dynamic_components; SELECT * FROM v$pgastat;

• 临时表空间扩展：

-- 查看临时表空间使用 SELECT tablespace_name, bytes_used, bytes_free FROM v$temp_space_header; -- 添加临时文件 ALTER TABLESPACE TEMP ADD TEMPFILE '/path/to/temp02.dbf' SIZE 2G;

I/O性能问题：

• 识别热点数据文件：

SELECT file#, phyrds, phywrts, phyblkrd, phyblkwrt FROM v$filestat fs, v$datafile df WHERE fs.file# = df.file# ORDER BY phyrds + phywrts DESC;

• 解决方案包括：
  • 优化SQL减少物理I/O
  • 考虑使用SSD存储
  • 调整DBWR进程参数

4. 预防数据库hang住的最佳实践

4.1 监控体系建设

建立完善的监控体系可以提前发现潜在问题：

关键监控指标：

• 锁等待数量和时间
• 内存使用率（特别是PGA）
• 临时表空间使用率
• 磁盘I/O延迟
• 活跃会话数

推荐监控工具：

• Oracle Enterprise Manager
• Prometheus + Grafana（配合oracle_exporter）
• 自定义脚本定期采集关键指标

4.2 日常维护建议

1. SQL审核：

   • 所有上线的SQL都应经过性能评审
   • 特别注意全表扫描、大表连接等操作

2. 定期统计信息收集：

-- 自动收集统计信息设置 EXEC DBMS_STATS.SET_GLOBAL_PREFS('AUTOSTATS_TARGET','ORACLE');

3. 资源限制配置：

-- 设置用户资源限制 CREATE PROFILE app_user LIMIT SESSIONS_PER_USER 10 CPU_PER_SESSION 10000 LOGICAL_READS_PER_SESSION DEFAULT CONNECT_TIME 60 IDLE_TIME 15;

4. 定期健康检查：

-- AWR报告分析 @?/rdbms/admin/awrrpt.sql -- ADDM报告分析 @?/rdbms/admin/addmrpt.sql

5. 疑难hang住问题处理案例

5.1 日志切换导致的hang住

现象： 数据库周期性hang住，每次持续约1-2分钟，AWR报告显示大量"log file switch"等待。

分析： 检查日志组配置和切换频率：

SELECT group#, bytes, members, status, archived FROM v$log; SELECT to_char(first_time, 'YYYY-MM-DD HH24:MI'), count(*) switches_per_hour FROM v$log_history GROUP BY to_char(first_time, 'YYYY-MM-DD HH24:MI') ORDER BY 1;

解决方案：

• 增加日志组数量（从3组增加到5组）
• 增大日志文件大小（从200M增加到1G）
• 优化提交频率（避免过于频繁的commit）

5.2 RAC环境下的实例hang住

现象： RAC环境中一个实例hang住，其他实例运行正常。

诊断步骤：

1. 检查实例间通信：

SELECT * FROM gv$instance;

2. 查看集群资源状态：

crsctl status resource -t

3. 检查等待事件：

SELECT inst_id, event, count(*) FROM gv$session_wait WHERE wait_class != 'Idle' GROUP BY inst_id, event ORDER BY inst_id, count(*) DESC;

解决方案：

• 调整LMON进程参数
• 优化私网连接（增加带宽、减少延迟）
• 检查ASM磁盘组状态

6. 高级工具与技巧

6.1 使用ORADEBUG进行深度诊断

对于复杂的hang住问题，可能需要使用ORADEBUG工具：

-- 获取系统状态转储 ORADEBUG setmypid ORADEBUG unlimit ORADEBUG dump systemstate 10

6.2 分析hang分析工具（HANGANALYZE）

Oracle提供的专门工具用于分析hang住问题：

-- 执行hang分析 ORADEBUG setmypid ORADEBUG hanganalyze 3

6.3 使用SQLT进行问题诊断

SQLT（SQLT XTRACT）是Oracle提供的强大诊断工具：

-- 获取SQLT脚本 @sqlt/install/sqcreate.sql -- 针对问题SQL收集诊断信息 SQL> START sqltxtract.sql [SQL_ID]

在实际处理数据库hang住问题时，保持冷静、系统性地收集证据是关键。我建议建立自己的诊断检查清单，按照"现象观察→数据收集→问题定位→解决方案→验证效果"的标准流程操作。每次处理完问题后记录详细的过程和解决方案，这些经验在未来遇到类似问题时将非常宝贵。