Oracle报错|数据库故障 ORA-32059:deadlock detected on mapping structures 远程修复处理方法

数据库卡死了？ORA-32059死锁报错远程修复指南

场景还原：
凌晨3点，你正睡得香甜，突然手机疯狂震动——监控系统报警："ORA-32059: deadlock detected on mapping structures"，生产库卡死了！客户投诉电话一个接一个，而你只能穿着睡衣盯着屏幕干瞪眼...别慌，这份实战指南能帮你远程灭火。

先搞清楚发生了什么

这个报错直白得很——Oracle在内存映射结构上检测到了死锁（就像两个人互相拽着对方的衣领谁也不松手），常见于：

• 多个会话同时争抢内存资源
• 系统负载激增时（比如月初批量任务扎堆）
• 内存参数配置不合理

紧急止血三步走

第一步：快速释放当前死锁

连上数据库执行：

-- 查看阻塞会话  
SELECT * FROM v$session WHERE blocking_session IS NOT NULL;  
-- 强制终止最占资源的会话（慎用！先确认业务影响）  
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;  

小技巧：用v$sqlarea定位正在执行的SQL，优先杀长时间运行的会话。

第二步：调整关键参数（临时方案）

修改内存参数缓解争抢：

ALTER SYSTEM SET "_kgl_latch_count"=32 SCOPE=MEMORY;  -- 默认8，可适当增加  
ALTER SYSTEM SET "_db_block_hash_latches"=1024 SCOPE=MEMORY; -- 默认CPU数×8  

注意：带下划线的参数是隐藏参数，建议先测试环境验证。

第三步：收集证据供后续分析

-- 抓取死锁trace文件  
ALTER SYSTEM SET EVENTS '32059 trace name errorstack level 3';  
-- 生成AWR报告（包含1小时内的性能数据）  
@?/rdbms/admin/awrrpt.sql  

文件默认在udump目录，用FTP拖回本地分析。

根治方案（天亮后必做）

1. 优化SQL：
   90%的死锁源于烂SQL，重点检查：

   • 全表扫描（TABLE ACCESS FULL执行计划）
   • 缺失索引的外键关联
   • 嵌套循环连接大表

2. 内存调优：

   -- 调整共享池（根据AWR报告的推荐值）  
   ALTER SYSTEM SET shared_pool_size=2G SCOPE=SPFILE;  
   -- 启用内存顾问（11g+）  
   ALTER SYSTEM SET memory_target=4G SCOPE=SPFILE;  

3. 应用层改造：

   

   • 批量作业错峰执行
   • 添加重试机制（特别是短时死锁）
   • 考虑使用NOWAIT选项：

     SELECT * FROM orders FOR UPDATE NOWAIT;  

避坑指南

• 千万别做的事：

  • 直接重启数据库（可能引发数据不一致）
  • 盲目调整_kgl_latch_count超过CPU核数×4
  • 忽略警告日志中的前驱报错（ORA-04031等）

• 远程操作必备工具：

  • SQL*Plus（比GUI工具更可靠）
  • 终端复用工具（比如tmux防断连）
  • 预先准备好的应急脚本

最后提醒：如果死锁频繁发生（每周超过2次），强烈建议联系Oracle支持分析核心转储文件，毕竟有些深层bug（比如19c的某些版本的内存管理缺陷）需要打补丁才能解决。

本文方法基于Oracle 12c至21c版本验证，部分参数在10g中可能不存在，实际操作前请确认数据库版本。