Dan,

Thanks for that, however we pay the penalty for caching because we want
more than 1 days incrementals in the disk pool.  We have enough cache
for about 3 days worth of backups which really speeds up any restores.
We don't notice any problem with performance during backups (F40, AIX
4.2.1, ADSM 3.1.1.3).

We will checkout this other option people have been mentioning though
(compressalways NO).

Cheers,
Simon
----------
| From: ADSM-L AT VM.MARIST DOT EDU; DGCrouse AT IX.NETCOM DOT COM
| From: ADSM-L AT VM.MARIST DOT EDU; DGCrouse AT IX.NETCOM DOT COM
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: ANR0534W
| Date: Wednesday, 22 July, 1998 10:28PM
|
| Gentlemen,
|
| One compromise that you may try is to leave your backups on disk through the
| day and migrate them to tape immediately prior to your next backup cycle by
| updating your storage pool thresholds.  You would only need to migrate
| enough of the pool to comfortably hold your next night's backup.  One issue
| with storage pool caching that none of you have mentioned is that it has an
| adverse effect on backup throughput.  This is due to the fact that ADSM must
| perform approximately twice as many updates in order to the same backup
| load: Once, to delete the entry for the cached file(s) and then again to
| make the entry for the new file to be backed up.  This strategy gives you
| the benefits of restoring current backups from disk without incurring the
| performance penalty and other adverse side effects of storage pool caching.
| I hope this was helpful.
|
| DanC
| =============================================
| Daniel G. Crouse
| IBM Certified Specialist - ADSM
| Mainstar Software Corporation
| Storage and Recovery Solutions
|   URL:  www.mainstar.com
| Email:  Dan.Crouse AT mainstar DOT com
| Vmail:  800-233-6838
| Voice:  770-682-7739
|    Fax:  770-682-7739
| >>Date:    Wed, 22 Jul 1998 08:43:27 +0800
| >>From:    Simon Watson <Simon.S.Watson AT OPENMAIL.FIC32.BSPSER.SIMIS DOT 
COM>
| >>Subject: Re: ANR0534W
| >>
| >>We are having the same problem and have preferred to turn client
| >>compression off rather than do away with the cache.  This seems to work
| >>but is not ideal.  The problem seems to be worst on files that are
| >>already compressed on the client, in our case MS Mail MMF files, which
| >>actually grow when ADSM tries to compress them!  The space they need in
| >>the storage pool is then more than what was originally asked for.
| >>
| >>We are seriously thinking of moving completely to H/W compression
| >>because of this problem.  We are using 3590 drives.  Haven't quite
| >>thought this through yet about how to make this change.  Do we need to
| >>create now tape pools, or if we change the drives can our existing
| >>tapes still be read?  Network bandwidth is not really an issue at this
| stage.
| >>
| >>Regards,
| >>Simon
| ----------
| | From: ADSM-L AT VM.MARIST DOT EDU; roger_hohmann AT WESTLB DOT DE
| | To: ADSM-L AT VM.MARIST DOT EDU
| | Subject: Re: ANR0534W
| | Date: Tuesday, 21 July, 1998 11:41PM
| |
| | We saw this message some times ago. Then we corrected the stgp def, the
| | following way:
| |
| | 1. caching off
| | 2. maxfilesize = (100 - high mig)/100 * est cap of stgp vol.
| |
| | Afterwards, we have less problems.
| |
| | Regards
| | Roger
| |
| | >We are getting a number of the following messages each day:
| | >
| | >07/21/1998 02:22:01 ANR0534W Transaction failed for session 353
| | >for node PDLEWI01 (WinNT) - size estimate exceeded and server
| | >is unable to obtain additional space in storage pool IT-WS-BACK-DASD.
| | >
| | >The message manual suggests we either have to turn off cache
| | >at the server or compression at the client, neither of which is
| | >an attractive solution. Is there a fix that would force the
| | >server to go ahead and free up more space and then retry the file?
| | >
| | >David Ehresman
| | >University of Louisville
| | Roger Hohmann
| | WestLB
| | Division: 009 Services
| | Abteilung: 001-80633
| | Herzogstrasse 15
| | D - 40217 Dusseldorf
| | Tel.: +49211 826 8155
| | Fax: +49211 826
| |
|