OCI 7.3.x upgrade time abnormally long?

[gmilazzoitag]

Hi everybody,

past week I've upgraded a 7.1.x instance to 7.3.1 SP1 in less than one hour.

Today I don't understand if, on another customer, the time is taking is normal or not. Customer has a big installation but...

DB size (from a backup) is more or less 150 MB, there are also 90 files of performance archival, 400 MB each.

During installation from the msi (ran from a dos prompt as administrator) at the end of db backup a gz file more than 6 GB has been created in one hour and now the installer windows seems stuck "installing" with a very small blue bar slice on the left.
And anoter hour has passed!
OCI server is functional, has been restarted, a manual backup has been done...

What do you suggest? To scratch everything and restore the manual backed up db? 

What's about the 90 days of performance archive already recorded?

Thank you in advance,

[ostiguy · Accepted solution]

Ciao Giacomo,

My suspicion is that the 150MB backup does not include time series (historically performance) data. If your daily archive is 400MB, then I'd expect a full backup to be at least 400MB*7 = 2.8GB for time series data.

If you have archive data, you must be doing a 7.3.0 to 7.3.1 upgrade, as archive data didn't exist until 7.3.0.

General recommendations for understanding what OCI upgrades/restores are doing:

..\sanscreen\bin\log -> What files are being written to? When were they last being written to?

..\SANscreen\wildfly\standalone\log -> On 7.3.x , this is the folder where WIldFly logs to. If an OCI install has gotten far enough along, the "SANscreen Server" service is up and running, and logs get created and updated in this folder.

Upgrade.log is what you want to look at to see where the database/data restores are.

Task Manager - is anything driving substantial CPU? The MySQL portion of OCI restores/upgrades tends to peg one CPU core.

Resource Monitor -> Disk activity -> Where is disk IO occurring?

[gmilazzoitag]

Hi Matt, 
thank you very much for prompt answer.

Yet it's a 7.3.0 > 7.3.1 (and then SP1) upgrade.

Thank you for the suggestions that are always very useful but, in the mean time, installation process unlocked itself and we've also discovered the reasons of that very slow process.

VMware guys were performing a VM move without notice us!!! 😕

In the meantime we've also discovered that as you right suspect the normal backup (the weekky one or the manual one) does not include performance archive, too small indeed! 
So the common onplace upgrade that has created that 6 GB gz file instead includes them, and we expect to see them restored (restore is in progress, mysql is working and writing as expected).

Maybe can be useful another information we've discovered. Removal phase stopped two times because there was err.txt in \sanscreen\acq\log locked by two applications: dscli.exe and java32.exe both related to the IBM DSCLI tool installed on OCI server to acquire IBM storage data.
For an unattended installation maybe somebody would expect that installer kills autonomously the locking processes.

Thanks a lot!
Giacomo