ADSM-L

Re: TSM DB -- How big is too big?

2005-01-21 11:04:42
Subject: Re: TSM DB -- How big is too big?
From: "Stapleton, Mark" <mark.stapleton AT BERBEE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 21 Jan 2005 10:04:24 -0600
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