暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 数据库一体机响应慢问题分析

数据库一体机响应慢问题分析

IT那活儿 2025-08-01
72

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

一

问题现象

大数据侧反馈，某数据库一体机从2月头开始（2月1日-2日），业务反馈数据库执行SQL慢，3月月头（3月1日-3月2日）时数据库再次出现SQL执行慢问题，需要协助进行分析数据库性能问题。
应用侧反馈每天执行的SQL都一样，月头并无特殊的SQL执行。但是周日都会出现慢的问题。例如2月2日，3月2日正好都是周日。随后提供了3月头感知慢的几条SQL，2月28日执行只要几分钟，而3月2日执行要差不多1小时。
二

分析过程及原因

2.1 DBA分析
  • TOP SQL 在平时执行和月头执行时，SQL执行计划相同，但是访问数据量在月头变大； 
  • 访问数据量变大，TOP SQL执行时间变长，速度变慢，消耗IO ；
  • IO开销大，影响整个磁盘的IO访问，平均IO等待时间变长 ；
    IO等待时间变长，导致整个数据库其他SQL执行时，执行速度变慢。
2.1.1 SQL分析
例如开发提供的同样一条慢的SQL，2月28日执行执行耗时2分43秒， 3月2日执行耗时54分39秒，SQL文本如下：
CREATETABLE  NMK.yxkd_accnbr_bind_20250301_temp  TABLESPACE BaS_dBoI COMPRESSFOR ALL OPERATIONSPARALLEL16
SQL的实际执行时间对比：
  • SQL_ID:dw4f1y9d8arxt 2月28日执行 2分钟43秒；
  • SQL_ID:2mz7443f2bga8 3月02日执行 54分钟39秒。
SETLINES300
COL max_time FOR A30
COL exec_time FOR A30
select d.SQL_ID,
         d.SQL_EXEC_START,d.SQL_PLAN_HASH_VALUE,
         max(d.SAMPLE_TIME) max_time,
         (max(d.SAMPLE_TIME) - d.SQL_EXEC_START) exec_time
    from DBA_HIST_ACTIVE_SESS_HISTSQL> ORY d
   where D.SQL_ID in ('dw4f1y9d8arxt','2p5sjz2qfbcuk','2mz7443f2bga8')
     and dbid in (20250301,20250302,20250228)
   groupby d.SQL_ID, d.SQL_EXEC_START,SQL_PLAN_HASH_VALUE
   orderby2;

SQL_ID SQL_EXEC_START SQL_PLAN_HASH_VALUE MAX_TIME EXEC_TIME
------------- ----------------- ------------------- ------------------------------ ------------------------------
dw4f1y9d8arxt 20250228 06:52:13 3969463057 28-FEB-25 06.54.56.552 AM +000000000 00:02:43.552
2p5sjz2qfbcuk 20250301 07:29:54 20620199 01-MAR-25 07.37.54.054 AM +000000000 00:08:00.054
2mz7443f2bga8 20250302 11:03:14 1137030774 02-MAR-25 11.57.53.789 AM +000000000 00:54:39.789
执行计划都相差不大，性能瓶颈都在CUSTGROUP_PROD_MEMBER表上，它作为NEST LOOP的被驱动表，在2月28日，驱动表结果集估算为2573，而3月2日，驱动表结果集估算为3802，驱动表估算行数增加了超过50%，驱动表结果集越大，被驱动表执行次数也就越多。这条SQL被驱动表CUSTGROUP_PROD_MEMBER的扫描次数，3月2日要比2月28日多扫描1229次。
2.1.2 AWR对比分析
1）AWR中的数据库负载报告对比
左侧为2月28日的awr，右侧为3月2日的awr。从报告对比中，可以看到3月2日比2月28日IO量大幅增加。
  • 2月28日执行该类型SQL时
    数据库整体节点1每秒物理读为 67599，IOPS 4088.2次，MBPS 653M。
  • 3月02日执行该类型SQL时
    数据库整体节点1每秒物理读为156591，IOPS 5509.8次,MBPS 1388.9M。
平均每秒物理读的块数，3月2日是2月28日的156591/67599 = 2.32倍；
平均每秒的IOPS次数，3月2日是2月28日的 5509.8/4088.2 = 1.35倍；
平均每秒的IO吞吐量，3月2日是2月28日的1388.9/653 = 2.13倍。
2）AWR中等待事件对比
我们重点关IO类型等待对比：
  • db file sequential read：
    2月28日，平均每次等待  1ms不到；
    3月02日，平均每次等待 16ms；
    3月02日是2月28日的平均等待时长的16倍以上。
  • direct path read：
    2月28日，平均每次等待 16.38ms；
    3月02日，平均每次等待 36.81ms；
    3月02日是2月28日的平均等待时长的2.25倍。
  • db file scattered read:
    2月28日，平均每次等待  9.83ms；
    3月02日，平均每次等待 28.18ms；
    3月02日是2月28日的平均等待时长的2.87倍。
2.1.3 IO 等待时间对比分析
对比平均IO等待时间，2月28日， IO等待最高也就50ms，而3月2日的IO类型等待，最高超过了300ms，如下图所示：
怀疑可能是存储底层IO响应慢导致应用侧SQL执行变慢，并且是周末的sql执行变慢，怀疑是什么定时任务导致，然后核查数据库主机的crontab定时任务无异常，于是联系硬件工程师检查。
主机工程师反馈每个周日的0点-10点存储底层在做RA卡一致性校验，该操作会消耗大量IO，目前怀疑应用侧反馈每个周日应用响应慢很可能与此操作有关。 
2.2 关闭某数据库一体机RAID卡一致性校验
3月20日晚主机工程师关闭了某数据库一体机RAID卡一致性校验后，3月23日周日凌晨RAID卡一致性校验任务未启动，业务侧观察程序执行时间正常，后续未出现明显变慢等情况。 
三

后续计划及建议

3.1 错峰执行操作
主机工程师已于3月21日将某数据库一体机RAID卡一致性校验任务调整到了每周3下午3点钟开始，与业务错开，避免影响业务。
3.2 超大表改造分区表
针对前期DBA提出的部分超大表需改造为分区表，以及部分SQL可以在改造为分区表后使用交换分区、创建索引等提高SQL执行效率，目前检查应用侧仍未调整，建议应用侧按照DBA建议进行调整以提高业务程序执行效率 。

END


本文作者：刘思龙(上海新炬中北团队）

本文来源：“IT那活儿”公众号

数据库sql数据库一体机
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论