We have had archives dramatically impact our TSM data base in the past. The
issue became users archiving the exact same data to the same description
daily. In our case the archive file in question was about 800MB but our
default retention is 365 days. Also because the same description was used
it took longer and longer for the archive process to run as it kept
appending 800MB to the same archive every day. As far as I know an
unload/reload will not do anything to address this.
We actually deleted the archive data and set up a TSM schedule to archive
and delete the data from the client. our DB growth went away.
Hope that this helps.
- Brian
"shekhar Dhotre"
<Shekhar.Dhotre@LENDLEA To: ADSM-L AT VM.MARIST
DOT EDU
SEREI.COM> cc:
Sent by: "ADSM: Dist Subject: Re: TSM DB
growing @1.5Gb /2 day ??
Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>
05/20/03 08:56 AM
Please respond to
"ADSM: Dist Stor
Manager"
Yes,it is running on daily basis (one of the admin schedule ) .
Visvam Kumaraguru <visvamk AT YAHOO DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/20/2003 05:36 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: TSM DB growing @1.5Gb /2 day ??
Have you tried the expire inventory???.
kumaraguru.
TSM Admin.
--- Roger Deschner <rogerd AT UIC DOT EDU> wrote:
> My first reaction when I see a TSM database growing
> rapidly is to ask
> the obvious question:
>
> Is expiration broken somehow?
>
> Expiration and reclamation are the heartbeat of a
> TSM server. They've
> got to work. If expiration had stopped or some
> reason, such as a broken
> administrative schedule, and you can get it to go
> again, you might be
> able to get things under control before completely
> running out of space.
>
> As far as unload/reload, I'm one of those who say
> that you should NEVER
> do it. Yes, you'll achieve some short-term savings
> of disk space and CPU
> cycles. But over a relatively short amount of time,
> those savings will
> be lost, as normal database activity occurs. And the
> process is
> extremely long (days!) and fraught with peril. Those
> several days of
> downtime and very anxious work and worry are better
> spent making a case
> to your boss for more disk drives and a faster
> computer.
>
> Roger Deschner University of Illinois at
> Chicago rogerd AT uic DOT edu
>
>
> On Mon, 19 May 2003, shekhar Dhotre wrote:
>
> >Hi all ,
> >
> >On one of our TSM server(Sydney) database is
> growing 1.5 GB in 2
> >days??? (AS per AP-TSM admin). What could be the
> reasons? He is saying
> >that it is happening because of archive
> operations and unload /reload
> >will solve problem . I am going through TSM
> manuals to find out root
> >cuase, meanwhile any thoughts on how to resolve
> this problem. DB size is
> >160GB (aprox) .
> >
> >His comments :
> >>1) AP(Asia Pacific) TSM: TSM db @ 99% utilsation
> - extended database by
> >1.5Gb (very last space) -This will buy us 1-2 days
> by which we need to get
> >more disk in place.
> >
> >Thanks
> >SD
> >Atlanta ,GA.
> >
> >
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
***********************************************************************************
CONFIDENTIAL: This communication, including attachments, is intended only for
the exclusive use of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient, you are hereby
notified that you have received this document in error, and any use, review,
copying, disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy any and all copies of this
communication.
***********************************************************************************
|
