I would also add to Mark's comments:

1.  Time to recover/restore TSM DB.
2.  Time to audit/repair/fix TSM DB (on the very rare occasion that you
might need to do this).
3.  Time to do upgradedb during TSM server software upgrade.

If your TSM DB restore test starts taking 2 hours, and that is too long for
you, then it is probably time to split it up between multiple servers.

The number is different for everyone, but my personal preference would be
to start thinking about/planning going to a 2nd TSM server once my DB got
above 80GB.  Anything less than that and you should be perfectly fine on a
single server.  I've been to several places that run just fine on a TSM DB
much larger than 80GB, but that seems to be a good starting point to ponder
the option of splitting it up.

______________________________
John Monahan
Senior Consultant Enterprise Solutions
Computech Resources, Inc.
Office: 952-833-0930 ext 109
Cell: 952-221-6938
http://www.computechresources.com




             Jeff Kloek
             <tsm AT KLOEK DOT COM>
             Sent by: "ADSM:                                            To
             Dist Stor                 ADSM-L AT VM.MARIST DOT EDU
             Manager"                                                   cc
             <[email protected]
             .EDU>                                                 Subject
                                       Re: Capacity Planning

             03/21/2005 01:21
             PM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






Mr. Monahan, you've given me a lot to think about, and I really appreciate
it. Whild I digest all this, I'd like I to ask another related question.
I've seen in the past many questions about the maximum operational size of
the TSM database. I've seen responses from 50Gb to 100Gb to even more. Is
there any advice from IBM in print on this that you (or anyone) know(s)
of?

Many thanks in advance.