ADSM-L

Re: Splitting TSM ...

2005-04-21 12:06:47
Subject: Re: Splitting TSM ...
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 21 Apr 2005 12:06:11 -0400
> Dear Colleagues,
>
> Well, I've decided it's just about time to bite the bullet and split my
> 260GB TSM database into two or more.  My plan is to have a "TSM_DR"
> (disaster recovery), and maybe two others (TSM_A and TSM_B), which can have
> their load split by client platform or TSM client type or some other scheme
> to attempt to equalize the DB size.  The TSM_DR  will only contain those
> clients that we have designated to be reovered in a site disaster... this
> will reduce the time required to restore the database at the DR site.
>
> I plan to share our STK L700, with the TSM_DR acting as library server.
> I've already tested this and I'm satisfied that it will work.

Past postings on this topic have generally advised having a server
instance that is purely a library server, with no client data.

> My question
> for you all is, how to move the "DR" storage pools and volumes from the
> existing TSM to TSM_DR.  We've come up with two possibilities:
>
> - Export/Import...  this is the obvious approach, and probably what Tivoli
> would recommend, but it will take a while.
> - Duplicate the existing database, and then delete what does not belong in
> each; then shrink them down to appropriate size.  I think this could be
> done in a day.
>
> Does anyone see any reason why the second approach would not work?
> Is there another method that I am missing?

You will need to think very carefully about tape management, and ensure
that you do not end up with one of the new servers reusing tapes that
still contain data belonging to another of the new servers.

Reducing a 260 gigabyte database to something like a third of that size
implies deleting something in the neighborhood of two hundred million
files. It would take a very impressive processor, buffer pool, and disk
subsystem to do that in a day.

The TSM database is organized in four megabyte segments. Segments left
completely vacant by file deletions can be removed from the database
using the 'reduce db' command. On the other hand, unused space in
segments that still contain some data can be removed only by unloading
and reloading the database. Sites that have tried this report that it
is a very time-consuming process.

<Prev in Thread] Current Thread [Next in Thread>