Spatial Index Inefficient

Jump to solution
05-14-2013 11:07 PM
Occasional Contributor II
Dear Admins,

I imported a layer containing polygon features around 25000 records from Geodatabase (9.3) to Geodatabase(10.1), it created a layer, attribute index and spatial index as usual.
I found that the layer is much more faster in 9.3 than in 10.1, for sure it is not because of version change.
For tuning i tried Analyse, Rebuild Spatial Index too
I was wondering what measures could help me to improve layer process faster ?
How to create a spatial index in an efficient way ? Is it OK if we do not create a spatial index ?

9.3 Environment: RHEL 5, Oracle, ArcSDE 9.3 SP1
10.1 Environment: RHEL 6, Oracle, ArcSDE 10.1 SP1

Waiting eagerly for replies
0 Kudos
14 Replies
Esri Esteemed Contributor
I did an experiment at a user site that was having network issues a few years ago.
We tried splitting the table storage into independent disks, spatial defragmentation
changing the spatial index size (both smaller and larger), and coordinate reference
scale reduction.  I would have thought that they all would have significant benefit,
but the big winner was coordref change.  All of the changes had some give, though --
you might have been able to get away with a 10m or 5m XY scale (10x or 2x of the
1m precision), just as a 10-20% difference in single grid size produced no significant

- V
0 Kudos
New Contributor II
Is there a similar way to do this in SQL?
0 Kudos
Esri Esteemed Contributor
Sure, I guess.  Unless you're in a situation where it isn't possible.
Or wouldn't matter.

What is your situation?

- V
0 Kudos
Occasional Contributor III
Hi Vince,

We're experiencing terribly slow drawing performance with our parcel fabric and I'm wondering if this could be our issue.  Is it possible to 'downgrade' the default coordinate reference parameters as below?

You can gain some of that perfromance back by proactively managing your
coordinate reference parameters -- Instead of defaulting to the -400,-400,1billion
XY offsets and scale, try using -400,-400,1million.  Lopping off those extra digits
will cut the storage requirements (at the cost of going from sub-millimeter to
sub-decimeter precision).

- V

0 Kudos
Esri Esteemed Contributor
You didn't post it here, but elsewhere you indicated you were using SQL-Server GEOMERTY
storage, which would be completely oblivious to ArcSDE precision (only SDEBINARY, SDELOB
and ST_GEOMETRY storage size would be impacted the coordinate reference changes).

You probably want to contact Tech Support about your parcel fabric issue.

- V
0 Kudos