Actually, I think the key factor is expiration. And one reason it is an
issue is that expiration is also single-threaded. And, expiration can
take much longer than full DB backup on an active system, making it a
more critical factor in determining ultimate capacity of a hardware
configuration.

When you can no longer expire database entries as quickly as they are
being added, you are over the database size limit. If expiration takes
longer than the time window allowed for it in your daily schedule, you
have exceeded your hardware configuration's absolute maximum database
size. Or, put another way, the average time it takes to do expiration,
divided by the size of the time window you allow in your daily schedule
for it, is the percentage of your maximum database size that you are
presently at.

One way of determining whether you are expiring adequately or not, is to
compare the numbers returned by QUERY OCCUPANCY to the size of the
dataspace being backed up. This multiple should not be too much larger
than the number of inactive copies of a file you have decided to keep,
in your policies. It could be less, if it is relatively static. But if
this multiple is a lot higher than the number of inactive copies in your
policies, it should be a red flag of expiration trouble.

Faster hardware and/or splitting the server are the only answers. If
your computer has multiple processors, and they are not all fully
utilized, you could split the server into multiple images on the same
machine and gain an advantage, in this way multi-threading expiration,
as well as database backup.

An SLA governing your Disaster Recovery Plan is secondary to the basic
principle that you've got to get rid of stuff at least as quickly as it
arrives.

IT WOULD BE NICE to simply allow multiple simultaneous expiration
processes.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
================== If we do not change our direction ===================
============= we are likely to end up where we are headed. =============


On Fri, 5 Apr 2002, Scott McCambly wrote:

>Thanks to all who responded to my inquiry.
>
>All your comments were valid, and I especially liked Nick Cassimatis point
>about TSM DB backups spanning multiple volumes.
>
>The main point of my question was to gather a survey of database sizes out
>there, so I'm happy to keep seeing responses come in on that.
>
>Obviously as people go beyond a defined SLA for maximum time to restore the
>TSM environment then a second server is justified.  Those of us who have no
>formal SLA's have to make a judgement call.
>
>My only hope is that Tivoli is working towards enhancing the performance
>and capabilities for backing up TSM's database (multi-threaded perhaps?),
>just as the TDP agents do for our other business systems. Might we assume
>they are lacking incentive due to the possibility that such an enhancement
>could result in fewer server license sales? ;-)
>
>Are any TSM developers listening aware of something to look forward to in
>this area?
>
>Thanks, and have a good weekend!
>
>Scott.
>
>At 10:56 AM 4/3/02 -0600, you wrote:
>>80 GB is in the range of what I think of as "barely manageable" on your
>>average midrange Unix computer (IBM H80, Sun E450).  I know folks run
>>bigger DBs (somebody's got one in excess of 160GB) but you need
>>substantial server hardware and very fast disks.
>>
>>_____________________________
>>William Mansfield
>>Senior Consultant
>>Solution Technology, Inc
>>
>>
>>
>>
>>
>>Scott McCambly <mccambly AT ATTCANADA DOT CA>
>>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>04/03/2002 11:08 AM
>>Please respond to "ADSM: Dist Stor Manager"
>>
>>
>>        To:     ADSM-L AT VM.MARIST DOT EDU
>>        cc:
>>        Subject:        TSM database maximum recommended size
>>
>>
>>Hello all,
>>
>>Our data storage requirements have been driving our TSM database usage to
>>new heights, and we are looking for some references to "just how big is
>>too
>>big" in order to help build a business case for deploying additional
>>servers.
>>
>>Our current TSM database is 86.5GB and although backup and restore
>>operations are running fine, database management tasks are becoming
>>painfully long.  I personally think this database size is "too big".  What
>>are your thoughts?
>>How many sites are running with databases this large or larger? On what
>>hardware?
>>
>>IBM/Tivoli's maxiumum size recommendations seem to grow each year with the
>>introduction of more powerful hardware platforms, but issues such as
>>single
>>threaded db backup and restore continue to pose problems to unlimited
>>growth.
>>
>>Any input would be greatly appreciated.
>>
>>Thanks,
>>
>>Scott.
>>Scott McCambly
>>AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa, Ontario, Canada
>>(613)799-9269
>>
>>
>Scott McCambly
>AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa, Ontario, Canada
>(613)799-9269
>