4.x upgrade path - re-importing + upgrading the database....right path?
Hey fellow Jazzertons,
So, we're going live with our 4.0.2 upgrade soon. I've successfully set up a staging environment, populated the database with production data from our 3.0.1.4 system (via an Oracle export and import), and the system was tested successfully, and we're going live. Also, we're going to use the same staging servers as production servers, and are just going to change DNS aliases on the network to reflect this.
Now, all is well, although I've got to re-import our production data, which is in the 3.0.1.4 format.
My plan to go live is as follows:
So, we're going live with our 4.0.2 upgrade soon. I've successfully set up a staging environment, populated the database with production data from our 3.0.1.4 system (via an Oracle export and import), and the system was tested successfully, and we're going live. Also, we're going to use the same staging servers as production servers, and are just going to change DNS aliases on the network to reflect this.
Now, all is well, although I've got to re-import our production data, which is in the 3.0.1.4 format.
My plan to go live is as follows:
- Shut down the production server
-
Perform a database export from our 3.0.1.4 production server
-
Perform a database IMPORT of the 3.0.1.4 data into our 4.0.2 staging server, overwriting existing tables as necessary
- Run the upgrad_ccm, etc scripts, but only the step that upgrades the database
- Regenerate indices on staging
My concerns:
- The 3.0.1.4 database export will not have the same tables as what already exists in my staging server, as I've already imported and upgraded that database for the sake of testing.
Should I completely re-create my oracle database? Or will the steps above be sufficient?
Thanks all,
Chris
Accepted answer
Hi Chris -
It is not safe to reuse a database in the way you suggest above (importing 3.X into a populated 4.X database). The import code will not remove what was populated for 4.x so you will end up with a mix of 3.X and 4.X states of data. Fortunately, it is also unnecessary. to do this exporting and importing as the repotools -addTables can convert a 3.X repository to a 4.X repository. Here are the steps I was thinking you'd take to update your staging server with the latest production data from your 3.0.1.4 environment, upgrading it to 4.X and flipping the DNS switch to make the staging environment the production one:
1) shutdown the 3.0.1.4 production server
2) backup the final state of the 3.0.1.4 production databases (jts, applications' repositories, data warehouse)
3) shutdown your 4.X staging server
4) update your 4.X staging environment teamserver.properties files to point to the final 3.0.1.4 production databases
5) run the repotools-jts -addTables and -upgradeWarehouse commands as well as the repotools -addTables commands for CCM and QM ie. repotools-ccm -addTables, repotools-qm -addTables
5) recreate all the indices in your 4.X staging environment ie. repotools-xxx -reindex all
6) do whatever DNS magic is necessary to ensure only the 4.X environment will respond to the Public URLs you established for your production environment
7) bring up your new production environment
I have done similar steps in setting up test environments but I have not done this in a production environment. Krzysztof - do you agree with the above proposed steps?
Let me know if you have any questions - thanks!
Gail
It is not safe to reuse a database in the way you suggest above (importing 3.X into a populated 4.X database). The import code will not remove what was populated for 4.x so you will end up with a mix of 3.X and 4.X states of data. Fortunately, it is also unnecessary. to do this exporting and importing as the repotools -addTables can convert a 3.X repository to a 4.X repository. Here are the steps I was thinking you'd take to update your staging server with the latest production data from your 3.0.1.4 environment, upgrading it to 4.X and flipping the DNS switch to make the staging environment the production one:
1) shutdown the 3.0.1.4 production server
2) backup the final state of the 3.0.1.4 production databases (jts, applications' repositories, data warehouse)
3) shutdown your 4.X staging server
4) update your 4.X staging environment teamserver.properties files to point to the final 3.0.1.4 production databases
5) run the repotools-jts -addTables and -upgradeWarehouse commands as well as the repotools -addTables commands for CCM and QM ie. repotools-ccm -addTables, repotools-qm -addTables
5) recreate all the indices in your 4.X staging environment ie. repotools-xxx -reindex all
6) do whatever DNS magic is necessary to ensure only the 4.X environment will respond to the Public URLs you established for your production environment
7) bring up your new production environment
I have done similar steps in setting up test environments but I have not done this in a production environment. Krzysztof - do you agree with the above proposed steps?
Let me know if you have any questions - thanks!
Gail
2 other answers
Hello Chris,
The best way would by configuring your staging server again from scratch. You are risking mixing the data from two servers now. Cleanup database and set indices directory to a different than in previous server (or cleanup it first).
I am also a bit confused, are you planning to change production server between 3.0.1.4 and 4.0.2? Or you want simply to test the migration on production data on staging server?
Best regards,
Krzysztof Kazmierczyk.
The best way would by configuring your staging server again from scratch. You are risking mixing the data from two servers now. Cleanup database and set indices directory to a different than in previous server (or cleanup it first).
I am also a bit confused, are you planning to change production server between 3.0.1.4 and 4.0.2? Or you want simply to test the migration on production data on staging server?
Best regards,
Krzysztof Kazmierczyk.