Spatial Index Inefficient

[User35489]

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 11.2.0.2.0, ArcSDE 9.3 SP1
10.1 Environment: RHEL 6, Oracle 11.2.0.3.0, ArcSDE 10.1 SP1


Waiting eagerly for replies
Thanks
Abdullah

[VinceAngelo]

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
change.

- V

[BenArmstrong]

Is there a similar way to do this in SQL?

[VinceAngelo]

Sure, I guess.  Unless you're in a situation where it isn't possible.
Or wouldn't matter.

What is your situation?

- V

[MichaelSnook]

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

Thanks,
Mike

[VinceAngelo]

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