Jerry,
Thanks for the insight! I suppose I am still better off having a big
cache but it may explain some unexpected tape mounts!
Cheers,
Simon
----------
| From: ADSM-L AT VM.MARIST DOT EDU; jlawson AT THEHARTFORD DOT COM
| From: ADSM-L AT VM.MARIST DOT EDU; jlawson AT THEHARTFORD DOT COM
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: ANR0534W
| Date: Friday, 24 July, 1998 1:34AM
|
| ---------------------------- Forwarded with Changes
---------------------------
| From: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
| From: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
| Date: 7/22/98 10:59PM
| To: Jerry Lawson at ASUPO
| *To: ADSM-L AT VM.MARIST DOT EDU at SMTP
| Subject: Re: ANR0534W
|
-------------------------------------------------------------------------------
| Simon -
| Simon -
|
| Be careful with your expectation that if my cache is big enough to handle 3
| days, that you'll have 3 days worth of files there. ADSM does not migrate
| based on age (FIFO) logic. They use what I refer to as the PIG algorithm (no
| acronym - just an observation). When migration is needed, then the largest
| user gets moved, and then the next largest, and so on, until the lower
| threshold is achieved. So if I back up a lot, my data will move off quicker,
| and therefore be a candidate for being rewritten sooner than the guy who just
| backs up a few small files - theoretically he may never be migrated out of
| the pool.
|
| Jerry Lawson
| jlawson AT thehartford DOT com
|
|
| ______________________________ Forward Header
__________________________________
| Subject: Re: ANR0534W
| Author: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
| Date: 7/22/98 10:59 PM
|
|
| 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
| | 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
| | |
| |
|
|
