Adding 1 edit to a feature class slows versioned layers to a crawl.

Question

I am experiencing very slow redraw times in ArcMap, when connected to a versioned layer AFTER adding and saving at least 1 edit.

I started by ensuring the database was cleaned up as follows (via nightly scripts);
- Reconcile/post all versions
- Compress the database (Cleaned out A & D tables)
- Remove all versions
- Validate entire ROADSNETWORK topology
- Rebuild editor versions
- Analyse  ROADSNETWORK featuredataset

Now I bring in a few layers and everything works snappy under all versions. I go into one of the layers and make a single edit under JIM version and save.  From this point on the map redraws at a crawl and will stay that way untill I run the above scripts again.  The slowness will only happen while I am referencing a layer under the JIM version.  The other versions (with no edits) and DEFAULT remain snappy.

So, with that said, there seems to be something going on when a layer is being accessed through a version with a state_id.  Anyone have any clues?

I am using ArcSDE 9.3.1 with Oracle 11g R1 on Windows Server 2008.

Jim Irwin

rest_export.jpg

soap_export.jpg

CornerLabel.png

Clip_1353.jpg

adobestock-181528131-25p.jpeg

RobertKrisher_0-1776811356351.png

GavinMcGhie · Answer

Thanks for the feedback. We actually only have 1 editor working part time, so I know there are rearely more than a few 100's of edits in any 2 week period and I compress every 2 weeks. The state_lineages table only has 158 rows/16 Kb, and I assume that is small. Regardless, for unknown reasons the edit_versions are now working at normal speed again today. Haven't even restarted the servers since the problem was diagnosed, so hoping it won't come up again... No way to further troubleshoot without it working either. Fingers crossed...
Thanks, Gavin

Anonymous User · Answer

Original User: crafty762I know this is an old thread now, but did you ever resolve this? I'm having almost the same issue with 10.2, but it just started after the last database compress. Issue logged with support, but I thought I'd see if it was ever resolved.
Thanks, Gavin

I experienced similar behavior as described here.  This can happen after a big compress (e.g., lots of records are moved from the delta tables to base once a number of versions are rec/posted and states are released).  Over time, if the number of states and lineages grows huge, the STATE_LINEAGES table's row count becomes extremely large.  I recommend that you check the physical size of your SDE.STATE_LINEAGES table within the database.  Does it take up a lot of blocks even with only a few rows after a compress?  It may be that the STATE_LINEAGES table has expanded to be quite large over time on disk and the time it takes to traverse it during a query may be costly.  Take your database as close to state 0 as possible, get everyone out the database, export the table data records using EXPDP, drop the table, extract its DDL, re-create the table (with indexes, PKs, etc.) using the SQL from the DDL extract, and then re-import its records from the export using IMPDP.  This should create the table only as big as it needs to be at that moment.  I had success resolving this issue in Oracle when seeing horrible performance.  Let me know if this addresses your performance issue.

GavinMcGhie · Answer

I know this is an old thread now, but did you ever resolve this? I'm having almost the same issue with 10.2, but it just started after the last database compress. Issue logged with support, but I thought I'd see if it was ever resolved.
Thanks, Gavin