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:[EMAIL PROTECTED] On Behalf Of TSM_User Sent: Saturday, September 16, 2006 1:13 AM To: ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> 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
