1、10.1 日常运维工具概述Runstats 是 run statistics 的缩写，意思是收集统计信息，目的是为 DB2 优化器提供最佳路径选择；Reorg 是重组的意思，目的是减少表和索引在物理存储上的碎片，提供性能；Reorgchk 是重组前的检查Rebind 是对一些包、存储过程或静态程序进行重新绑定。几个工具的执行流程：首先通过 Runstats 收集表和索引的统计信息，然后执行 Reorg 重组，如果有必要则执行，然后再次收集统计信息。最后，对于静态语句、存储过程等，执行 Rebind 绑定。10.2 Runstats在系统运行一个查询的时候，优化器需要决定用某种方式来访问数据。只
2、有当 DB2 对表中的数据有一个大概的了解，才能知道每一步操作大约需要处理多少数据，返回多少行。当优化器了解了这些信息后，就会根据一系列的运算，判定出各种访问途径所需要消耗的资源，然后从中选择一个消耗资源最少的方法。最普通的 Runstats 就是统计表和索引中有多少行数据，有多少不同的数值。Runstats 命令使用 DISTRIBUTION 参数手机数据分布。数据分布分为两种，一种叫做频率采样（Frequency）,一种叫做百分比采样（Quantile） 。当收集数据分布时，两种采样方式都会被收集。其中频率采样是手机表中拥有相同数量最多的几行，比如 10000 行数据中 9000行为 10
3、，然后 500 行为 9，然后 100 行为 8，剩下的部分平均分布。如果我们制定Frequency 为 3 的话，那么系统就会记录下来有 9000 行 10,500 行 9，然后 100 行 8，剩下的部分在估算时则假定平均分布。而百分比采样则是将整个 10000 行数据分成相等大小的若干段，然后记录每一段的段首和段尾的数值，当需要查询一个数据段时（比如 C110 AND C1. ON ALL COLUMNS WITH DISTRIBUTION AND DETAILED INDEXES ALL2)收集索引统计信息，如果表上没有统计信息，该选项会同时对表做统计。但该选项并不会收集数据分布信息，
4、代码如下：RUNSTATS ON TABLE . FOR INDEXES ALL3)使用伯努利算法抽样统计。DB2 会扫描每一行数据，但只对一定比例的抽样数据进行统计。这种方法一般用于数据仓库中的大表。如果收集全表数据统计，将需要很长时间，并占用 CPU 资源，应用性能会造成影响。下列采用了伯努利 10%抽样统计，代码如下：runstats on table . tablesample bernoulli(10)如何查看一个表是否收集了统计信息？一个比较有效的办法是查看 syscat.tables 的 stats_time 字段，如果该字段值为空，则表示没有收集过统计信息，否则会显示统计信息的
5、时间：db2 “select char(tabname,20) as tabname,stats_time form syscat.tables where STATS_TIME is NULL“DB2 runstats 命令只能针对单表执行，而无法对整个数据库做运行时统计（虽然可以使用reorgchk update statistics 对所有表收集统计信息，但 reorgchk 并不会收集分布统计） 。可考虑将需要执行 runstats 的表写入一个脚本，以下是一个脚本范例：#!/bin/kshif “$#“createRunstats.txtgrep RUNSTATS createRun
6、stats.txt runstats_detailed.sqldb2 -tvf runstats_detailed.sqlRunstats 命令有 allow write accesss 和 allow read access 选项，allow write access 选项是默认行为，表示 runstats 表时，可以读取修改表数据；allow write access 选项，会在 runstats 的表上加 IN 锁，而指定 allow read access 时，会在 runstats 表上加 S 锁。当运行 Runstats 时，如果出现表和索引统计信息不一致，将会导致 Runstat
7、s 报警而影响优化器路径选择。出现这种情况，需要同时收集表和索引统计信息。db2 delete from t1db2 runstats on table db2inst1.t1SQL2314W Some statistics are in an inconsistent state SQLSTATE=01650db2 runstats on table db2inst1.t1 and detailed indexes all当执行大数据量得统计信息收集时，可能出现“sql2310N”使用程序不能生成统计信息，返回错误“-930”错误，这时可考虑采用抽样统计。Runstats 统计结果存在系统表
8、中，如 SYSSTAT.TABLES，如 SYSSTAT.TABLES 保存了表的统计信息，SYSSTAT.INDEXES 保存了索引统计信息，可以查看这些统计信息，但不建议手动修改。在生产环境中，当遇到性能问题时，通常的做法是在测试机上搭建环境，模拟实际场景，但如果生产环境数据量太大、太敏感时，就无法创建相同的数据环境了，这样统计信息就不会一致，从而无法保证两边的执行计划是一致的。这时，可以采用的做法是将生产数据库的统计信息抽取出来，在测试库上进行更新，以此来“欺骗”优化器。db2look 提供了 mimc 选项用于保存统计数据。db2look -d sample -m db2look_st
9、at.out以下是 Runstats 命令的最佳实践：1.当表的数据量发生了很大变化，如通过 load 加载了大量数据，或 reorg 后，或新增了索引等，建议为相应对象收集 runstats 信息，为优化器提供最准确的依据。2.为减小对应用的影响，应尽可能的在空闲时间执行 runstats.3.当表很大、或运维窗口很小，或表数据频繁变动时，可考虑在某些关键字段上执行runstats，而不是在所有字段。4.当表很大、统计的时间很长时，可考虑采用抽样统计。5.为提高可用性，推荐使用 allow write access 选项，但使用该选项时不能有太多的增删改操作，否则可能会造成数据和索引统计的不
10、一致。6.系统表也需要经常做 runstats。7.为减少统计信息不一致的情况，考虑在表和索引上同时进行统计信息收集。8.当执行完 runstats 后，要发出 commit 命令以释放锁，对于静态语句，还需要对 package重新绑定，以便生成新的访问计划。10.3 Reorg10.3.1 问什么需要 Reorg在 DB2 中，如果经常对数据进行增 删 改操作，可能会造成表和索引数据的物理组织不连续，出现空页和溢出等情况。同磁盘碎片整理工具类似，DB2 提供了 Reorg 工具进行表和索引重组，使数据在物理存储上连续，提高页使用效率，减少 I/O 次数，提高查询性能。Reorg 是日常运维的
11、重要工具。当出现以下问题时，Reorg 表可能会大大提供性能：1.如果表中有许多行被删除，可能会导致某些数据页只包含一部分数据，甚至有些页变成空页，当空间并不会释放。通过 Reorg 后表占用的空间会大大降低。 （释放空页）2.当发生行溢出时。所谓行溢出（overflow ）,主要发生在表中包含 varchar 变长字段的情况，对变长字段值进行更新后，记录的长度比以前更长，使得原有的页空间不足以放下更新的数据，DB2 就会将这行数据放到另外一页，而在原有位置通过指针指向新行的 RID,这样对该行的访问需要两次 I/O。如果行溢出的发生得很频繁，会导致大量不必要的 I/O 开销。这时可 Reor
12、g 表数据，重新组织数据的存储顺序，减少不必要的 I/O。3.按照某个索引重新组织表数据的物理顺序。前面我们讲过聚集索引（cluster index）的概念，就是表数据在物理上的存储顺序与索引的顺序相匹配，但随着数据的频繁操作，有些表数据的物理顺序可能无法匹配索引顺序，这时可通过 Reorg 操作重新按索引物理排序。4.当启用了表数据压缩功能时，可通过 Reorg 建立字典表，并对表数据进行压缩。当出现以下问题时，Reorg 所以可能会大大提高性能1.当表数据删除后，可能会导致很多索引页变成空页，可通过 Reorg 索引减少索引页空间。2.减少索引的层次。索引是 B+树结构，包含树根、树枝和叶
13、子节点，根据索引数据的大小，索引可能会包含几层，层次越低，索引查询需要的 I/O 就越少。通过 Reorg 可能降低索引的层次。3.去除伪删除的行和页。当删除数据后，索引中指向这些行的指针被标记为 pseudo deleted，而不是物理上删除。这时候可通过 Reorg 删除这些指针，减少索引叶子节点的数量。当然，Reorg 并不总会降低数据页大小。有时候按照索引重组后数据页会增加，这是一种具有建设性的增长。在生产环境下，DBA 比较关心的是 Reorg 的执行时间、执行频率和对应用的影响。对于大表来说，执行一次 Reorg 需要的时间可能会更长，对资源的占用率很高，对应用会有一定的影响，建议
14、在业务空闲的时候执行，执行的频率可考虑每周，或每月做一次。如何判断一张表或索引是否需要 Reorg，有两种方法可供选择：1.通过 Reorgchk 工具2.另外一个是通过 sysibmadm.snaptab 管理视图。Reorgchk 工具利用 8 个公式（3 个表公式、5 个索引公式）判断表和索引是否需要重组。如果表统计结果 F1 F2 F3 标记为*，则该表需要重组；如果索引统计结果 F4-F8 有*标记，则需对索引重组。db2 reorgchk on schema db2admin当表很多时对 Reorgchk 结果的解析会比较麻烦，这是可考虑 sysibmadm.snaptab 管理视
15、图，如果发现 overflow_accesses 与 rows_read 比例高于 3%，则需要对表进行重组。注意：采用此方法需要将实例监控器打开开关（update dbm cfg using dft_mon_table on）:db2 “SELECT substr(TABNAME,1,18) as TABNAME,ROWS_READ,OVERFLOW_ACCESSES from SYSIBMADM.SNAPTAB where (ROWS_READ 999) and (OVERFLOW_ACCESS * 100)/(ROWS_READ + 1) 3)“10.3.2 Reorg 用法与离线 Re
16、org 相比，在线 Reorg 对资源的占用较少，对应用的影响也很小。在线 Reorg 也叫 inplace reorg,可以保证在重组过程中，其他应用对数据的不间断访问，在线表重组并不会创建数据副本，而是在原空间中进行，表数据的重组是分批次的，每批次只处理一部分数据，因此它的速度比离线 Reorg 要慢得多。在线 Reorg 可随时启动和终止，为了保证可恢复性，在线 Reorg 会记录大量的日志，需要的日志空间依赖于要移动的行数、表上索引的个数和索引键大小，因此可能是表大小的几倍。在线 Reorg 命令举例：db2 reorg table db2inst1.employee inplace
17、allow write access在线 Reorg 是在后台异步执行的，因此即使我们看到命令成功返回，实际上仍然在后台执行。如果要重组的表很多，通常的做法是写成脚本，需要注意的是，在线重组是异步过程，这可能会造成脚本里的多个 reorg 命令同时执行，导致 I/O 和 CPU 资源占用很多，并且会消耗所有的活动日志，影响应用系统正常工作。为解决该问题，在编写脚本时采用以下方法控制多个表的在线 Reorg 执行顺序：每个在线Reorg 执行时，都有一个对应的 db2reorg 应用程序，通过 db2 list applications show detail|grep -i db2reorg
18、判断，如果有 Reorg 正在执行，则等待该 Reorg 正在执行，则等待该Reorg 执行完毕，否则执行脚本里的下一个表重组。除此之外，还可以通过其他方法在线表重组，参考前面的离线表重组。3.Reorg 索引当离线表重组结束后，会重建表上的所有索引。在线表重组仅仅维护索引，而不会重建索引（聚集索引除外） ，当在线重组结束后，如果需要进行索引单独重组，可通过 reorg indexes all for 。db2 reorg indexes all for table t1对于在线索引重组的监控，可以通过 list history reorg all 或查看 db2diag.log 文件。db2
19、 list history reorg all for sample10.3.3 Reorg 最佳实践对于 DBA 来说，在 reorg 时有几个问题需要注意：1.离线重组还是在线重组一般来说，如果应用有一定的运维实践窗口，建议选择离线 Reorg 加快执行速度；对于要求 7*24 小时持续运行、具有很小运维窗口的应用，建议在业务相对空闲的时候选择在线 Reorg,虽然速度较慢，但可以减小对应用的影响。在线重组在设计时考虑的更多的是如何减小对应用的影响，而不是速度。离线重组支持的访问模式：Allow No Access Allow Read Access(默认)优点：提供最快的表重组；原始数据
20、在最终替换前是只读的一旦表重组结束后会进行索引重建缺点：占用数据空间大，大概是原表的 2 倍；访问受限，只读；如果重组工程中失败，则需要重新执行选择建议：如果有运维时间窗口，并且要求 Reorg 执行速度，则选择离线 Reorg在线重组支持的访问模式：Allow Read Access Allow Write Access(默认)优点：执行重组时允许应用访问；可以随时终止和恢复；异步运行；因为增量处理，所以占用的空间小缺点：要求更多日志空间；比离线 reorg 速度慢很多，可能慢 10-20 倍；不能重组大对象；维护索引，但是不能重建索引，可能需要随后对索引重组选择建议：一般来说，对于 7*2
21、4 小时持续运行并具有很小运维窗口的应用，建议选用在线重组，确保高可用，当时建议在交易较小的时候使用2.如果在重组的过程中出现意外（比如断电）,对正在重组的表或索引有何影响？对于离线重组，如果断电时 Reorg 正在进行 scan 或 build，当崩溃恢复时该表将恢复到初始状态；如果 Reorg 正在进行 replace(copy),崩溃恢复将重新执行该阶段；如果正在执行 index create,崩溃恢复阶段将把索引失效，并延迟索引的重建。对于在线重组，如果断电时 Reorg 正在执行，那么正在执行 Reorg 的那个事务将回滚（因为在线 Reorg 采用增量的方式进行数据处理，已完成的迁
22、移并不会收到影响） 。但 reorg 的状态是终止（paused）,可以重新恢复。对于在线索引重组，断电后，崩溃恢复将回滚索引创建，并延迟索引重建。以下是关于 Reorg 的几点最佳实践：1.如果表上有大量的增删改操作，产生碎片的几率会很大，建议重组。2.当 Reorgchk 命令提示需要重组时，建议重组。3.创建表压缩时，通过 Reorg 建立压缩字典表，并进行表压缩。4.对于离线重组，需要确保有足够的表空间存取影子拷贝，否则重组会失败。5.对于在线重组，由于每次数据迁移都需要记录日志，因此必须确保有足够的日志空间。同时，需要确保 util_heap_sz 数据库参数的值足够大。6.在同一时
23、刻，同一张表上只能有一个重组。但只要资源允许，可以同时执行几个表重组。7.对于普通表来说，当执行在线索引重组时，必须为一张表的所有索引执行，而无法选择为某个索引执行。8.对于系统表也要经常做 Reorg.9.重组最好不要和其他工具一起执行，因为可能会产生锁竞争，导致回滚。10.4 Rebind讲到 Rebind，则不能不提 bind。开发过 SQLC 的工程师对 bind 应该不会陌生，包含在 C程序的 DB2 SQL 语句经过预编译（prep）后，会绑定（bind）到 DB2 的 package 中，package 里包含了每条 SQL 语句的访问计划。以后执行这个 C 程序时，就会按照保存
24、在package 的访问计划执行 SQL 语句。Rebind 工具会根据当前的统计信息为 package 里的 SQL 语句重新生成新的访问计划，对性能可能会有比较好的提升。Rebind 一般用于嵌入式 SQL，如嵌入 SQL C、嵌入 SQL Java、嵌入 SQL Cobol 等，这些嵌入式语言的 sql 如果是静态语句时，当表的统计信息发生重大变化，或新增索引等可能造成执行计划发生变化的时候，建议用 Rebind 命令重新绑定。对于存储过程，本质上也是存储到 package 中，Rebind 同样适合。使用 Rebind 命令时，需要提供 package 名。对于 SQC(嵌入 C)等程
25、序，在 bind 的时候会创建一个 package，在 DB2 内部，每个存储过程对应一个 package。可以通过 db2 list packages for all(或 schema xx)列出相应的 package 名。db2 rebind package P6045027如果针对所有的 package 重新绑定，可以考虑 db2rbind 命令db2rbind sample -l db2rbind.log all动态 SQL 是在执行时才编译，并存储到 package cache 中。如果更新了统计信息，可以通过 flush package cache dynamic 更新 packa
26、ge cache10.5 获取数据库占用空间的大小从 v9 开始，DB2 提供了 SYSSPROC.GET_DBSIZE_INFO 存储过程来计算当前数据库大小和最大容量大小：db2 call GET_DASIZE_INFO(?,?,?,)其中前三个参数为输出参数，第四个参数为输入参数，表示在该时间后进行数据库大小和容量大小的刷新，单位为分钟，默认为 30 分钟，如果为 0，则会马上进行刷新。如果需要统计每天数据大小的增长情况，可考虑将此更新窗口设为 24 小时，即 24*60=1440 分钟。例如：db2 “call GET_DBSIZE_INFO(?,?,?,0)“参数名：DATABASE
27、SIZE参数值：180142080（Bytes）参数值：DATABASECAPACITY参数值：39617922048（Bytes ）注意：1.如果存在多个 SMS 表空间的情况，db 容量的计算结果不一定准确。2.在多分区环境下，此存储过程只能看 dbsize 大小，无法看 db 容量。10.6 获取某个表空间占用空间大小可以使用 db2 list tablespaces show detail在 9.1 版本中，可通过 SYSIBMADM.TBSP_UTILIZATION 查看表空间使用大小。10.7 获取某个表/索引占用空间大小1.计算某个表占用空间有 db2pd -tcbstats A
28、dmin_get_tab_info 表函数和SYSIBMADM.ADMINTABINFO 系统管理视图三种方法。1）db2pd 的 tcbstats 可以查看表的 TCB 信息，其中 DataSize 字段用来表示表的页数，乘以页大小即为表的大小。使用该方法时，只有该表被访问过才会显示出来：db2pd -d sample -tcbstats2)Reorgchk 结果中，NPAGES 代表页数，乘以页大小就是表的大小，但 Reorgchk 需要执行runstats,对于大表来说，需要的时间较长：db2 reorgchk updata statistics on table db2inst1.em
29、ployee3)SYSIBMADM.ADMINTABINFO 管理视图，DB2 9 版本引入，可获得表的大小和状态信息，以 KB 为计量单位：dscribe table SYSIBMADM.ADMINTABINFOdb2 “select (data_object_p_size + index_object_p_size + long_object_p_size + lob_object_p_size + xml_object_p_size) as totab_p_size from sysibmadm.admintabinfo where tabname=EMPLOYEE“DATA_OBJEC
30、T_L_SIZE 代表表的逻辑大小（KB）DATA_OBJECT_P_SIZE 为表的物理大小我们往某张表中插入很多数据，然后删除一些数据，但表占据的空间并不会释放，当新的数据插入时，仍然会使用这些空间。实际占用的空间叫逻辑空间，分配过的空间叫物理空间，逻辑空间可能会小于物理空间，这两者的差异可以通过 reorg 来消除。初次之外，SYSIBMADM.ADMINTABINFO 视图提供了其他几个有用的字段，如REORG_PENDING INPLACE_REORG_STATUS LOAD_STATUS 详细解释，请参看信息中心。10.8 小结一般来说，DBA 的日常运维包括定期收集统计信息，整理表和表空间，检测磁盘使用情况，当然还有定期的备份与检查备份介质。对于一个较为成熟的系统，大部分这些运维操作早已经存在规范化的脚本，每天或者每周定期运行。但是对于一个新建的系统，作为 DBA 就要建立这一套规范化的运维体系。
