It's all about the answers!

Ask a question

4.x upgrade path - re-importing + upgrading the database....right path?

Chris Ryan (15732428) | asked Jun 18 '13, 9:16 p.m.
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 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 format.

My plan to go live is as follows:
  1. Shut down the production server
  2. Perform a database export from our production server
  3. Perform a database IMPORT of the data into our 4.0.2 staging server, overwriting existing tables as necessary
  4. Run the upgrad_ccm, etc scripts, but only the step that upgrades the database
  5. Regenerate indices on staging

My concerns:

  • The 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,

Accepted answer

permanent link
Gail Burati (611) | answered Jun 19 '13, 9:42 a.m.
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 environment, upgrading it to 4.X and flipping the DNS switch to make the staging environment the production one:

1) shutdown the production server
2) backup the final state of the production databases (jts, applications' repositories, data warehouse)
3) shutdown your 4.X staging server
4) update your 4.X staging environment files to point to the final 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!

Chris Ryan selected this answer as the correct answer

Chris Ryan commented Jun 20 '13, 1:18 p.m.

Helped me out a lot.

Thanks Gail.

2 other answers

permanent link
Krzysztof Kaźmierczyk (7.5k478103) | answered Jun 19 '13, 3:01 a.m.
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 and 4.0.2? Or you want simply to test the migration on production data on staging server?
Best regards,
Krzysztof Kazmierczyk.

Chris Ryan commented Jun 19 '13, 7:14 a.m.

Hello there,

I'm planning on making our staging servers production.  It would be easier for us than to completely reinstall and configure a Jazz installation.

permanent link
Krzysztof Kaźmierczyk (7.5k478103) | answered Jun 19 '13, 7:25 a.m.
In this case you can look at this article to see which data to move:
Let us know if it helps for you.

Best regards,
Krzysztof Kazmierczyk

Your answer

Register or 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.