监控 DB2 活动之使用解释工具分析SQL


  什么是解释工具?

  将一条 SQL 语句提交给 DB2 数据库引擎进行处理时,DB2 Optimizer 会对其加以分析,以生成所谓的访问计划。各访问计划包括将用于执行该语句的策略的详细信息(例如是否使用索引;若有排序方法,需要怎样的排序方法等)。如果该 SQL 语句是在一个应用程序中编写的,则访问计划生成于预编译时(若使用了延时绑定,则在绑定时生成),另外还会生成一个可执行形式的访问计划,它作为称为 “包” 的对象存储在系统目录中。但若语句是通过 Command Line Processor 提交的,或者语句是应用程序中的一条动态 SQL 语句(也就是说,这是一条在应用程序运行时构造的 SQL 语句),则访问计划将在该语句发出时生成,而所生成的可执行形式则临时地存储在内存中(位于全局包缓冲区中),而不是系统目录。(若发出了一条 SQL 语句,而全局包缓冲区中已有其可执行形式的访问计划,则已有访问计划将被重用,不会再次调用 DB2 Optimizer。)

  为什么说这非常重要?原因在于,尽管可以使用数据库系统监控器和健康监控器来获取关于某些 SQL 操作执行的情况有多好(或多糟)的信息,但不能用这些监控器来分析单独的 SQL 语句。要执行此类分析,您必须能够捕获并查看存储于 SQL 语句的访问计划中的信息。而为了捕获并查看访问计划信息,您必须使用 DB2 9 解释工具。

  使用解释工具,您可以捕获并查看为特定 SQL 语句选择的访问计划的具体信息,还有可用于帮助确定编写不良的语句或数据库中弱点的性能信息。特别地,解释数据将帮助您了解 DB2 Database Manager 如何为满足查询而访问表和索引。解释数据还可用于评估采取的任何性能调优行动。实际上,只要您更改了 DB2 Database Manager 的某些方面、SQL 语句或与语句交互的数据库,都应收集并检查解释数据,弄清楚您的更改对性能产生了怎样的效果(如果有效果的话)。

  解释表

  必须首先创建一组特殊的表,即解释表,之后才能捕获解释信息。表 4 列出了所用的各解释表以及各表设计用于容纳的信息。

表 4. 解释表

表名 内容
EXPLAIN_ARGUMENT 包含所用各独立操作符的独特特征(如果存在的话)。
EXPLAIN_INSTANCE 包含所解释的 SQL 语句的源的基本信息,还有关于进行解释的环境的信息。(EXPLAIN_INSTANCE 表是所有解释信息的主要控制表。其他解释表中的各行数据显式地链接到该表中的各行。)
EXPLAIN_OBJECT 包含关于为 SQL 语句生成的访问计划所需的数据对象的信息。
EXPLAIN_OPERATOR 包含 SQL 编译器为满足 SQL 语句而需的所有操作符。
EXPLAIN_PREDICATE 包含确定特定操作符应用哪些谓词的相关信息。
EXPLAIN_STATEMENT 包含在得到不同级别的解释信息时存在的 SQL 语句文本。用户输入的原始 SQL 语句存储在该表中,另外还有 DB2 Optimizer 用于选择满足 SQL 语句的访问计划的版本。(后一种版本可能与原始版本的语句略有差异,因为 SQL Precompiler 可能已通过额外的谓词重写和/或增强了该语句。)
EXPLAIN_STREAM 包含关于各单独操作符和数据对象之间存在的输入输出数据流的信息。(数据对象本身显示于 EXPLAIN_OBJECT 表中,而数据流中涉及的操作符可在 EXPLAIN_OPERATOR 表中找到。)

  典型情况下,解释表用于数据库开发之中,协助应用程序数据,但不会在应用程序代码较为稳定的生产数据库中。出于这方面的原因,它们不会随系统目录表一起作为数据库创建过程的一部分而创建。相反,解释表必须在要应用解释工具的数据库中手动创建,之后才能使用解释工具。幸运的是,使用 Command Line Processor 创建解释表的流程相当简单,您只要建立一个到恰当数据库的连接,并执行名为 EXPLAIN.DDL 的脚本即可,可在 DB2 9 软件最初安装的 “sqllib” 目录下的 “misc” 子目录中找到此脚本。(此文件头部的注释提供了执行方法信息。)


« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3