ADSM-L

Re: Expiration woes!!!!

2000-07-11 15:45:48
Subject: Re: Expiration woes!!!!
From: Bill Colwell <bcolwell AT DRAPER DOT COM>
Date: Tue, 11 Jul 2000 15:45:48 -0400
Alan - two things come to mind; do either or both.

1. Look into running the archive directory cleanup tool which became available
at the 3.1.2.30 level.  Read about it in the cleanup.

2. If you can get to TSM 3.7.3, a new option of expire inv addresses this
problem.  You can say 'skipdirs=yes'  to skip processing of the ugly nest
of directories created by archiving.

Hope this helps,

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <87256919.006B5533.00 AT CGY-NT1.gulf DOT ca>, on 07/11/00
In <87256919.006B5533.00 AT CGY-NT1.gulf DOT ca>, on 07/11/00
   at 03:45 PM, Alan Cheski <Alan_Cheski AT GULF DOT CA> said:

>Howdy, we are running ADSM V3.1.2.50 on a Compaq Proliant with 300MHZ processor
>and 300+ Meg of ram and Windows NT 4.0 SP5. It seems that ever since we 
>upgraded
>to V3.1.2.50 expiration processing gets hung up on filesystems with thousands 
>of
>objects to check. What happens is expiration processing runs fine and then when
>it hits one of these filesystems the cpu usage goes to 100% and the memory 
>usage
>goes to 100%. Then, the ADSM server process dies because it can't allocate
>anymore memory. We have a 500M pagefile as well. The filesystems that seem to
>cause the problem are oracle archivelog filesystems which can have thousands of
>files produced over a period of a month (the retention on these archived files
>is 35 days). This problem is snowballing because without successful expiration
>more and more objects are being stored that don't need to be. Anyone have any
>solutions?

>Alan Cheski
>Gulf Canada Resources
<Prev in Thread] Current Thread [Next in Thread>