Expiration is working fine. It starts every morning at 5 AM, and runs for
about 30-40 minutes.
*********
ANR0812I Inventory file expiration process 295 completed:
examined 944182 objects, deleting 37102 backup objects, 0
archive objects, 0 DB backup volumes, and 0 recovery plan
files. 0 errors were encountered
*********
Does this mean I only have 944,182 objects being managed by the database?
If so, it sounds like I do have something bloating my database. If Thomas
D. can get primary and copy pool backups for 4.8 million + files in a 10GB
database, and my 8GB database is filled nearly 70% utilized with less than
a million objects, something is wrong somewhere.
Also, I in looking for things that stand out, I found occasional instances
in my 30 days worth of activity log where a TDP for SQL server started/end
sessions for storage agent on the order of 5-40 times per second, sometimes
lasting 4-5 seconds, sometimes lasting 4-5 minutes. I understand that
anything in the activity log is in the database, too. Any ideas what could
be causing the storage agent to start/end sessions 40 times per second for
5 minutes?
|--------+------------------------>
| | Roger Deschner|
| | <[EMAIL PROTECTED]|
| | U> |
| | Sent by: |
| | "ADSM: Dist |
| | Stor Manager" |
| | <[EMAIL PROTECTED]|
| | IST.EDU> |
| | |
| | |
| | 07/31/02 01:14|
| | AM |
| | Please respond|
| | to "ADSM: Dist|
| | Stor Manager" |
| | |
|--------+------------------------>
>-------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Minimizing Database Utilization
|
>-------------------------------------------------------------------------------------------------------------------|
Consider the possibility that you are not expiring well enough, which
could be causing database bloat. (Not to mention tape storage pool
bloat.) How long does your expiration process take? Does it seem to
never end? If so, you may be in an expiration bound death spiral.
If you are having trouble with expiration as it is, you are in no
position to take on an additional large client system, as was the start
of this thread. Dramatically lengthening expiration process run times
are a true sign that a TSM server is out of gas, and needs an upgrade
just for its present workload, not to mention adding more work to it.
Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED]
On Tue, 30 Jul 2002, Todd Lundstedt wrote:
>Well, well.. I totally read my book the wrong way. I will go recalculate.
>Thanks for pointing out this huge error on my part. Now I have to go
>figure out where the rest of my database utilization is going, too.
