ADSM-L

Re: Problem deleting filespace SYSTEM OBJECT

2002-09-26 02:10:01
Subject: Re: Problem deleting filespace SYSTEM OBJECT
From: Joel Fuhrman <joelf AT CAC.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Sep 2002 23:09:21 -0700
My responses are within the text ...

On Tue, 24 Sep 2002, Gerhard Rentschler wrote:

> Hello,
> in the meantime I upgraded to 5.1.1.6. With this level I could delete the
> filespace without problem.
> However, I couldn't resist to try "cleanup backupgroup" again. Under 5.1.1.4
> it worked. It only seemed strange that it obviously didn't finish its work,
> as Joel described:
> > On 5.1.1.4, I did the CLEANUP BACKUPGROUP and I still could not delete the
> > system objects.  I reran the cleanup command numerous times and
> > each time it
> > reported inspecting and deleting fewer objects than the previous run.
>
> On 5.1.1.6 cleanup backupgroup stopped immediately with return code 4. In
> the activity log I found the following messages:
> 09/24/02 10:31:51     ANR2017I Administrator GERHARD issued command: CLEANUP
>                        BACKUPGROUPS
> 09/24/02 10:31:51     ANR9999D imutil.c(6663): ThreadId<67> Failure deleting
>                        member 0 585368742 for group 1637 3 - encountered
>                        repeatedly in loop.
> 09/24/02 10:31:51     ANR9999D imutil.c(3931): ThreadId<67> Error 19
> deleting
>                        dependents for node 0 fs 0 and leader 1637 3.
> Now I'm little bit concerned. Is cleanup backupgroup broken or is it my
> database?
>

The CLEANUP did the same thing for me on 5.1.1.6 until I did an AUDITDB
FIX=YES.  After doing the auditdb, it ran properly.

> > My suggestion to all TSM admins is to do a
> >    QUERY OCCUPANCY * "SYSTEM OBJECT"
> > to verify that you do not have excessive copies.
> >
> How can you tell from the output of the q occ command how many excessive
> copies you have?

For most of my servers, the system object consists of about 1800 objects and
require 230 MB. Do the math and you will know if you have excessive backups.

>
>
> BTW, I cannot confirm that system objects are not expired. I used the
> following SQL statement in the middle and at the end of an expiration
> process:
> select sum(num_files) from occupancy where filespace_name='SYSTEM OBJECT'
> The first number I got was 1043479, the last 1012998. So I got rid of at
> least 30481 files.
>
> Best regards
> Gerhard
> ---
> Gerhard Rentschler            email:g.rentschler AT rus.uni-stuttgart DOT de
> Regional Computing Center     tel.   ++49/711/685 5806
> University of Stuttgart       fax:   ++49/711/682357
> Allmandring 30a
> D 70550
> Stuttgart
> Germany
>

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