nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Contour Feature Class Gets Huge When Copied to SDE

MattDeitemeyer

I have a contour feature class that takes up 2 GB in a File GDB. When I move it to SDE the disk space quadrupled. This is a SQL Server instance of SDE. I've tried a number of different methods. I have the same problem regardless if I use ArcGIS 10.5.1 or PRO. I've tried SQL spatial and ESRI binary types for the destination feature class. To move the data I've tried; Load Features, Append, Copy Features, and an old fashion copy/paste. I keep getting the same result, a huge 'file' that takes forever to render. I can move the data between File GDBs with no problem. Any ideas?

Find more posts tagged with

Accepted answers

All comments

DanPatterson

Michelle Mathias‌ this needs to be moved.

JoshuaBixby

Sharing with Geodatabase‌.

Have you tried Rebuild a spatial index—ArcGIS Help | Documentation ?

George_Thompson

Is the issue the performance of the layer or the size on disc?

If it is the size, what is the concern on the size?

If it is performance, what are your concerns?

George_Thompson

Also take a look at this post: https://community.esri.com/message/859580-re-feature-classes-quadruples-in-size-when-imported-to-sde?commentID=859580#co…

MattDeitemeyer

Yeah, I read through this. I didn't see anything actionable.

MattDeitemeyer

I only care about performance. I only bring up disk space because the bloated size and poor performance appear correlated.

MattDeitemeyer

Regarding performance, it comes down simple things like draw time or just opening the attribute table. The FGDB version renders the entire feature class in a minute. The SDE version takes so long I have to kill the application. It's so unmanageable I can't test other performance metrics.

George_Thompson

Where is the fGDB located, on the network or local? If on the network, is it in the same location as the SQL Server machine?

What are the resources of the SQL Server machine when running the draw?

What is the version of SQL Server and machine specs?

Did rebuilding the spatial index make any difference?

I can say that if you are drawing all the contours at full scale, that is a ton of vertices to draw and request.

Based on your comment about timing out, I would look at the SQL machine to see what it is doing when you are trying to draw the contours. I do not think that it has anything to do with the "size on disc".

George_Thompson

Sorry have a few other thoughts:

Have you generalized the contours at all?

Are you using them for analysis or visualization?

MattDeitemeyer

I have a FGDB version on the network and locally, they both behave fine. The network version is not on the same server as SQL Server. I'll need to coordinate with our DB admin to watch the server while drawing the feature class. We are running SQL Server version 12. I should add, size on disk is a concern for the DB admin - it's a secondary issue for me. Rebuilding the spatial index didn't help. I have done a few things to the feature class to drive down size; tolerance and resolution were altered. I ran an identity (and a multi to single part operation) to tile out the features so the spatial index could perform better. The contours are for visualization. Simplify failed with an error of 'out of memory'. Generalize causes overlapping contours, the interval is 2ft and some of the contours are less then a foot apart.

MMBR

yes, it is expected and known the data will take more disk space when it is loaded into SDE. You can improve performance using SQL Server Page Compression, create the empty featureclass schema, enable page compression on the tables and indexes, then load the data using ArcCatalog Simple Data Loader, also you can have a custom SDE DBTUNE to separate tables and indexes into different filegroups, large featureclasses like "contours" can have its own SDE DBTUNE keyword with its own filegroups/datafiles that are completely separate from the rest of the data, you still need to tune and maybe rebuild the spatial index after you load the data to make sure you get the best drawing performance possible, another thing to consider is table partitioning and index partitioning, you can implement SQL Server partitioning to improve performance, also when loading data on large featureclasses if the datafiles are in autogrow then this will cause lots of fragmentation, then consider to run dbcc shrink database, or resize the datafiles before you load the data to avoid heavy fragmentation, now all these best practices will help you improve disk I/O, but still at the end of the day your database storage plays a crucial role in I/O, you might find that even after implementing the best practices that the storage does not scale up and you need to consider a faster storage for your database datafiles, this can be determined if you run SQL Profile traces when the data is drawing in ArcGIS to find the slow queries and by analyzing the SQL Query PLAN you can get more info about the storage performance. Also the version of SQL Server plays an important role in performance, if you are using SQL Express then you cannot expect it to scale up with very large featureclasses, and the advanced features like SQL Server Page Compression requires SQL Server Enterprise Edition. I hope this helps.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.