>Up to now I kept my DB and Rlog sizes to a minimum (96MB and 50MB
>respectively). Most of my backups are SQL dbases or large files so there was
>no need to increase them.
>However, I have a new client (windows) that requires to backup a complex
>folder structure with about 30 million files! These are cheque images of
>about 20KB each - the total space is 600GB.
>I have no problem with my storage pool as I have enough empty tapes.
>I'm worried about the DB and Rlog sizes that I have to increase - I just
>don't know how much. A colleague suggested something between 1% and 5% of
>the size of the data to be backed up.
>Has anyone faced a similar situation, and if yes, any suggestions on the
>sizes ?
>Are there any catches as to how performance is affected by such a large
>database ?

Yiannakis - Your database and recovery log have thus far been tiny, but
            now it's time for them to grow to handle more challenging
work.  We've all been through this: it's just the demands of reality.

I'd be more concerned about the client and its subsequent impact than the
TSM database per se.  It's not the first backup that's going to be
painful - it's every incremental after that, as the whole inventory list
of millions of Active files has to be pulled from the TSM db, sent to the
client, and there be sorted and scanned.  That will make for a long-
running backup and will severely tax the memory on the client system
(where other, "real" work will probably be trying to happen at the same
time).

The people running that client system application should be encouraged to
pursue files consolidation, amassing files into a single composite using
an appropriate utility.  That will be much easier for them to manage, and
will greatly reduce backup overhead.

  Richard Sims