On Tuesday, May 27, 2003, at 09:45 AM, Richard Sims wrote:

...
05/27/2003 09:00:56  ANR2017I Administrator XXXXXX issued command:
                    DELETE FILESPACE ZZZZZZ *
...

I would caution against wildcard or like multiple mass updating
operations
(Delete Volume) in the TSM database due to the possibility of
collisions in
the same area of the database.  One could argue that utterly safe
locking
should be in place to prevent problems in concurrent updates, but I
don't
like pushing my luck.  (In a prior life I worked in database support.)
Realize that deletions of this type are *intense* database updating
operations, and appreciate that things can go very wrong if there is
any
exposure in that proprietary database software.

Valid point - I only used the wildcard here to force the emergence of
the
error for the list (so that it could be seen in context).

I have a volatile environment and have to do a lot of deletions. This is
caused mainly by upgrades to workstations, replacement of equipment
and the coming and going of students (yes, we back everyone up). With
graduation upon us, I will have a lot of deletions again to perform.

Over the years, and especially now, I've found that the database really
can't 'tolerate' a lot of change. I try to balance what I have to get
done
and what the database can deal with. When I do have to do a lot of
deletions (or reclaims, etc.), I will throttle back the number of
sessions
to about a tenth of what I would normally run. It seems like the 'holes'
that the expirations/deletions/etc. cause are more problematic to 'fill'
and the log pins with regularity (even though I have close to 13 GB of
log space).

Although I'd like to be more temperate about deletions, I often can't.
Just
too short on resources. I'm trying to keep the number of clients under
8,000 (spread across five servers), but I may have to give up my test
server soon.

The whole point of this was to provide some time estimates for those
with
audits looming on the horizon and find out if anyone else has been
helped
by support with a strategic deletion in the database...

Gretchen Thiele
Princeton University