Has anyone else experienced long upgrade times when moving to San Diego?

gunnergraves
Giga Expert

My Team is working through the Upgrade process to San Diego.  The upgrade time in our sub-production instances has increased around 6 hours for Rome to 36 hours for San Diego.  We are worried that this will not be acceptable to our end users when we upgrade Production.  Curious if anyone else has experienced this and if they were able to find a work around to increase speed.  

Thanks,
Gunner

1 ACCEPTED SOLUTION

gunnergraves
Giga Expert

We have been working with support to identify the root cause of these scripts taking so long.  We have a high number of records in our sys_ui_message table caused by an apparent bug in the auto-translation functionality we use.  As the table is reparented, it is causing the long run time for the upgrade.  Support is helping us to clean up this table and we are hoping this will help with some other performance related ghosts we have been chasing.  

View solution in original post

7 REPLIES 7

Allen Andreas
Administrator
Administrator

Hi,

I haven't heard of a 36 hour upgrade before. How many skipped changes did you all have on this sub-production instance?

There isn't anything you can do on Production, right now, to speed that up as it depends on many factors, almost all are outside your control (and some that you do, you probably won't "test" on Prod beforehand).

I'd recommend reviewing your skipped changes, reviewing the upgrade start and end times to ensure they are as long as you mentioned, then submit a case via your customer support account to talk this through with SN and get their thoughts on what may have happened here.

It may be the backup that gets created before the upgrade that is extending things. So you'd want to review each component to see where the process is taking the longest. The larger your database is, the longer it takes to do the backup, etc. If you all don't archive things, have been a customer of SN for several years and never had a zBoot, etc. then all of these factors can extend the time.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

hanaphouse
Giga Guru

Never heard of a 36 hours upgrade. Ours is usually < 60 mins with < 100 skipped records. 🙂

Jeff Marino
Tera Contributor

I'd guess this has nothing to do with skipped updates since these are things that didn't update so there'd be minimal time spent skipping them.  Take a look at the Upgrade Monitor under Top 10 Schema Changes by Duration.  This is usually where we see the majority of our upgrade timing.  Task and CMDB schema changes are the longest for us.  We work with support to identify what the change is so we can preload it as we find it unacceptable as well to have 36+ hour upgrade duration.

Thanks Jeff.  These plugins look to be the issue.  This seems odd to me as we haven't experienced this on any of our previous upgrades and I believe these have all been there since before the last upgrade.  Have you upgraded to San Diego yet?  

find_real_file.png