Thanks to both of you for your information!



_________________________________

Kathleen Hallahan
Freddie Mac





   William Boyer <bjdboyer AT COMCAST DOT NET>
   Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
   09/16/2006 01:02 PM
   Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: 3584 library sharing followup






The problem is that after "cloning" the existing database to the 2nd
instance, they BOTH have the same volume information. When you
do the AUDIT LIBR on the library client, the library manager updates the
ownership of all the tapes known by that client. So if you
were to then run an AUDIT LIBR from the 2nd (cloned) instance, ALL the
same volumes would now be "owned" by the 2nd instance. The
library manager doesn't seem to enforce that if an instance already owns
the volume(s) that another instance just can't take
ownership away.

The TYPE=REMOTE entries in the library manager volhist table prevent you
from being able to check in a tape that has data on it as a
scratch volume. But if there's no TYPE=REMOTE entry for that tape, you can
check it in as scratch and another instance can actually
overwrite the data on that tape. So you need to be careful about keeping
track what tapes are still good for each instance.

Another thing I noticed, if client1 owns a tape and client2 calls for it
to be mounted...the library manager will mount the tape and
change the ownership over to client2. Maybe this is WAD, but I don't think
that the library manager should allow the ownership
change of a tape volume just because a client asks. I don't think that the
library manager should even allow a non-owner instance to
mount the tape. Ownership changes should be a manual process to get the
desired effect. Interesting that if on the library manager a
tape is checked in and owned by client1, you cannot issue the UPD LIBV
command to change ownership to client2. You must first check
out the volume and then check it back in so the library manager is listed
as the owner and private. Then you can issue the UPD LIBV
command to make client2 the owner.

So my current DB has both daily and monthly data, separate domains and
storage pools. I'll be "cloning" the database over to another
instance. Then:

On DAILY instance (current):
- update all the monthly volumes to ACC=UNAVAIL
- Lock all the monthly nodes.
- VARY OFF all the monthly disk volumes.

On the MONTHLY instance (cloned):
- Update all daily volumes to ACC=UNAVAIL
- Lock all daily nodes.
- VARY OFF the daily disk volumes.

On the library manager:
- Change ownership of all checked in MONTHLY tapes.
- Delete the TYPE-REMOTE entries for all the MONTHLY tapes.

At this point any monthly tapes not checked in to the library are not
known to the library manaager. So you could actually check
these tapes in as scratch. This is where you need to be careful. Also you
don't want to do an AUDIT LIBR on either of the clients at
this point. As it will change the ownership of all the tapes to that
client. Then you'll have to start all over again.

On the DAILY instance:
- DELETE all the monthly data/filespace/nodes/domains.

On the MONTHLY instance:
- Delete all the daily data/filespace/nodes/domains.

One thing I did notice is that if client1 owns the tape and client2
deletes that tape the library manager will report an error and
not change the status of the tape. So when you delete a DAILY tape from
the MONTHLY instance, ownership and status won't change.


Once all the volumes/data has been deleted from the appropriate instances,
you can issue the AUDIT LIBR to update the library
manager for correct ownership.

This was a lot of trial and error and testing. I haven't split the
production database. That's planned for next month.

Bill


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
TSM_User
Sent: Saturday, September 16, 2006 1:13 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: 3584 library sharing followup

On one of the instance you will delete the library and then create a new
"shared" library.  When you run the audit library command
on a library client it updates the library manager updates it's volhist to
show that the volumes in its library are remote and not
belong to the other instnace.

  We had a server that we wanted to retire but it had been the library
manager. We simply made one of the other library clients the
manager.  Due to the fact that this new instance had no information about
any of the library clients we found we only had to run the
audit library command on all the library clients after they were pointed
to the new library manager.

  Seems like this same approch would work for you.

Kathleen M Hallahan <Kathleen_Hallahan AT FREDDIEMAC DOT COM> wrote:
  Last week, Bill Boyer posted a message (which I no longer have) about
splitting a database and library sharing. and ownership of
tapes. I saw one response suggesting exporting and importing the data, but
nothing else.

Did anyone ever come up with other ideas on this? I'm actually getting
ready to do something similar, splitting a very large TSM
database by loading a duplicate instance onto the same AIX server and then
selectively deleting from each. I'm presuming that using
the TSM library sharing function will create the same ownership issue for
us as Bill is/was experiencing. There is far too much data
for export/import to be practical.

In our case, all of the tapes for one (legacy) instance will reside
outside of the library unless needed for a specific restore, and
no new data will be added. Can I leave the library definitions intact in
the second instance, and just make sure the two systems
never have the same drive online at the same time? I would then check
tapes into the legacy instance of TSM when restores were
required. As this is old data, it would only happen on an occasional
basis.

We're on TSM 5.2.3.1 on AIX 5.2, using a 3584 with LTO2 drives.

Thanks!



_________________________________

Kathleen Hallahan
Freddie Mac



---------------------------------
Get your email and more, right on the  new Yahoo.com