Hi,
could you please tell why you are saying
'Is the ratio of deleted to examined objects less than 50%? That's good.'  ?

Our ratio is normally > 90% and the total number of examinend objects
is just varying with the frequency of the expiration processes.

I cannot see any problem - so running expration on a small server shows the 
following

once a week expiration looks like
08/23/08   13:18:07      ANR2753I (SCH_EXP_SAT):326 completed: examined 690951
                          objects, (SESSION: 13138)
08/23/08   13:18:07      ANR2753I (SCH_EXP_SAT):deleting 690689 backup objects, 0
                          archive (SESSION: 13138)
08/23/08   13:18:07      ANR2753I (SCH_EXP_SAT):objects, 0 DB backup volumes, 
and
                          28 recovery (SESSION: 13138)
08/23/08   13:18:07      ANR2753I (SCH_EXP_SAT):plan files. 0 errors were
                          encountered.  (SESSION: 13138)
... with a processing time of 140 min ( examined 690951  ... deleting 690689)


an everyday expiration  looks like
08/24/08   11:19:05      ANR2753I (SCH_EXP_SUN):355 completed: examined 86262
                          objects, (SESSION: 13904)
08/24/08   11:19:05      ANR2753I (SCH_EXP_SUN):deleting 86026 backup objects, 0
                          archive (SESSION: 13904)
08/24/08   11:19:05      ANR2753I (SCH_EXP_SUN):objects, 0 DB backup volumes, 
and 0
                          recovery (SESSION: 13904)
08/24/08   11:19:05      ANR2753I (SCH_EXP_SUN):plan files. 0 errors were
                          encountered.  (SESSION: 13904)

... with a processing time of 19 minutes ( examined  86262 ... deleting 86026 )

I always thought it is good and more effective when the number of deleted 
objects is close
to the number of examined objects. Can someone bring some light into this ?

The above actlog is from a quite new TSM 5.5.1.0 Server on solaris.

Thanks
Rainer




Roger Deschner schrieb:

.
Everything Wanda said. We have a 377gb TSM database that mostly runs OK.
(It only acts up when I'm on vacation.) It's on 15,000RPM SSA disks, in
JBOD mode, with TSM mirroring.

But you have to watch expiration closely. Basically, you have to expire
as many objects as you back up, every day. Here are the clues that
expiration gives you.

o Does expiration finish on its own in less than 24 hours? That's good.
If you have to cancel expiration in order to run database backup, that's
bad.

o Is the ratio of deleted to examined objects less than 50%? That's
good. I've seen it over 95% on a database that was in very bad trouble.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
================ Nothing is ever as simple as it seems.=================



On Thu, 28 Aug 2008, Wanda Prather wrote:

max size of 534GB.

It depends on how well you can manage your data base with your existing
hardware:
.
-You need to be able to back up the data base in a reasonable period of
time;
-You need to be able to run EXPIRE INVENTORY in a reasonable period of time;
-You need to be able to restore the data base in a reasonable period of
time, assuming it can take twice as long to restore as to back up.

"reasonable" is whatever is suitable for your site; if you are getting all
your work done in your 24 hour backup & maintenance window, that's
reasonable.

However, if you had a problem that would require you to run an AUDIT of the
DB, consider that people have reported audit times of 12 hours or more for
DB's around 200 GB.

What is reasonable for a site that backs up 50 clients and is done by 2am,
may not be reasonable in a site that backs up 700 clients and takes 23 hours
in a day to complete their maintenance window.

I have seen customers that have difficulty managing a TSM DB over 200GB
because it is located on old, slow disk.  There are other customers that
easily manage a TSM DB over 300GB because it is located on a high-end disk
array like a SHARK with lots of cache.

Put the DB on the fastest disk you've got.  If you are happy with the time
it takes to back up,  and you could afford to be down twice that long to do
a DB restore, it's OK.

Also, when you enter Q DB, make sure the DB cache hit rate stays above 98%
(except during an immediately after a DB backup).  If it isn't high, look up
the TSM server parm for BUFPOOLSIZE in the performance and turning guide and
adjust that according to instructions; it greatly affects your DB
performance.

W




On 8/28/08, Patel, Ankur <Ankur.Patel AT au.harveynorman DOT com> wrote:

Dinesh,

See if this helps.
Extract from: http://en.wikipedia.org/wiki/IBM_Tivoli_Storage_Manager
ITSM maintains a relational database (limit 534GB through ITSM v5.5) and
recovery log (aka transaction log, limit 13.5GB) for logging,
configuration, statistical information, and object metadata. DB pages
are always 4KB, and partitions every 4MB. Single row inserts only. On
average, 20GB of space is consumed for every 25 million objects. Shallow
directory structures utilize less TSM DB space than deeper paths. This
database may generally be queried via an emulated SQL-98 compliant
interface, or through undocumented SHOW, CREATE or DELETE commands.


Also, see IBM site:
http://www-01.ibm.com/support/docview.wss?rs=0&q1=Maximum+TSM+DB+Size&ui
d=swg21243509&loc=en_AU&cs=utf-8&cc=au&lang=en
The Administrator Guide manual specifies that the maximum size of the
database is 530GB. This is however a rounded figure.The actual maximum
size of the database is 543184 MB, which equates to about 530.5 GB.




Regards,



Ankur Patel
TSM Administrator


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Pahari, Dinesh P
Sent: Friday, 29 August 2008 11:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM database size?

Hi All,
I have got a TSM server with the 80GB database size. It is already
utilized above 80%. Could someone please let me know, what is the exact
recommended database size by IBM? Any links with such information would
be good.

Kind Regards,

Dinesh Pahari

************************************************************************************************
DISCLAIMER

Confidential Communication: This email and any attachments are intended for
the addressee(s)
only and are confidential. They may contain legally privileged or copyright
material. If you
are not the intended recipient, please contact the sender immediately by
reply email and
delete this email and any attachments. You must not read, copy, use,
distribute or disclose
the contents of this email without consent and Harvey Norman Holdings
Limited ACN 003 237 545
(and its related subsidiaries) ("Harvey Norman") does not accept
responsibility for any
unauthorised use or reliance on the contents of this email.

Harvey Norman does not represent or warrant that the integrity of this
email has been maintained
or that it is free from errors, viruses, interceptions or interference. Any
views expressed by
the sender do not necessarily represent the views of Harvey Norman.

This notice should not be removed from this email.

************************************************************************************************

--
------------------------------------------------------------------------
Rainer Wolf                          eMail:       rainer.wolf AT uni-ulm DOT de
kiz - Abt. Infrastruktur           Tel/Fax:      ++49 731 50-22482/22471
Universitaet Ulm                     wwweb:        http://kiz.uni-ulm.de