How Many Database States is too many?

Question

Hi,

I currently run a weekly Compress and Rebuild Indices/Analyze every Friday at 11:30 PM. This works because it avoids conflicts with the maintenance IT does over the weekends.

My question is: should I compress daily? There has only been one time the compress did not get to state 0, and this was due to an orphaned lock. We have never had orphaned states (thankfully) and the highest state count I have seen in the compress log table was around 900 or so.

Since I haven't found good documentation on how many DB states is considered "too much" I am not sure if less than 1000 is fine for a weekly compress, or if I should be compressing daily.

Thank you!

Anonymous User · Answer

It's a relatively small shop, we only have a few analysts and a few field collection efforts going on. Thanks for your reply!

Anonymous User · Answer

Thanks for the responses!

George_Thompson · Answer

As Joe mentioned, getting to 0 states is best but not required.

As for your primary question, I do not think that there is a documented limit to the # of states. The biggest issue that I have seen when the states gets into really large #'s is related to performance. The number of queries being performed on the data is causing the RDBMS server to be slower than expected. Also remember that performance can be impacted in many different ways with versioned data (old indexes, statistics, lots of data in the delta tables, etc.) and is the biggest driver of good Enterprise Geodatabase maintenance.

When it comes to maintenance scheduling, I say start with every other week (depending on the amount of edits) and increase / decrease from there. Many people start with and stay on a weekly cadence.