解决TSM磁带VOL占用增多的问题.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
解决TSM磁带VOL占用增多的问题.doc

  解决TSM磁带VOL占用增多的问题   IBM3582的磁带库里面放了14盘磁带作为存储池。这个存储池用来备份两个节点的FS数据,RMAN的备份数据也往里面写。数据是直接往存储池里面写的,没有经过磁盘存储池。今天用q libv命令检查的时候发现临时卷的数量只有3盘了。在两个月前临时卷的数量都保持在7-8盘之间。两个星期之前临时卷的数量在5-6盘之间,当时没怎么注意,以为是数据量的增大造成的。现在开来问题可能不是这样。   tsm: SERVER1gt;q vol   Volume Name Storage Device Estimated Pct Volume   Pool Name Class Name Capacity Util Status   ------------------------ ----------- ---------- --------- ----- --------   RP0000 3582POOL 3580 623,900.1 41.5 Full   RP0001 3582POOL 3580 692,041.7 10.6 Full   RP0002 3582POOL 3580 289,503.8 1.2 Full   RP0003 3582POOL 3580 690,432.4 10.8 Full   RP0004 3582POOL 3580 787,172.1 6.3 Full   RP0005 3582POOL 3580 773,027.9 78.4 Filling   RP0006 3582POOL 3580 381,468.0 2.0 Filling   RP0007 3582POOL 3580 723,873.8 0.7 Full   RP0008 3582POOL 3580 381,468.0 23.3 Filling   RP0010 3582POOL 3580 287,254.3 81.7 Full   RP0013 3582POOL 3580 693,343.4 10.2 Full    首先检查配置:stgpool里的Delay Period for Volume Reuse参数值为0,卷的scratch volume属性为YES.这说明VOL上的数据只要全部过期,就可以立即成为临时卷再次使用。详细说明请参考我BLOG上的另一篇文章:《TSM中关于scratch 卷的处理》。检查tsmserv.opt配置文件,EXPInterval 24 每24小时做一次过期处理。这个应该也没问题。我现在RMAN上删除过期数据:RMANgt;delete noprompt obsolete    然后手工在TSM上做过期数据处理:tsm: SERVER1gt;expire inventory    重新查看VOL的使用情况,问题还是一样的。查看状态是FULL的VOL的内容:q content RP0001 f=d    发现一个不应该备份的节点数据被备份了。在TSM查看客户节点的调度列表,确实有这个调度。查看调度内容,发现要备份的数据跟VOL里面的数据是一样的。问题到这,突然明白了。我们在实施TSM的时候对某个节点是有备份计划的,所以定义了相应的备份策略,但后来实际使用的时候发现这个备份是没必要的,所以停用了客户节点的DSMC SCHE进程,备份就没有进行。后来重启过一次服务器,DSMC SHCE进程自动启动,造成备份继续进行,使用了大量的磁带空间。(备份的目录是oracle数据库的归档路径,所以数据量很大)问题到这解决起来就比较容易了。   首先tsm: SERVER1gt;q filespace   Node Name Filespace FSID Platform Filespace Is Files- Capacity Pct   Name Type pace (MB) Util   Unicode?   --------------- ----------- ---- -------- --------- --------- -------- -----   ERPDB /orc9i_db 10 TDP Ora- API:ORAC- No 0.0 0.0   cle AIX LE   ERPDB /install 11 TDP Ora- JFS2 No 204,800. 5.9   cle AIX 0   这里filespace name=/install的节点数据是要删除的。根据filespace我们可以验证某些VOL是否包含这些数据:tsm: SERVER1gt;q content RP0005 filespace=/install   

文档评论(0)

ggkkppp + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档