数据库系统就像一辆高性能的赛车，需要一些例行检查来保证其运行良好。本文介绍何时去监视数据库的运行以及阶段时间内数据库管理人员应该如何做。随着数据库自动运行维护技术的提高，维护数据库的人工劳力也降低了不少。监视数据库系统的运行是为了确保当前状态下数据库没有错误配置并且能发现潜在故障。
正常情况下，需要对DB2和操作系统两方面来进行监视，以获得服务器上数据库的运行状态的全面信息。建议至少连续1个小时地监视每隔1到5分钟的系统快照状态数据来分析系统的健康状况。

基本知识
在Linux或Unix平台下可使用vmstat和iostat等命令工具来监视CPU和内存的使用情况，这些命令后面可带2个参数，第一个是以秒记的间隔时间，按这个时间间隔运行命令，第二个是以秒记的连续时间段，在这个时间段结束时命令也就会自动停止执行。例如，下面两条命令：vmstat 300 28800 >vmstat.out 以及 iostat -tx 300 28800 > iostat.out，其中300秒是5分钟，28800秒是指8个小时。第二个参考命令中的-tx开关不是在所有的Linux/Unix平台下都有效，有了-tx开关将在每条输出的系统状态快照信息的开头位置打上信息产生的时间标志。
注意保证数据库运行的峰值负载别超过服务器系统许可的范围。Windows平台下可以使用图示化的任务管理器窗口来监视系统内CPU和内存的运行状态，但不能将结果记录到文件中。
DB2使用多种工具用来监视数据库系统以及数据库实例的运行和活动情况，这些工具比如健康中心、快照监控器、SQL快照函数以及事件监控器等。还有一些管理日志文件也记录了一些系统运行状态信息，比如DB2DIAG.LOG以及内存可视化工具等。
1-健康状况监视器，通过监视DB2数据库实例的运行状态来预测发生潜在问题的可能性，及时通知用户对非健康实例进行处理。一旦监测到错误，可以通过email告知用户或运行预设CLP脚本的方式来进行处理。健康状态监视器对预先设定的各种健康指标的阀值进行监视，指标突破阀值将产生警报或触发预设处理脚本。健康管理中心则提供了对健康监视器的图形化显示接口，命令和API都可以从健康管理中心运行，在管理中心可对健康管理器进行配置，看到数据库实例和对象的累积的报警信息以及处理办法。
2-快照监视器及SQL快照函数，DB2负责维护的数据有操作方面、性能方面、以及来访数据库的应用程序方面，比如你可以从数据中找到，正在连接数据库的应用程序数以及应用程序正在执行哪些SQL语句，还可帮助你进行数据库配置调优，以及正在被应用程序占用和锁住的表等数据库对象有哪些，以及SQL语句的执行内容和次数等等详细信息，还有每条SQL语句占用的CPU时间等等。还有排序动作的发生次数以及正在发生的排序动作也可以被快照监视器记录到。
监视器开关（monitor switches）可单独地针对特定数据库对象进行监视，这些对象有实例、实例中的全部数据库、或数据库会话。使用会话监视开关的命令是UPDATE MONITOR SWITHES或调用sqlmon()接口API函数。举例说明，开启缓冲池、锁以及动态SQL语句监视可以使用以下命令：update monitor switches using bufferpool on lock on statement on。注意你必须要拥有sysadm,sysctrl,sysmaint,或sysmon（db2 9新增）权限才可以扳动监视器开关执行快照运算。利用事件察看器也可以访问数据，在命令行下使用GET SNAPSHOT命令，调用SQL快照表函数，使用控制中心，以及调用sqlmonss()接口函数自己编程来进行数据访问。
3-事件监视器，启动该监视器后，将记录数据库的连接/断开，死锁或锁超时，语句执行以及事务开始或结束等事件信息。比如一个死锁事件监视器负责监视死锁事件的发生，一旦死锁情况发生应用程序的信息以及造成死锁的条件将被收集和记录，可以使用CREATE EVENT MONITOR语句来生成事件监视器，监视器只有在激活的情况下才可以记录事件信息，激活/停止监视器的命令是：SET EVENT MONITOR语句。EVENT_MONITOR_STATE函数将返回指定的事件监视器的当时状态。
一旦执行了CREATE EVENT MONITOR命令，事件监视器的定义集将生成并存放在系统类目表中，例如：
为数据库定义的事件监视器SYSCAT.EVENTMONITORS，
为数据库监视的事件类型SYSCAT.EVENTS，
以及需要监视的目标表的名称SYSCAT.EVENTTABLES等。

注意对整个数据库系统（包含OS以及DBMS两个方面）的状态进行监视，以确保数据库环境能良好地运行。
每天做的
1-确保所有实例启动并运行。有以下一些方法：

使用健康中心图形环境；

export/set DB2INSTANCE=实例名称，然后运行db2start命令；

使用脚本来附加所有实例；

察看每个实例至少有一个db2sysc进程，具体命令是ps -ef|grep db2sysc；在Windows平台下检查每个DB2实例的服务是否启动。

一致性定义混乱后，执行GET DB CFG命令经常会引发问题。只有被确认后的事务数据才写入磁盘中保存，比如某些应用程序发生的事务改变了一些数据库页，事务可能被确认，但那些被改变的数据库页面文件也可能不会从缓冲写入磁盘。也有事务回滚但页面内容写入磁盘的情况发生。检查这种数据库一致性问题，可以用编写脚本的方式来完成，前提是所有数据库应该被分类在工作之上。

管理员提醒日志为DBA准备，DB2DIAG.LOG文件为DB2服务小组而准备。在windows平台上通过察看事件管理器中的应用程序事件来获得DB2事件信息。在Linux/Unix平台下日志文件被写入<instant_ID>.nfy的文件中，存放在DIAGPATH指定的目录中，察看的方法有：使用TELNET或远程终端服务登陆数据库服务器进行察看，对单独的实例可察看DIAGPATH目录，在命令行模式下，针对管理员提醒日志文件运行tail命令获取最后100条日志信息，编辑文件察看文件底部最近的日志纪录条目。

晚上备份如果有错或没有存放在安全的地方，那么对日后的恢复来说简直就是灾难。确认备份成功的命令是：list history backup all for 跟上数据库名称作为参数。可以使用脚本方式在备份过程结束后运行该命令，并且将结果email给用户，异地的备份文件可通过LAN驱动器、NFS驱动器或磁带设备来恢复。如果不能丢失任何确认事务信息记录，请开启数据库日志功能。<待续...>

如果是只读数据库或内容可以从草稿中方便地恢复，那么管理员就不必启用数据库日志功能，因此可略过此段介绍。但如果管理的是事务性的数据库，那么任何一个确认性事务处理都应该被记录到日志中，而且日志文件应该成功备份，当灾害发生时，数据库内容以及发生的事务才能够被恢复和再现。需要校验日志文件是否被成功归档的另外一个重要原因是，日志文件如果不归档，那么它们将遗留在LOGPATH目录中，该目录空间大小固定，一旦被旧日志内容充满没有归档处理，将使新的日志文件无建立的空间而导致DB2数据库的停机。归档一个日志文件时，将调用userexit进程，调用结果会被写入到LOGPATH目录中的ARCHIVE.LOG和USEREXIT.ERR两个文件中，管理员可通过编写并执行含有tail命令的脚本来读取这些日志文件的最后50到100行的日志记录条目，供分析用。

在有多个管理员的数据库环境下，经常会发生某个管理员改动配置参数而其他管理员不知晓的情况，所以管理员需要检查数据库相关配置文件的正确性，通过下列命令实现：“get dbm cfg” 和“get db cfg for 具体数据库名称”。将这些命令的结果输出到一个文件，文件名可写上当时的时间，比如结果文件名“DB_DBM_CFG.06122006.out” ；使用diff命令来比较各天的配置文件有无改变，例如：“diff DB_DBM_CFG.02032006.out DB_DBM_CFG.02042006.out”，如果两个配置文件内容有不一样的地方，将被显示出来。

对一个在线事务处理系统(OLTP)来说，缓冲池的利用比率是非常重要的。数据仓库应用中不可能有非常高的缓冲池利用率，所以根据工作负载量来进行各项性能检查就显得很重要了。

下面的这条语句将计算日期、索引和缓冲池利用率以及异步读取内容的百分比：

“select substr(bp_name,1,20) as BP_NAME, int ((1- (decimal(pool_data_p_reads) / nullif(pool_data_l_reads,0)))*100) as data_hit_ratio, int ((1-(decimal(pool_index_p_reads)/nullif(pool_index_l_reads,0)))*100) as index_hit_ratio, int ((1-(decimal(pool_data_p_reads+pool_index_p_reads)/nullif((pool_data_l_reads+pool_index_l_reads),0)))*100) as BP_hit_ratio, int ((1-(decimal(poo_asyn_data_reads+pool_asyn_index_reads)/nullif((pool_async_data_reads+pool_async_index_reads+direct_reads),0)))*100) as Async_read_pct, int ((1-(decimal(direct_writes)/nullif(direct_reads,0)))*100) as Direct_RW_Ratio from table (snapshot_bp ('sample', -1)) as snapshot_bp;” 。

注意上面语句中的nullif函数，当()中的值等于零时将返回NULL，否则除零语句将会出错。下面的查询语句将报告被读或被写的记录的行数等：“select substr(table_schema,1,8) as Schema, substr(table_name,1,30) as Table_Name, rows_read, rows_written, overflow_accesses from table (snapshot_table ('sample', -1)) as snapshot_table;”。

如果要检查所有数据库中的读写行数对比、发生的等锁数、总的锁占用时间、单位时间内的锁占用数量、死锁或锁增加趋势、发生了多少次排序操作以及相关的时间量等数据库使用模式，可以执行下一条语句：“select db_name, SNAPSHOT_TIMESTAMP,rows_read, rows_selected, lock_waits, lock_wait_time, lock_wait_time/nullif(lock_waits,0) as avg_wt_time, deadlocks, lock_escals, total_sorts, total_sort_time, total_sort_time/nullif(total_sorts,0) as avg_sort_time, sort_overflows, sort_overflows/nullif(total_sorts,0) as pct_ovflow_sorts from table (snapshot_database ('',-1)) as snapshot_database;”。

虽然自动化程度提高了，但对于自动化的结果管理员还是需要关注的，这些就包括配置参数以及表空间的分配的细节了。跟踪表空间分配情况用“list tablespaces show detail” 命令；内存自动调优的日志记录到stmmlog目录下的stmm.#.log文件中。在windows系统下stmmlog目录位于SQLLIB\Instance目录下，Unix/Linux系统下的stmmlog目录位于不同用户的SQLLIB目录下。

察看服务器上的总内存大小和DB2数据库占用的内存大小情况是很重要的一件事，在Unix/Linux平台下使用free命令将显示出系统的总内存大小以及被应用程序占用掉的内存大小，和当前系统剩余可用的内存大小。

广泛的阅读相关资料，比如“DBA手册、杂志、新闻组以及邮件列表等”对数据库管理员有帮助，comp.databases.ibm-db2新闻组就是一个不错的参考知识站点。而且DB2认证系列图书也很有提醒价值。

察看是否有人在你的生产型数据库中建立了新的数据库对象（比如，表、索引、存储进程、）也是一件重要的事情。新对象的出现，一般意味着服务器上有新的应用出现了，否则新出现的对象会影响到系统操作的特性。另外新对象也会消耗掉系统的一部分存储空间，如果是非管理员建立的新数据库对象将可能会对数据库表空间和运行效率产生不良影响。有几种方法用来检查DB2数据库中的新对象，比如，通过运行“db2look”命令并对每周输出结果写报告对比的方式；或者采用从SYSCAT.TABLES,SYSCAT.INDEXES,SYSCAT.PROCEDURES表中列出对象名的方法来进行每周的比较处理。通过发现新对象的建立者CREATOR来进行维护管理。

因为经常会发现应用程序开发人员调整了应用程序中的代码，而没有及时告诉数据库管理调优人员，导致调优工作经常需要反复。所以数据库管理员经常需要查找新的或变化了的应用程序。采用“list applications show detail”命令将输出结果保存到文件供每周对照，以发现有无新应用程序出现。

采用建立新表来观察运行的sql语句的方式，来发现有无改变了的应用程序代码：首先“create table SQLstmts (stmt varchar(200), tstamp timestamp not null with default)” ，然后“insert into SQLstmts (stmt) select substr(stmt_text,1,200) as SQL_Stmt from table (snapshot_dyn_sql ('sample', -1)) as  snapshot_dyn_sql” 最后察看有无当前未执行的语句“select distinct stmt, count(stmt), tstamp from sqlstmts group by stmt, tstamp”结果中注意那些是1的语句对象。

当在表上插入、更新、删除记录行时，表中的数据需要重新组织，以便使索引、空间、记录等能更优化地存在。采用的命令工具是“reorgchk”，该工具可针对单个表、所有用户表、以及指定计划中的所有表、或所有的系统分类表。该工具还能直接读取系统表中的已有统计或自己重新收集统计数据，例如，执行命令“reorgchk update statistics on table user” 检查用户的所有表的已有统计数据。当察看reorgchk命令工具输出的结果时，F1,F2,F3用户的表列；F4,F5,F6,F7和F8用户的索引列，其中如果发现*值，就表示那列的值超出了DB2的限制。出现*值需要部分调整索引的组织，这里比较繁琐，暂时忽略。各列相关内容简介：“F1列：超值记录条，F2列：数据页面上的已用空间，F4列：丛串的比率，F5列：每索引页面使用键值的空间，F6列，每索引级别上可存放的键数量，F7列：每页上已经被标记删除的记录IDs，F8列：索引中的空子页”。比如针对ORG表进行ORGX索引重新组织，可采用命令“reorg table org index orgx”。DB2优化器可以根据使用数据库的统计数据来安排SQL语句的优化执行。如果用户的数据库表中数据发生了很大的变化，那么就有必要使用“runstats” 命令工具捕获新的统计数据，并将这些新数据存到系统表中去，确信对新表和新索引做了统计数据捕获。比如，使用命令“runstats on table <schema>.org with distribution and detailed indexes all”对ORG表进行捕获操作，注意命令中必须指定对象表的schema值。

察看7天以上或无相关统计数据的表的命令是“select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.systables where stats_time < ((current timestamp) - 7 days) or stats_time is null” 或者执行“select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.sysindexes where stats_time < ((current timestamp) - 7 days) or stats_time is null”。

根据被读的频率来确定需要执行reorg或runstats命令的表，使用以下语句：“select substr(table_schema,1,10) as tbschema, substr(table_name,1,30) as tbname,rows_read,rows_written,overflow_accesses,page_reorgs from table (SNAPSHOT_TABLE(' ', -1)) as snapshot_table order by rows_read desc fetch first 10 rows only”，根据被写的次数找出10张更新最频繁的表使用以下语句：“select substr(table_schema,1,10) as tbschema,substr(table_name,1,30) as tbname, rows_read, rows_written, overflow_accesses, page_reorgs from table (SNAPSHOT_TABLE(' ', -1)) as snapshot_table order by rows_written desc fetch first 10 rows only”，通过这些命令发现的表需要做runstats或reorg等处理。

这些日志文件需要每周做处理，保存以便将来调查分析，压缩保存以节省存储空间，Unix/Linux系统下使用tar命令将所有*.nfy文件以及db2diag.log文件聚集在一起，然后用gzip或compress命令压缩结果文件的大小，Windows平台下使用日志文件窗口处理这里就不再啰嗦了。

当系统平稳运行时，一般不需要升级或补丁自己的DB2软件。可关注的两个DB2相关软件更新的地址是：“[url]http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP[/url]” 和“[url]http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report[/url]” 。

回顾表空间在过去的一个月时间里，增长了多少，发现特别消耗空间的表，以便提前做预处理。比如，采用以下命令“select substr(tablespace_name,1,120) as TBSPC_NAME,used_pages, free_pages from table (snapshot_tbs_cfg (' ', -1)) as snapshot_tbs_cfg”获取表空间大小以及剩余可用空间大小。从系统类别表中察看用户表空间的大小，执行语句是“select tabname,npages from syscat.tables where tablename not like 'SYS%'”，注意如果表的统计数据没有捕获，那么npages值将显示-1。结果可以输出到外部文件来分析。

比较你收集到的处理器、内存、以及磁盘利用率等系统级信息，规划DB2数据库对象今后扩展的对策。