Oliver,
We have had this problem when a client tries to backup up already
"compressed" files and has the client option "compression on" set in =
the
dsm.opt.
By compressed files I mean zip or tar files. We have found that the =
files
start to expand during additional compression and then exceed the size
estimates.
Richard.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Technical Services (ADSM) - Dawson House
Int: 33298 Ext: (44) 1925 233298 Mob: 0961 146738
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On 04 April 2000 10:35, Oliver Janzen [SMTP:OJANZEN AT DE.IBM DOT COM] wrote:
> Hi *SMers,
>=20
> Maybe anyone has got an idea/solution to the following problem:
> (Server 3.1.2.50 on AIX 4.3.2
> Client 3.1.0.6 on NT 4.0 SP 3)
>=20
> We=B4ve a storage pool with caching enabled. This storage pool has
> a PCT_UTIL of 99,9 %, which is normal after a much Backup-cycles,
> since PCT_UTIL includes the cached copies. (Nevertheless, the data
> are migrated each morning.)
>=20
> When performing incremental backups of our clients some (mainly big)
> files are not backuped because of the following error message:
> ANR0534W Transaction failed for session ...
> <Client_name> - size estimate exceeded and server is =
unable
> to
> obtain additional space in storage pool <stgpool_name>
>=20
> The reason is - as I understood - that ADSM frees
> only that amount of space on the disks (deletes cached files)
> what it estimated for the file. If it underestimated the space =
needed,
> it looks for more free space in the stgpool, but can not free more
> space by deleting cached files.
>=20
> Does anyone of you know about a solution?
> Is there any option or any fix which optimizes the estimation =
procedure?
> Or any option to keep a distinct amount of the storage pool real free =
(not
> used
> with cached files?)
> Maybe setting a retry for the backup of such failed files?
>=20
> The problem is that the files are really not backed up.
>=20
>=20
> Kindly regards, Oliver Janzen.
***********************************************************
The information contained in this e-mail is intended only=20
for the individual to whom it is addressed. It may contain=20
privileged and confidential information. If you have=20
received this message in error or there are any problems,=20
please notify the sender immediately and delete the message=20
from your computer. The unauthorised use, disclosure,=20
copying or alteration of this message is forbidden. Neither=20
Vertex Data Science Limited nor any of its subsidiaries=20
will be liable for direct, special, indirect or=20
consequential damage as a result of any virus being passed=20
on, or arising from alteration of the contents of this=20
message by a third party.
Vertex Data Science Limited (England and Wales No. 3153391)=20
registered office Vertex House, Greencourts Business Park,=20
333 Styal Road, Manchester, M22 5TX
***********************************************************
|
