I just did this, on AIX. Here is some of what I learned:
1. You will be putting up a "toy system" on the new server.
a. Copy dsmserv.opt. Change only what is absolutely necessary.
This is not the time to get creative with tuning settings.
WHAT YOU MUST CHANGE: locations of the volhist and devconfig
files will most likely be different on the new server.
b. While editing dsmserv.opt, set DISABLESCHEDS YES to keep the
thing from going off and doing its scheduled things while you're
working on it. Remember to remove it when you go production later.
c. Give it the same server name. (Necessary? Maybe not, or maybe so.)
d. Make the library name the same, too.
e. Run the same version of the server. Patch levels are OK to be
different within the same release number. (e.g. 4.2.2.2 to
4.2.2.3 is usually OK but check with support first.)
f. No matter how empty or full your database, make the new one at
least as large as the old. This is not the time to defragment,
so neither expect nor try to force defragmentation during a
server change, and also leave arguments about the merits and
techniques of defragmentaiton to another thread. It is OK for
the Log to be smaller. It is OK for the Database and Log
locations, names, and other attributes such as mirroring, to
be different, as long as the Database SIZE does not shrink.
g. Back up the toy server so that when you screw it up in your
restore attempts, you can get it back quickly.
2. Consider the volhist and devconfig files. You will want to use the
devconfig file that you are building on the toy server, once it
works, so do not worry too much about restoring it from the old
server. The volhist is more important. Bringing over a copy of the
Volume History File which was written AFTER your final backup on the
old server, can make the restore easier. You CAN restore a Database
if you don't have a volhist file, as long as you absolutely know
which tapes to use in what order.
3. I assume you're getting the backup tapes defined to the toy server
OK, since you appear to have been able to restore OK. This was a
problem for me. You've got to CHECKIN it, from the perspective of
the toy server, even though it is known to the old server.
4. Restore DB. Remember that you will have changed EVERYTHING in the
restore - that you will now have all the settings and such from
your old system, not the toy system. Mine came right up.
5. When you start the new server for the first time, and every time
until you go production, keep your hand poised over the keyboard
to log into an ADMIN session and type DISABLE SESSIONS the moment
it comes up, and then CANCEL any that somehow got in. You cannot
afford to have any users yet.
6. UPDATE LIBVOL to make the backup tape you just restored from, to
be "Private". It is now, from the perspective of your restored
system, a Scratch tape, and will get overwritten very soon, unless
you protect it manually like this. You might need to re-restore
from it, and it's easy to keep from burning this bridge. For
paranoia, set the tape cartridge's physical read-only tab.
7. Be prepared to re-enter your licenses. Make sure to note how many
of which kinds you have on the old server, which will save a lot
of head scratching and clairvoyance after you come up on the new
server and it tells you that you are unlicensed.
8. Delete the old disk storage pool volumes and define your new ones.
9. DELETE DRIVE for all the tape drives, and DEFINE DRIVE for them -
even if they are the same. This makes sure that the OS drivers
are properly connected up to TSM's interfaces. I didn't do this,
and I was unable to use tapes at all, after my DB restore, until
I did.
10. DO NOT DO AUDIT LIBRARY until you are sure you have all the tapes
in the new library that you had in the old one. Doublecheck
manually! OK, they're all here? Now do AUDIT LIBRARY.
11. My Quantum ATL tape library changed its SCSI addresses on its own
in the middle of all this. Once I figured this out I was able
to adjust things OK, but I never expected this little surprise.
12. I got mine up and running, but it wouldn't migrate. Problem was in
tape drive/device type definitions in some way I could not understand
that resulted in all the "Filling" tapes being of the wrong type, and
thereby unavailable FOR WRITING. They were OK to read, so I just
defined every Filling tape as being ReadOnly, which fixed things and
made migration happen again. Normal reclamation could not happen on
these either, because they weren't "Full" yet, but an ordinary MOVE
DATA returned these tapes to the scratch pool which made everything
work OK again. I'd try to figure this out, except that all the
evidence is gone.
13. Understand that you have just done a moderately good Server
Disaster Recovery Drill, and take good notes.
>From how you describe your problem, I'd look first into dsmserv.opt,
and start over there with a copy directly from the old server.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
On Tue, 28 Jan 2003, Tait, Joel wrote:
>Hi,
>
>What is the easiest way to move TSM to another server?
>I need a step-by-step process.
>
>We want to move the DB to another server then attach the library.
>
>I tried a database restore and received this error message, we attempting to
>start TSM:
>
>ANR9999D pkthread.c(791): ThreadId<0> Run-time assertion failed: "CmpLsn(
>*pageLsnP, hdrP->updtLsn ) != LESSTHAN", Thread 0, File dblog.c, Line 1061.
>
>The server names are not the same, but the TSM version is. The location for
>the db and recovery log is in a different location.
>
>Information:
>
>Both servers are:
>Windows 2000 AS
>TSM 5.1.5.1
>DB is 1.1GB
>
>Thanks
>
>JET
>
|
