This content has been marked as final. Show 4 replies
Oracle Spatial uses RTree indexes - these don't require any tuning. In the past Quadtree indexes required a bit of tuning, but they've been deprecated in favour of RTree indexes.
There are a few parameters that are worth setting - check this link: http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_objindex.htm#i78196
"layer_gtype" should be set where possible - it ensures that only the specified geometry type can be added to the indexed column and it has performance benefits for point data.
The other index parameters start to become important once you move towards very large data sets.
That's a very open ended question. When posting questions on this forum you'll get better results if you have very specific questions. So do you have a specific spatial query which isn't performing well? If so then post as much information as you can about it.
- Exactly what version of Oracle database?
- What is the SQL query you're running - if possible include the explain plan
- What is your expected response time for the query?
- How much data is in the table and what kind of data is it
- Is possible provide some information about the use case behind the query you're running.
There are various techniques available to make spatial queries perform as you'd expect, but I'm not going to waste my time going through them here until you provide some useful information.
I'd recommend having a look at this presentation for some advice:
Also have a look at this:
Unless you do a lot of full-view reads of your data, or don't use 126.96.36.199 to 188.8.131.52 - you should apply the work-around highlighted in this thread. Otherwise, you will see very slow response to spatial queries.
Re: 10.2.0.4 to 184.108.40.206 upgrade = SLOW sdo_geometry return