A few of our Geodatabases will not compress all the way to State 0. They are hanging up at end state 2. I am not sure the process of troubleshooting this problem. Everything is syncing nightly and our compress is running weekly. Everything is running fine but they will not compress to state 0. I am looking for ways of finding out what is holding them back from rolling all the way to state 0.
I stop all map and feature services , and kill all direct connections to these databases before I compress , rebuild , and analyze.
Any help would be greatly appreciated.
How many versions do you have? Do you delete the versions after you reconcile/post them to their parent?
Do you have any replicas in the geodatabase?
Here is a link that covers how to get a full compress on the geodatabase: http://resources.arcgis.com/en/help/main/10.2/index.html#//003n000000s5000000
Hopefully this will help with getting a "full" compress.
They are versioned but only with the default. They do have replications going and coming from them, and we are syncing the correct way by bringing all information in before we are sending any data out. Thanks for the article I will read through it!
I have had this same issue. My only solution was to reconcile and post all versions, delete the versions, then compress. Also, keep in mind that Geodatabase replicas count as versions...so they need to be removed as well. This proved to be such a pain that I created a model to 1. Reconcile/Post All Versions, Delete Versions, Compress, and Create versions again.
Here is some more info.
29160 - Compress a versioned database to state 0 - Dated, but still seems to hold turn
Hussein Nasser: The Unorthodox Way to Compress a Replication-Enabled Versioned GeoDatabase to State ... - For the daring.
Thanks for the quick response and for sharing the article I will read through it!
This is confusing to me. This is what the D-base is showing, Police_editor is showing state id 0, but the others do not match the default either. What would be the ramifications of changing these all to match the default version?
Ahhh, if you mean manually changing the state_id's using a SQL update...be prepared for potential data loss. I am not sure what kind of replica's these are...if they are one way, SDE.DEFAULT parent to File Geodatabase replicas..you might be okay, but my guess is that you might corrupt your replicas.
If it were me, I would take the safe approach and "unregister" the replica's using the ArcGIS desktop tools. Once you do that, query the versions table again..you want to get it so you only have DEFAULT. Once you are there, then compress (kick everyone out of database first)..and your state_id on default should be 0. Then register your replicas again.
Also, I personally have not tried the methods outlined in the article below, but it clearly states to implement these methods at your own risk. That's your call. Also, Esri support would most likely not recommend this approach, but if you are the type of person that voids warranties, backup everything up twice
Hussein Nasser: The Unorthodox Way to Compress a Replication-Enabled Versioned GeoDatabase to State ...