ADSM-L

Re: cleanup backupgroups

2002-10-14 12:48:08
Subject: Re: cleanup backupgroups
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 14 Oct 2002 19:46:19 +0300
Matt,

you got it right - there is a problem with SystemObject expiration
introduced in v4.2.2 and you have to run CLEANUP BACKUPGROUP to prevent
enourmous high space usage in DB and storage pool. This applies if you
have many W2k nodes backing up to TSM. It would last until you upgrade to
a version without the bug. It is expected in v4.2.3 the bug to be fixed.
So without upgrade (in far future) to v5.1.x you still can apply v4.2.3
(or later) maintenance.

Without additional information I cannot be sure this is your only problem
leading to 100% DB full. It might be somehwhere else - for example
expiration not running at all. Compare output of 'q fi' and 'q occ' - is
the ratio higher than number of copies to be kept by default classes.

Zlatko Krastev
IT Consultant






Matt Simpson <msimpson AT UKY DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
14.10.2002 17:52
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: cleanup backupgroups


I'm a newcomer to this list, and a newcomer to TSM. So there's a very
good chance that I'm totally confused.  I'm catching the tail end of
this cleanup backupgroups discussion, and I need some clarification.

I think I'm reading that there's a problem in 4.2.2.x versions of TSM
which causes SYSTEM OBJECTS not to expire, requiring the CLEANUP
BACKUPGROUPS.  I've seen some messages that indicate the cleanup
needs to run after conversion to 5.1.

We're running TSM 4.2.2.0 on Solaris.  We hope to upgrade to 5.1
sometime, but probably not soon.  While we're still on 4.2.2.0, do we
need to do this cleanup regularly?  We recently had a problem with
TSM coming to a screeching halt after our database got 100% full, and
we're not sure why a database that was supposedly way bigger than we
would ever need has filled up before we've even got half our backups
on it.  Is it possible that this systems objects problem is
contributing to our db size problem?
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as
fast
as last year's.

<Prev in Thread] Current Thread [Next in Thread>