更新目录统计信息背景知识RUNSTATS 实用程序用于更新系统目录表中的统计信息,以帮助查询优化过程。如果没有这些统计信息,数据库管理器可能会做出对 SQL 语句的性能产生不利影响的决定。RUNSTATS 实用程序允许您收集表和/或索引中所包含数据的统计信息。使用 RUNSTATS 实用...
显示全部更新目录统计信息
背景知识
RUNSTATS 实用程序用于更新系统目录表中的统计信息,以帮助查询优化过程。如果没有这些统计信息,数据库管理器可能会做出对 SQL 语句的性能产生不利影响的决定。RUNSTATS 实用程序允许您收集表和/或索引中所包含数据的统计信息。使用 RUNSTATS 实用程序收集基于表和索引数据的统计信息,以便为下列情形中的存取方案选择过程提供精确的信息: 当向表装入数据并创建了合适的索引时。当用 REORG 实用程序重新组织表时。当存在大量影响表及其索引的更新、删除和插入操作时。(此处的“大量”可能意味着 10% 到 20% 的表和索引数据都受到了影响。)在绑定性能至关重要的应用程序之前。当您希望将新的和以前的统计信息进行比较时。定期进行统计使您能够在早期阶段发现性能问题。当预取数量发生变化时。当您已经使用了 REDISTRIBUTE NODEGROUP 实用程序时。
当对 SQL 查询进行优化时,SQL 编译器所做出的决定会受到优化器的数据库内容模型的重大影响。优化器使用该数据模型来估计可以用于解决某个特定查询的其它存取路径的成本。数据模型中的关键元素是一组统计信息,该统计信息收集了有关数据库中所包含的数据和系统目录表中所存储的数据的信息。这包括表、别名(nickname)、索引、列和用户定义的函数(UDF)的统计信息。数据统计信息中的变化会引起对存取方案的选择发生变化,该存取方案作为访问所期望数据的最有效方法。
下面列举了一些统计信息,这些统计信息可以帮助给优化器定义数据模型: 表中的页数和非空的页数。从原始页移到其它(溢出)页的程度。表中的行数。有关单个列的统计信息,比如一列中唯一值的数量。一个索引的群集程度;即,表中行的物理顺序与索引的符合程度。有关索引的统计信息,比如索引级别的数量和每个索引中叶子页的数量。经常使用的列值的出现次数。列值在列中所有值中的分布状况。用户定义的函数(UDF)的成本估计。
RUNSTATS 可以帮助您确定对数据库的更改与性能之间的关系。统计信息显示出表中的数据分布状况。常规使用时,RUNSTATS 提供了在一段时期内有关表和索引的数据,从而随着时间的流逝,可以确定数据模型的性能趋势。在使用 RUNSTATS 之后需要重新绑定使用静态 SQL 的应用程序,这样查询优化器就可以选择新统计信息所给出的最佳存取方案。但是,对于使用动态 SQL 的应用程序(比如大多数供应商应用程序)而言,没必要进行重新绑定,因为语句的优化是根据统计信息在运行时进行的。当有关表的统计信息不准确时,可能会造成性能问题。最糟的情况是,某个特定的 SQL 语句可能会造成 DB2 使用表扫描而不是使用索引扫描。
如何更新统计信息
只有当进行显式的请求时,对象的统计信息才会在系统目录表中被更新。有几种方法可以更新部分或全部统计信息: 使用 RUNSTATS(运行统计信息,run statistics)实用程序。使用带有指定的统计信息收集选项的 LOAD。对针对一组预先定义的目录视图进行操作的 SQL UPDATE 语句进行编码。使用“reorgchk update statistics”命令。
当您不完全知道所有表名或表名实在太多时,进行 RUNSTATS 的最简单方法就是使用“db2 reorgchk update statistics”命令。正确的脚本如下:
db2 -v connect to DB_NAME
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
db2 -v reorgchk update statistics on table all
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
db2 -v terminate
|
我们上面所选的示例不需要表名。这一命令对所有表执行 RUNSTATS。
记住:
在填充数据库之后再运行 RUNSTATS 实用程序。
如果您知道表名并且想避免对大量表运行 RUNSTATS 实用程序(因为这样做可能要花很长时间),那么一次对一张表进行 RUNSTATS 更为可取。命令如下:
db2 -v runstats on table TAB_NAME and indexes all |
这个命令将收集该表及其所有索引(基本级别)的统计信息。
查看是否运行了 RUNSTATS
要查看是否对数据库执行了 RUNSTATS,一种快捷方法便是查询一些系统目录表。例如,如上面的脚本所示,可以运行下面这条命令:
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" |
如果还未运行 RUNSTATS,您会看到 nleaf 和 nlevels 列为“-1”且 stats_time 列为“-”。如果已经运行了 RUNSTATS,则这些列包含实际的数字,并且如果运行过 RUNSTATS,则 stats_time 列将包含时间戳记。如果您认为 stats_time 中所示时间离现在已有很长一段时间,那就该再次运行 RUNSTATS。
缓冲池大小
背景知识缓冲池是内存中的一块存储区域,用于临时读入和更改数据库页(包含表行或索引项)。缓冲池的用途是为了提高数据库系统的性能。从内存访问数据要比从磁盘访问数据快得多。因此,数据库管理器需要从磁盘读取或写入磁盘的次数越少,性能就越好。对一个或多个缓冲池进行配置之所以是调优的最重要方面,是因为连接至数据库的应用程序的大多数数据(不包括大对象和长字段数据)操作都在缓冲池中进行。
缺省情况下,应用程序使用缓冲池 IBMDEFAULTBP,它是在创建数据库时创建的。当 SYSCAT.BUFFERPOOLS 目录表中该缓冲池的 NPAGES 值为 -1 时,DB2 数据库配置参数 BUFFPAGE 控制着缓冲池的大小。否则会忽略 BUFFPAGE 参数,并且用 NPAGES 参数所指定的页数创建缓冲池。
建议对于仅使用一个缓冲池的应用程序,将 NPAGES 更改成 -1,这样 BUFFPAGE 就可以控制该缓冲池的大小。这使得更新和报告缓冲池大小以及其它 DB2 数据库配置参数变得更加方便。
确保可以使用数据库配置中的 BUFFPAGE 参数来控制缓冲池大小之后,将该参数设置成合适的值。根据数据库的大小和应用程序的性质将该参数设置成一个合理的大值,这种做法很安全。通常,该参数的缺省值非常小,可能满足不了要求。请考虑下列情况:
一开始,如果您的机器上有足够大的内存,请将 BUFFPAGE 设置成 40000 个页(160 MB),或者等于机器总内存的 10%。对于大型 OLTP 数据库,在保持系统稳定的同时为缓冲池留出尽可能多的内存。一开始,先尝试使用 1.6 GB 的内存,然后尝试用更多内存。
如何更改该参数运行下面这个脚本,以便: 验证目录值启用数据库配置参数 BUFFPAGE更新所有数据库的 BUFFPAGE 值。
db2 -v connect to DB_NAME
db2 -v select * from syscat.bufferpools
db2 -v alter bufferpool IBMDEFAULTBP size -1
db2 -v connect reset
db2 -v update db cfg for dbname using BUFFPAGE bigger_value
db2 -v terminate |
研究步骤要确定数据库的缓冲池大小是否由 BUFFPAGE 参数所决定,请运行:
db2 -v connect to DB_NAME
db2 -v SELECT * from SYSCAT.BUFFERPOOLS
db2 -v connect reset
db2 -v terminate
|
检查结果。如果每个缓冲池都有一个为“-1”的 NPAGES 值,那么缓冲池大小是由数据库配置中的 BUFFPAGE 参数控制的。
要确定缓冲池大小是否足够大,请在运行应用程序时收集数据库和/或缓冲池的快照。类似于下面的脚本为您提供这些所需的信息:
db2 -v update monitor switches using bufferpool on db2 -v get monitor switches db2 -v reset monitor all
-- run your application -- db2 -v get snapshot for all databases > snap.out db2 -v get snapshot for dbm >> snap.out db2 -v get snapshot for all bufferpools >> snap.out db2 -v reset monitor all db2 -v terminate |
收起