DB2 UDB DBA 核对清单

本文摘自 http://www-128.ibm.com/developerworks/cn/db2/library/techarticles/dm-0404snow/index.html
DB2 UDB DBA 核对清单
一.简介
 虽然数据库越来越具有自我感知（self-aware）和自我修复（self-healing）的能力，但是仍然需要进行一些监控，才能使数据库尽可能高效地运行。就像汽车一样，数据库也需要进行一些检查，才能够以最佳状态运行。本文被划分为一些检查或任务，这些检查或任务应该按不同时间间隔执行。
 第一组检查或任务应该每天都执行，以确保当前或者将来一段时间内没有问题。第二组检查或任务则需要每周运行一次，以检查本周内曾出现的问题，或者下周很可能会出现的问题。最后一组检查或任务不必每天或每周都运行，但是应该每个月都运行一次，以保持系统正常运行，如果的确出现了问题，则防止问题扩大。
二.监控系统
 有很多原因致使您应该监控数据库，不过，最主要的原因是为了确保系统当前或者在将来一段时间内不存在问题。在问题还未发生之前就检测到问题，并采取行动，总比等到问题已经发生而被动地作出反应要好。如果按照本文描述的那样监视 DB2 数据库系统，就可以在很多问题发生之前检测到它们，并维护系统的性能。
三.可用的监控工具
 通常，您需要将对 DB2 的监控与对操作系统的监控结合起来，以便得到对数据库服务器上所发生一切的完整描述。单凭 DB2 工具一般不能提供完整的描述。
 在捕捉用于分析的信息时，应确保同时捕捉 DB2 和操作系统的信息，因为我们不能把在不同时间捕捉到的信息相关联。
3.1 Linux 和 UNIX 工具
 在监控系统时，每过一段时间就拍一次快照。如果只是拍一两分钟内的快照，那么就无法提供系统活动的真正视图。我建议每隔一两分钟就拍一次，并坚持至少一个小时。例如，为了捕捉 CPU、内存以及其他操作系统使用情况，可以使用工具 vmstat。
 vmstat命令的参数如下：
 参数 1: 时间间隔，以秒计，该工具按照这个时间间隔捕捉系统信息。
 参数 2: 该工具应该捕捉系统信息的次数。
 为了连续一个小时每一分钟捕捉一次 vmstat 信息，并将输出写到一个名为 vmstat.out 的文件中，可以使用如下命令：
 vmstat 60 60 > vmstat.out
 为了连续一个小时每两分钟捕捉一次 vmstat 信息，并将输出写到一个名为 vmstat.out 的文件中，可以使用如下命令：
 vmstat 120 30 > vmstat.out
 既要捕捉正常/平均工作负载，也要捕捉峰值工作负载。虽然确保高效地处理正常工作负载很重要，然而同样重要的是，还应确保系统能够在不使服务器超载的情况下处理峰值工作负载。
3.2 DB2 工具
 DB2 有很多工具可用于监控数据库和实例的活动。这些工具包括：
 Health Monitor / Health Center
 Snapshot Monitors / SQL Snapshot 函数
 Event Monitor
 还有其他一些工具和日志也可以提供关于数据库和实例的信息，包括：
 administration notification log
 在 Linux 和 UNIX 中，这是一个独立的文件，而在 Windows 中，这个文件被合并到 Event Log 中。
 DB2DIAG.LOG
 Memory Visualizer
    1. Health Monitor
 在 Version 8 中，DB2 引入了两个新特性，用于帮助监控 DB2 系统的健康状况，这两个新特性分别是：Health Monitor 和 Health Center。
 这两个工具可以就系统潜在的健康问题向用户发出警告，从而为 DB2 Universal Database 添加了 management by exception（基于异常的管理）功能。
 这样就可以在那些会影响系统性能的健康问题真正发生之前，将它们解决掉。
 Health Monitor 运行在 DB2 服务器上，并持续地监控 DB2 实例和数据库的健康状况。如果 Health Monitor 检测到用户定义的某个阈值被超出
 （例如，可用日志空间占总空间的百分比下降到低于某个指定的百分数），或者检测到某个对象的状态反常（例如，DB2 实例不再运行），则 Health Monitor 将发出警告。
 当有警告发出时，就可能发生两件事情：
 发送警告通知。 可以通过 e-mail 发送，或者发送到寻呼台。
 采取预先配置的行动。 执行一个 CLP 脚本或者 Task Center 任务。
 健康指示器（health indicator）是 Health Monitor 所检查的一个系统特征（system characteristic）。Health Monitor 自带了一组针对这些健康指示器的预定义阈值。
 当判断是否发出警告时，Health Monitor 对照这些健康指示器阈值来检查系统状态。通过使用 Health Center、命令或 API，您可以定制这些健康指示器的阈值设置，
 并定义如果发出警告，则通知的对象是谁，应该运行什么样的脚本或任务。
 Health Center 提供了 Health Monitor 的图形化界面。您可以使用它来配置 Health Monitor，并查看实例和数据库对象累积的（rolled up）警告状态。
 通过使用 Health Center 的下钻（drill-down）功能，可以访问关于当前警告的详细信息，并获得建议的行动清单，其中描述了如何处理警告。
 可以直接在该工具中选择遵循某一条建议的行动。我们可以很容易地配置 Health Center，使其显示状态行健康提示（status line health beacon）和/或弹出一个对话框，
 告诉 Health Center 有一个处于警告状态的对象。
    2. Snapshot Monitors / SQL Snapshot 函数
 DB2 维护着关于它的操作、性能以及访问它的应用程序的数据。这种数据是在数据库管理器运行时维护的，可以提供重要的关于性能和故障诊断的信息。
 例如，您可以发现：
 连接到数据库的应用程序的个数，这些应用程序的状态，以及每个应用程序正在执行的 SQL 语句。
 表明数据库管理器和数据库的配置情况的信息，这些信息可以帮助对数据库管理器和数据库进行调优。
 某个指定的数据库何时发生了死锁，调用了哪些应用程序，以及哪些锁存在竞争。
 由应用程序或数据库持有的锁列表。如果应用程序由于要等一个锁而不能往前执行，那么就要添加关于这个锁的附加信息，包括哪个应用程序正持有这个锁。
 对某个特定数据库执行的 SQL 语句的清单，这些语句执行的次数，跟这些语句有关的排序的次数，以及每条语句占用的 CPU 总时间。
 曾经发生过的排序次数以及当前正在发生的排序数目。
 由于监视器的确会给系统增加一些开销，所以应该可以独立地启用或禁用 监视器开关（monitor switch）。
 监视器开关可以为整个实例而设，为实例中所有的数据库而设，或者仅用于一个数据库会话。
 如果在一个会话内启用监视器开关，那么这些监视器仅仅对于这个会话是“活动的（active）”，从其他会话中拍得的快照无法捕捉监视器信息。
 如果使用 DB2 实例配置参数启用监视器开关，那么所有会话都可以使用监视器，除非显式地在某一个会话中将监视器开关关掉。
 为了在一个会话内设置监视器开关，可以使用 UPDATE MONITOR SWITCHES 命令或 sqlmon() API。
 例如，要启用缓冲池监视，可以使用以下命令打开监视器开关：
 update monitor switches using bufferpool on
 注意： 要想更新监视器开关和/或拍 DB2 快照，必须具有 SYSADM、SYSCTRL 或 SYSMAINT 授权。
 可以通过拍快照或者使用事件监视器来访问由数据库管理器维护的数据。我们可以使用下列方法中的任意一种来拍快照：
 在命令行中使用 GET SNAPSHOT 命令。
 调用 SQL Snapshot 函数。
 使用 Control Center。
 编写自己的应用程序，从该应用程序调用 sqlmonss() API 。
    3. Event Monitor
 一旦创建并激活了一个事件监视器（event monitor），则当指定的事件发生时，该事件监视器将收集关于数据库和任何数据库应用程序的信息。
 所谓事件是指在数据库活动中的一次更改，它可能由下列某一原因引起：
  数据库连接/断开连接。
  死锁或锁超时。
  语句执行。
  事务开始或结束。
 事件监视器是根据想要检测和记录的事件类型来创建的。
 例如， 死锁事件监视器（deadlock event monitor）等待死锁的出现；当出现死锁时，该监视器便收集并记录关于涉及死锁条件的应用程序和锁的信息。
 事件监视器可以使用 CREATE EVENT MONITOR 语句来创建，只有在被激活的时候，它才会收集事件信息。
 可以使用 SET EVENT MONITOR STATE 语句激活或禁用事件监视器。EVENT_MON_STATE 函数可以返回指定的事件监视器的状态。
 当执行 CREATE EVENT MONITOR 语句时，将创建事件监视器的定义，并将其存储在系统编目表中。
 SYSCAT.EVENTMONITORS：为数据库定义的事件监视器。
 SYSCAT.EVENTS：为数据库监视的事件类型。
 SYSCAT.EVENTTABLES：针对表事件监视器的目标表的名称。

3.3 操作系统工具
 单凭数据库工具/快照一般不能提供对系统性能的全面描述。
 例如，或许我们可以将一个数据库调整到 100% 的最佳状态，但是如果在服务器上出现了 I/O 竞争，那么该数据库就不能很好地执行。
 因此，一定要查看整体情况，确保整个 系统运行良好。
四. 每日规程 
4.1 验证所有实例是否已打开并且正在运行
 这可以通过多种方法来完成：
  1.使用 Health Center。
  2.导出/设置 DB2INSTANCE=instancename  并运行 db2start。
  3.附加到所有实例。
  4.在 UNIX 或 Linux 中，运行 ps -ef | grep db2sysc  验证对于每个实例都有一个 db2sysc 进程。
  5.在 Windows 中，检查针对每个 DB2 实例的服务是否已开启。
  只要对工作站上的所有实例（即节点）进行了编目，就可以很容易地将这种附加方法编写成脚本。
  为了在 UNIX 和 Linux 中使用 ps 命令，首先需要远程登录（telnet）到每台服务器。

4.2 验证所有数据库是否为活动的和/或一致的
 关于一致（consistent）的定义容易混淆，而且 GET DB CFG 命令的报告方式也常常会引起问题。
 按照定义，对于一个数据库，如果所有提交的事务都已经写到了磁盘上，并且任何未提交的事务都不在磁盘上，那么该数据库就是一致的。当一个数据库正在运行的时候，如果有应用程序连接到它，那么就会有一些对页作了更改的事务，也许这些事务已经被提交，但是被更改的页还没有刷新到磁盘上。在这种情况下，GET DB CFG 将报告数据库是不一致的，但实际上该数据库完全没问题。因此，仅仅获得关于所有数据库的数据库配置信息是不够的。
 一个好方法是成功地连接到所有数据库，说它好是因为它还将使不一致的数据库变得一致，从而减少将来请求连接的时间。只要对工作站上的所有数据库进行了编目，就可以很容易地将这种方法编写成脚本。

4.3 查找任何新的 Notification Log 和/或 DB2DIAG.LOG 条目
 一定要确保夜里没有发生问题。在 Version 7 中，所有错误和消息都被写到 DB2DIAG.LOG 中。由于这个原因，日志文件中的很多消息对于大多数 DBA 来说是没有用的。而在 Version 8 中，消息被分离到两个日志中。notification log （instance_ID.nfy）包含用于 DBA 的消息。而 DB2DIAG.LOG 文件则在需要报告关于 DB2 的问题时，可以为 DB2 服务小组（DB2 service team）所用。
 在 Windows 中，Notification log 被写入到 Application Event Log 中，并且可以通过 Event Viewer 来查看，方法是选择 Application log 并查找由名为 DB2 的应用程序所写的事件。
 在 Linux 和 UNIX 上，日志被写入到一个名为 <instance_ID>.nfy 的文件中，这个文件位于由 DIAGPATH 实例级配置参数指定的目录中。为了查看 notification log，可以：
 使用 telnet 或远程终端服务连接到每个服务器。
 对于每个实例，进入到 DIAGPATH 目录。
 在命令提示符下：
 对 notification log 运行 tail 命令，列出最后 100 个条目。
 编辑该文件，并查看位于文件底部的最近的一些条目。

4.4 检查前一夜的备份是否成功
 最坏的情况莫过于在系统存在问题并决定利用最近的备份进行恢复时，却发现没有作备份或者备份不完整。因此，检查前一夜的备份是否成功，以及这些备份是否存储在安全的地方，就显得非常重要了。
 第一步是确保备份成功。这可以通过 List History 命令来完成，如下所示：
 list history backup all for <db_name>
 我们可以将其编写成脚本，以便在备份完成之后运行该脚本，并通过电子邮件发送报告。然后就可以在每天早晨验证报告了。
 如果在一段持续的时间内整个服务器崩溃，那么就可能需要借助灾难恢复计划，将数据库还原到另一台服务器，这台服务器也许在另一个不同的位置。因此，一定要将备份映像（backup image）存储在一个安全的站点，而不是仅仅存放在采取备份的那台服务器上。通过将备份映像复制到一个 LAN 驱动器、一个 NFS 已安装的驱动器（mounted drive）或者一个磁带设备，可以很容易地实现这一点。

4.5 验证数据库日志是否被成功归档
 如果数据库是只读的，或者很容易从头开始重建，那么您很可能不会启用日志保留功能，所以可以略过这一步骤。然而，对于那些事务处理数据库来说，由于丢失任何提交的事务都是承受不起的，因此确保日志保留功能处于启用状态，并且日志可以成功地归档，这就显得非常重要了，因为这样一来就可以在出现灾难的时候重建数据库，并让事务重演。
 虽然灾难恢复是验证日志是否被成功归档的首要原因，但是还存在另外一个重要原因。如果日志没有归档的话，它们就会留在 LOGPATH 中。由于 LOGPATH 通常是在一个大小固定的文件系统中，如果日志文件没有归档，那么随着新日志的创建，文件系统就会慢慢地被填满。当出现这种情况时，DB2 将无法再创建日志文件，从而会停下来。
 当调用 userexit 归档一个日志文件时，它将把信息写到两个地方。第一个地方是 userexit audit log，对于 userexit 收到的每个归档日志请求，都要写一个条目到这里。如果在 userexit 执行过程中发生了错误，那么还要将一条消息写入到 userexit error log 文件中。这些日志文件位于 LOGPATH 中，文件名分别为 ARCHIVE.LOG 和 USEREXIT.ERR。
 为了检查这些日志，您可以很容易地编写一个脚本，为所有实例从这两个文件中捕捉最后 50 到 100 行（使用 tail 命令），并通过电子邮件发送给您自己。然后就可以在每天早晨将这些行与恢复历史信息放在一起研究。

4.6 学习 DB2
 从长远来看，最有价值的还是经验丰富、阅读广泛的 DBA。可供 DBA 学习的内容应该包括 DBA 手册、杂志、新闻组和邮件列表。
 对于 DBA 同仁来讲，comp.databases.ibm-db2 新闻组是学习知识、共享信息的好地方。
 在这个站点上还提供了大量的信息。
 要了解更详细的信息，您应该查找我们的 DB2 Certification Guide 系列，因为这些书籍包含的信息非常丰富。

五. 每周规程
5.1寻找新对象
 重要的是，要知道人们是否在您的生产数据库中创建新表、新索引、新存储过程，等等。新对象通常表明服务器上安装了新的应用程序，任何新的应用程序和/或对象都将影响系统的操作特征（operational characteristics）。
 此外，新的对象将消耗数据库里的空间，因此重要的是在这些对象变得太大并可能填满一个表空间之前，将它们识别出来。如果这些对象不是由 DBA 创建的，那么很可能就是在错误的表空间中创建的，这样就会导致空间和/或性能问题。
 这里有一些方法可用于检查系统中的任何新对象：
 1.每周运行 db2look 并写报告到一个文件中。
 检查新输出与上周输出之间的不同。
 2.从 SYSCAT.TABLES、SYSCAT.INDEXES 和 SYSCAT.PROCEDURES 中选择对象名称。
 检查新输出与上周输出之间的不同。
 对于任何不同之处，您可以从编目表中判定该对象的 CREATOR，并利用该信息追溯到创建该对象的人。

5.2 查找新的或更改过的应用程序
 如果根据当前工作负载对数据库作了优化，那么最令人沮丧的就是收到一个呼叫，说数据库没有运行良好，并且发现这么差的性能是由于新应用程序或者对已有应用程序的更改引起的，而关于这一点没有人告诉您什么。不幸的是，这种现象随处可见。对于新的和/或更改过的应用程序，通过监控数据库，就很有希望在这些更改导致性能问题之前就检测到它们。
 为了查找新的应用程序，可以使用 list applications show detail命令。如果将该命令的输出重定向到一个文件，并将这些文件保留一段时间，就可以在每个星期比较一下这些文件，看看输出中是否突然出现了新的应用程序名。
 为了查找更改过的应用程序，可以查看当前正在系统运行的 SQL，并查找之前没有运行过的新的 SQL。要做这些事情，可以像下面这样创建一个表：
 create table SQLstmts ( stmt varchar(200), tstamp timestamp not null with default)
 接着从当前的包缓存中获取 SQL 语句，并使用下面的语句将这些 SQL 语句插入到一个表中以用于分析：
 insert into SQlstmts (stmt)
 selectsubstr(stmt_text,1,200) as SQL_Stmt
 from table (snapshot_dyn_sql ('sample', -1) ) as snapshot_dyn_sql
 然后使用以下语句检查这个表，看有没有之前未执行过的 SQL 语句：
 select distinct stmt, count(stmt),tstamp from sqlstmts group by stmt, tstamp
 在该语句的输出中，任何计数为 1 并且 timestamp 列显示的是当前日期的语句，都是之前未运行过的语句。

5.3 查找需要 REORG 的表和索引
 当插入、更新和删除表中的行时，都要对表中的数据进行 REORG（重组），以便：
 1.按照最重要索引的顺序重新群集（re-cluster）数据。
 2.去掉散布在整个表中的自由空间。
 3.去掉溢出的记录。
 reorgchk工具将对表进行检查，并表明需要对哪些表进行 reorg。可以对单个的表、所有用户表、某个特定模式中的所有表或者所有系统编目表运行 reorgchk工具。还可以指示该工具是应该使用当前统计信息作为基础，还是应该首先收集新的统计信息。
 为了对所有表运行 reorgchk工具，并确保您正在使用当前统计信息，可使用命令：
 reorgchk update statistics on table user
 这里应将该命令的输出重定向到一个文件中，以供进一步的分析。
 当查看 reorgchk工具的输出时，找到用于表的 F1、F2 和 F3 这几列，以及用于索引的 F4、F5、F6、F7 和 F8 这几列。如果这些列中的任何一列有星号 (*)，则说明当前的表和/或索引超出了阈值。
 记住，对于一个表，如果任何列中有一个星号，那么通常就需要 reorg该表。然而，由于很多表都拥有不止一个索引，按照定义，如果某个索引是 100% 群集的，那么其他索引就不是群集的。因此，在判断是否 reorg 索引时，需要调查 reorgchk输出的索引部分，并考虑表上的所有索引。
 对 reorgchk所使用的度量的考虑因素包括：
 F1: 属于溢出记录的行所占的百分比。当这个百分比大于 5% 时，在输出的 F1 列中将有一个星号 (*)。
 F2: 数据页中使用了的空间所占的百分比。当这个百分比小于 70% 时，在输出的 F2 列上将有一个星号 (*)。
 F3: 其中含有包含某些记录的数据的页所占的百分比。当这个百分比小于 80% 时，在输出的 F3 列上将有一个星号 (*)。
 F4: 群集率，即表中与索引具有相同顺序的行所占的百分比。当这个百分比小于 80% 时，那么在输出的 F4 列上将有一个星号 (*)。
 F5: 在每个索引页上用于索引键的空间所占的百分比。当这个百分比小于 50% 时，在输出的 F5 列上将有一个星号 (*)。
 F6: 可以存储在每个索引级的键的数目。当这个数字小于 100 时，在输出的 F6 列上将有一个星号 (*)。
 F7:在一个页中被标记为 deleted 的记录 ID（键）所占的百分比。当这个百分比大于 20% 时，在输出的 F7 列上将有一个星号 (*)。
 F8: 索引中空叶子页所占的百分比。当这个百分比大于 20% 时，在输出的 F8 列上将有一个星号 (*)。
 在重组一个表的时候，可以选择指定 DB2 应该按哪个索引群集数据。为了基于 ORGX 索引 reorgORG 表，可以使用命令
 reorg table org index orgx

5.4 查找需要 RUNSTATS 的表和索引
 DB2 优化器使用数据库统计信息来决定 SQL 语句的最佳访问计划。如果对表中的数据总量或者数据本身作了重大更改，则应使用 runstats工具捕捉新的统计信息，并将这些信息存储在系统编目中。还应确保对于任何新的表或索引都捕捉到了统计信息。
 为了捕捉上述 ORG 表及其索引的统计信息，使用命令
 runstats on table <schema>.org with distribution and detailed indexes all
 注意：在使用 runstats 命令的时候，必须指定表所在的模式。
 可以使用如下语句来检查任何没有统计信息的表：
 select tabname from syscat.tables where stats_time is null
 可以使用如下语句来检查任何没有统计信息的索引：
 select indname from syscat.indexes where stats_time is null
 可以使用如下语句来查找具有时间超过 30 天的统计信息的表和索引：
 select tabname from syscat.tables
 where stats_time < current timestamp - 30 days
 select indname from syscat.indexes
 where stats_time < current timestamp - 30 days

5.5 归档所有 Alert Logs 和 DB2DIAG.LOG 文件
 定时地清除诊断日志是一个很好的习惯。这样一来，当发生错误时，就不必回顾日志中过去 6 个月的信息，这时日志要小得多，同时也容易编辑得多。在清除文件之前，应先做一个备份，以防在将来某个时候想要回头调查系统在某个时间点上曾发生过什么。
 在 Windows 上，可以在 Event Viewer 中将事件日志保存到另一个文件，方法是选择 Action 菜单，再选择 Save Log File As& 选项。然后，就可以通过选择 Action 菜单，再选择 Clear All Events 选项将条目从日志中清除。
 注意：用当前日期命名该文件是一个好的习惯，这样使得在以后某天回头查看文件时更方便。
 对于 Linux 和 UNIX 上的 DB2DIAG.LOG 文件以及 administration notification log 文件，应该进行压缩，然后在命名时也使用当前日期。
 在 Linux 或 UNIX 上，可以将 *.nfy 和 db2diag.log 文件归档到一起，然后使用 gzip或 compress减少最终文件的大小。

5.6 对软件更新的检查
 知道当前运行的软件是否有更新总是有益的。如果系统运行顺利，您可能不想应用任何服务到服务器上。通过阅读 fixpak / service 包中所含的关于修复（fix）的信息，在面临是否应用修复包（fixpack）时就能作出有根据的决定。如果碰到了问题，则可以查看修复描述，以判断其中是否存在可以解决当前问题的修复。
 从 DB2 的角度来看，最重要的 Web 站点是 DB2 for Linux, UNIX, and Windows Technical Support Page：
 http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP
 为了确保自己清楚何时有新的 fixpak 提供，一种方法是订阅以下站点的 DB2 Alerts：
 http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report

六. 每月规程
6.1 查找异常增长的指示器
 检查表和表空间，看看上个月它们的增长情况。如果知道了表和表空间的增长速度，以及还剩下多少可用空间，就可以事先检测潜在的空间问题。
 通过使用以下语句，可以获得表空间的大小和可用空间的大小。
 select substr(tablespace_name,1,120) as TBSPC_NAME,
 used_pages, free_pages,
 from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg
 通过查看系统编目表，可以知道每个表的大小。只要统计信息是时新的，上述信息就可以准确无误。为了获得表的大小，可以使用语句
 select tabname, npages from syscat.tables where tabname not like 'SYS%'
 注意：如果没有捕捉到某个表的统计信息，则 npages 上的值就是 -1。
 创建一个历史表来存储该信息，这样就可以详细调查表和表空间对空间的使用情况。

6.2基于有计划的增长规划未来的性能
 比较一直以来收集到的关于系统级 CPU、内存、网络和磁盘利用率的信息，以及收集到的 DB2 对象信息，以便识别出可能导致将来这些资源存在争用或短缺现象的趋势。
 根据对上述信息的分析，就可以在这些状况发生之前制订针对性的计划，并采取行动组织这些状况的发生。
 下面的附录包含了一些有用的脚本，这些脚本可用于监控系统和数据库。注意，这些脚本写在用 CLP 运行的文件中，因此含有注释。注释的前面有双破折号（ --），如果直接在命令行中运行这些命令的话，需要将注释去掉。

附录 1：表空间信息脚本
-- 创建一个名为 tablespaceinfo 的表来存储从表空间的快照信息以用于分析。
create table TablespaceInfo(
timestmp timestamp,
tablespace_name char(128),
pct_free int,
-- Percent of space free in the table space
type char(5),
-- SMS or DMS
contents char(5),
total_pages int,
-- total # of pages
usable_pages int,
-- useable pages, total - tag, etc..
used_pages int,
-- # of pages used
free_pages int,
-- # of free pages
page_size int);
-- page size

-- 向 tablespaceinfo 表中插入快照信息以用于分析。
insert into tablespaceinfo
select
current timestamp,
substr(tablespace_name,1,120) as TBSPC_NAME,
(case
-- We can calculate pct free for DMS table spaces only as total_pages is
set to 0 for SMS by this stmt...
-- Therefore, check if DMS, and then calculate pct_free as 1-
(used/total) * 100%
when tablespace_type = 0 then (int( (1- (decimal(used_pages) /
decimal(total_pages))) * 100) )
-- For SMS set pct_free to 100... Could set to any numeric value.
else 100
end) as pct_free,
(case
-- Display the table space type, i.e. DMS or SMS as a string, not the numeric
value in the info.
when tablespace_type = 0 then 'DMS'
when tablespace_type = 1 then 'SMS'
-- Only 0 and 1 are VALID, therefore return an error for anything else.
else 'Error'
end) as Managed_By,
(case
-- Display the type of data that can stored in the table space, i.e. TEMP,
LARGE/LOB OR ALL,
not the numeric value in the info.
when tbs_contents_type = 2 then 'TEMP'
when tbs_contents_type = 1 then 'LARGE'
when tbs_contents_type = 0 then 'ALL' end) as Data_Type,
-- Also return the total_pages using the heading ALLOCATED PAGES,
total_pages as allocated_pages,
usable_pages,
used_pages,
free_pages,
page_size
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg
order by pct_free;
select tablespace_name,
date(timestmp) as dte,
pct_free
from tablespaceinfo
group by tablespace_name, pct_free, timestmp ;

附录 2：表空间容器信息脚本
-- 输出用于支撑每个表空间容器的名称、大小和类型。
-- 设定数据库名称参数为空表明是从当前连接的数据库获取信息。
select
substr(tablespace_name,1,12) as TBSPC_Name,
substr(Container_name,1,67) as Cont_Name,
(case
when container_type = 0 then 'SMS Directory'
when container_type = 6 then 'DMS File'
else 'DMS Device'
end) as Container_Type,
usable_pages
from table (snapshot_container (' ', -1) ) as snapshot_container;

附录 3：缓冲池 - 表空间信息
-- 输出缓冲池的名称和大小以及每个相关表空间的名称和大小。这有助于更好地规划表空间的大小。例子中首先按 bpname 分组来获取与每个缓冲池相关的所有表空间。
select substr(b.bpname,1,12) as BufferPool,
b.npages as BP_Pages,
substr(t.tbspace,1,12) as TableSpace,
usable_pages as TBSPC_Pages
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg ,
syscat.tablespaces t, syscat.bufferpools b
where t.bufferpoolid = b.bufferpoolid
and t.tbspace = tablespace_name
group by b.bpname, t.tbspace, usable_pages, npages;

附录 4：检索最重要的数据库快照信息
-- 输出从数据库快照中得出的最重要的性能相关信息。
-- 设定数据库名称参数为空表明是从当前连接的数据库获取信息。
select
db_name,
rows_read,
rows_selected,
-- The ratio of rows read to rows selected should be as close to 1-1 as possible.
lock_waits,
lock_wait_time,
deadlocks,
lock_escals,
total_sorts,
total_sort_time from table (snapshot_database (' ', -1) ) as snapshot_database;