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
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
Accepted answer
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.
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.
Comments
Kevin Ramer
Jun 26 '14, 10:48 a.m.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
ARMAND ANGLADE
Jun 26 '14, 11:46 a.m.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 ?
Kevin Ramer
Jun 26 '14, 2:37 p.m.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.
ARMAND ANGLADE
Jun 27 '14, 6:22 a.m.Yes Kevin, I was referring to the DB2 indices. Your answer really helped ! thanks again.