记录一次真实Oracle系统SQL问题的案例
问题现像:
某客户业务的应用人员找到我,说是重要的业务系统出问题了,今天早上开始就很卡,现在卡到几乎无法工作。
前台窗口查询啥都半天没有返回结果,多数都会弹出快照过旧的报错。
他们进行了 观察,发现数据库RAC实例1节点的UNDO满了,2节点的没有满。
他们尝试了自己扩容一下RAC1节点的UNDO,但是扩了好久也没有成功。
基本环境:
运行这套数据库系统的硬件是Oracle的小机,这套RAC实例虽说分的资源不是最多,但是也不少了
数据库版本:oracle 12.2 CDB
LDM配置:VCUPU=224、VRAM=448G、SWAP=60G
存储空间20T,HPE 3PAR 20000系列存储,全闪SSD。服务器配置了6*16GB端口HBA。
解决过程:
连上VPN,登录系统一看资源情况,好家伙!CPU的负载50多,一直持续很长时间
于是我用Oracle sqldeveloper 登录到数据库,查询一下时间段SQL等待事件情况
SELECT trunc(sample_time, 'mi') tm, sql_id, nvl(event,'CPU'),count(distinct session_id) cnt
FROM dba_hist_active_sess_history
WHERE sample_time>=to_date('2024-1-39 09:00:00','yyyy-mm-dd hh24:mi:ss')
AND sample_time<=to_date('2024-1-30 14:00:00','yyyy-mm-dd hh24:mi:ss')
GROUP BY trunc(sample_time, 'mi'), sql_id,nvl(event,'CPU')
ORDER BY cnt desc;
这与AWR里的等待事件也吻合,主要的原因还是I/O问题导致的。
使用SQL DEVELOPER实例查看器查看,系统主要是卡在user i/o这个等待事件。
使用“实时SQL监视”工具查看,后台果然还是一直在跑这个SQL,任务一大堆,等待时间相当的长
select count(*) from wh53 where sjbbh=:1
查看一下这个SQL的执行计划,又是全表扫描,看样子就是缺少关键字段索引导致的,1个SQL查询的IO居然有41G,我这HPE 3PAR 20000全闪存的阵列都给干趴下了!
这个简单,SQL优化工具都不用了,直接联系开发,告诉他们SJBBH这个字段没有索引,需要添加一下,并告诉他们添加索引的时候一定要加online。
添加完我再看,他这个表索引还不少,估计没有几个能用上的。。。
总结:
这个问题不算复杂,很容易就能发现是索引的问题,但这个问题是十分的经典。
一条有问题的SQL,再牛的服务器存储也挺不住,新需求不要草草上线,数据量稍微一大,一点失误就干瘫痪。
也欢迎关注我的公众号【徐sir的IT之路】,一起学习!
————————————————————————————
公众号:徐sir的IT之路
CSDN :徐sir(徐慧阳)-CSDN博客
墨天轮:徐sir的个人主页 - 墨天轮
PGFANS:PGFans问答社区:全球唯一的PostgreSQL中文技术交流社区
————————————————————————————