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.
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?
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.
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.
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.
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.
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.
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!