Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question
If you change the hostname of the TSM after you install TSM 6 (DB2)
there is an issue ...
here is steps how to fix it, if you REALLY need to change the hostname
of TSM server AFTER installation of TSM v6.x
1 disable client sessions
2 Backup TSM DB type=full
3 Halt TSM server
4 Set TSM service to maunal
5 Stop DB2 instance
6 Stop DB2 admin server
7 Open DB2 command prompt and execure:
db2set -g DB2SYSTEM=<new_host_name>
db2set -g DB2_EXTSECURITY=NO << switch back after reboot
8 Execute db2set -all to check settings
9 Change Windows system name to <new_host_name>
10 Reboot Server
11 Stop DB2 instance
12 Stop DB2 admin server
14 Check settings ==> db2set -all
C:\Program Files\Tivoli\TSM\db2\BIN>db2set -g
16 Reboot Server
17 Start TSM server
18 Change TSM service to authomatic
19 Edit dsm.opt file to reflect new hostname
20 Enabel sessions ==> enable ses
On Mon, Apr 23, 2012 at 6:31 PM, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu>
> I am having difficulty reconciling which order to do what based on
> documentation that says not to do it the way I have/need to do it. I am
> getting ready to do a complete migration from an old 5.5 server (Linux) to
> a brand new box (both hardware and OS).
> I need to restore the 5.5 DB, volhist, devconfig and dsmserv.opt to the
> new box so I can do the conversion to 6.2.3.
> Problem is this.............the DB backup will be on an offsite TSM
> server, so server-to-server communications is required.
> To establish the server-to-server connection from the brand new 5.5
> install and the offsite backup server, I need to bring up the new, virgin
> 5.5 instance and do an "DEFINE SERVER .... FORCESYNC=YES".
> The Administrator Guide section on "Recovering Your Server Using Database
> Backups - Restoring a Database to a Point-In-Time" says that after
> formatting the log and database files and BEFORE the "dsmserv restore":
> "Attention: Do not start the server until after you restore the database
> (the next step). Starting the server before the restore would destroy any
> existing volume history files."
> But since I have to start the new server to define the connection so I can
> restore the database........ Or am I simply reading this wrong and they
> are assuming the volhist on the machine I am restoring to has the original
> volhist (which it wouldn't, at this point).
> So, should I simply ignore this and restore the DB and then replace the
> volhist/devconfig/dsmserv.opt files on the restored server with the
> originals from the server I am replacing/upgrading after I restore the DB
> and before performing the upgrade?
> As you can tell, this is my first total server upgrade/replacement, so I
> am getting anxious about the details/processes/steps.
> My current steps are:
> Original Server:
> 1. Disable client sessions, stop all admin schedules
> 2. Empty and delete ALL disk volumes
> 3. Backup DB, volhist, devconfig, dsmserv.opt and HALT server
> New Server:
> 1. Install 22.214.171.124 - define/format DB volumes
> 2. Bring up server and define connection to offsite server with DB backup
> 3. Restore DB
> 4. Replace volhist, devconfig, dsmserv.opt from backups of original
> 5. Install 6.2.3
> 6. Run /opt/tivoli/tsm/server/bin/dsmupgdx to prepare, convert and insert
> 5.5 DB into 6.2.3 instance
> 7. Change hostname and IP addresses to that of old 5.5 server
> 8. Bring up 6.2.3 - redefine disk storage volumes - update server -
> forceresync other, library manager servers - update paths
> Thoughts, suggestions, ideas, corrections?
> Zoltan Forray
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://infosecurity.vcu.edu/phishing.html