Re: Minimizing Database Utilization

        Look to make sure your TDP's are actually deleting their backups.  I
was burned by DB2, Oracle and MS-EXCHANGE platforms not sending the command
to TSM to delete their old backups.   These files are NOT really being
managed by the copygroup policy the way you may think they are.  The client
must tell the server that the file (the TDP backups are all date/time
stamped and therefore UNIQUE) has been deleted.  Then your deleted file
policy in the copygroup is in effect.
Matt

-----Original Message-----
From: Todd Lundstedt [mailto:Todd_Lundstedt AT VIA-CHRISTI DOT ORG]
Sent: Wednesday, July 31, 2002 10:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Minimizing Database Utilization

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|
|        |          <rogerd AT UIC DOT ED|
|        |          U>            |
|        |          Sent by:      |
|        |          "ADSM: Dist   |
|        |          Stor Manager" |
|        |          <ADSM-L AT VM DOT MAR|
|        |          IST.EDU>      |
|        |                        |
|        |                        |
|        |          07/31/02 01:14|
|        |          AM            |
|        |          Please respond|
|        |          to "ADSM: Dist|
|        |          Stor Manager" |
|        |                        |
|--------+------------------------>

>---------------------------------------------------------------------------
----------------------------------------|
  |
|
  |      To:     ADSM-L AT VM.MARIST DOT EDU
|
  |      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     rogerd AT uic DOT edu

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.