database compress hangs

[MaryElliott]

For 2 days running, the daily versioned DB compress hangs.  Generally takes 3-5 minutes to complete.  Ideas on why this might be happening and how to fix / avoid?  TIA.

Mary

[JakeSkinner]

Hi Mary,

Do you have any locks on your geodatabase?  You may want to give this tool a try:

https://community.esri.com/docs/DOC-9914-compress-geodatabase-tool 

[MaryElliott]

No, no locks on the DB. I always check just before beginning the compress.

Is there a benefit to using a tool rather than simply R-clicking on the DB and selection ‘Compress’?

[JakeSkinner]

Yes, this tool will ensure there are no locks, no users connected, and no users can connect to the geodatabase when the compress is occurring.  It will also reconcile/post all versions to ensure that you are compressing to a state of 0.

[MaryElliott]

We regularly to what we term the full compress to state 0 several times a year.

None of this answers the question of what happened during these 2 compresses, and what can be done to avoid / fix it so it does not recur in future. Ideas?

[JakeSkinner]

It's tough to say why the tool is not compressing.  When did you perform the compress, during business hours? I would not recommend this unless you are making sure there are no services accessing any feature class within the geodatabase, and you have taken the steps to prevent users from connecting to the geodatabase.  Users connecting to the geodatabase during a compress should not prevent the compress from completing, but it will not compress any feature classes that the user has a lock on.

If you don't already, I would create a workflow for your compress (i.e. schedule a time no users are accessing the database, synchronize any replicas, reconcile/post versions, stop all ArcGIS Server services accessing data within the geodatabas,e prevent users from connecting, rebuild indexes and stats after compress, start up services, allow connections).  The tool I provided does most of this workflow for you.  I would not recommend just right-clicking on the geodatabase > Compress at any given time.

[MaryElliott]

My schedule includes this “before work” time, so I can get this done prior to anyone needing to connect, or even being in the office. And, as always, I check for locks. Anyone who might have left a connection has their connection disconnected. Then I recheck for locks to ensure they are “gone”.

The staff knows to not connect to any database until I give them the OK, simply because sometimes things take longer than expected. Once a week I also run the repair indices, which takes additional time.

After these hung sessions, I rechecked for connections, but there were none. We’ve been doing this since 2007, so we are all quite aware of the process.

Tomorrow I will use the tool you suggested. Do you know if it takes an appreciably longer time to complete than the R-click on Admin method?

[JakeSkinner]

The execution of the tool will take a little longer than a regular compress as it will stop/start services, as well as perform a reconcile/post of all the versions.  One thing to check is the sde.sde_process_information (for SQL Server) or sde.prcoess_information (for Oracle) tables once all users are disconnected and services stopped.  If there are any entries within this table, you have an orphaned connection.

[MaryElliott]

I see there are no options to running this too, Jake. We already reconcile & post (R&P) all the versions before the compress, so that is redundant. There are no services connected to this DB, so that’s unnecessary, too.

But if it is safer, more complete, more certain, whatever the term might be that applies, I’ll give it a whirl in the morning. Will let you know how it goes.

Thanks for suggesting the tool, rather than the shortcut, method. Fingers crossed!

Mary

[MeghanBlair]

How was this resolved? I had to stop compression after taking 10 hours.