23-Emerald III

Question

Restore system

Forum|Forum|3 years ago
August 26, 2022
2 replies
4352 views

When doing an upgrade on different virtual hardware, UpgradeManager modified my production database and now Windchill will not start. My first comment is that this should NEVER happen. I do upgrades on new computers so my existing systems remains viable.

Now that I have a corrupt system due to PTC, how do I restore it? I have backups taken about a 6 weeks before the attempted upgrade. That is my fault for not taking them just before the upgrade. My backup data consists of the Oracle DB, the file vaults and an LDIF export. What had me confused was that my source Windchill system was still running after the failed upgrade attempt. Only when IT rebooted the computer did the issue come up with the method servers failing to start due to incompatible data.

So, what steps do I need to take to restore the system to my April backup? I am thinking about wiping both systems and rebuilding them from scratch and then importing the Oracle and LDIF files and restoring the vaults. Is there a restore method that I could do without wiping the 2 servers?

This issue has also made me gun shy on doing upgrades to my other 2 Windchill systems as they are both current active production systems. This third Windchill was taken offline in July due to a contract termination, but I was using it for the practice of going from Windchill 11.0 M030 to Windchill 12.0.20.6, as that is the configuration of one of my production systems, the other is 11.1 M020 CPS20. I will do full backups of the Oracle and LDAP before doing upgrades in the future, even for testing. Both of these systems have daily Oracle dumps done nightly and the 11.1 systems uses robocopy for a daily backup vault copy.

T

TomU

23-Emerald IV

Right off the bat I would get an 'enterprise down' case open with PTC.

Second, are you sure it modified the database itself, or do you think it may have changed the codebase and/or Windchill DS? If it really was the database (and only the database), then the only good solution is probably going to be restoring the database from a previous backup. Anything created since that backup was taken will need to be removed from the file vault to prevent conflicts going forward. (Pretty easy to do by timestamp or use the 'remove unreferenced files' command on the vault.)

Preventing something like this is why I modify the hosts files on my Windchill test systems and block access to the production database server. Only the production Windchill system is allowed to talk to the production database server.

T

TomU

23-Emerald IV

I'm sure it wouldn't be supported by PTC, but you could restore the last backup of the database to a separate instance and then run a comparison tool on the two of them to see what changed. Maybe you can identify some key differences that can be manually undone. Obviously take a fresh backup of the current database before you attempt to change anything.

B

BenLoosli

Author

23-Emerald III

The current Oracle database is already corrupt and is useless.

avillanueva

23-Emerald I

@BenLoosli oof, I know that feeling of dread when I am in these situations. I would love to see a post mortem summary when you get this sorted out as to how this happened. I cannot assist with as this is where I call for help too. I suspect the the db.properties or perhaps the upgrade manager entries were pointing to the wrong DB host. Is that what happened? I hope you are doing well. BTW, how many Windchill instances do you have running?

B

BenLoosli

Author

23-Emerald III

Thinks are going well all things considered. I have 3 Windchill systems running different builds that we are trying to get to Windchill 12.0.2.x.

M

mmeadows-3

16-Pearl

The Upgrade Manager's DB history includes what was changed and on what dates back to the initial installation of Windchill. You can use it to track down the installed component numbers for all modules..

UpgradeManager -exportdbhistory dbHistory.xml

Note: We can also edit the file and re-load it. It may be easier than hacking database entries. However, I would make a backup of your currently broken database before doing this.

The following comes from my upgrade notes. It is not your current issue but the technique may prove useful.

Uninstall Modules During Rehosting

When we request the database history, the command exports an XML file with the full update/upgrade history of the system. This content is stored in database tables that start with ‘WtUpgInst_*’.

select owner, table_name from dba_tables where table_name like '%WTUPGINST_%';

We can query the database to get a list of all installed modules. (SQL Server)

select * from INFORMATION_SCHEMA.TABLES where TABLE_NAME LIKE '%VersionedAssembly%';

select * from WtUpgInst_VersionedAssembly;

And if we know the offending module(s), we can query for them directly.

select * from WtUpgInst_VersionedAssembly where releaseId like '%infomodeler%';

PTC does not recommend changing any of this information through database queries. Uninstallation of any module is not supported, so don’t bother logging a PTC Tech Supt call for this. However, sometimes there are installed modules that we don’t have or won’t seriously impact Windchill: PSM, PTC’s development environment, infomodeler, etc. When we encounter these modules, first check the knowledge base to see if there are explicit uninstall instructions for the module. Search for ‘uninstall’ and ‘module’ and the name of the module. Several modules have explicit instructions: MPMLink, SOLR, COGNOS, etc. If you can’t find instructions, follow these steps.

1. Ensure WindchillDS is running and run the UpgradeManager command from a Windchill shell:

UpgradeManager -exportdbhistory dbHistory.xml

This will export the DB history to the location where the command was executed (usually %wt_home%).

2. Copy the file to a new name.

copy /y %wt_home%\dbHistory.xml %wt_home%\dbHistory_mod.xml

3. Edit the file and delete all rows of the undesired entries.

%wt_home%\dbHistory_mod.xml

4. Import the modified history file.

UpgradeManager -importdbhistory dbHistory_mod.xml

5. Using a database query (as the database user), confirm module no longer exists.

select * from WtUpgInst_VersionedAssembly where releaseId like '%infomodeler%';

6. Start Apache and run the update_tool to clean up any issues.

bin\update_tool.bat -username wcadmin -password wcadmin -noui

windchill version

The installed version information should no longer include the offending module.

7. Now clean cache and restart Windchill.

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded