SDE gdb is producing state lineages despite all featueres are unreg. as versioned

PoulLaustsen · ‎03-06-2013

We have an Arcsde v10 / PostgresQL v8.4 geodatabase that has been performing badly the last few weeks when using long transaction for web editing. If we switch to short transactions (unregister as versioned) the system run with good performance. Anyway the system can serve upto ap. 20 concurrent webeditors without any hickups. Despite no featuredatasets is registrated as versioned the system is still producing state lineages. How come?

The database is compressed twice a day. Autovacuum is running as default. A year ago we experienced performance problems and we were recommended to run "full vacuum" with analyze. It was a very helpfull - the database performed well again. Therefore we have done this on a weekly basis ever since. We have notised that in the PostgresQL documentation it is stated that this method can degrade performance over time because indexes not are treated the right way.

The sdegdb has been part of 2 ways replica with another sdegdb for almost ½ a year. Data has been syncronised daily by an automated process (Python scripts). One month ago the replica was unregistrated in Replica Manager by a mistake without a final synchronising - replication was not needed anymore. Data is exported every day so no data was lost.

Though it is possible to make af full Compress to state 0 - the table sde_state_lineages is still rather large - about 8 GB after the sdedb has been vacuumed. It is not possible to shrink it below this limit. When no datasets is versioned anymore and no replica version exist can this be right then? Can there be hidden system tables containing trash data. If so will it be possible to clean system? If the systemtables is not the problem what could be the problem most likely? - any suggestions.

We have tried to export/import data in the the DB. No effect.

Features in the sde Gdb: ap. 800 000 polygons

WillAllender · ‎03-19-2013

Did you ever get any help on this?

We are having issues with our state_lineages table growing out of control and am trying to determine if others are having a similar problem, or if your issue is related. It's only the web edit side, not the desktop editing side.

80 million records in state_lineages, but our feature edit count is in the high 100's to low 1000's. 7-hour compress, then less than 100 new edits. Now we're back up to 4.3 millions records in state_lineages.

mehmetbursal_ · ‎01-08-2014

Did you ever get any help on this?

We are having issues with our state_lineages table growing out of control and am trying to determine if others are having a similar problem, or if your issue is related. It's only the web edit side, not the desktop editing side.

80 million records in state_lineages, but our feature edit count is in the high 100's to low 1000's. 7-hour compress, then less than 100 new edits. Now we're back up to 4.3 millions records in state_lineages.

Hi WillAllender,
we are having exactly the same issue as yours. We have a web application running on clustered ArcGIS server site and allthough total AGS REST api request count made by this appication is less than 10000, we have 25 million records in state_lineages. Did you ever get any solution on your issue?

MeghanBlair · ‎12-01-2023

Did you ever get a resolution to this?