legato备份磨难记

华西某省进行数据库主机升级，将一台老机器升级到新机器上，在新机器上安装完数据库软件之后，把存储从老机器往新机器一挂，数据库算是迁移完成了。但是自从升级完成后，legato一直备份不成功。为了这个问题，和华西的dba王术成研究了好几天。

第一天：
发现备份执行完了，但任务状态不恢复正常，检查数据库主机的归档目录，arch日志已经被备份走，但是在legato的GUI界面，发现还是备份作业未完成的闹钟状态：

重启server端的networker服务，无效。重启client端的networker服务，无效。
检查相关进程：

发现rman进程已经完成，按照原理，当rman备份完的时候，会写index和bootstrap，但是目前却一直停留在rman完成的状态，nsrnmostart -s gz_bak01 -g OracleArch -LL -m gz_db -l full -q -进程一直挂死。如果在GUI界面中stop掉作业，在client端还是能看到上述的进程。

在GUI重新配置group和client，指定scheduel，再次备份，还是挂死，且此次rman备份完之后，磁带都没被eject出来，手工umount磁带，报错了，晕倒！

没有其他什么办法了，只好叫人去机房重启带库。

第二天：
昨晚重启带库后，今天尝试备份还是一样的挂死，按理说应该开始备份index和bootstrap了，而index和bootstrap是需要用tape0或者tape1来写，是否是本地驱动器的问题？检查用tape0和tape1做label，发现能正常完成。但是在检查计算机的硬件时，发现介质变换器被启动了！

介质变换器是带库在windows机器上的硬件显示，带库是HP的MSL 6000的带库。但是由于我们在windows安装legato的备份软件，legato会调用自己的接口去找带库。如果启动了介质变换器，就容易造成legato自身的接口和介质变换器的接口之间的争用。因此必须禁用介质变换器。
ps：如果是用DP的备份软件，则一定不能禁用介质变换器。DP需要通过介质变换器去调用带库。

禁用后，测试备份，还是挂死。
重启windows机器，重启client的networker的服务，重新配置jbconfig。原以为找到原因了，却还是不行。彻底崩溃……

第三天：
为啥还是不能写index和bootstrap，难道真的是本地驱动器有问题？去HP的网站上下载了LTT（HP StorageWorks Library and Tape Tools），用LTT检查driver状态正常，升级driver和library的firmware：

再次尝试备份，还是挂死。

再次核对各个脚本，oraclearch备份脚本，nsrnmo1脚本：

发现均正常。
通过检查脚本，添加log跟踪调试，也了解了legato的调用原理，在windows的机器上调用client的nsrnmo1脚本，nsrnmo1脚本会接收从windows主机传来的参数，再调用nsrnmostart脚本，生成执行语句。因此上面的脚本中的第254行，我们跟踪到实际的语句是：

当nsrnmo1执行完成后，再写index和bootstrap。此时一个想法升起：难道是nsrnmo1无法正常结束才导致后续写index和bootstrap无法进行？

尝试在GUI中再次启动备份作业，但是挂死的时候，kill掉nsrnmo1的进程，果然！开始写index和bootstrap了！
但是，为何nsrnmo1无法正常结束呢？

第四天：
在网上搜索相关的信息，发现一个CU的帖子是和我遇到问题的现象很类似。原因是nsrnmo的版本问题，他在oracle 10g下，用nmo 4.2不能正常结束进程，但是用nmo 4.1却可以正常结束。赶紧叫主机工程师查nmo版本，结果是令人兴奋的！！：

发生问题的贵州的nmo版本是：
NMO 4.2 NetWorker Module for Oracle
NetWorker 7.1.2.Build.325 NetWorker for HP-UX 11.XX (64-bit)

对比能正常备份的陕西的版本是：
NMO 4.1 Legato NetWorker Module for Oracle
NetWorker 7.1.2.Build.325 NetWorker for HP-UX 11.XX (64-bit)

再次问了做工程的工程师，他说当时在桌上拿了张光盘，也没仔细看版本！！

于是赶紧重新安装了nmo4.1的包，再次测试备份，终于这次备份终于在rman备份结束后，开始抓带写index和bootstrap了！不过兴奋的心情很快就消失了，在抓带的时候，又报错read open error：

第五天：
如果备份的时候，报错read open error，那么我测试label会怎么样呢？
用slow方式指定tape0或者tape1做label，正常。


用fast的方式，报错：

再次尝试备份，log中还是一样的报错：

按照log的建议，手工label一卷磁带到index pool，仍然报错read open error。

找来北办的dba，Rill来一起讨论这个问题，他说之前遇到过类似的问题，可以试试将device的CDI的访问方式从scsi command该成not used：

修改之后，再次备份，哇！终于成功了！

可是为啥割接之前配置的scsi commands是能够备份的，现在却不可以了呢？

再次把CDI的参数改回scsi commands，见鬼了！这次，能正常备份了！

第六天：
继续追究这个问题，通过查阅相关文档发现：在CDI手工改成not use的时候，会自动清洗一下磁带，而我们之前总是报错read open error，应该就是driver需要清洗了。当CDI改成not used之后，就被清洗了一次，当再次改回scsi commands的时候，由于磁带被清洗过，于是也就正常备份了。

附文档《Legato Command Reference》中的描述：
Next, if the jukebox contains tape devices, you are asked if automated cleaning of devices in the
jukebox should be turned on. If automated cleaning is enabled, the jukebox and all devices in the
jukebox are configured for automated cleaning. On successful installation, the information that
pertains to device cleaning for the jukebox and all its devices are displayed. Note that with the
introduction of the Common Device Interface (CDI), NetWorker now has two events that will
cause an automatic cleaning to occur: schedule-based cleaning, with devices being cleaned after a
certain (configurable) amount of time has elapsed, and on-demand cleaning, where cleaning is initiated
by TapeAlert warnings issued by the devices. Schedule-based cleaning is always active when
autocleaning is enabled. On-demand cleaning is used when the CDI attribute for a tape device is
set to anything other than ’Not Used’ in the device resource. If on-demand cleaning is being used,
you should set the Cleaning Interval for the device itself to a large time, such as 6 months, so that
NetWorker does not clean the device unnecessarily. See nsr_device.5 for a more detailed explanation
of CDI, TapeAlert and Cleaning Interval.

至此，问题和疑惑终于全部解决！