[转帖]TSM Server+IBM 3494启动失败故障解决一例_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛

总帖数

每页帖数

1/1页

返回列表

发起投票

查看: 2936 | 回复: 1

主题： [转帖]TSM Server+IBM 3494启动失败故障解决一例

本主题由 koei123 于 2015-2-5 17:32:49 移动

koei666

注册用户

等级：新兵
经验：61
发帖：63
精华：0
注册：2012-1-9
状态：离线
发送短消息息给koei666

加好友发送短消息息给koei666

发消息

发表于：

2014-12-31 9:55:04 | [全部帖] [楼主帖]

楼主

上周，远程支持了同事一把。
TSM Server无法启动，直接用dsmserv执行看到输出是这样：

[GXRMAN:root:/usr/tivoli/tsm/server/bin]dsmserv
ANR7800I DSMSERV generated at 14:39:05 on Sep 14 2007.
Tivoli Storage Manager for AIX-RS/6000
Version 5, Release 3, Level 6.0
Licensed Materials - Property of IBM
(C) Copyright IBM Corporation 1990, 2006.
All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corporation.
ANR0900I Processing options file dsmserv.opt.
ANR4726I The ICC support module has been loaded.
ANR0990I Server restart-recovery in progress.
ANR0200I Recovery log assigned capacity is 1624 megabytes.
ANR0201I Database assigned capacity is 3500 megabytes.
ANR0306I Recovery log volume mount in progress.
ANR0353I Recovery log analysis pass in progress.
ANR0354I Recovery log redo pass in progress.
ANR0355I Recovery log undo pass in progress.
ANR0352I Transaction recovery complete.
ANR1635I The server machine GUID, 00.00.00.00.d5.bc.11.da.ba.ba.08.63.0a.a8.1e.69, has initialized.
ANR2100I Activity log process has started.
ANR4726I The NAS-NDMP support module has been loaded.
ANR1414W Volume Y00028 access mode is "read-only" due to previous write error.
ANR1412W Volume Y00130 access mode is "unavailable".
ANR1414W Volume ZY1207 access mode is "read-only" due to previous write error.
ANR1414W Volume U00009 access mode is "read-only" due to previous write error.
ANR1414W Volume U00112 access mode is "read-only" due to previous write error.
ANR1413W Volume A00158 access mode is "read-only".
ANR8774W Volume Y00182 not checked into library 3494LIB but is using category 300.
ANR8774W Volume Y00130 not checked into library 3494LIB but is using category 300.
ANR8774W Volume ZY1290 not checked into library 3494LIB but is using category 300.
ANR8774W Volume ZY1277 not checked into library 3494LIB but is using category 300.
ANR8451I 349X library 3494LIB is ready for operations.
ANR8444E Internal Operation: Library 3590LIB is currently unavailable.
ANR8452E Initialization failed for 349X library 3590LIB; will retry in 2 minute(s).
ANR8444E Internal Operation: Library 3592LIB is currently unavailable.
ANR8452E Initialization failed for 349X library 3592LIB; will retry in 2 minute(s).
ANR8444E Internal Operation: Library 3592LIB is currently unavailable.
ANR7838S Server operation terminated.
ANR7837S Internal error Invalid file handle detected.
0x0000000100007ea8 pkAbort
0x0000000100018684 pkClose
0x00000001002bdef0 PvrCloseDevice
0x0000000100631280 FlagCloseLmcp
0x00000001004626b0 MmsReleaseAuto
0x000000010062a4b4 LibQueryVolData
0x000000010062f680 FlagDeleteVolume
0x0000000100452568 MmsDeleteVolume
0x00000001005bdc2c NtpDeleteVolume
0x00000001002a7d90 pvrDelete
0x000000010024e110 AsEndDeleteVol
0x000000010024ee40 AsVolRestart
0x00000001006badec AsInit
0x00000001000eaf18 ssInit
0x000000010021cfa4 admStartServer
0x0000000100002b14 main
ANR7833S Server thread 1 terminated in response to program abort.
ANR7833S Server thread 2 terminated in response to program abort.
ANR7833S Server thread 3 terminated in response to program abort.
ANR7833S Server thread 4 terminated in response to program abort.
ANR7833S Server thread 5 terminated in response to program abort.
ANR7833S Server thread 6 terminated in response to program abort.
ANR7833S Server thread 7 terminated in response to program abort.
ANR7833S Server thread 8 terminated in response to program abort.
ANR7833S Server thread 9 terminated in response to program abort.

处理过程：
1、由于报的内部错误，不像通常的错误有明确的指示说问题在什么地方，所以首先想到打补丁，原来是5.3.6.0，对于稳定版补丁来说，FIX PACK 6已经是最高了，然后又打到5.3.6.3，结果一样
2、一线同事给TSM LOG扩了空间，无效
3、我让一线同事做dsmserv auditdb进行TSM DB的全面校验。这个时间较长，花了大约2小时

重点来了：在auditdb的同时，用google等方式查找关键错误信息中的内容，没有任何类似的。即：

0x0000000100007ea8 pkAbort
0x0000000100018684 pkClose
0x00000001002bdef0 PvrCloseDevice
0x0000000100631280 FlagCloseLmcp
0x00000001004626b0 MmsReleaseAuto
0x000000010062a4b4 LibQueryVolData
0x000000010062f680 FlagDeleteVolume
0x0000000100452568 MmsDeleteVolume
0x00000001005bdc2c NtpDeleteVolume
0x00000001002a7d90 pvrDelete
0x000000010024e110 AsEndDeleteVol
0x000000010024ee40 AsVolRestart
0x00000001006badec AsInit
0x00000001000eaf18 ssInit
0x000000010021cfa4 admStartServer
0x0000000100002b14 main

这个信息，只有TSM手工前台执行才能看到，dsmerror.log都看不到，所以选择正确的手段拿到全面完整的信息，是第一个主要步骤。

打补丁、扩LOG、校验DB之外，唯一可能有有问题的就是TSM在激活设备的时候有问题了。为什么这样说？

环境是这样，当初这个TSM SERVER在原来的机房，一堆机器从那个机房搬迁到新机房，在今年第一季度做的。当初这个TSM SERVER连有其他带库设备，也是IBM 3494系列，从刚才我贴的启动过程可以看到，它找到3494LIB，工作正常，这是现在使用的3494磁带库，还找两个带库：3590LIB和3592LIB，均失败，并重试。

这两个带库设备是以前这个TSM用的，从搬迁以来就没有用了，但未从TSM配置中删除。按理说也不应该有问题。

IBM带库都要安装一套驱动，叫做Atape，对于3494这种带自身控制点的带库，还要装一个atldd驱动。大带库有一个Control Point，硬件实体就是一台PC，实际上主机控制带库就是通过IP协议跟这台PC通讯来控制的，带库里有什么磁带，在什么位置，有多少什么样的驱动器，机械手怎么移，全是这台PC管，这台PC跟3494带库集成在一起，跑的操作系统是定制化了的IBM OS/2。

所以IBM大带库的控制逻辑从软件驱动层次来讲比较复杂，不像通常见到的中档带库，驱动一装，主机一cfgmgr或ioscan认到就完事了

IBM 3494带库的驱动运行中，在主机上体现出来，有个进程，叫做lmcpd，实际全称是Library Manager Control Point Daemon，负责跟Control Point通讯。然后会有一个设备，安装的时候用smit加的，可以自定义名字，对于本案例来说，原来的设备是/dev/tl_lm，现在在用的新设备是/dev/gx_lm，这对于AIX来说，就代表了带库设备，TSM对带库的操作，都是向这个设备发出操作指令，lmcpd从这个设备截取到上层软件发来的指令，然后跟Control Point通讯，来完成实际动作。

凡是软件报错时报出一串类似过程调用的名称，比如我们的，从pkAbort开始就是，这就是软件在报出错时，过程调用的层次是怎么样的，写过程序的都知道，比如看JAVA的System.out错误信息，就是典型这类样式的错误信息。
只是不同软件，报出的这个错误信息层次，是最终出问题的在前面，最先调用的在后面，还是顺序相反。从我们的信息看，显然是最先调用（最外层调用）是在后面的，main是典型的C程序主体，main主体调用admStartServer来启动TSM Server，然后ssInit/AsInit是初始化一些东西，至于ss和As是啥东西我也不知道，但起码知道了顺序如何，所以需要关注的是最前面的几个。

pkAbort、pkClose几乎是google来的所有TSM内部错误格式的固定部分，表示TSM进行强行中止时调用的异常处理过程。“抛异常”，所有会写程序，哪怕历史上曾经会写，都知道什么意思。

所以重点是pkClose后面的，我们看到，紧接着是PvrCloseDevice，这个看不出来什么，就是说TSM想关闭某设备，但紧跟着的东西，FlagCloseLmcp，这个就有明显的指示意义了，前面我们说了，lmcpd是驱动程序的进程，这里，显然从字面来理解，是TSM给内部设置了一个标志——它要关闭LMCP设备，其他线程不要去动这个LMCP设备了。什么是LMCP设备，显然就是我们前面说的tl_lm或gx_lm。

gx_lm对应TSM里面的3494LIB，它都正常打开且is ready for operations了，所以gx_lm不应该有问题，而且无论有多少IBM带库，Atape和atldd驱动总是共用的，所以驱动软件本身应该没有问题，那么我就将怀疑重点集中到了tl_lm这个设备上。

从逻辑上看，TSM是在尝试打开它未果，试图关闭它的时候崩溃，很可能这个设备的定义有问题了。既然没用了，我就想把这个设备删除看看。具体删除方法，就不说了，在IBM的TotalStorage Tape Device Drivers Installation and User’s Guide （GC35-0154）中都有，这个文档是讲带库驱动Atape、atldd的安装、配置方法等等。一线工程师执行了删除这个设备的动作，然后重启TSM Server，一切正常，问题解决。