TSM故障解决--实战贴

今天跑出去帮一个朋友解决了一点儿tsm的小问题。
具体情况是这样的：
aix5.3 + tsm 5.2 + 3581 + oracle10g
环境比较简单，但是最近就是备份不成功，报磁带空间满。
1、检查配置，由于客户一致没有动过什么东西，所以只要以dsmerror.log和act为主
里面很奇怪，就只有out of space这样的错误信息。
2、检查其他的东西，也没发现错误
3、最后确认tsm没问题，检查3581，tapeutil检查，发现偶尔出现取带不正常，但是也不足以证明这就是问题根源啊
正在犹豫的时候，一个好的坏消息出现了：现在3581彻底抓带不成功了:L
甭管怎么说，3581卡带了，而且怎么弄也不行了，让他们换！

几经周折，换好了，我原以为就没啥事儿了呗，结果还是不好使。
现在报media mount failed，总算是有点儿进展嘛;P

查过act log没看出什么内容，做audit libr...
这下爆出错误了，无法打开driver和library
顿时慌了，q path 和 q driver看到的都是online的，怎么会无法打开呢？

重起也尝试过了，也不好使:'(

终于没有办法了，就在我准备缴枪的时候，想到了在系统里面测试一下。
tapeutil测试，完全正常，真的陷入僵局了，一世英名啊.....
lsdev -Cc tape 查看设备信息，设备名根原来都是一样的，肯定没有变过
灵机一动:P
lscfg -vl rmt0/smc0查看一下设备的微码，说不定新的带库微码跟以前版本不同呢
乖乖，我前次没有记录当时的微码是多少啊，现在看出来我怎么知道版本是不是相同呢，哎，失落

就在这个时候，我发现问题了，serial number不同！
q driver ibm3581 ibm3580 f=d看到的serial number尾数是8，而系统里看到的尾数是1，就是它了！
重新update driver/update libr 其实就是serial=autod就可以了
更新以后，现在都一致了。
重新测试，一切正常:victory:

本来serial=autod的话，tsm应该可以自动更新设备的serial，保持跟系统一致，不用人工干预。
而且客户以前就换过一次driver，换完了以后也没有做任何动作，就正常用了半年多，但是这次换完就不行了。
其实也可以直接设置，但是有时候可能会有问题，如果是主流设备最好还是自动识别的好些。

好贴，最近我也遇到一次，不过是用户手动操作带库玩，把磁带弄乱了，audit搞定

好玩意，大家都来学习学习