ADSM-L

Re: Some strange tape related issues?

2006-04-08 17:51:44
Subject: Re: Some strange tape related issues?
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 8 Apr 2006 17:38:18 -0400
On Apr 8, 2006, at 1:20 PM, Farren Minns wrote:

Hi Richard

I see the following which to me looks as I would expect and vol
000188 was
indeed the volume I used this morning. I did not see any errors during
backup or restore.

The only thing is that the database volumes on the new server had
mirrored
copies already in place. These were stale when I started the server
but
then syncd ok. Could this have caused a problem?

Farren -

Unused mirrors should not be an issue, in that the unmirrored copy of
the database should be fully viable unto itself.  The Vary On which
performed synchronization just copies the primary image data.

You mentioned in your first posting today that the library was in
Pause mode for some reason when the new instance of the TSM server
was started.  The library needs to be viable when TSM goes to use it
at any time; and at start-up time, TSM is trying to do a lot of
communication with it, for volumes consistency checking.  Putting the
3494 back into Auto mode does not result in an audit, but rather a
library-specific Inventory check (depending upon library settings),
where the accessor runs around scanning storage cell and drive
contents.  Manually performing a TSM Audit Library may correct TSM's
knowledge of its volumes in the library.

I would use mtlib commands to get a list of the library tapes with
Category Codes reported, to assure that all volumes seem reasonable
and appropriate for use with the Library category code numbers as end
up in the new TSM server.  Presumably, your atldd driver is in good
shape on the new server (?) and the 3494's Library Manager has been
updated to allow access by the new server system?  (I expect so, but
want to assure that basics are not overlooked.)

The only other thing I could think of is that there may be some
architectural inconsistency which makes a db restoral type of server
transfer dubious or invalid, possibly one system being 32-bit and the
other 64-bit, for example.  I would pore over the Activity Log in the
new server looking for other problem indications.

  Richard Sims