topic Re: importing shape file in SDE in Geodatabase Questions

importing shape file in SDE

DjalilDahhaoui — Sun, 01 Nov 2015 22:05:40 GMT

Hello,

I imported a shape file(polygon) 1.2 GB into SDE. what can be done to improve the performance of this feature class?

users are seeing a slow re-draw of this layer in Arcmap.

Thanks,

Djalil

Re: importing shape file in SDE

DanPatterson_Retired — Sun, 01 Nov 2015 22:08:53 GMT

for some operations... Add Spatial Index—Help | ArcGIS for Desktop

Re: importing shape file in SDE

DjalilDahhaoui — Sun, 01 Nov 2015 22:13:54 GMT

Hi,

is Spatial Index perform on a specific field?

Thanks,

Re: importing shape file in SDE

DanPatterson_Retired — Sun, 01 Nov 2015 22:15:15 GMT

Shape field

Re: importing shape file in SDE

DjalilDahhaoui — Sun, 01 Nov 2015 22:21:47 GMT

Thanks!

Re: importing shape file in SDE

DjalilDahhaoui — Sun, 01 Nov 2015 22:35:19 GMT

Would you recommend to perform spatial indexing before importing a shape file into sde?

Thanks,

Re: importing shape file in SDE

DanPatterson_Retired — Sun, 01 Nov 2015 22:38:22 GMT

can't hurt... why not run an experiment, try importing and using it without an index, remove it, create the index reimport and perform the same tasks again...any improvement? if not, nothing was damaged and nothing will deteriote performance wise with one

Re: importing shape file in SDE

VinceAngelo — Mon, 02 Nov 2015 03:09:32 GMT

Actually, you NEVER want to build a table indexes before initial load. This guarantees the worst possible load performance, and will fragment the spatial index (which will be sub-optimal, since the index parameters are best derived from the data to be indexed, after it has been loaded).

In reality, shapefiles will often out-perform an enterprise geodatabase table, especially in unbounded queries (draw all rows), just because the database overhead to support ACID can't compete.

Small subset draw performance for ALL data formats always benefits from reorganizing the features into spatial order, though it may be barely measurable with small tables, it's always present, and in large tables is always significant (and in very large tables can have several orders of magnitude of performance gain vice raindomly organized tables.

There are dozens of variables that go into draw performance, so a "What can be done?" question can only be answered, "Well, it really depends." To generate an answer, you'd need to provide:

The exact RDBMS
The exact version of ArcGIS (and if different, the version of the geodatabase)
The exact coordinate reference
The topology class (point/mpoint/line/poly)
The storage format
The number of features
The average number of vertices per feature
The average extent of each feature
An indication of the spatial fragmentation (how far apart the rowids are from each other for each index tile) -- whether the features are sorted on a spatial component like map grid designator or in feature creation order, or randomly over time.
What steps have been taken to optimize render performance

There are also render rule optimizations (Are the features being drawn by multiple queries?) and other issues that impact draw performance that have nothing to do with storage format.

It also helps to understand that features are NEVER "loaded into SDE". Features are always loaded into the database through ArcSDE components, as embedded in ArcGIS clients.

- V