DB2数据库日常维护手册(示例)

DB2数据库日常维护手册（示例）

1.1 检查管理相关服务
RHCS的包括4个服务，按照启动顺序依次是：ccsd、cman、fenced、rgmanager。可以使用service命令启停这些服务或查看状态。（service
service_name start/stop/status）
集群中有两个服务，数据库和FTP。数据库服务包括VIP、文件系统、db2run脚本三个资源。这些可以查看集群配置文件
/etc/cluster/cluster.conf。
在图形界面下，使用system-config-cluster启动集群管理工具。在命令行下，使用clustat命令可以查看集群状态；使用clusvcadm命令可以启动、切换服务。

用ps命令查看是否有db2sysc后台进程
＃ps -ef | db2sysc
Ø 检查数据库服务器是否可以通过网络访问
相关命令：ping 10.7.63.202
telnet 10.7.63.202 60000
db2 connect to ddn user db2inst （使用db2inst用户）


Ø 平台服务器重启后需要启动的服务汇总如下：
web1、2服务器:
service tomcat start 启动tomcat服务
service turbomq start 启动turbomq服务
/usr/local/GETGPSMaile/run.sh 启动获取里程数服务
可用ps -ef | grep java进行查看是否彻底关闭
lvs服务器无需单独启服务，随开机即可启动相关服务
Ø 手动挂载相关资源操作
如果RHCS集群出现异常，无法启动或切换数据库服务，可以通过手工方式挂载相关资源。但此时这些资源已经脱离集群软件的管理，集群状态恢复正常后，应同样通过手工方式卸载这些资源，再使用集群管理工具启动服务。

(1) 卸载失败节点上的资源

登陆出现故障的服务器，检查集群资源状态。

检查数据库实例是否已经停止（ps -ef | grep db2sysc），如未停止以db2inst用户执行db2stop命令；
检查文件系统是否已经卸载（df -h），如未卸载以root用户执行 umount 命令；
检查VIP是否已经解除绑定（ifconfig），如未解绑以root用户执行 ifconfig eth0:1 down 命令。

如果部分资源无法卸载，考虑在适当时候重启故障服务器。

(2) 在可用节点上挂载资源

登陆状态正常的服务器，以root用户执行如下命令：

绑定VIP：ifconfig eth0:1 10.7.63.202 netmask 255.255.255.128 up
挂载文件系统：mount /dev/sdb1 /mnt/data
启动数据库：su - db2inst
db2start

(3) 检查数据库状态

在WEB服务器上以db2inst用户执行如下命令：

连接数据库：db2 connect to ddn user db2inst 命令
查询表中的数据：db2 “select * from mbl_device fetch first 1 rows only”

1.2 检查DB2实例是否已经启动
用ps命令查看是否有db2sysc后台进程
＃ps -ef | db2sysc

也可以以DB2实例所有者登录，通过发出db2start命令来确保启动了实例（如果实例已经启动，则会告知SQL1026N
数据库管理器已激活；否则，将

把实例启动起来）

1.3 查看表空间状态是否正常
以db2实例所有者登录
#db2 conn to ddn
#db2 list tablespaces show detail //在单分区上查看表空间的状态,正常返回0x0000
# db2_all list tablespaces show detail //在所有分区上查看表空间的状态

可以使用LIST TABLESPACES 命令确定连接数据库中表空间的当前状态，可以使用SHOW
DETAIL选项查看表空间的详细信息。比如，我们连上SAMPLE数据库，执行list tablespaces show detail
，可以看到状态返回值是0x0000，此时，使用db2tbst可以查看状态编号对于的状态含义，具体语法如下：

db2tbst 可以查看编号所代表的状态

db2tbst 命令接收十六进制的状态值，并返回相应的表空间状态。例如，命令 db2tbst 0x0008 返回 State = Load Pending
。而该十六进制的状态值反过来又是 LIST TABLESPACES
命令输出的组成部分。表空间的外部可见状态是由单个状态值的十六进制总和构成的。例如，如果表空间的状态是 Backup Pending和 Load in
Progress，那么所返回的十六进制值就是 0x20020（0x00020 + 0x20000）

1.4 与表有关操作
Ø 显示与MBL_ME匹配的所有表：
#db2 list tables | grep MBL_ME
Ø 查看MBL_MESSAGE表结构：
#db2 discribe table MBL_MESSAGE
Ø 显示表中所有数据：
#db2 "select * from MBL_MESSAGE"
Ø 显示MBL_MESSAGELOG表中前n行数据内容：
#db2 "select * from MBL_MESSAGELOG fetch first n rows only"
Ø 导出表和删除表操作：
例如：将mbl_messagelog_1127表中的数据导出为.del格式的文件
db2 export to mbl_messagelog_1127.del of del select * from
mbl_messagelog_1127"
删除mbl_messagelog_1127表及包含的数据
db2 drop table mbl_messagelog_1127
1.5 查看磁盘空间
#df -h
1.6 检查配置文件信息
su – db2inst
db2 connect to ddn

显示DB2配置文件中与数据库ddn有关所有信息：
【db2inst@db1 ~】db2 get db cfg for ddn show detail|more
查看DB2配置文件，过滤出log的配置信息：
【db2inst@db1 ~】db2 get db cfg for ddn show detail | grep -i log
1.7 数据库备份与恢复操作
1.备份方式

集团业务接入平台业务系统已经上线运行两年多，数据量12GB左右，数据库容器总大小15GB，数据库使用档案日志记录，可以进行在线备份。
目前采用在线全量备份的方式来备份整个数据库，在发生灾难性故障时，使用备份文件和日志文件可以进行时间点恢复，将数据库恢复到故障发生的前一刻。

2.备份策略

目前，数据库每天凌晨两点进行一次全量备份，备份文件存放在本地硬盘，保留最近两天的备份。备份完成后，将备份文件传送到磁带机，保留最近50天的备份。这样既保证数据库备份文件异地存放，又实现了充分冗余

。

3.备份的实现

数据库的定期自动备份是通过操作系统cron程序定期执行备份脚本db2mbk-master来实现的。该脚本包括如下功能：

(1) 在线全备ddn数据库。
(2) 将备份文件tar到磁带中。
(3) 删除两天以上的旧备份文件。
(4) 将每项操作的时间、结果记录到备份日志中。
(5) 自动清理备份日志。

4.备份的检查

检查数据库的备份情况需要在服务器https://www.wendangku.net/doc/5f5215561.html,上进行，包括以下内容：

(1) 检查备份文件是否生成

备份文件存放在 /home/db2inst/db2backup/backup
目录下，文件名称类似DDN.0.db2inst.NODE0000.CATN0000.20091109164735.001，正常情况下该目录下应该有最近两天生成的两个备份文件。

(2) 检查备份过程是否正常

备份日志存放在 /home/db2inst/db2exec/log
目录下，日志文件名为backup.log。每天备份脚本执行过程中会在备份日志中记录备份数据库、tar备份文件到磁带、删除旧备份文件等操作的起止时间与结果，可以通过这些记录确定备份是否正常进行。

(3) 检查本地磁盘空间

备份目录位于本地磁盘的根分区，假设备份文件的大小为n GB，那么该分区的剩余空间最好大于2n GB，最少也要大于n+2 GB。

(4) 检查备份文件是否tar到磁带
通过 tar -tvf /dev/st0 命令查看磁带的内容，确认显示结果中有最新的备份文件。当磁带中的备份文件较多时，这个操作可能花费很长时间。
检查备份配置文件情况：
【db2inst@db1 ~】$ crontab -l
备份文件存放目录：
【db2inst@db1 ~】$ cd db2exec/bin
检查备用数据库服务器数据库运行是否正常：
备用服务器：db2 connnect to db2
Db2 list tables
Db2 “select count(*) from mb1_device”
用集群管理工具将数据库服务切换到备用DB服务器：
Clusvcadm –r <服务名> -m <成员名>
进行数据库的RESTORE恢复（如果出现SQL0322N错误，则修改DB2CODEPAGE参数，然后重新执行restore命令）：
主服务器db1: db2 restore db ddn from /home/db2inst/ddnback taken at <备份文件时间戳> to
/mnt/data 例如：db2set db2codepage=819
进行数据库的ROLLFORWARD恢复：
主服务器db1: db2 rollforward db ddn to end of logs and stop
测试数据库状态：
主服务器： db2 connect to db2
然后 db2 list tables
然后 db2”select count(*) from mb1_device”
然后 db2set db2codepage=1386
1.8 检查归档日志相关操作
请确保活动日志目录下没有的日志文件都已经正确归档到了带机上(查看TSM或第三方存储管理软件)。

归档日志配置文件参数及说明：
【db2inst@db1 SQLOGDIR】
su – db2inst
db2 connect to ddn
db2 get db cfg for ddn show detail | grep –i log
LOGRETAIN RECOVERY
USEREXIT ON
LOGARCH

METH1 RECOVERY
如果userexit为ON，但是LOGARCHMETH1相同，查看目录和链接 /home/db2inst/db2exec/bindb2mbk-master

如果LOGARCHMETH1为DISK:/archlog，则DB2会自动将归档日志归档到目录/archlog下
db2 “update db cfg for ddn using logarchmeth1 DISK:/archlog”

如果需要更改参数，执行更新命令：
db2 update db cfg for ddn using 参数名 参数值
如果更改参数生效，需要重新启动DB2连接
db2 force application all
db2 list applications

如果应用无法停止，重新启动DB2
db2 force application all
db2stop
db2start
1.9 扩容表空间
DB2现有表空间扩容方法
db2 list tablespaces show detail

1）直接添加一个容器的例子：
db2 " ALTER TABLESPACE PAYROLL ADD (DEVICE '/dev/rhdisk9' 10000) "
加容器之后DB2会有一个自动balance的过程,可能会持续几个小时!!!
2）改变现有容器的大小(该方法不会触发balance,但如果表空间建立在裸设备上,则要扩冲裸设备空间):
db2 " ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, DEVICE
'/dev/rcont1' 2000, FILE 'cont2' 2000) "
注意这种方式就是将原有的相应容器都改成大小是2000页
db2 "ALTER TABLESPACE TS1 RESIZE (ALL 2000)"
这种方式就是把表空间中所有的容器大小都改成2000页
db2 " ALTER TABLESPACE TS1 EXTEND (FILE '/conts/cont0' 1000, DEVICE
'/dev/rcont1' 1000, FILE 'cont2' 1000) "
这种方式就是将相应的容器都扩大1000页，也就是增加1000页。
db2 " ALTER TABLESPACE DATA_TS EXTEND (ALL 1000)"
这种方式就是将所有的容器都增加1000页。
db2 " ALTER TABLESPACE USERSPACE1 EXTEND (ALL 100)"
DB2日常维护月操作
1、 日志清理相关操作
检查第一活动日志：
[db2inst@db1 SQLOGDIR]$db2 get db cfg | grep “First active”
清理日志文件时只能清理第一活动日志之前的日志；
请至少每月查看一次db2diag.log文件，看其中是否有异常。
相关日志清理操作
无论采用哪种措施，都要先确定目前的活动日志。使用db2inst用户执行以下操作：

(1) 连接数据库：db2 connect to ddn
(2) 查看日志文件目录：db2 get db cfg | grep "Path"
(3) 查看第一活动日志：db2 get db cfg | grep "First active"

注意：第一活动日志及其以后的日志（序号更高的）为数据库的活动日志，不能进行移动、压缩、删除等操作，否则将造成数据库故障。

然后，请根据数据库日志文件保留时间的相关规定确定要进行处理的日志文件范围。建议至少保留60天以内的日志文件，并且不要进行压缩操作，以免损坏日志文件。


下面介绍对日志文件进行压缩和删除的方法。执行操作前请先用如下命令确认操作的日志文件：

find -name '*.LOG' ! -newer | more

其中，-newer 指定find命令查找最后修改时间比某个日志文件新的

所有日志文件，而在前面加上 ! 取反，则返回比该日志文件旧的所有日志文件及其本身。
可以使用如下命令确定符合条件的日志文件的数量：

find -name '*.LOG' ! -newer | wc -l


如果考虑压缩陈旧的日志文件，可参考如下方法：

a.直接压缩日志文件

在日志文件目录下执行命令：find -name '*.LOG' ! -newer -exec gzip {} \;

b.将日志文件打包后压缩：目前存在/mnt/data/db2logbak/

在日志文件目录下执行命令：find -name '*.LOG' ! -newer | xargs tar -zcvf
log_bak_20100402_1.tar.gz
然后，再将这些日志文件删除，方法稍后说明。


如果考虑删除陈旧的日志文件，可参考如下方法：

a.使用操作系统命令直接删除

在日志文件目录下执行命令：find -name '*.LOG' ! -newer -exec rm {} \;

b.使用数据库命令进行清除

执行命令：db2 prune logfile prior to S0003270.LOG
该命令会清除S0003270.LOG之前所有的在线档案日志文件（不包括S0003270.LOG本身）。

2、 检查备份和日志是否都保存好了
通过 tar -tvf /dev/st0 命令查看磁带的内容，确认显示结果中有最新的备份文件。当磁带中的备份文件较多时，这个操作可能花费很长时间。

DB2日常维护季度操作
1、 通过快照监控器，查看系统性能如何
通过快照监控器，抓取数据库的信息，分析数据库性能是否合理：
# db2 get snapshot for all on 数据库名 > log.txt
2、 数据库补丁级别
# db2level
注意事项
1、 不要删除活动日志文件
DB2 的活动日志文件不能被删除。一旦 DB2 的活动日志文件被删除，或者所在的存储设备出现问题，则不可避免地造成 DB2 数据库系统宕机。
2、 注意交易日志存储空间
在归档日志模式下，如果没有使用自动归档方式，则存储的日志文件会不断增多，有可能造成日志所在的文件系统空间满。 当这种情况发生时，会根据参数
BLK_LOG_DSK_FUL 的配置而有不同的现象：
1）如果该参数启用，则 DB2 数据库可继续读操作，但是写操作会挂起
2）如果该参数没有启用，则 DB2 数据库会停止工作

两种情况下，都需要到日志所在的文件系统添加了空间才恢复正常。

3、 按照系统的实际工作量配置日志空间
DB2数据库通过日志文件维护数据的完整性和一致性。DB2 数据库的日志空间可通过如下公式计算：
日志空间 = （主日志文件 + 二级日志文件） * 日志文件尺寸

其中：
1） 主日志文件由参数 LOGPRIMARY 控制，
2） 二级日志文件由参数 LOGSECOND 控制
3） 日志文件尺寸由参数 LOGFILSIZ 控制
4） LOGPRIMARY + LOGSECOND < 256 （不同的 DB2 版

本略有不同，请参看相同版本的 DB2 手册确认）
4、 检查许可证（License）安装情况
许可证过期会造成不必要的服务中断，所以在 DB2 安装完毕后，建议检察许可的安装情况
5、 创建数据库前调整好系统时间
在数据库创建好之后，调整系统时间会造成数据库内部时间戳的异常。数据库中一些对象和时间相关，一旦时间不准确要调整需要很小心。错误的时间调整可能会造成很多问题，如：
1）某些对象失效，例如 ：
SQL0440N，找不到具有兼容自变量的类型为 “<例程类型>” 的名为 “<例程名>” 的已授权例程
2）数据库日志逻辑错误 -> 宕机
3）常见错误 – 只调整时间，未调整时区
6、 不要随便执行 chown (chmod) –R （UNIX/Linux）
在实例目录下chown (chmod) -R 会造成
1） 在数据库服务器上 db2 connect to 能连接上数据库
2） db2 connect to user ... using ...连接不上
附：常用表空间扩容方法
DB2现有表空间扩容方法
db2 list tablespaces show detail

1）直接添加一个容器的例子：
db2 " ALTER TABLESPACE PAYROLL ADD (DEVICE '/dev/rhdisk9' 10000) "
加容器之后DB2会有一个自动balance的过程,可能会持续几个小时!!!
2）改变现有容器的大小(该方法不会触发balance,但如果表空间建立在裸设备上,则要扩冲裸设备空间):
db2 " ALTER TABLESPACE TS1 RESIZE (FILE '/conts/cont0' 2000, DEVICE
'/dev/rcont1' 2000, FILE 'cont2' 2000) "
注意这种方式就是将原有的相应容器都改成大小是2000页
db2 "ALTER TABLESPACE TS1 RESIZE (ALL 2000)"
这种方式就是把表空间中所有的容器大小都改成2000页
db2 " ALTER TABLESPACE TS1 EXTEND (FILE '/conts/cont0' 1000, DEVICE
'/dev/rcont1' 1000, FILE 'cont2' 1000) "
这种方式就是将相应的容器都扩大1000页，也就是增加1000页。
db2 " ALTER TABLESPACE DATA_TS EXTEND (ALL 1000)"
这种方式就是将所有的容器都增加1000页。
db2 " ALTER TABLESPACE USERSPACE1 EXTEND (ALL 100)"
附：归档日志相关知识
db2日志保存的两种方式：循环日志和归档日志
循环日志：
在任何情况下都不能删除循环日志，如果删除数据库就会出错。
如果出错了，只能用备份做恢复，如果没有做备份，那么只有找IBM官方来帮做一个连接
然后你export出数据，然后再重建数据库。据说这个还是要在你买了PPA的情况下才提供
的服务内容。
归档日志：
归档日志中的活动日志部份是不能删除的，如果删除结果同循环日志被删除的情况。
归档日志中的已归档日志是可以删除的，但删除了以后你可能就没法做一些前滚操作了。数据库备份的恢复涉及备份文件和日志
归档日志相关知识：
将LOGRETAIN设置为ON后，数据库将支持前滚恢复。此时，系统中

将会存在三种类型的日志文件:
活动日志:该日志包含尚未提交或回滚的事务单元的相关信息，以及已提交但尚未写入数据库文件的事务的信息。
联机存档日志:活动日志中所有改动对正常处理已不需要，即该日志中所记录的事务都已提交并写入数据库文件时，该活动日志转换为联机存档日志。称之为联机，是由于它们与活动日志存放在同一个目录下。

脱机存档日志:将联机存档日志从活动日志目录下Copy到另外的地方存档，就称为脱机存档日志。这些日志可能在数据库前滚恢复的时候仍然需要。
管理数据库日志的工作可以手工完成(即将联机存档日志手工拷贝到某个archive目录)，也可由编写USEREXIT程序自动维护。
由于DB2对所有平台都提供了相应的USEREXIT示例程序，而且非常易于修改和使用，所以IBM建议用户使用USEREXIT程序来管理日志文件。
使用USEREXIT程序的方法
要使用User exit program自动化log文件的archiving和retrieval过程:
1. 设置database cfg参数logarchmeth1 为USEREXIT。
connect to ddn
update db cfg using logarchmeth1 USEREXIT
随后操作可参考>>1.8 检查归档日志相关操作


附：使用 CLP 捕获数据库运行状况快照
可从 CLP 使用 GET HEALTH SNAPSHOT 命令来捕获运行状况快照。该命令语法支持检索运行状况监视器监视的不同对象类型的运行状况快照信息。
先决条件
必须具有实例连接才能捕获运行状况快照。如果没有实例连接，则创建缺省实例连接。要获取远程实例的快照，必须先连接至该实例。
过程
要使用 CLP 捕获数据库运行状况快照
从 CLP 发出带有期望参数的 GET HEALTH SNAPSHOT 命令。
在以下示例中，将在启动数据库管理器之后立即捕获数据库管理器级别运行状况快照。
db2 get health snapshot for dbm 对于分区数据库系统，可为特定分区捕获专门的数据库快照，或者为所有分区捕获全局的数据库快照。要对特定分区（如分区号
2）上的数据库捕获运行状况快照，请发出以下命令：
db2 get health snapshot for db on sample at dbpartitionnum 2要对所有分区上的所有应用程序捕获数据库快照，请发出以下命令：
db2 get health snapshot for db on sample global以下命令捕获的运行状况快照带有附加详细信息，包括公式、附加信息和运行状况指示器历史记录：
db2 get health snapshot for db on sample show detail 对于基于集合状态的运行状况指示器，可对所有集合对象捕获数据库快照，而不考虑这些对象的状态。常规 GET HEALTH SNAPSHOT FOR DB
命令返回所有集合对象，这些对象需要针对所有基于集合状态的运行状况指示器的警报。
要对列示了所有集合对象的数据库捕获运行状况快照，请发出

以下命令：
db2 get health snapshot for db on sample with full collection