db2日常维护和管理

DB2 中常用的管理工具包括图形化的控制中心, 命令行处理器(db2cmd) ，命令窗口。后
两者的处理能力是等价的。本文的命令操作缺省都在DB2 命令窗口中执行：

第一部分 DB2 日常基本的管理命令

(一）实例的启动和停止
启动实例： db2start
停止实例 db2stop
由于实例上运行的进程，实例往往不能直接停下来，而您需要强行停止实例，可以通过
db2stop force 强行停止实例。

(二）数据库的编目和访问
为了实现从本地客户端远程访问服务器上的DB2 数据库，需要先将远程的数据库编目
(Catalog) 到本地，编目可以理解为访问的快捷方式。通过命令行的实现要分为两步：

第一步：将远程服务器编目(Catalog) 到本地的节点Node, 假设我们要访问的服务器IP
地址为192.168.1.9; 其中DB2 提供服务的端口号为50000; Catalog 到本地后给定远程节点的
别名为DB2Server, 命令实现如下：

Catalog tcpip node DB2Server remote 192.168.1.9 server 50000
第二步，将已经Catalog 过的远程服务器上的数据库Catalog 到本地:
紧接上步，服务器192.168.1.9 上被编目到本地的节点DBServer, 下面我们将服务器上

名称为Demo 的数据库编目到本地，给它一个新的别名为Test ，当然也可以不改变原有数
据库名字，命令实现如下：

catalog db Demo as Test at node DB2Server

为了使编目生效，需要在每次操作完成后，通过命令terminate 命令刷新高速缓存。

访问一个本地的库，可以直接通过connect to db (db 代表数据库的名称)实现；
访问远程的库往往需要指明用户名和密码；例如

db2 connect to HR user db2admin using db2admin
这是由DB2 的认证方式决定的，本地的库缺省认为以当前系统用户身份连接，已经经
过操作系统认为，连接远程的库缺省情况下是Server 认证，所以需要输入用户名和密码。

(三) 了解系统中的数据库对象

在(二)中两步操作我们完成了在本地对远程服务器访问，您需要远程访问的数据库服务
器往往不止一个，经过一段时间后，您本地往往会有多个经过编目的服务器和库。作为管
理员的您需要清楚目前本地编目了哪些服务器和库，可通过下列操作实现：


（1）查看当前系统中的节点目录
命令： list node directory
返回在您本地编目过的远程服务器，类似如下结果，其中您可看到节点的IP 和端口号：
节点目录

目录中的条目数 = 1

节点 1 条目：

节点名 = DBSERVER

注释 =

目录条目类型 = LOCAL

协议 = TCPIP

主机名 = 192.168.1.4

服务名称 = 50000

(2) 查看当前系统中的数据库目录：
命令：List db directory
返回在本地编目过的数据库, 类似如下结果.
系统数据库目录
目录中的条目数 = 13

数据库 1 条目：

数据库别名 = TUTWHS

数据库名称 = TUTWHS

数据库驱动器 = C:\DB2

数据库发行版级别 = a.00

注释 =

目录条目类型 = 间接

目录数据库分区号 =0

备用服务器主机名 =

备用服务器端口号 =

…….
其中可以看到数据库的别名，原名，库路径；“目录条目类型=间接”说明这个库是您
本地创建的，如果=远程说明是从远程的数据库服务器上编目而来的。

(3) 查看和修改数据库服务器的实例级注册表变量：
db2set 可以看到当前实例的注册表信息；
设置新的注册表变量可以通过 DB2SET PARAMETER=VALUE 来实现

(4) 查看实例级的配置信息：
get dbm cfg
(5) 查看数据库一级的配置信息：
首先通过Connect to 语句连接到数据库，然后
get db cfg 查看在数据库上具体的配置信息
(6) 查看表空间相关的信息
db2 list tablespaces
得到类似如下结果
当前数据库的表空间

表空间标识
名称
类型
内容
状态

详细解释：
正常

表空间标识
名称
类型
内容
状态


详细解释：
正常

=0
= SYSCATSPACE
= 系统管理空间
= 任何数据
= 0x0000

=1
= TEMPSPACE1
= 系统管理空间
= 系统临时数据
= 0x0000

其中状态码反映了当前连接的数据库每个表空间的状态，每个码描述一个状态：

. 0x0 Normal
. 0x1 Quiesced: SHARE
. 0x2 Quiesced: UPDATE
. 0x4 Quiesced: EXCLUSIVE
. 0x8 Load pending
. 0x10 Delete pending
. 0x20 Backup pending
. 0x40 Roll forward in progress
. 0x80 Roll forward pending
. 0x100 Restore pending
. 0x100 Recovery pending (not used)
. 0x200 Disable pending
. 0x400 Reorg in progress
. 0x800 Backup in progress


. 0x1000 Storage must be defined
. 0x2000 Restore in progress
. 0x4000 Offline and not accessible
. 0x8000 Drop pending
. 0x2000000 Storage may be defined
. 0x4000000 StorDef is in 'final' state
. 0x8000000 StorDef was changed prior to rollforward
. 0x10000000 DMS rebalancer is active
. 0x20000000 TBS deletion in progress
. 0x40000000 TBS creation in progress
. 0x8 For service use only

(7) 查看表空间的容器一级的更详细的参数信息
db2 list tablespaces show detail

表空间标识
名称
类型
内容
状态

详细解释：

正常
总计页数
可用页数
已用页数
可用页数
高水位标记（页）
页大小（以字节计）
扩展数据块大小（页）
预取大小（页）
容器数


=2
= USERSPACE1
= 系统管理空
= 任何数据
= 0x0000

= 910
= 910
= 910
= 不适用
= 不适用
= 4096
= 32
= 32
=1


（8）对数据库中的某个表，了解构成这个表的各个列的详细信息，可通过：
describe table Tablename
（四）更改配置信息：

（1） 实例一级：
db2 update dbm cfg using parameter value

 (2) 数据库一级：
db2 update db cfg using parameter value
(3) 对于实例及数据库一级的配置，也可以采用DB2 的自动配置工具来调整，
对于数据库一级：db2 AUTOCONFIGURE apply db only
对于实例一级：db2 AUTOCONFIGURE apply db and dbm
数据库自动判断参数的合适取值，并更改了相应的参数值。
注：有些参数需要重启实例才能生效。
第二部分 DB2 监控

1. SNAPSHOT 监控工具
当用户抱怨系统运行慢，应用被挂起的时候，应该去检查是否存在数据库上的锁的问题。
snapshot 是一个非常有用的监控工具, 可以查看系统当前关于锁，SQL,应用等的快照,用户
可以查看到：

. 与一个数据库连接的应用程序数、它们的状态和每个应用程序正执行哪些 SQL 语句（如果
存在的话）。
. 显示数据库管理器和数据库是如何配置的以及帮助您调整它们的信息。
. 当特定数据库发生死锁时，涉及到哪些应用程序，又有哪些锁定处于争用中。
. 一个应用程序或一个数据库挂起的锁定的列表。如果由于应用程序在等待锁定而不能继续执
行，则存在有关该锁定的附加信息，包括哪个应用程序挂起该锁定。
运行 Snapshot去监控相应对象之前，应使用UPDATE MONITOR SWITCHES 打开相应的监
视器开关。例如打开锁开关： UPDATE MONITOR SWITCHES using lock on

类似的，您可以打开 BUFFERPOOL，SORT ，STATEMENT，TABLE，UOW 的开关。

监控具体对象的运行可以通过：db2 get snapshot for locks 来执行，其他对象的监控等同。

2. 运行Snapshot 的同时，应该结合系统运行的状态来判断
通过vmstat 来查看操作系统是否达到CPU 和IO 的瓶颈;

通过iostat 查看IO wait.

3. 通过日志db2diag.log 来监控
关于DB2 系统错误的诊断信息记录在此文本日志文件中。

. 在 Windows(R) 系统上，此文件位于 x:\sqllib\db2\db2diag.log，其中 x: 表示逻辑驱动器，
db2 表示实例名。
. 在 UNIX(R) 系统上，此文件位于 /u/db2/sqllib/db2dump/notifyloglevel.nfy，其中 db2 表
示实例名。
在该日志文件中，您会看到类似如下的条目：

2002-02-05-03.14.39.020766 1 实例：db2inst1 2 节点：000 3


PID:89198(db2agent (MYDB )) 4 Appid:*LOCAL.db2inst1.020205091435 5
恢复管理器 6 sqlpresr 7 探测：1 8 数据库：MYDB 9
ADM1530E 10 已启动崩溃恢复。 11

图注：

1. 消息的时间戳记。
2. 生成消息的实例的名称。
3. 对于多分区系统，生成消息的分区。（在非分区数据库中，该值为“000”。）
4. 写消息的 DB2 组件。对于由用户应用程序使用 db2AdminMsgWrite API 编写的消息，该组
件将读取“用户应用程序”.
5. 进程正在运行的应用程序的标识。在本示例中，生成消息的进程代表标识为
*LOCAL.db2inst1.020205091435 的应用程序工作。
6. 编写消息的 DB2 组件。对于由用户应用程序使用 db2AdminMsgWrite API 编写的消息，
该组件将读取“用户应用程序”。
7. 提供消息的函数的名称。此函数在编写消息的 DB2 子组件中运行。对于由用户应用程序使
用 db2AdminMsgWrite API 编写的消息，该函数将为“用户函数”。
8. 唯一内部标识。此编号允许 DB2 客户支持和开发在 DB2 源代码中定位报告该消息的位置。
9. 发生错误的数据库。
10. 以十六进制代码指示错误类型和编号的消息（如果有的话）。
11. 说明记录的事件的消息正文（如果有的话）
第三部分 DB2 性能调优与建议

(一) 系统环境

(1) 保证系统有足够的磁盘空间
(2) 将日志放在单独的磁盘上，不要与表空间放在一起
(3) 对临时表空间建议采用SMS 管理
(4) 对OLTP 不启用分区间并行 INTRA_PARALLEL 为 Disable
(5) SHEAPTHRES > 10X SORTHEAP
(6) OLTP 环境下建议日志缓冲大小LOGBUFSZ > 256 Page
(7) 根据需要调高 LOCKLIST 的大小，将参数 MAXLOCKS 的值设置为20-30%
(8) NUM_IOCLEANERS 在数据库代理进程需要缓冲池的空间之前，页清除程序将更改的页从缓冲
池写入磁盘。因此，数据库代理进程应该不必等待写出已更改的页，它们也能使用缓冲池中的空
间。对于只查询数据库，可将此参数设置为零（0）；对于事务型应用，可基于物理存储设备数和
CPU 个数决定。
(9) NUM_IOSERVERS 指定用于数据库的 I/O 服务器的数目。一个优选值通常是该数据库驻留的
物理设备的数目加 1 或 2。
(二) 设计顾问程序

对于应用的一组工作负载，用户很难决定如何生成相关索引以提高查询响应速
度，此时可以使用“设计顾问程序”来确定改进工作负载性能的最优方法。如果工作负载
中有一组 SQL 语句，“设计顾问程序”将建议使用下列一个或多个功能部件：


. 新建索引
. 新建具体查询表
. 转换至多维群集表
. 对表重新分区
. 删除指定工作负载未使用的对象
(三)DB2 控制中心还提供了“配置顾问程序”，可用来改变配置参数的值。此顾问程序根据
您对一组问题（例如，对数据库运行的事务的工作负载和类型）提供的回答来为参数
生成值。

(四) 建议：

1. Sql 语句中仅返回所需要的列；
2. 统计信息中包含了数据库中的表，昵名，索引，列，自定义函数等相关的信息。DB2 的
优化器依赖于这些统计信息来决定访问路径和查询计划，所以DBA 应该保持数据库的统计
信息与当前数据保持基本同步，尤其当数据库中发生下列操作时，应该去更新DB2 的统计
信息：
a. 向一个表中Load 数据同时定义了索引；
b. 使用Reorg 重组了表;
c. 对表中的数据执行了更新，删除，插入并影响了整个表大约10-20% 的数据;
d. 当更改了表空间的Prefetch (预取)的大小;
e. 执行过分区重组REDISTRIBUTE DATABASE PARTITION GROUP
保持统计信息最新可以直接通过在命令行处理器中运行RunStats 命令来实现。
通过下列命令可以查看数据库中近期是否更新过统计信息：
select stats_time, nleaf, nlevels, stats_time from syscat.indexes
查询结果如果在列nleaf 和 nlevels 列上为－1 说明该数据库上还没有运行过Runstats.
( 待续)


第四部分 DB2 日志

所有数据库都维护用于记录数据库更改情况的日志文件。有两种日志记录策略可供选择：

(一）循环日志记录，指的是日志记录填充日志文件，然后覆盖初始日志文件中
的初始日志记录。被覆盖的日志记录不可恢复。循环 日志记录是缺省行为。
（将 logarchmeth1 和 logarchmeth2 数据库配置参数设置为 OFF。）对
于这种类型的日志记录，只允许完整的脱机数据库备份。进行完全备份时，
数据库必须脱机（用户不可访问）。正如它的名称所表示的那样，循环日
志记录使用一个联机日志“环”，提供对事务故障和系统崩溃的恢复。仅
使用和保留日志到确保当前事务的完整性这样一个程度。循环日志记录不
允许将数据库在上次完全备份操作后执行的事务中前滚。上次备份操作后
发生的所有更改都将丢失。因为这种类型的复原操作将数据恢复至进行完
全备份的特定时间点，所以它称为 版本恢复 。崩溃恢复期间，使用 活


动 日志来防止故障(系统电源或应用程序错误）使数据库处于不一致的状
态。活动日志位于数据库日志路径目录中。

(二)归档日志记录，指的是日志文件由日志记录填满时会被存档。然后使用新的日志
文件来存放日志记录。是针对前滚恢复使用的。归档日志是曾经活动的，但不再
是崩溃恢复所必需的日志。使用 logarchmeth1 数据库配置参数来启用归档日志
记录归档日志文件可以启用 前滚恢复 。前滚恢复根据日志中记录的已完成的事
务来对数据库重新应用更改。您可以指定前滚恢复是恢复至日志末尾，还是恢复
至日志末尾之前的特定时间点。

归档日志的编号方案以 S0000000.LOG 开始，直到 S9999999.LOG，符合日志
文件的最大潜在大小 10000000。如果发生以下情况，数据库管理器将复位到
S0000000.LOG：

a.数据库配置文件更改为启用前滚恢复
b.数据库配置文件更改为 禁用 前滚恢复
c.已使用了 S9999999.LOG
无论哪种日志记录策略，对一般数据和索引页所作的所有更改都会被写入日志缓冲区。日志
缓冲区中的数据由记录器进程写入磁盘。在下列情况下，查询处理必须等待日志数据写入磁
盘后才能进行：

. 运行 COMMIT 语句时
. 在将相应数据页写入磁盘之前，因为 DB2(R) 需要使用预写日志记录。预写日志记录
的好处是当执行 COMMIT 语句完成事务之后，并非所有更改的数据和索引页都需要
写入磁盘。
. 在更改元数据（大多数是通过执行 DDL 语句产生的）之前
. 在将日志记录写入日志缓冲区时，如果日志缓冲区已满
DB2 以这种方法管理向磁盘写入日志数据的目的是尽可能地缩短处理延迟时间。在发生许多
较小的并发事务的环境中，大多数处理延迟是由 COMMIT 语句造成的，因为此语句必须等待
日志数据写入磁盘后才能进行。因此，记录器进程频繁地将少量日志数据写入磁盘会造成大
量处理延迟，另外一些延迟是由日志 I/O 开销造成的。为平衡此类日志记录延迟导致的应
用程序响应时间，请将 mincommit 数据库配置参数设置为大于 1 的值。虽然这样设置可能
会对某些应用程序的 COMMIT 命令造成更长的延迟时间，但是这会使系统可在一次操作中写
入更多的日志数据。

以下数据库配置参数允许您更改归档日志的存储位置：newlogpath 参数和
logarchmeth1 与 logarchmeth2 参数。更改 newlogpath 参数还会影响活动日志的存储位
置。