Select to view content in your preferred language

How Many Database States is too many?

1223
4
08-25-2020 08:27 AM
by Anonymous User
Not applicable

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!

Tags (3)
4 Replies
JoeBorgione
MVP Emeritus

...There has only been one time the compress did not get to state 0...

I suspect there will be a number of EGDB admins that see this and go 'Wow; how cool is that?'  So let me be the first to say; wow, how cool is that?!  Some time ago I inherited an EGDB that had tens of thousands of states; it was crazy and we never got close to 0 states.

You might want to schedule a compress on Wednesday night and see what your count is and go from there, but it sounds like you are running a pretty tight ship!  

That should just about do it....
by Anonymous User
Not applicable

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

0 Kudos
George_Thompson
Esri Notable Contributor

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. 

--- George T.
by Anonymous User
Not applicable

Thanks for the responses! 

0 Kudos