[GIS] How to explain why a particular ArcSDE state does not compress

enterprise-geodatabaseesri-geodatabaseversioning

I am maintaining an ArcSDE database and would like to avoid killing connections to ArcSDE in order to run the compress operation. Our versioning workflow is very simple. Everyone edits the DEFAULT version directly. I know that it is not possible to compress to state 0 without reconciling and removing connections but we do not need to compress to state 0. All our applications are accessing SDE via ESRI software or an API which can access the DEFAULT version so our users/scripts should have access to all the data all the time.

Having said that I am constantly monitoring the states that remain uncompressed and sometimes I cannot explain why a specific state would not be merged with state 0. I know that if there is branching in the state tree due to current edit sessions, some of those states cannot be removed. Same is the case if you have named versions that have not been reconciled. Also if users have locks on particular states, those states will not be blown away. For this reason I kill processes that are older than 1 day.

But what if I have a linear state tree and a couple of states that do not have state locks on them do not get removed? Why might this be? What other factors influence which states get removed during a compress.

The ultimate goal here is to have no down time at all except for when performing schema changes.

Best Answer

In addition to the reasons you already account for, you can:

  1. Check the states table for unclosed (open) states.
  2. Check the versions table to see if perhaps a replica version or transactional version points to one of the blocking states (the states that will not compress).
  3. Identify the lineage the blocking state(s) participate in for further querying.
  4. Run the sdegdbrepair tool with the -o diagnose option for tables and metadata. Maybe you have a state-state_lineage relationship that needs to be repaired.
  5. Check all the locks tables, not just state_locks : object, table, layer as well.
  6. Make sure there are no active connections during the compress. You state you remove aged connections, but it only takes one active connection.
  7. Run the Compress operation twice.

Here's a tech article from Esri Australia that is fairly comprehensive without going into some of the ramifications of compressing with multiple replicas present:

Compressing the ArcSDE geodatabase http://esriaustraliatechblog.wordpress.com/2012/10/08/compressing-the-arcsde-geodatabase/

Related Question