如何快速诊断Oracle性能问题?

一、性能类故障标准处理思路

核心原则:先宏观 → 再微观 → 抓现场数据 → 定位根因

  1. 先了解全局背景(不登录数据库也能做)
    主机配置:CPU、内存、磁盘、网卡规格
    业务架构:应用 → 中间件 → 数据库拓扑
    近期变更:发布、扩容、流量突增、数据量暴涨、配置修改
  2. 检查主机操作系统资源
    使用 Linux 命令排查CPU/IO/ 内存瓶颈:
    bash
    运行

1. 看CPU、进程负载

top

2. 看CPU上下文切换、运行队列、swap

vmstat 1 10

3. 看磁盘IO瓶颈(最常见性能根因)

iostat -x 1 10

4. 看内存使用

free -h

重点观察 3 个指标:

CPU:运行队列长、% us、% sy 高

IO:% util 接近 100%、await 高、IO 等待严重

内存:swap 频繁交换(性能杀手)

找到耗资源的进程 PID 后,用oradebug 跟踪 SQL:

-- 绑定操作系统进程PID

sql 复制代码
oradebug setospid xxx;
oradebug unlimit;

-- 开启10046 trace(level 12 包含绑定变量+等待事件)

sql 复制代码
oradebug event 10046 trace name context forever, level 12;

-- 关闭trace

sql 复制代码
oradebug event 10046 trace name context off;
  1. 登录数据库,检查会话排队
    核心判断:活动会话数远高于平时 = 性能拥堵

-- 查看当前活动会话

sql 复制代码
select count(*) from v$session where status='ACTIVE' and username is not null;
  1. 查等待事件(最核心诊断视图)

-- 查看当前实时等待事件(性能问题根因90%在这里)

sql 复制代码
select event, count(*) 
from v$session_wait 
where wait_time=0 
group by event 
order by 2 desc;

V$SESSION_WAIT 是 Oracle 性能故障第一现场视图。

  1. 采集性能报告(保留现场证据)

表格

版本 推荐报告

Oracle 9i Statspack(6 级,采样 10 分钟)

Oracle 10g+ AWR 报告 + ASH 报告(10 分钟最佳)

AWR/ASH 优势:未被时间平均,真实反映故障瞬间性能。

  1. 排查外部组件

中间件连接池耗尽

网络延迟、丢包

存储性能瓶颈

二、快速定位资源持有者(锁 / 闩锁 / Mutex 争用)

Oracle 三大资源保护机制:LOCK、LATCH、MUTEX

性能故障本质 = 资源争用 + 等待持有者释放

下面是直接可复制执行的定位脚本:

  1. 定位 LOCK 持有者(表锁、行锁争用)

-- 查出阻塞别人的锁持有者

sql 复制代码
select * from gv$lock where block=1;

-- 查看等待者与持有者对应关系

sql 复制代码
select * from dba_waiters;
  1. 定位 LATCH 持有者
sql 复制代码
select * from v$latchholder;
  1. 定位 MUTEX 持有者(高并发最常见)
    典型等待事件:cursor: pin S wait on X

-- 查 MUTEX 持有者 SID

sql 复制代码
select to_number(substr(to_char(rawtohex(p2raw)),1,8),'XXXXXXXX') sid
from v$session
where event = 'cursor: pin S wait on X';
  1. 定位 Library Cache Lock 持有者
sql 复制代码
select b.sid,a.user_name,a.kglnaobj
from x$kgllk a , v$session b
where a.kgllkhdl in
(select p1raw from v$session_wait
where wait_time=0 and event = 'library cache lock')
and a.kgllkmod <> 0
and b.saddr=a.kgllkuse;
  1. 定位 Library Cache Pin 持有者
sql 复制代码
select sid from x$kglpn , v$session
where KGLPNHDL in
(select p1raw from v$session_wait
where wait_time=0 and event like 'library cache pin%')
and KGLPNMOD <> 0
and v$session.saddr=x$kglpn.kglpnuse;
  1. 定位 Row Cache 持有者
sql 复制代码
select * from v$rowcache_parent where lock_mode<>0;

总结

性能故障处理流程:全局背景 → OS 资源 → 数据库会话 → 等待事件 → 性能报告 → 外部组件

核心视图:v$session_wait(第一现场)

争用根因定位:用脚本快速找到 LOCK/LATCH/MUTEX 持有者

关键动作:故障时必须采集 AWR/ASH,这是定位根因的核心依据

相关推荐
wuqingshun3141591 小时前
MYSQL默认的事务隔离级别是什么?为什么选择这个级别?
数据库·mysql
空中湖1 小时前
电池简史(五):极限之梦与终章——锂硫、锂空气、量子电池,以及你该知道的电池投资与生活指南
数据库·程序人生
蓝胖子酱2 小时前
在 Electron 中用 electron-store 实现加密存储与自定义格式文件
前端·javascript·数据库
snow@li3 小时前
Redis:数据库语法速查表 / 全景梳理
数据库·redis·缓存
Devlive 开源社区3 小时前
Nebula 1.6.0 发布:跨区域桶自动路由、秒传、文本/PDF 预览一次到位
数据库·sql
这个DBA有点耶4 小时前
导个数据中文全变问号?字符集这事儿真没那么简单
数据库·mysql·代码规范
wuqingshun3141594 小时前
MYSQL中如果发生死锁应该如何解决?
数据库·mysql
DO_Community4 小时前
Weaviate 托管数据库现已在 DigitalOcean 上开放公测
数据库·人工智能·开源·向量数据库·weaviate
报错小能手5 小时前
索引常见面试题
数据库
Database_Cool_5 小时前
时序数据库选型:阿里云 Lindorm 时序引擎 vs InfluxDB 全维度对比
数据库·阿里云·时序数据库