From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) Berbee Information Networks Office 262.521.5627
