Joe,

I think Richard is spot on in saying that the hardware configuration
dictates the size of the database that you can support.  And there is
no magic formulae ...

Over the last five years we have taken *SM from :
a single server on RS6000/R24
moved it to on RS6000/R40
  (not much gain; because early V2 did not work on SMP ... long time ago!)
split off archive and HSM functions onto a second server (another R40)
moved all backup services onto single server on RS6000/H70
lastly split 'server' backups onto RS6000/M80 (leaving desktops on H70);
  archive/HSM server also now runs on same M80 - works very well

What I have learned in all this is that the constraints on the DB
are largely relieved as you move through each hardware upgrade
(cpu, memory and SSA etc).  We had a 70GB database on the R40 that
took 5 hours for a full backup and went to less than 2 on the H70;
similarly expire inventory on R40 took 1-2 days at weekend (at its
worst) - and on H70 went down to less than 12 hours (that was
examining 8 million entries and deleting 2-3 million, typically).

Currently the H70 TSM DB is 75GB and we are ok with that.

It is fair to say that there have also been some significant
software performance improvents over the 5 years as well.

My other recommendation is to think quite carefully about any
conflicting needs of different types of services :  e.g.  server
backups will be needed overnight but maybe desktops have some
daytime requirements.  This applies not just to the *SM DB, but
whether the host server can cope with all the work.

Costs are an issue - hardware and licensing - but given choice I
would go for separate functions on *SM servers and share servers
on a box if the disk needs could be met and there is cpu/memory
capacity.  The big minus of sharing is the sharing of tape drives
we haven't had much luck with 3590 sharing and have returned to
dedicated drives until things (hopefully) improve.

Should you go for a single large *SM server, I would strongly
recommend a logical separation of the storage hierarchies from the
outset - that way should the services grow and you have resources,
splitting the server into multiple functions will be a lot, lot
easier!

Best regards, Sheelagh
--
Sheelagh Treweek
Sheelagh Treweek
Oxford University Computing Services
Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Phone: +44 (0)1865 273205 Fax:-273275