Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Migration from 301 to 406 with Backup / Restore (Windows to Unix)

Hi,

I am currently working on a scenario of migration of CLM 301 to CLM 406 that include a change of architecture (Windows CLM with Windows DB2 to Linux CLM with Linux DB2). This scenario should have a very low downtime for all RTC users. At this time of the evaluation, having 4 hours of downtime is not acceptable.

I would be grateful if you could help me to clarify those concerns:
Can I use the backup/restore scenario describe in deployment WIKI (https://jazz.net/wiki/bin/view/Deployment/BackupCLM) to upgrade JTS/RTC 301 running on Windows(JTS and DB)  to JTS/RTC 406  running on Linux (JTS and DB) ?

In case we can use this scenario, I have 2 additional questions :
Is it possible to restore the indexes (JFS and Fulltext) from Windows CLM to Unix CLM ? (We want to avoid rebuild the indexes as it could take hours of downtime during this operation).
What about the configuration files ? Can I propagate easily changes of configuration files to the new CLM environment in 406 ?

Best Regards,
Armand

0 votes

Comments

Please also be aware that one cannot restore a db2 backup across platforms !  One must use db2move export / db2move import.  So your desire of a short downtime is likely not possible as you may have to go through repotools -export

Thanks for your answer.
In that case, if we go through the db2move export/db2move import to restore on a different platform, will I need to rebuild the indexes ?

By indexes are you referring to DB2's indices ?  Here's where my db2 experience lacks with respect to this.  I've done the export/import on "simple" databases w/o much considerations to the end result.  However, CLM has rather complex databases with many schema and more than a few indexes.   It is possible to use db2look to extract the db2 commands that would recreate a new (empty) database with identical structure, then use the import side.  However there may be table constraints that could prevent import (e.g.  generated values for work item id, etc).  

My point was to not let you go down the path of having a db2 backup file to restore on the day of your intended migration only to hit that cross-platform issue.

Yes Kevin, I was referring to the DB2 indices. Your answer really helped ! thanks again.


Accepted answer

Permanent link
You should divide this into two jobs
1.) Upgrade from 3.0.1 to 4.0.6 (or 5.0)
2.) switch the hardware

Regarding the upgrade to 4.0 it can be done within four hours if it is only JTS and RTC.
An upgrade to 5.0 can take a longer time, if you are using the SCM component within RTC.

Regarding platform switch.
Are you using a DNS alias? If yes, how long will take the switch to the "new" IP adress?
If not, you'll have to plan a server rename in addition.
The configuration files shouldn't be a problem, the indices I don't know.

greetings georg.
ARMAND ANGLADE selected this answer as the correct answer

0 votes

Comments

Thanks for the advice Georg !
It will be wiser indeed to divide it into 2 steps.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 7,489
× 267
× 118

Question asked: Jun 26 '14, 4:38 a.m.

Question was seen: 5,714 times

Last updated: Jun 27 '14, 6:22 a.m.

Confirmation Cancel Confirm