Compress to state zero before enterprise geodatabase upgrade?

[AndrewRudin1]

Does anyone out there follow a practice of compressing your enterprise geodatabases to state zero before upgrades?  For example when upgrading your geodatabase version from 10.6.1 to 10.7.1, or upgrading the Oracle version from 12c to 19c.

We have done it in my organization on our Oracle geodatabases as far back as we can remember.  I think it was a requirement in really early versions of the geodatabase that supported versioning (8.3 or 9.0??) or maybe it was required to avoid a bug in early versions, but I can't find anything to back that up. Regardless, compressing to state zero prior to upgrade is not spelled out as a requirement in any of the documentation for recent versions.  

I'm wondering if we could start eliminating this step as it seems to just be a cautionary one to make the geodatabase a little simpler before the upgrade, so I'm just curious if others do upgrades with lots of transactional versions floating around without any issues.  

Thank you,

Andrew

[RyanUthoff · Accepted solution]

I've personally never compressed the EGDB before upgrading it. I'm not aware of any bugs or documentation that says you should, although I suppose it wouldn't hurt to do a full compress before the upgrade. I'm not sure if you could expect to see better performance during the upgrade process or not if you compress first.

[Robert_LeClair]

Andrew - in the "Upgrade a geodatabase in Oracle" Help Page, it has a workflow certainly to upgrade but I don't see anything stating compressing to a state of zero.  If you have gdb replication and/or archiving enabled, one would never get to a state of zero anyway.  It doesn't hurt anything to do a compress prior to upgrade so that you remove orphaned records and move all edits common to all versions to the BASE table.

[AndrewRudin1]

Thank you both for your responses.  I got confirmation from the product team that state zero is not required for the upgrade.  After speaking to our team about the history, seems like there were some problems in the early years of our geodatabases, circa 2007-2012.  Details are fuzzy, but at the time there were problems with the upgrade.  One of the things support recommended was "let's try upgrading with things unversioned", and so after that we started doing it as a practice to be conservative. We usually used the opportunity to do large schema revisions anyways so unversioning wasn't a bad thing anyways. 

Still good to know what's required and what's a nice to have.

Thanks again!