1

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.

Improve this question

2 Answers 2

Reset to default
2

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/

Improve this answer
0
1

I know this is answered but I just ran up against the same thing and in searching found this esri KB article that outlines nearly the same procedure as above but also what to look for to compare if you have errant versions. The article is specifically looking for replications that were deleted but not properly dropped from the database. Which is exactly what happened to us.

http://support.esri.com/en/knowledgebase/techarticles/detail/40807

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.