Re: TSM DB -- How big is too big?
2005-01-21 11:04:42
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of Robin Sharpe
>I know this question has no definitive answer, but I have to
>ask because of our situation.
>My TSM database is currently about 220GB, 98% utilized and
>growing steadily. It hasn't posed a serious problem, other
>than having to throw disk at it. Backup takes 1.5 - 2 hours
>to LTO2 tape.
>I also have an overflowed STK L700 library... 14 LTO2 drives,
>6 DLT drives,
>618 slots.... about 450 carts on a rack in the computer room
>
>I'm considering a couple of options...
>1) Freeze current database (shut it down) and start over with
>a new one.
>May need to bring the old one up for occasional restore...
>lots of unanswered questions here, like how will this work
>with RMAN - TDP Oracle?
>2) Split into two or more TSM's -- maybe one for Disaster
>Recovery (i.e.
>hot site) machines, and two or three more split by platform or
>application.
>
>Both options will require sharing our library (until we get an
>additional one), and I'm not sure that can be done by multiple
>TSMs on the same host machine.
>Both options create a much more complex TSM environment to
>manage... right now everything is nice and simple - one TSM,
>one library.
>
>So, I'm open to suggestions & comments.... is a 220GB
>database justification to create a more complex environment,
>and is it feasible on one host? (Host is an HP rp7410 running
>HP-UX 11i, and could be partitioned if needed).
Speaking from a fairly non-technical basis, I would definitely split the
database up. (There's a saying about having all of your eggs in one
basket.) You're actually getting pretty damned good throughput if you
can back 220GB of TSM database is less than 2 hours.
The easiest way to do this, if you're not in a whopping hurry, is to
create the new instance (or install TSM on a separate server), create a
node movement schedule, and move the nodes one at a time by creating
server-to-server communications and doing a direct export/import. (Not
only is the direct export/import faster, it doesn't depend upon the
vagaries of moving data onto and off of tapes.) Once a node is
completely moved to the new server, point the client at the new server
and delete the filespaces/admin/node from the old server.
This will require patience and a library with sufficient space to hold
two copies of a given node's data at any one time.
--
Mark Stapleton (stapleton AT berbee DOT com)
Berbee Information Networks
Office 262.521.5627
|
|
|