
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2022 06:34 AM
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
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-20-2022 07:47 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2022 06:40 AM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2022 09:56 AM
Never heard of a 36 hours upgrade. Ours is usually < 60 mins with < 100 skipped records. 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2022 11:53 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2022 12:50 PM