Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Translate the entire conversation x

Windchill upgrade

vivek2
7-Bedrock

Windchill upgrade

Version: Windchill 12.1

 

Use Case: Hi, we are upgrading Windchill + Flexplm 11.0m030 to Windchill + Flexplm 12.1.2.9. we have completed upgrade for 3 rehersal as well. Now during the pre prod and production we are reusing the Windchill 12.1.2.9 application servers. If we install ootn 12.1.2.9 and perform upgrade as a part of pre-prod. Can we simply drop the db user which was upgraded as a part of preprod,create a new user and import the database and execute the upgrade manager ? Similar way we normally refresh our lower environment using rehosting.


Description:

1. During pre pod rehersal, Windchill ootb installation+ upgrade is completed.

2. During the next rehearsal can we use the same above Windchill instance by dropping the db user, recreate and re import the database and execute the upgrade manager.

ACCEPTED SOLUTION

Accepted Solutions

For multiple upgrade passes of one system (e.g. production), I follow this approach to minimize risk throughout the process.  The first part occurs once per upgrade, independent of upgrade passes.

 

  • Create a temporary upgrade server and use it for all upgrade passes (including production).  I typically install the DB software on this server and tune it for upgrade performance.
  • Clone/rehost the upgrade source from the production (11.0) environment into the upgrade server.  You don't need files in the vaults, just the file vault folders.
  • Install the upgrade target (12.1) into the upgrade server and configure it as required for upgrade.
  • Create a restore point for the upgrade in the upgrade server.  I use robocopy to create a backup of the Windchill 12.1 target installation.  After each upgrade pass I can reverse the robocopy to copy from the backup.
  • Install your production (12.1) system with all components (SOLR, WVS, replicas, etc.) and tune it for production use.  All validation testing will occur in the production 12.1 system.

The iterative part is...

  1. Create a restore point for the upgrade.
  2. Get a fresh copy of the 11.1 production DB for the next upgrade.
  3. Prep and run your upgrade pass and follow post-upgrade steps.
  4. Rehost the upgraded DB into the future 12.1 production environment for performance and validation testing.
  5. Reset the upgrade environment to the restore point.  Make any necessary permanent upgrade changes and refresh the restore point. 

So, for each upgrade pass, I get a fresh copy of the 11.0 production database for the upgrade source environment.  However, as @BenLoosli  said, the upgrade manager will not recognize the DB unless you also restore the target Windchill 12.1 from your restore point backup.

 

If you are using SQL Server, you can just restore the 11.0 DB backup into the upgrade source DB.  You don't have to delete and recreate the DB to reset.  For Oracle, I typically drop and recreate the Windchill database and then import the 11.0 DB from production.

View solution in original post

4 REPLIES 4
BenLoosli
23-Emerald III
(To:vivek2)

Nope

UpgradeManager will complain that the system is already at the target version and not go any further. There are files in the Windchill installation structure that get modified by UpgradeManager, it is not all DB updates.

I do many test upgrades, too and always wipe my systems back to nothing before starting an additional upgrade test. This includes running Regedit to remove all traces of the Oracle and Windchill installation on both servers.

 

 

For multiple upgrade passes of one system (e.g. production), I follow this approach to minimize risk throughout the process.  The first part occurs once per upgrade, independent of upgrade passes.

 

  • Create a temporary upgrade server and use it for all upgrade passes (including production).  I typically install the DB software on this server and tune it for upgrade performance.
  • Clone/rehost the upgrade source from the production (11.0) environment into the upgrade server.  You don't need files in the vaults, just the file vault folders.
  • Install the upgrade target (12.1) into the upgrade server and configure it as required for upgrade.
  • Create a restore point for the upgrade in the upgrade server.  I use robocopy to create a backup of the Windchill 12.1 target installation.  After each upgrade pass I can reverse the robocopy to copy from the backup.
  • Install your production (12.1) system with all components (SOLR, WVS, replicas, etc.) and tune it for production use.  All validation testing will occur in the production 12.1 system.

The iterative part is...

  1. Create a restore point for the upgrade.
  2. Get a fresh copy of the 11.1 production DB for the next upgrade.
  3. Prep and run your upgrade pass and follow post-upgrade steps.
  4. Rehost the upgraded DB into the future 12.1 production environment for performance and validation testing.
  5. Reset the upgrade environment to the restore point.  Make any necessary permanent upgrade changes and refresh the restore point. 

So, for each upgrade pass, I get a fresh copy of the 11.0 production database for the upgrade source environment.  However, as @BenLoosli  said, the upgrade manager will not recognize the DB unless you also restore the target Windchill 12.1 from your restore point backup.

 

If you are using SQL Server, you can just restore the 11.0 DB backup into the upgrade source DB.  You don't have to delete and recreate the DB to reset.  For Oracle, I typically drop and recreate the Windchill database and then import the 11.0 DB from production.

Upgrade strategies vary based on size of the data set being upgraded.  I'm not following what you are asking.  Are you just upgrading one system (production) and cloning to create/refresh pre-production, test, dev, etc.?  Or are you upgrading each system separately, starting with non-production and working your way up to production?

Thanks for your inputs.

As we are planning to use the same VM for a database server during the pre prod and production upgrade. Also same time target  Windchill application VM is common for pre prod and production upgrade.

We will follow the std approch as suggested above to do complete upgrade, Wipeout everything and go for next production Upgrade.

 

Thanks

Vivek 

Announcements



Top Tags