wangql
作者wangql·2011-12-14 13:27
系统工程师·NULL

TSM备份db2时“SQL2025N An I/O error "-72" occurred on media "TSM&

字数 2388阅读 14917评论 4赞 1
最近巡检发现db2的调动备份日志中有失败的db2增量备份,报错内容为:
$ db2 backup db xxdb online use tsm include logs
SQL2025N An I/O error "-72" occurred on media "TSM".
通过db2 ? SQL2025N 命令查看解释为:
SQL2025N  An I/O error "<code>" occurred on media "<dir_or_devices>".

Explanation: 

An I/O error occurred while accessing a file on the specified media.

The utility stops processing.

If media is "TSM", there is a problem related to Tivoli Storage Manager.
A common TSM-related problem is time-out of a TSM session due to an
inadequate COMMTIMEOUT setting.

User response: 

If media is TSM, search the Tivoli Information Center at
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp for the
full text of the error code using phrases such as "API return codes in
numeric order".

For the COMMTIMEOUT case, attempt to increase COMMTIMEOUT to a higher
setting in dsmserv.opt or dsm.sys. Example settings to test are 6000s,
or 10000s.

For other media types, ensure that "<dir_or_devices>" is accessible and
check for media errors. For example for media TAPE, ensure that the tape
library is online. If you are attempting to backup to TAPE and you are
using tape with variable block size, reduce the buffer size option to
within the range that the tape device supports (DB2 automatically
chooses an 'optimal' value for this parameter if it is not specified).

More information will be in the db2diag log file. Use the db2diag log
analysis tool command db2diag to search for the particular rc: db2diag
-rc <RC>.

手动调整了tsm server和storage agent的两个参数后解决:
COMMTIMEOUT 10800
IDLETIMEOUT 480

时隔一段时间后,再次发生此类错误。经过咨询800,并查询相关资料,彻底明白故障原因。
当时进行tsm备份db2配置时,修改的参数如下:
db2 update db cfg for xxdb using LOGARCHMETH1 TSM TRACKMOD ON
db2 update db cfg for xxdb using TSM_MGMTCLASS standard
其含义为,当db2的活动日志进行归档动作时,直接将归档日志存入tsm,具体到tsm的那个位置,是由 TSM_MGMTCLASS参数决定的,由db2节点所属的策略域下的管理类(standard)下的归档副本组对应的目标存储池来存放归档日志。示意图如下:
策略域----策略集----管理类(standard)---副本组----归档存储池

而tsm环境中存放db2备份数据的备份存储池和存放归档日志的归档存储池指向了同一个存储池(db2pool)。这样,当产生归档日志时,归档日志直接通过api进入了db2pool中的磁带里;当进行db2数据库联机备份时,由于使用了include logs语句,备份程序会将所需的归档日志抽取到备份集中,如果这些日志和新产生的备份集在同一盘磁带中,这样就会不停的倒带卷带,最后就会发生io -72的报错。

解决的方法有两个:
1. 将存放归档日志的归档存储池与备份存储池分开,即为归档日志创建单独的存储池。这样当进行联机备份时就不会发生前面所说的问题。
 这样做的限制就是最少要有两个驱动器,以便在进行备份时一个驱动器读,一个写。
 还有一个问题是,当有多个数据库并且事务频繁的时候,多个数据库都需要切换归档日志,这时候需要有足够多的驱动器,否则还是会报错。
2. 第二个方法就是讲LOGARCHMETH1参数改为DISK类型,即将产生的归档放到硬盘上,当进行联机备份的时候,再由备份程序将所需的归档日志取到磁带上。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论4 条评论

wuwenpinwuwenpin软件开发工程师南京
2017-11-30 10:38
真的不错!!!
leibo_0110leibo_0110系统工程师中国华能
2013-11-15 11:23
真的不错!!!
shp2010shp2010系统架构师IBM
2012-05-21 09:17
我也觉得你又钻研精神
qian1110qian1110联盟成员 华通信联
2012-05-09 01:29
不错,有专研精神
Ctrl+Enter 发表

作者其他文章

相关问题

X社区推广