Good morning Richard
On the first point I may have confused things. When I brought the new TSM
server up I made sure the library was indeed in Auto mode, I just had it in
manual when I did the initial db restore (which completed without any
errors). However, I did not try to get the new TSM server to do an audit of
the lib.
This may sound like a silly question, but I'm assuming that the TSM audit
commands can have no effect on the actual library inventory. I just want to
make sure I don't create any more problems for myself.
On the second point, I did run a few mtlib queries on the old server (after
all server activity had finished and TSM had been halted), and on the new
server immediately after it was connected to the library.
The commands I ran were as follows :-
mtlib -l 3494a -vqK -s fffd (to count all cleaning tapes)
mtlib -l 3494a -vqK -s 12E (to count all scratch)
mtlib -l 3494a -vqK -s 12C (to count all private)
mtlib -l 3494a -vqK -s 0000 (to count all volumes)
mtlib -l 3494a -qS (to get info about lib)
mtlib -l 3494a -qI (to get a list of all volumes)
I then compared the output from the old server with that of the new one and
confirmed that the output was identical on both. I would not have gone
ahead had this not been the case.
I am assuming the atldd driver is in good shape, but apart from running the
above queries, how can I tell? I am running a later version of the driver
form that on the original server.
As far as the lib being able to talk to the server OK, it has it's own
dedicated little network. I didn't change anything on the library here, I
just made sure that the required interface with the exact same IP address
was present on the new server. Again, as the mtlib commands work, I'm
assuming this is OK.
On the third point, there are architectural differences. The original
server resides on a Solaris 2.7 server, and the new one is Solaris 2.9.
But, last time I tried this, I got as far as being able to back up the db,
audit volumes etc, and it only started having problems when trying to
migrate to tapes that already had a state of 'filling' (which I was hoping
to solve this time round). So it doesn't sound like an OS problem here.
Thanks
Farren
|-----------------------------+-------------------------------------------|
| Richard Sims <rbs AT BU DOT EDU> |
|
| Sent by: "ADSM: Dist Stor | |
| Manager" | To|
| <ADSM-L AT VM.MARIST DOT EDU> | ADSM-L AT
VM.MARIST DOT ED|
| | U |
| 08/04/2006 22:38 | cc|
| | |
| Please respond to | Subject|
| "ADSM: Dist Stor | Re: [ADSM-L] Some |
| Manager" | strange tape |
| <ADSM-L AT VM.MARIST DOT EDU> | related issues?
|
| | |
| | |
| | |
| | |
| | |
| | |
|-----------------------------+-------------------------------------------|
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
######################################################################
The information contained in this e-mail and any subsequent
correspondence is private and confidential and intended solely
for the named recipient(s). If you are not a named recipient,
you must not copy, distribute, or disseminate the information,
open any attachment, or take any action in reliance on it. If you
have received the e-mail in error, please notify the sender and delete
the e-mail.
Any views or opinions expressed in this e-mail are those of the
individual sender, unless otherwise stated. Although this e-mail has
been scanned for viruses you should rely on your own virus check, as
the sender accepts no liability for any damage arising out of any bug
or virus infection.
######################################################################
|
