Re: Problem deleting filespace SYSTEM OBJECT
2002-09-24 11:01:32
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?
> 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?
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
|
|
|