昨天同一台机备份还是可以的。今天通过TDP备份Oracle提示“ Server out of data storage space”
昨天第二次备份时也出现过该情形。增大存储池空间就解决了。
但是这次，我把存储池空间增大了几倍，还是出现同样的错误。检查node的domain没有错。copygroup的destination也没错。后来尝试备份归档日志，结果也提示存储空间不足。
请问各位大侠还有没有其他情况会导致这种错误呢？谢谢!

启动 backup 于 16-7月 -07
通道 t1: 正在启动 full 数据文件备份集
通道 t1: 正在指定备份集中的数据文件
输入数据文件 fno=00001 name=D:\ORACLE\ORADATA\D620\SYSTEM01.DBF
输入数据文件 fno=00002 name=D:\ORACLE\ORADATA\D620\UNDOTBS01.DBF
输入数据文件 fno=00005 name=D:\ORACLE\ORADATA\D620\EXAMPLE01.DBF
输入数据文件 fno=00010 name=D:\ORACLE\ORADATA\D620\XDB01.DBF
输入数据文件 fno=00006 name=D:\ORACLE\ORADATA\D620\INDX01.DBF
输入数据文件 fno=00009 name=D:\ORACLE\ORADATA\D620\USERS01.DBF
输入数据文件 fno=00003 name=D:\ORACLE\ORADATA\D620\CWMLITE01.DBF
输入数据文件 fno=00004 name=D:\ORACLE\ORADATA\D620\DRSYS01.DBF
输入数据文件 fno=00007 name=D:\ORACLE\ORADATA\D620\ODM01.DBF
输入数据文件 fno=00008 name=D:\ORACLE\ORADATA\D620\TOOLS01.DBF
通道 t1: 正在启动段 1 于 16-7月 -07
释放的通道: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t1 channel at 07/16/2007 14:04:25
ORA-19502: 文件 "D620_38_628092261_1.bak", 块编号 2689 写错误 (块大小 = 512)
ORA-27030: skgfwrt: sbtwrite2 返回错误
ORA-19511: 从介质管理器层接收到错误, 错误文本为:
   ANS1329S (RC29)   Server out of data storage space




Storage         Device          Estimated       Pct       Pct     High     Low     Next Stora-
Pool Name       Class Name       Capacity      Util      Migr      Mig     Mig     ge Pool   
                                                                   Pct     Pct     
-----------     ----------     ----------     -----     -----     ----     ---     -----------
ARCHIVEPOOL     DISK                0.0 M       0.0       0.0       90      70     FILPOOL1   
BACKUPPOOL      DISK                0.0 M       0.0       0.0       90      70     FILPOOL1   
DISKPOOL        DISK                  5 G       0.0       0.0       90      70               
FILPOOL1        FILEDEV1            0.0 M       0.0       0.0       90      70               
SPACEMGPOOL     DISK                0.0 M       0.0       0.0       90      70

Server out of data storage space



没空间啊 。。

我的存储池空间已经是数据库的10倍了。。。

回复 1楼 zhangbin 的帖子

chinaunix 看到类似问题，你试下。。。。

原因：最初定义磁带卷时指定为临时卷。（而tsm对临时卷写数据后，便把此卷设定为专用卷，tsm再需要使用临时卷时，便会找不到临时卷，提示空间不够。等到磁带状态为空时，重新置为临时卷。）
解决办法：在库卷中，更新卷为专用卷，然后再加入到磁带存储池中。

把copygroup的定义帖上来看看吧
怎么只有diskpool里面写了东西呀？
是不是写到diskpool上去了？


另：发现你都是用的disk设备嘛
如果不是上述原因，检查一下devclass吧

[ 本帖最后由 crazyshow 于 2007-7-16 22:39 编辑 ]

老大，检查一下的你存储池中的单个卷的大小是多少？对于DISK类型的存储池，单个卷的容量不足以放下1个backup set时会出现这种情况的呀!!

filepool1的定义可能有问题，贴上来看看

我觉得楼主COPYGROUP的目标存储池应该是指向DISKPOOL的，只是DEFINE VOLUME的时候FORMATSIZE太小了，单个卷放不下一次的备份，FILE DEVICE的存储池应该不会有单个卷空间不足就备份失败的。

哈哈，我看到帖子后也很想贴上来，最后因为赶时间，所以把TSM Server删了，重装了。呵呵
但是在我重装后，还是出现上述情况。大家看我的diskpool 是5G的空间。而且利用率是0，一个卷设置了500M。
我备份归档日志都提示存储空间不足。按道理，归档日志不应该有多大。
后来再尝试selective一个很小的txt文件，结果也提示存储空间不足。
现在打算重装系统算了。

楼主是不是用命令行update copygroup更新了COPYGROUP的目标存储池，但没有使用ACTIVATE POLICYSET使STANDARD的COPYGROUP变成ACTIVE的吧？呵呵!!

别老是要重装系统，要是到了用户那动不动就要重装，会被用户骂S的..........

你用query copygroup就会发现每个COPYGROUP都有ACTIVE和STANDARD两个版本，ACTIVE的才是生效的，一般只能修改STANDARD的，如果需要STANDARD生效，就必须使用ACTIVATE POLICYSET命令使之生效。用图形界面就会有问你是否ACTIVE这个配置的提示，命令行则需要手动执行。哈哈

肯定有active！这个我有注意的。。。
不过看我的情况，其他的stgpool全都是0，的确挺像是没有active。呵呵。。。

[ 本帖最后由 pangyi 于 2007-7-25 11:14 编辑 ]