Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2519880
  • 博文数量: 323
  • 博客积分: 10211
  • 博客等级: 上将
  • 技术积分: 4934
  • 用 户 组: 普通用户
  • 注册时间: 2006-08-27 14:56
文章分类

全部博文(323)

文章存档

2012年(5)

2011年(3)

2010年(6)

2009年(140)

2008年(169)

分类: 服务器与存储

2008-07-21 17:36:06

  IBM3582的磁带库里面放了14盘磁带作为存储池。这个存储池用来备份两个节点的FS数据,RMAN的备份数据也往里面写。数据是直接往存储池里面写的,没有经过磁盘存储池。今天用q libv命令检查的时候发现临时卷的数量只有3盘了。在两个月前临时卷的数量都保持在7-8盘之间。两个星期之前临时卷的数量在5-6盘之间,当时没怎么注意,以为是数据量的增大造成的。现在开来问题可能不是这样。
tsm: SERVER1>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上删除过期数据:
RMAN>delete noprompt obsolete
然后手工在TSM上做过期数据处理:tsm: SERVER1>expire inventory
重新查看VOL的使用情况,问题还是一样的。查看状态是FULL的VOL的内容:q content RP0001 f=d
发现一个不应该备份的节点数据被备份了。在TSM查看客户节点的调度列表,确实有这个调度。查看调度内容,发现要备份的数据跟VOL里面的数据是一样的。问题到这,突然明白了。我们在实施TSM的时候对某个节点是有备份计划的,所以定义了相应的备份策略,但后来实际使用的时候发现这个备份是没必要的,所以停用了客户节点的DSMC SCHE进程,备份就没有进行。后来重启过一次服务器,DSMC SHCE进程自动启动,造成备份继续进行,使用了大量的磁带空间。(备份的目录是oracle数据库的归档路径,所以数据量很大)问题到这解决起来就比较容易了。
  首先tsm: SERVER1>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: SERVER1>q content RP0005 filespace=/install
现在我们开始删除这个节点的数据:
tsm: SERVER1>delete filespace ERPDB /install type=any
ANR2238W This command will result in the deletion of all inventory references to the data on filespaces that
match the pattern /install (fsId=11) for node ERPDB , whereby rendering the data unrecoverable.
Do you wish to proceed? (Yes (Y)/No (N))
Do you wish to proceed? (Yes (Y)/No (N)) yes
ANS8003I Process number 4 started.
tsm: SERVER1>q process
 Process     Process Description      Status                                          
  Number                             
--------     --------------------     -------------------------------------------------
       4     DELETE FILESPACE         Deleting file space /install (fsId=11)          
                                       (backup/archive data) for node ERPDB: 1016     
                                       objects deleted. 
--我不知道delete filespace ERPDB * type=any 会不会影响这个节点RMAN所备份的数据,因为没实验环境所以没有验证。有环境的朋友可以验证一下。
OK,现在我们重新来看一下VOL的使用情况:
tsm: SERVER1>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 
RP0002                       3582POOL        3580           289,503.8       1.2       Full 
RP0005                       3582POOL        3580           773,027.9      69.7     Filling
RP0006                       3582POOL        3580           381,468.0       2.0     Filling
RP0008                       3582POOL        3580           381,468.0      23.3     Filling
RP0010                       3582POOL        3580           287,254.3      81.7       Full 
 
--5盘磁带的空间被释放。
 
 
 
 
阅读(2287) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2009-05-15 15:15:16

IBM TSM征文大赛——存储管理步入“智慧”时代,现已启动,邀请您参加。无论是新作品,还是旧博文,只要是原创的,都可以提交参赛。 活动详情请点击: http://storage.it168.com/focus/200905/200905zhengwen/index.html