ACDante
作者ACDante2017-01-09 15:32
技术经理, SS

TSM故障分析案例分享一例

字数 875阅读 806评论 0赞 0

TSM故障分析案例分享一例

故障现象:无法进行每天backup_db的操作; 在重启TSM的时候发现,612ABF(ORAPOOL)试图进行reclamation的步骤,但是因为在ORAPOOL中没有其它磁带,所以一直报scratch volume not available的错,同时报reclamation failure和mount failure

故障分析:ORAPOOL中唯一的一盘磁带612ABF的空间已满,所以需要用一盘空白磁带(scratch volume)进行reclamation的操作。由于没有空白磁带在同一个storage pool中,所以造成612ABF无法mount,导致备份操作失败

故障解决方法: 故障在加入一盘新的空白磁带SHA476后得到解决。以下是加入新磁带的详细过程和命令: (在操作时,开启另外一个AIX窗口,用dsmadmc –console命令打开一个可以监控TSM log的窗口) 1)label libvolume 3583lib sha476 checkin=scratch overwrite=yes 这时系统在TSM log窗口会给出一个request号,并要求把空白磁带放入3583带库的I/O station中;把磁带放入后,用这个命令继续操作: reply <request号> 系统会自动完成把磁带加入libvolume的操作

tob_id_3541

以上命令把sha476加入到libvolume中去,状态设为scratch; 可以用这个方法对这条命令的操作结果进行验证: query libvolume 可以看到sha476已经被加入,且状态为scratch 2)define volume orapool sha476 这条命令把sha476加入到orapool中去 完成以上2步操作之后,系统重新发起reclamation的操作,成功mount 612ABF和scratch volume sha476,完成reclamation操作

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

0

添加新评论0 条评论

Ctrl+Enter 发表
相关推广
  • 商业银行基于VMAX3完成数据迁移及同城容灾技术手册
    本文从商业银行运维管理角度出发,结合VMAX3技术要点,以VMAX100k/200k为例介绍存储管理工具,逻辑配置,及利用SRDF/S进行数据迁移及同城容灾搭建案例。从硬件架构和软件特点出发,使读者了解与熟悉VMAX3存储产品的运维要点:如物理架构新特性与冗余性、实施配置、SRDF及容灾架构、SRDF/Metro技术要点、监控维护等。希望读者能通过本文熟练掌握VMAX3管理和运维工具,能提高存储采购选型、运行维护效率,提升具体项目场景中关键技术的实际运用灵活性与准确性,在符合监管部门容灾架构要求的基础上,提升商业银行关键业务系统可靠性和连续性。
  • 某城商行基于VPLEX+RecoveryPoint的存储灾备方案
    伴随着城市商业银行业务的快速发展,信息技术在金融业应用日渐深入,信息系统安全稳定运行的重要性日益突出。银行业信息系统的灾备体系建设是保障银行业务连续性的重要防线,是维护银行业信息和网络安全的重要保障机制。本文结合某城商银行的实际案例着重介绍城商银行如何基于集中式存储实现两地三中心灾备建设的方案设计过程。