I have a polygon ArcSDE feature class (in sql server) that is drawing very slow.

[ShannonSmith]

It has about 78,000 records. We are using 10.3.1. This is the only feature class that is slow. Generalizing the data is not an option. And I have tried adding the data to its own basemap. Also when i export the data to a file geodatabase it is super fast. The database is compressed nightly.

[JoeBorgione]

Have you compressed your database lately?

[ShannonSmith]

Yes, the database gets compressed nightly.

[ChristianWells]

What state does the geodatabase get compressed to?

If the state is other than 0, are there a lot of records in the Adds/Deletes tables following the compress?

[ShannonSmith]

Right now it is at state 30. I can't get to state 0 right at the moment because of a couple of versions that cannot be deleted because of long term editing.  Any other suggestions?

[JoshuaBixby]

What do the add and delete tables look like?  If the users doing "long term editing" aren't reconciling regularly, the add and deletes can get bloated, and compressing the geodatabase won't be able to compress much.

To determine whether it is the workflows of these long term editors that are causing the issue, I suggest you work with them to reconcile and post so you can get a clean compress.  If doing so improves the performance, then you know you need to focus on workflow changes.

[MicahBabinski]

Hello Shannon,

Two thoughts come to mind:

1. Do the features contain many polygons that snake all over the place? Polygons with very complex edges (lots of vertices) that stretch over a large part of the feature class' extent will be very hard to index efficiently. If this is the case, it may be worth splitting up the features by some sort of regular boundary, like township. This may improve your drawing performance.
2. How many attributes does the feature class contain? If there is only one attribute that will be queried, convert the data to raster and it will draw super fast.

Otherwise, it may be worth researching the problem with the specific version of SQL Server added to your search terms. Or, if you have one, ask your SQL DBA if there is anything in the database that might be causing the problem.

Good luck!

Micah

[ModyBuchbinder]

The first (and easiest) test is to copy & paste the layer into temporary layer in the same geodatabase.

If it draws fast then delta tables/states are the problem. If it draw slow then the features are too complex.

In that case try to zoom to different areas. Usually there are just a few very complex polygons. If you can split them it can solve the problem.

Have fun

Mody 

[ThomasBuchmann1]

Are you using the GEOMETRY Spatial Type? Have you checked the Spatial Index? the BoundingBox has to fit the FeatureExtent of the Feature Class.

We also encountered problems with the Spatial Indexes. And with the newly AutoGrid-Index in 10.3 it got even worse.

We always change the Spatial Indexes away from the AutoGrid to a manual 4-Level Index (for our data the best setting is LLLL / 16).

Esri's idea to prevent us from the complexity of the Spatial Index is imho a very bad idea 😞

[Robert_LeClair]

In addition to Compress, I'd recommend the following data maintenance tools:

• Analyze
• Analyze Datasets (both as data owner and SDE (system tables)
• Calculate Default Spatial Grid Index

Good luck!