实战过程记录：濒临宕机的业务系统仅优化1个SQL即恢复！！

记录一次真实Oracle系统SQL问题的案例

问题现像：

某客户业务的应用人员找到我，说是重要的业务系统出问题了，今天早上开始就很卡，现在卡到几乎无法工作。

问题的现象如下：

前台窗口查询啥都半天没有返回结果，多数都会弹出快照过旧的报错。

他们进行了 观察，发现数据库RAC实例1节点的UNDO满了，2节点的没有满。

他们尝试了自己扩容一下RAC1节点的UNDO，但是扩了好久也没有成功。

于是做为一名啥都得会一点的打工人被撵上架来处理。。。。。

基本环境：

运行这套数据库系统的硬件是Oracle的小机，这套RAC实例虽说分的资源不是最多，但是也不少了

2个RAC节点的配置如下：

操作系统：solaris 11.3

数据库版本：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;

查看一下返回结果，基本都是同1个SQL_ID的SQL搞的

这与AWR里的等待事件也吻合，主要的原因还是I/O问题导致的。

使用SQL DEVELOPER实例查看器查看，系统主要是卡在user i/o这个等待事件。

使用“实时SQL监视”工具查看，后台果然还是一直在跑这个SQL，任务一大堆，等待时间相当的长

确定问题SQL

select count(*) from wh53 where sjbbh=:1

查看一下这个SQL的执行计划，又是全表扫描，看样子就是缺少关键字段索引导致的，1个SQL查询的IO居然有41G，我这HPE 3PAR 20000全闪存的阵列都给干趴下了！

看一下这个表的行数，1亿7千5百万行左右的堆表。

这个简单，SQL优化工具都不用了，直接联系开发，告诉他们SJBBH这个字段没有索引，需要添加一下，并告诉他们添加索引的时候一定要加online。

添加完我再看，他这个表索引还不少，估计没有几个能用上的。。。

这次添加完再看执行计划，己经走了索引

之后服务器的CPU负载也慢慢的下来了。最后系统恢复了正常。

总结：

这个问题不算复杂，很容易就能发现是索引的问题，但这个问题是十分的经典。

一条有问题的SQL，再牛的服务器存储也挺不住，新需求不要草草上线，数据量稍微一大，一点失误就干瘫痪。

也欢迎关注我的公众号【徐sir的IT之路】，一起学习！

————————————————————————————
公众号：徐sir的IT之路
优快云 ：徐sir（徐慧阳）-优快云博客
墨天轮：徐sir的个人主页 - 墨天轮
PGFANS：PGFans问答社区:全球唯一的PostgreSQL中文技术交流社区

————————————————————————————