From: Gretchen L. Thiele [mailto:gretchen AT PRINCETON DOT EDU] 
> I've been plagued by a few problems when deleting accounts. So far,
> it seems like Win2K or WinXP clients (SYSTEM OBJECTs are involved
> again!) are prone to this error:
> 
> 05/27/2003 09:00:56  ANR2017I Administrator XXXXXX issued command:
> DELETE FILESPACE ZZZZZZ *
> 05/27/2003 09:00:56  ANR0984I Process 185 for DELETE FILESPACE started
> in the BACKGROUND at 09:00:56.
> 05/27/2003 09:00:56  ANR0800I DELETE FILESPACE * (fsId=6) for node
> ZZZZZZ started as process 185.
> 05/27/2003 09:00:56  ANR0802I DELETE FILESPACE * (fsId=6)
> (backup/archive data) for node ZZZZZZ started.
> 05/27/2003 09:00:57  ANR0104E imutil.c(7761): Error 2 
> deleting row from table "Expiring.Objects".
> 05/27/2003 09:00:57  ANR9999D imfsdel.c(1872): ThreadId<25> Error 19
> deleting group leader 0 176658713.
> 
> I've tried a number of things - renaming the filespace, 
> moving the node data and then
> auditing the tape, deleting the filespace specifically - but it's
> really a database
> 'corruption' and can only be fixed by an audit (per support).
> 
> Over the course of the last two weeks, I recovered this database to a
> test server and
> ran an audit. Here are the pertinent stats for your reference:
> 
> Server: H80, 4 way, 2 GB, AIX 4.3.3
> TSM: v5.1.6.4
> DB size: 179,544 MB - 74.4% full
> Log size: 13,280 MB
> Audit command: dsmserv auditdb fix=yes
> Audit start: 5/19 09:05
> Audit end: 5/25 19:15
> Number of database entries: Processed 1050073565 database entries
> (cumulative).
> Elapsed time: 6 days 10 hours 10 minutes
> 
> The audit was successful and did allow me to delete the problem node.
> However,
> there really should be a way to go after the offending entry and blast
> it (under
> adult supervision, of course!). I'm not really going to be able to
> justify a down
> time of 7 days just to clean up an account. It's now happened again on
> another
> server, so I will have to do this test again to get a good estimate of
> the down time required to clean that server up.
> 
> I've pushed these accounts 'aside' by renaming them and changing the
> contact
> info, but the clients would really like me to remove the data (legal
> reasons). Having
> errors like this makes me wonder what else is going on in the
database.

To tell the truth, the problem lies in the size of your TSM database
(and probably also the speed of disk upon which said database resides
and the speed of the processor used by the TSM server). You probably
ought to consider breaking it up into several separate TSM servers. This
gives the added ability to export nodes to alternate serves when a
particular server is giving you fits.

When you grow to enterprise size, you've got to start thinking in
enterprise mode.
 
--
Mark Stapleton (mark.stapleton AT berbee DOT com)
Berbee Information Networks
Office 262.521.5627