DB2的runstats和慢sql慢存储过程解决方法

最新推荐文章于 2025-04-02 10:55:19 发布

原创最新推荐文章于 2025-04-02 10:55:19 发布 · 1.5k 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#数据库

本文介绍了在DB2中使用RUNSTATS命令收集统计信息的情况，包括新索引、数据更新操作频繁、性能优化前、预存取改变以及静态SQL应用更新需求。还讨论了自动runstats的开启与手动runstats的必要性，以及如何诊断和优化SQL执行计划。

在哪些情况下，建议使用RUNSTATS命令进行统计信息收集？

当向表装入数据并创建了新的索引
当用REORG命令重组表和索引时
当存在大量影响表及其索引的更新、删除和插入操作时（大量=10%-20%）
在绑定对性能要求很好的应用程序之前
在预存取（prefetch size）大小发生变化时
当在表中创建新的索引时
当想要比较当前和先前统计信息时
使用RUNSTATS命令来收集关于XML列的统计信息
关于最后一条：在成功执行RUNSTATS命令之后，静态SQL查询并不会使用最新的数据库统计信息，这是因为静态SQL的访问策略在之前执行BIND时就已确定，而当时使用的统计信息有可能与现在的并不一致。这时候就需要重新绑定使用静态SQL的应用程序，这样查询优化器就可以根据数据库最新统计信息来选择获取数据的最佳访问策略。但是，对于使用动态SQL的应用程序而言，则没必要重新进行重新绑定，因为动态SQL语句的访问策略是根据统计信息在运行时动态生成的。

如下是在DB2环境中做的测试，对应慢sql或者慢的存储过程，首先要看数据库是否开启了自动runstats，如果没有开启（一些数据仓库查询比较少的情况下会关闭自动runstats，因为runstats会影响性能），需要手动runstats，如果开启了自动runstats，则需要关注每个表的runstats是否是最新。对于一些慢的存储过程，因为是静态sql，需要做了runstats后重新rebind才能生效。

[db2inst1@t3-dtpoc-dtpoc-web04 ~]$ db2 get db cfg for test |grep -i runstats
Automatic runstats (AUTO_RUNSTATS) = ON

[db2inst1@t3-dtpoc-dtpoc-web04 ~]$ db2 "select FPAGES,STATS_TIME from syscat.tables where TABNAME='SC'"

FPAGES STATS_TIME
-------------------- --------------------------
5076 2023-08-11-14.02.49.086314


db2 "RUNSTATS ON TABLE db2inst1.SC WITH DISTRIBUTION ON KEY COLUMNS AND DETAILED INDEXES ALL TABLESAMPLE SYSTEM(2)"

[db2inst1@t3-dtpoc-dtpoc-web04 DIAG0000]$ db2 "RUNSTATS ON TABLE db2inst1.SC WITH DISTRIBUTION ON KEY COLUMNS AND DETAILED INDEXES ALL TABLESAMPLE SYSTEM(2)"
DB20000I The RUNSTATS command completed successfully.
[db2inst1@t3-dtpoc-dtpoc-web04 DIAG0000]$ db2 "select FPAGES,STATS_TIME from syscat.tables where TABNAME='SC'"

FPAGES STATS_TIME
-------------------- --------------------------
5076 2023-08-21-10.36.34.129793

1 record(s) selected.

可以看到6分钟后自动做了runstats
[db2inst1@t3-dtpoc-dtpoc-web04 liys]$ db2 "select FPAGES,STATS_TIME from syscat.tables where TABNAME='SC'"

FPAGES STATS_TIME
-------------------- --------------------------
1 2023-08-21-10.42.48.760222

1 record(s) selected.

我们Load14万行数据后再访问该表发现没有处罚runstats。

db2 "load from /tmp/SC of del insert into SC"
Number of rows read = 140000
Number of rows skipped = 0
Number of rows loaded = 140000
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 140000

[db2inst1@t3-dtpoc-dtpoc-web04 liys]$ db2 "select count(*) from SC"

1
-----------
140000

1 record(s) selected.

[db2inst1@t3-dtpoc-dtpoc-web04 liys]$ db2 "select FPAGES,STATS_TIME from syscat.tables where TABNAME='SC'"

FPAGES STATS_TIME
-------------------- --------------------------
1 2023-08-21-10.42.48.760222

1 record(s) selected.

然后等过了三分钟后自动做了runstats
[db2inst1@t3-dtpoc-dtpoc-web04 liys]$ db2 "select FPAGES,STATS_TIME from syscat.tables where TABNAME='SC'"

FPAGES STATS_TIME
-------------------- --------------------------
1016 2023-08-21-10.45.44.100566

db2caem工具可以生产sql的执行计划，里面包含每一步返回的真实rows。可以直观的看出执行计划的估计值和真实值是否有很大差距，如果有很大差距说明这个执行计划的错误的，需要做runstats来让DB2获取最真实的数据量。
Using db2caem to diagnose queries which do not complete or are resource intensive
https://eclient.lenexa.ibm.com:9445/search/?fetch=source/TechNote/1983791

列如：
db2caem -d test -st 'select * from SC where SC_ID=89'

Access Plan:
-----------
Total Cost: 20.3032
Query Degree: 1

Rows
Rows Actual
RETURN
( 1)
Cost
I/O
|
1
1
FETCH
( 2)
20.3032
NA
/---+----\
1 140000
1 NA
IXSCAN TABLE: DB2INST1
( 3) SC
13.5368 Q1
NA
|
140000
NA
INDEX: SYSIBM
SQL230811094543140