DB2数据库管理最佳实践笔记-10日常运维.
- 格式：docx
- 大小：20.68 KB
- 文档页数：8
10.1日常运维工具概述
Runstats是run statistics的缩写，意思是收集统计信息，目的是为DB2优化器提供最佳路径 选择；
Rcorg是重组的意思，目的是减少表和索引在物理存储上的碎片，提供性能：
Reorgchk是重组前的检查
Rcbhid是对一些包、存储过程或静态程序进行重新绑泄。
几个工具的执行流程：
首先通过Runstats收集表和索引的统计信息，然后执行Reorg重组，如果有必要则执行，然 后再次收集统汁信息。最后，对于静态语句、存储过程等，执行Rebind绑左。
10.2 Runstats
在系统运行一个查询的时候，优化器需要决左用某种方式来访问数据。只有当DB2对表中 的数据有一个大概的了解，才能知道每一步操作大约需要处理多少数据，返回多少行。当优 化器了解了这些信息后，就会根据一系列的运算，判左出各种访问途径所需要消耗的资源， 然后从中选择一个消耗资源最少的方法。
最普通的Runstats就是统计表和索引中有多少行数据，有多少不同的数值。
Runstats命令使用DISTRIBUTION参数手机数据分布。数据分布分为两种，一种叫做频率 采样（Frequency）,—种叫做百分比采样（QmuHile）。当收集数据分布时，两种采样方式都 会被收集。其中频率采样是手机表中拥有相同数量最多的几行，比如10000行数据中9000 行为10,然后500行为9,然后100行为8,剩下的部分平均分布。如果我们制Frequency 为3的话，那么系统就会记录下来有9000行10.500行9,然后100行8,剩下的部分在估 算时则假定平均分布。而百分比采样则是将整个10000行数拯分成相等大小的若干段，然后 记录每一段的段首和段尾的数值，当需要查询一个数据段时（比如Cl>10ANDCl<15）,就 可以根据每一个数拯段的启始数值加上段落的大小，估算岀符合查询条件的记录数量。
理论上，数据分布收集的越细致越好。但是经过细致的数据分布信息可能会导致DB2在优 化SQL时需要处理更多的信息，并占用更多的系统存储空间，可能会导致性能的下降。因 此，一般情况下我们建议使用默认的数据分布采样设置，也就是频率采样为10,百分比采 样为20。但是，有些情况下，则需要根据实际情况调整分布参数。
Runstats的语法比较复杂，在实际应用中，最常用的几种使用方法如下：
1）为表和索引收集统汁信息，包括数据分布，代码如下：
RUNSTATS ON TABLE V表模式>.v表名〉ON ALL COLUMNS WITH DISTRIBUTION AND DETAILED INDEXES ALL
2) 收集索引统计信息，如果表上没有统讣信息，该选项会同时对表做统讣。但该选项并不会 收集数据分布信息，代码如下：
RUNSTATS ON TABLE v表模式av表名〉FOR INDEXES ALL
3) 使用伯努利算法抽样统讣。DB2会扫描每一行数据，但只对一左比例的抽样数据进行统计。 这种方法一般用于数据仓库中的大表。如果收集全表数据统计，将需要很长时间，并占用 CPU资源，应用性能会造成影响。下列采用了伯努利10%抽样统计，代码如下：
runstats on table v表模式a.v表名：> tablesample bernoulli(lO)
如何査看一个表是否收集了统计信息？
一个比较有效的办法是査看syscat.tables的statsjime字段，如果该字段值为空，则表示没 有收集过统计信息，否则会显示统计信息的时间：
db2 ”select char(tabname,20) as tabname,statsjime form syscat.tables where STATS_TIME is NULLH
DB2 runstats命令只能针对单表执行，而无法对整个数据库做运行时统计(虽然可以使用 reorgchk
update statistics对所有表收集统计信息,但reorgchk并不会收集分布统计)。可考 虑将需要执行nmstats的表写入一个脚本，以下是一个脚本范例：
#!/bin/ksh
if [H$#M<3]；then
echo ”USAGE: SO DB_NAME DB_USER_NAME DB_PASSWORD”
exit
fi
DB=$1
DB_USER=$2
DB_PWD=$3
db2 connect to $DB user $DB_USER using $DB_PWD
db2 Select rtrim(RUNSTATS ON TABI^llrtrim(tabschema)ll7lltabnamell, ON ALL COLUMNS WITH
DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL ALLOW WRITE ACCESS;1) from
syscat.tables where type=,TH,>creatcRunstats.txt
grep RUNSTATS createRunstats.txt > runstats_detailcd.sqi
db2 -tvf runstats^detailed.sql
Runstats 命令有 allow write accesss 和 allow read access 选项，allow write access 选项是默认
行为,表示runstats表时，可以读取修改表数据:allow write access选项，会在nmstats的表 上加IN锁，而指定allow read access时，会在runstats表上加S锁。
当运行Runstats时，如果出现表和索引统计信息不一致，将会导致Runstats报警而影响优化 器路径选择。岀现这种情况，需要同时收集表和索引统计信息。 db2 delete from 11
db2 ninstats on table db2instl.tl
SQL2314W Some statistics are in ail inconsistent state ... SQLSTATE=O 1650
db2 ninstats on table db2instl.tl and detailed indexes all
当执行大数据量得统il•信息收集时，可能岀现“sql2310N”使用程序不能生成统计信息，返回 错误“-930“错误,这时可考虑采用抽样统计。
Runstats统计结果存在系统表中，如SYSSTAT.TABLES,如SYSSTAT.TABLES保存了表的 统汁信息，SYSSTAT.INDEXES保存了索引统计信息，可以査看这些统汁信息，但不建议手 动修改。
在生产环境中，当遇到性能问题时，通常的做法是在测试机上搭建环境，模拟实际场景，但 如果生产环境数据量太大、太敏感时，就无法创建相同的数拯环境了，这样统计信息就不会 一致，从而无法保证两边的执行汁划是一致的。这时，可以采用的做法是将生产数据库的 统计信息抽取出来，在测试库上进行更新，以此来“欺骗”优化器。
db21ook提供了 mime选项用于保存统计数据。
db21ook -d sample -m > db21ook_stat.out
以下是Runstats命令的最佳实践：
1•当表的数据量发生了很大变化，如通过load加载了大量数据，或rcorg后，或新增了索引 等，建议为相应对象收集runstats信息，为优化器提供最准确的依据。
2. 为减小对应用的影响，应尽可能的在空闲时间执行runstats.
3. 当表很大、或运维窗口很小，或表数据频繁变动时，可考虑在某些关键字段上执行i-unstats,
而不是在所有字段。
4. 当表很大、统计的时间很长时，可考虑采用抽样统讣。
5. 为提高可用性，推荐使用allow write access选项，但使用该选项时不能有太多的增删改操 作，否则可能会造成数据和索引统计的不一致。
6. 系统表也需要经常做ninstatsQ
7. 为减少统计信息不一致的情况，考虑在表和索引上同时进行统计信息收集。
8. 当执行完runstats后,要发出commit命令以释放锁，对于静态语句，还需要对package重 新绑泄，以便生成新的访问计划。
10.3 Reorg
103.1问什么需要Reorg
在DB2中，如果经常对数搦进行增删改操作，可能会造成表和索引数据的物理组织不连 续，出现空页和溢出等情况。同磁盘碎片整理工具类似，DB2提供了 Reorg工具进行表和 索引重组，使数据在物理存储上连续，提髙页使用效率，减少I/O次数，提高查询性能。Reorg
是日常运维的重要工具。
当出现以下问题时，Reorg表可能会大大提供性能： 1. 如果表中有许多行被删除，可能会导致某些数据页只包含一部分数据，甚至有些页变成空 页，当空间并不会释放。通过Reorg后表占用的空间会大大降低。(释放空页)
2. 当发生行溢出时。所谓行溢岀(overflow),主要发生在表中包含varchar变长字段的情况, 对变长字段值进行更新后，记录的长度比以前更长，使得原有的页空间不足以放下更新的数 据，DB2就会将这行数据放到另外一页，而在原有位置通过指针指向新行的RID,这样对该 行的访问需要两次I/O.如果行溢岀的发生得很频繁，会导致大量不必要的I/O开销。这时 可Reorg表数据，重新组织数据的存储顺序，减少不必要的I/O.
3. 按照某个索引重新组织表数据的物理顺序。
前而我们讲过聚集索引(cluster index)的概念，就是表数据在物理上的存储顺序与索引的 顺序相匹配，但随着数据的频繁操作，有些表数据的物理顺序可能无法匹配索引顺序，这时 可通过Reorg操作重新按索引物理排序。
4. 当启用了表数据压缩功能时，可通过Reorg建立字典表，并对表数据进行压缩。
当出现以下问题时，Reorg所以可能会大大提高性能
1. 当表数据删除后，可能会导致很多索引页变成空页，可通过Reorg索引减少索引页空间。
2. 减少索引的层次。索引是B+树结构，包含树根、树枝和叶子节点，根据索引数据的大小, 索引可能会包含几层，层次越低，索引査询需要的I/O就越少。通过Reorg可能降低索引的 层次。
3. 去除伪删除的行和页。当删除数据后，索引中指向这些行的指针被标记为pseudo deleted, 而不是物理上删除。这时候可通过Reorg删除这些指针，减少索引叶子节点的数虽。
当然，Reorg并不总会降低数据页大小。……
有时候按照索引重组后数据页会增加，这是一种具有建设性的增长。
在生产环境下，DBA比较关心的是Reorg的执行时间、执行频率和对应用的影响。对于大 表来说，执行一次Reorg需要的时间可能会更长，对资源的占用率很高，对应用会有一圧的 影响，建议在业务空闲的时候执行，执行的频率可考虑每周，或每月做一次。
如何判断一张表或索引是否需要Reorg,有两种方法可供选择：
1. 通过Reorgchk工具
