本文展示了将 DB2 UDB 历史文件放入一个表中，再以这个表为基础执行管理任务的一种方法。

简介
DB2® Universal Database™ (UDB) 历史文件包含了恢复事件和管理事件的记录，它与 OS/390® 系统下 DB2 中的 SYSIBM.SYSCOPY 表是等效的。除了包含恢复和备份事件之外，历史文件还保存一些 DDL 事件，比如针对表空间和表的 CREATE、 altER、DROP 和 RENAME。对 DB2（OS/390 下）中 SYSIBM.SYSCOPY 表的使用大部分局限于恢复场景和记录对表空间的处理活动这两个方面。DB2 UDB 上的历史文件在以下两点上比 SYSCOPY 表要更胜一筹：

• 它有更细的粒度——在表层次上记录事件。
• 它所记录的事件并不局限于恢复场景，还包括 DDL 类的语句。

然而，如果 LIST HISTORY 输出可以以表的形式来捕捉，而不是以普通输出情况下的文本文件格式来捕捉，那么它就可以使得分析和使用更加容易。在本文中，我将解释如何通过使用您自己的 SYSCOPY 表来做这件事情。

本文介绍 Solaris 和 Linux 下的 DB2 V8.1 Enterprise Server Edition fix pack 1 (single-partition) 服务器 。 可下载的 zip 文件中提供的代码在 Solaris 和 Linux 下的 DB2 V8.1 ESE 上运行良好。

为什么将历史数据放入表中？
DB2 LIST HISTORY 命令的确带有一些参数，这些参数返回特定的信息，但您对给命令的使用还是有些限制。 例如，检索某个对象（假设是 obj1 ）自 2003 年 5 月以来的备份的详细信息就不是那么轻松的事情，因为 LIST HISTORY 命令允许您要么指定 SINCE <timestamp> 部分， 要么指定 CONTAINING <object_name> 部分，但是不能同时指定这两部分。

一旦 LIST HISTORY 中的数据被捕捉到一个表中，我们就可以查询该数据，以生成对数据库的管理活动的报告。在联邦服务器群（federated server farm）上，这个表中的数据可以为您提供针对远程数据库的活动的概述。我还将讨论一种备份策略，它不是时间表驱动的（scheduler-driven），而是使用我们的 SYSCOPY 表，并且维护一个用于存储频率信息的驱动表。最后，我们将看一下使用 SYSCOPY 表的日志文件维护。

接下来几节中的例子使用 DB2 命令行来调用脚本。因而这里没有对任何工作或脚本时间表的引用。理想情况下，这些脚本将按照 DBA 通过时间表指定的时间运行。根据数据库上的活动，您可以设置运行频率，使其尽可能接近您想要的实际时间（对于日志归档脚本更应如此，因为当存放活动日志目录的磁盘崩溃时，日志归档脚本对于恢复来说是至关重要的）。

恢复方面在本文中不会涉及。将必需的日志从归档文件路径移到活动目录是恢复过程的一部分，这些日志文件可以从 SYSCOPY 表中识别出来。

SYSCOPY 表的定义和设置
我们将在 DB2 UDB 上使用一个名为 <user>.SYSCOPY 的表来模拟 OS/390 下 DB2 中的 SYSCOPY 表结构。我们将使用一个 perl 脚本格式化来自历史文件的输出，通过这样做就可以用 LIST HISTORY 命令得到的数据来填充这个表。

图 1 展示了 <user>.SYSCOPY 表的描述。在您想在其中分析 LIST HISTORY 输出的那个数据库中创建这个表。

图 1. <user>.SYSCOPY 表

对该表创建以下索引：

• Index1 on (NAME, OBJECT and OPERATION)
• Index2 on (TIME_STAMP DESC)

脚本 syscopy.pl （在可下载的 zip 文件中）填充 <user>.SYSCOPY 表。

用法：

            syscopy.pl <dbname> -<full/incremental>