Select to view content in your preferred language

Compress to state zero before enterprise geodatabase upgrade?

1052
3
Jump to solution
05-27-2022 07:12 AM
AndrewRudin1
Frequent Contributor

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

0 Kudos
1 Solution

Accepted Solutions
RyanUthoff
Frequent Contributor

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.

View solution in original post

3 Replies
RyanUthoff
Frequent Contributor

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
Esri Notable Contributor

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.

0 Kudos
AndrewRudin1
Frequent Contributor

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!