1. 数据库hang住现象解析与应急处理数据库hang住挂起是DBA日常运维中最棘手的故障之一表现为数据库实例无响应、会话长时间阻塞、前端应用持续等待。根据Oracle官方文档定义当数据库进程因资源争用或内部错误无法继续执行时即进入hang状态。不同于简单的性能下降hang住意味着事务链的完全中断。1.1 典型症状识别通过Linux系统监控可观察到以下特征组合CPU利用率异常要么接近0%要么100%I/O wait持续超过30%通过top命令查看%wa指标数据库警报日志出现ORA-00060: deadlock detected或WAITED TOO LONG FOR A RESOURCE类错误V$SESSION_WAIT视图显示大量会话处于enq: TX - row lock contention等待事件注意单纯的CPU高负载不一定是hang住需结合等待事件判断。我曾遇到一个案例RAC环境中一个节点hang住时反而显示CPU利用率下降这是因为集群服务已停止工作。1.2 紧急处理四步法当确认hang住发生后建议按以下优先级操作会话级清理最快恢复业务-- 查询阻塞会话链 WITH blocking_sessions AS ( SELECT sid, serial#, username, ROW_NUMBER() OVER (ORDER BY level) as chain_level, CONNECT_BY_ROOT sid as root_blocker FROM v$session WHERE blocking_session IS NOT NULL CONNECT BY PRIOR sid blocking_session START WITH blocking_session IS NULL ) SELECT * FROM blocking_sessions; -- 终止最上层阻塞会话需DBA权限 ALTER SYSTEM KILL SESSION sid,serial# IMMEDIATE;系统级清理当Oracle级kill失效时-- 获取操作系统进程ID SELECT p.spid, s.sid, s.serial#, s.program FROM v$session s JOIN v$process p ON s.paddr p.addr WHERE s.sid [被阻塞会话ID]; -- 在操作系统执行需root权限 kill -9 [spid]服务重启最后手段# Oracle重启步骤 sqlplus / as sysdba EOF shutdown abort startup EOF事后分析防止复发-- 捕获历史阻塞信息 SELECT * FROM dba_hist_active_sess_history WHERE sample_time SYSDATE-1/24 AND event LIKE enq:%;2. 根因分析与深度排查2.1 锁争用场景剖析根据Oracle内部锁机制最常见的hang住场景涉及以下锁类型锁类型等待事件典型场景解决方案TX行锁enq: TX - row lock contention并发更新同数据行优化事务粒度TM表锁enq: TM - contentionDDL与DML并发避免业务高峰执行DDLCF控制文件锁enq: CF - contention控制文件同步增加控制文件副本我曾处理过一个电商系统案例凌晨批量订单处理时频繁hang住。最终发现是库存扣减存储过程未提交事务导致TX锁雪崩。通过以下查询定位到问题SQLSELECT s.sid, s.serial#, s.sql_id, sq.sql_text, s.blocking_session, s.seconds_in_wait FROM v$session s JOIN v$sql sq ON s.sql_id sq.sql_id WHERE s.status ACTIVE AND s.wait_class ! Idle ORDER BY s.seconds_in_wait DESC;2.2 系统资源瓶颈非锁导致的hang住往往与底层资源相关内存问题诊断-- PGA内存压力检查 SELECT name, value/1024/1024 as size_mb FROM v$pgastat WHERE name IN (total PGA allocated,total PGA inuse); -- 共享池碎片化检查 SELECT free_space/total_space*100 as frag_percent FROM v$sgastat WHERE pool shared pool AND name free memory;存储I/O问题诊断# Linux层I/O监控需root iostat -xm 2 # 关键指标 # %util 70% 表示磁盘饱和 # await 20ms 表示延迟过高3. 防御性设计与自动化处理3.1 参数调优建议根据不同的工作负载特性推荐调整以下参数OLTP系统-- 减少锁等待超时默认300秒过长 ALTER SYSTEM SET _kgl_time_to_wait_for_locks60 SCOPEBOTH; -- 增强死锁检测频率 ALTER SYSTEM SET _deadlock_detection_time3 SCOPESPFILE;数据仓库系统-- 增加临时表空间组 ALTER TABLESPACE TEMP ADD TEMPFILE /path/to/temp02.dbf SIZE 10G; -- 优化排序内存 ALTER SYSTEM SET pga_aggregate_target8G SCOPESPFILE;3.2 监控体系搭建推荐部署以下监控脚本锁等待实时报警-- 创建自定义指标 BEGIN DBMS_SERVER_ALERT.SET_THRESHOLD( metrics_id DBMS_SERVER_ALERT.ELAPSED_TIME_PER_CALL, warning_operator DBMS_SERVER_ALERT.OPERATOR_GE, warning_value 5, critical_operator DBMS_SERVER_ALERT.OPERATOR_GE, critical_value 30, observation_period 1, consecutive_occurrences 3, instance_name NULL, object_type DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE, object_name SYS$USERS); END; / -- 创建自动化处理Job DBMS_SCHEDULER.CREATE_JOB ( job_name AUTO_KILL_BLOCKERS, job_type PLSQL_BLOCK, job_action BEGIN FOR r IN (SELECT sid,serial# FROM v$session WHERE blocking_session IS NULL AND wait_time 300) LOOP EXECUTE IMMEDIATE ALTER SYSTEM KILL SESSION ||r.sid||,||r.serial#|| IMMEDIATE; END LOOP; END;, start_date SYSTIMESTAMP, repeat_interval FREQMINUTELY;INTERVAL5, enabled TRUE);4. 经典案例复盘4.1 存储过程死循环某物流系统凌晨ETL任务导致数据库hang住特征为每小时新增50个僵死会话所有会话执行相同SQL语句锁等待链呈放射状分布根本原因是存储过程的异常处理逻辑缺陷CREATE OR REPLACE PROCEDURE process_orders AS CURSOR c_orders IS SELECT * FROM pending_orders WHERE statusNEW; BEGIN FOR r IN c_orders LOOP UPDATE orders SET statusPROCESSING WHERE order_idr.order_id; -- 缺少异常处理导致失败时继续循环 COMMIT; END LOOP; END;解决方案增加显式异常处理添加乐观锁控制限制最大重试次数4.2 RAC脑裂场景某银行系统Oracle RAC集群频繁hang住表现为节点间心跳中断gnsd进程CPU占用100%大量IPC等待事件根本原因是网络交换机MTU设置不一致导致大包分片。通过以下命令验证# 检查集群网络状态 crsctl check cluster -all # 测试节点间通讯 cluvfy comp nodecon -n all -verbose最终解决方案统一配置交换机MTU为9000调整RAC私网参数ALTER SYSTEM SET cluster_interconnectseth1:9000 SCOPESPFILE;对于关键业务系统建议在开发阶段就引入锁等待分析工具如Oracle SQL Developer的Database Monitor功能可以图形化展示实时锁依赖关系。另外定期进行负载测试时使用AWR报告的Top Blocking Sessions部分作为重点检查项。