Slow editing in 10.1

11552
40
06-22-2012 06:47 AM
RobbHodges
Occasional Contributor II
I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb
Tags (2)
0 Kudos
40 Replies
DawnSowinski
New Contributor
Ever since we've gone to 10.1 with the direct connect we've had nothing but problems. We've had multiple duplicate key errors and countless snapping issues. The snapping will just at times quit working all together, but strangest we've encountered is snapping issues with a large lake layer. It's located on the SDE and anytime a person goes to edit it the snapping gets killed until a compression is done. I would get it if we did a lot of edits, but all it takes is moving one point in this file and snapping dies for every other layer until a compression is done. We have very few people that look at the layers on the SDE and only two edit on it but we need it to work. Before we upgraded from 10 to 10.1 it worked fine. We have moved several points but haven't really added many so the file size hasn't changed much from then to now.


This sounds like the problem I've been experiencing.  The data is in feature classes on an Oracle based server in 10.1.1.... Snapping quits until a compression and we can't afford to stop editing to compress multiple times a day...

Yes, it's a bulky file with lots of parcels, but there is no network or massive analysis/queries being performed (or attempted), just simple editing.  Trying everything I can find in these documents but nothing seems to work.  Has anyone had any success in overcoming these issues?

Has anyone tried recreating the entire geodatabase since the upgrade?  Any other suggestions?
TONIFAIRBANKS
New Contributor III

We have a 32 core SQL Server with a MAXDOP setting of 6, which was set after we upgraded from SDE 10.0 to 10.2.1 and migrated our data from SDE_Binary to SDE_Geometry.  We have started rebuilding our spatial indexes on our large feature classes, but are still experiencing SEVERE slowness while editing, especially when snapping.  It seems to be worse while multiple users are connected and actively editing.  The slowness is intermittent throughout the day, and slowness can be experienced by one user and not another during the same time period. If we export our data to a file geodatabase we do not experience slowness while snapping and panning.

Has anyone else solved the slowness problem or received a good answer from ESRI?

0 Kudos
JonathanMori1
New Contributor III

Hi, I know this is a little old, but I was having some of the same issues as you were. I was wondering why you decided to migrate from SDEBinary to SDEGeometry. I did the opposite and migrated to SDEBinary and noticed significant performance improvement.

0 Kudos
TONIFAIRBANKS
New Contributor III

We migrated to SDEGeometry because it is ESRI's standard and we were informed that SDEBinary was going away.  We continue to have performance problems and are working with ESRI to try and resolve the problems, but we still don't have a clear path forward.  We are running 10.2.1 currently.

0 Kudos
JonathanMori1
New Contributor III

Hmm, that's not good. Did they mention that SDEBinary was going away in 10.3? We are using 10.2.2. SDEBinary seemed to be our best solution to the performance problems we were having. It may be a while until I update to 10.3 if this is the case.

0 Kudos
TONIFAIRBANKS
New Contributor III

We had a ESRI tech here several months ago.  He mentioned that at 10.1 SDEGeometry was the default.  He didn't give us an exact "when date" as much as he said SDEBinary wasn't the future.  SDEBinary is still available at 10.3.  He also said we should expect a "big" increase in performance when we migrated to SDEGeometry, but that hasn't proven to be true for us.

At this point, the biggest issues we are working on related to performance are: 1) maintaining our spatial indexes and 2) large SQL spatial views (200,000 + records) created from command line tools.

ESRI's rebuild indexes tools don't appear to work on SDEGeometry spatial indexes so we have to manually rebuild them every couple weeks to maintain performance on large feature class that are regularly edited.

With large SQL spatial views, we see VERY poor performance when trying to snap against them while editing.  As a result, we are scripting all of our large spatial views to output as separate feature classes.  We don't have a solution yet for creating the spatial views after command line tools go away.

When we were using SDEBinary, we saw better overall performance and we didn't have to implement any of these work-a-rounds.

0 Kudos
JessicaGooch1
Occasional Contributor

I am having a similar experience. I was having issues editing (poor performance, slow, unable to snap, spinny wheel etc). I just got off the phone with ESRI tech support who identified that the 3 feature classes I was trying to edit were all SDE Geometry and that I should copy them and change the Config Keyword to SDEBINARY.  He mentioned that he had three other tickets just this week having the same poor editing performance issues. 

0 Kudos
TONIFAIRBANKS
New Contributor III

Have you tried using ArcCatalog to delete and recreate your spatial index? We have to do this regularly on feature classes we edit.

0 Kudos
JessicaGooch1
Occasional Contributor

No, I have not.  I will have the SDE Admin try that though! Thanks!

0 Kudos
Aaron_Kreag
New Contributor II

Just to wake up this thread...we are using 10.2.2, SQL2012 SP2 and SDE with DBO schema and direct connect.  We have been fighting this issue for almost one year with no  resolution.  The SDE Geometry type seems to be a culprit and yes we heard SDEbinary was going away at 10.4.  It seems worse when the data is within a feature data set.  We are still testing different variations.  I have recently set up a test environment with 10.3.1 and SQL2014.  If anyone has more info, please drop a note.  Thanks!

0 Kudos