db2数据库常见问题处理

1 数据库实例挂起

现象：

数据库操作无返回，应用程序无响应，查看数据库实例发现挂起。

分析：

1、执行ps -ef|grep db2sysc 确认系统中是否存在db2sysc 进程，判断数据库实例是否出现异常。

2、执行db2gcf -s -p 分区号-i 实例名确认实例状态是否为Available。

处理：

1、执行如下命令收集db2fodc -hang 数据：

db2fodc –hang –alldbs

2、如果收集的时间过长，可适当减小收集范围：

db2pd –stack all –repeat 5

db2pd –latch –repeat 5

3、使用DB2 数据库系统用户执行db2_kill 命令杀掉DB2 进程，使用ps –ef|grep db2 命令确认DB2 进程已全部清除，然后执行db2start 命令启动数据库，再执行

db2 connect to db_name；

db2 “select * from syscat.bufferpools”

验证DB2 数据库操作正常。

4、重新启动DB2 后再使用db2support 收集相关信息：

db2support /tmp/db2data -d <db_name> -a -g -l -r -s

5、在AIX 系统中可执行snap -gc 命令、在Linux 系统可执行support –a 命令收集操作系统信息，以帮助分析数据库实例进程为何出现异常。

2 数据库实例崩溃

现象：

DB2 进程异常结束，无法提供服务。

分析：

执行ps –ef |grep db2sysc 发现DB2 进程消失。

处理：

1、使用DB2 数据库系统用户执行db2start 命令启动数据库，并执行

db2 connect to db_name；

db2 “select * from syscat.bufferpools”

验证DB2 数据库操作正常。

2、执行db2support . –d db_name -c –s –f 命令收集数据，执行

db2trc on -t -f server.dmp；

db2trc fmt server.dmp server.fmt;

db2trc flw -t server.dmp server.flw

命令开启db2trc，监控问题是否重现，收集trace 数据。

3 数据库连接数满

现象：

应用程序连接数据库时出现SQL1040N The maximum number of applications is already connected to the database 报错，无法建立新的数据库连接。

分析：

1、执行db2 get db cfg for sample | grep –i maxappls 查看当前数据库maxappls 参数值。

2、执行db2pd –db db_name –app 或者db2 list applications |wc –l 检查应用程序的总连接数是否已超过数据库最大允许连接数。

处理：

执行db2 update db cfg for sample using maxappls automatic 命令更新maxappls 参数，使之自动增长。

4 数据库事务日志满

现象：

单个交易处理数据量大，导致日志满情况发生。

分析：

执行如下查询，可检查占用日志较大的交易：

db2 “SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, AGENT_ID, ROWS_READ,ROWS_WRITTEN, UOW_LOG_SPACE_USED, UOW_START_TIME, UOW_STOP_TIME,ELAPSED_EXEC_TIME_S FROM SYSIBMADM.SNAPAPPL”

处理：

1、若数据库日志满，DB2 将强制回滚事务。可通过db2pd –db db_name –apinfo 数据库名察看应用状态，应该处于rollback 状态。

2、DB2 数据库有2 个参数可以控制每个交易使用的日志量，避免单个交易占用索引日志情况， 可执行

db2 update dbm cfg using MAX_LOG 80 和db2 update dbm cfg usingNUM_LOG_SPAN 80

设置该参数为80%，避免单个大交易的情况。

3、规避方法：

当数据库日志空间存在用尽风险时，可以通过在线增加logsecond 参数来增加可用的日志空间，避免出现日志空间满的情况。在扩展此参数前，需确认数据库日志所在的文件系统有空闲空间。

确认数据库的日志路径:

db2 get db cfg for |grep “Path to log files”

增加logsecond:

单分区环境：

db2 update db cfg using logsecond

注：num 为参数logsecond 的新的值。

多分区环境：

db2_all “db2 update db cfg using logsecond ”

注：num 为参数logsecond 的新的值。

5 数据库事务日志误删

现象：

数据库活动日志被误删除。

分析：

进入DB2 活动日志目录下，检查发现日志文件已经被误删除。

处理：

通过最新的数据库备份进行恢复，执行恢复之后前滚日志。命令：

db2 RESTORE DATABASE 数据库名 FROM 备份文件位置" TAKEN AT 时间戳 to 待恢复的实例名" logtarget 日志目录REPLACE EXISTING redirect

注：日志重置后，强烈建议数据库重建，避免存在隐患。

6 数据库表空间满

现象：

巡检发现数据库日志中出现如下错误信息：

FUNCTION: DB2 UDB, buffer pool services, sqlbDMScheckObjAlloc, probe:830

MESSAGE : ZRC=0x85020021=-2063466463=SQLB_END_OF_CONTAINER “DMS Containerspace full”

分析：

1、执行如下SQL 语句，确认表空间使用率：

$db2 “connect to 数据库名 user 用户 using 密码

$db2 “select substr(a.tbsp_name,1,18) as name,substr(a.tbsp_type,1,10) as

tbstype,a.TBSP_USING_AUTO_STORAGE as AUTO_STORAGE,substr(a.tbsp_state,1,8) as

state,a.tbsp_total_size_kb/1024 as TotalMB ,a.TBSP_PAGE_TOP*a.TBSP_PAGE_SIZE/1024/1024 as

top_size_mb,a.tbsp_used_size_kb/1024 as UsedMB, a.TBSP_UTILIZATION_PERCENT as

UsedPer ,b.CONTAINER_NAME from sysibmadm.tbsp_utilization a, sysibmadm.SNAPCONTAINER

b where tbsp_type=‘DMS’ and a.TBSP_ID=b.TBSP_ID order by AUTO_STORAGE,UsedPer desc”

2、执行如下命令确认容器类型：

单分区环境

$db2pd -d -tab

多分区环境：

$db2_all “db2pd -d -tab”

处理：

执行

$db2 “alter tablespace extend(all NG)”

扩容表空间。

注：表空间增加的大小为容器数量*N，N 为每个容器增加的大小。

7 数据库表空间状态异常

现象：

系统监控报警数据库表空间状态异常。

分析：

1、由于存储、操作或者权限等原因，会导致DB2 表空间状态异常。此时，可查询表空间16 进制的状态值。命令：

$db2 list tablespaces show detail|grep -i state

2、根据返回的16 进制值，确认表空间状态。命令：

$db2tbst

3、表空间状态信息对应的描述：

处理：

常见异常状态的处理方式：

8 数据库表或数据误删

现象：

数据库中的表或数据被误删除。

分析：

与操作人员确认误删除发生的时间以及被删除的数据内容。

处理：

1、如果该表或数据所在的表空间不大，恢复时间较短，且该表所在的表空间已启用DROPPED TABLE RECOVERY 选项，建议采用数据库前滚恢复的方式恢复表或数据。可通过如下命令查询字典表SYSCAT.TABLESPACES 来验证表空间是否已开启DROPPED TABLE RECOVERY选项：

db2 “select tbspace,drop_recovery from syscat.tablespaces”

TBSPACE DROP_RECOVERY

SYSCATSPACE N

TEMPSPACE1 N

USERSPACE1 Y

ALANSPACE1 Y

ALANSPACE2 Y

SYSTOOLSPACE Y

2、尝试恢复数据库：

（a）、执行db2 restore database irmdb from D:\IBM\alanbak taken at 20100628154742 into irmdb命令，将会显示SQL2539W 警告！正在复原至与备份映像数据库相同的现有数据库。

数据库文件将被删除。想要继续吗？（y/n）

回答Y。

DB20000I RESTORE DATABASE 命令成功完成。

（b）、执行db2 list history dropped table all for irmdb从历史文件中检索已经丢失表对象的ID。列示irmdb 的历史记录文件：

匹配的文件条目数= 1

Op 对象时间戳记+序列类型设备最早日志当前日志备份标识

D T 20100628154949 000000000000f40200030004

“DB2ADMIN”.“ALANTEST1” 驻留在1 表空间中：00001 ALANSPACE1

注释：DROP TABLE

开始时间：20100628154949

结束时间：20100628154949

状态：A

EID：13

DDL: CREATE TABLE “DB2ADMIN”.“ALANTEST1” ( “ID” INTEGER , “NAME” VARCHAR(10) ) IN “ALANSPACE1” ;

其中我们可以查看一下备份标识:000000000000f40200030004，这个信息对于恢复表非常重要。

（c）、Rollforward数据库到日志结尾,同时生成恢复导入文件(我们需要利用上面的备份标识000000000000f40200030004来恢复数据库,同时准备出一个导出目录D:\IBM\exporttab)。执行如下命令：

db2 “rollforward database irmdb to end of logs and stop tablespace (alanspace1) online recover

dropped table 000000000000f40200030004 to D:\IBM\exporttab”

前滚状态

输入数据库别名= irmdb

节点数已返回状态= 1

节点号= 0

前滚状态= 未暂挂

下一个要读取的日志文件=

已处理的日志文件= S0000002.LOG - S0000004.LOG

上次落实的事务= 2010-06-28-07.49.50.000000 UTC

DB20000I ROLLFORWARD 命令成功完成。

（d）、此时我们可以看到在D:\IBM\exporttab\NODE0000目录下生成了一个data文件,内容就是我们表中丢失的数据。然后，我们用LIST HISTORY中的DDL来重建表结构并IMPORT相应的数据，如下：

DDL: CREATE TABLE “DB2ADMIN”.“ALANTEST1” ( “ID” INTEGER , “NAME” VARCHAR(10) ) IN “ALANSPACE1” ;

db2 CREATE TABLE “DB2ADMIN”.“ALANTEST1” ( “ID” INTEGER , “NAME” VARCHAR(10) )

DB20000I SQL 命令成功完成。

db2 import from D:\IBM\exporttab\NODE0000\data of del insert into db2admin.alantest1

SQL3109N 实用程序正在开始从文件"D:\IBM\exporttab\NODE0000\data” 装入数据。

SQL3110N 实用程序已完成处理。从输入文件读了"5" 行。

SQL3221W …开始COMMIT WORK。输入记录计数= “5”。

SQL3222W …对任何数据库更改的COMMIT 都成功。

SQL3149N 处理了输入文件中的"5" 行。已将"5" 行成功插入表中。拒绝了"0" 行。

读取行数= 5

跳过行数= 0

插入行数= 5

更新行数= 0

拒绝行数= 0

落实行数= 5

3、如果该表所在的表空间很大，恢复时间远大于停机窗口，建议根据之前的建表语句重建表，并利用最新的逻辑备份导入最新的备份数据，手工补做数据丢失的时间段业务。

9 死锁或超时，导致当前事务回滚

现象：

当前事务因死锁或超时而回滚，提示信息如下：

SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code “2”

分析：

根据报错的具体信息，可以判定，原因为死锁导致超时。

处理：

为了帮助避免死锁或锁定超时，可以采用如下两种方法

1、对长时间运行的应用程序或有可能遇到死锁的应用程序频繁发出COMMIT 操作（若有可能的话）。

2、修改数据库参数，适当地增大锁超时时间（此处60 秒为例），命令如下：

db2 update db cfg using LOCKTIMEOUT 60