Spatial queries slow

Hi,
I'm working with a point table with approximately 6100 tuples (each has a point geometry)
When I run the query:
SELECT ID, shape FROM POINT_TAB WHERE SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 1000001, null, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY( 568220.418621453, 8628249.80447949, 575257.418621453, 8632873.80447949) ), 'querytype=window') = 'TRUE';
it takes about 12 seconds.
However when I run an equivalent query using the Spatial Index Advisor it takes about 1 second to draw the points on screen.
I've created an R-Tree index on this table.
Please any cues?
Thanks a lot,
Claudio.

Hi Daniel,
Here it is the info youÂ´ve requested:
USER_SDO_GEOM_METADATA
table_name: POINT_TAB
column_name: SHAPE
SDO_DIMINFO: SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -47302, 630691,6, ,5), SDO_DIM_ELEMENT('Y', 8013976, 9044443, ,5))
SRID: 1000001
Oracle Version: 9.2.0.1.0
INDEX creation:
CREATE INDEX Point_RTREE_IDX ON POINT_TAB(shape)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
The query returns 134 rows (out of 6151)
We are using a customized SRID:
WKTEXT: PROJCS["UTM Zone 24, Southern Hemisphere (Aratu)", GEOGCS [ "Aratu", DATUM ["Aratu", SPHEROID ["International 1924", 6378388.000000, 297.000000]], PRIMEM [ "Longitude of Origin", -39.000000 ], UNIT ["Decimal Degree", 0.00048481368110953599]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999600], PARAMETER ["Central_Meridian", -39.000000], PARAMETER ["False_Easting", 500000.000000], PARAMETER ["False_Northing", 10000000.000000], UNIT ["Meter", 1.000000000000]]
TRACE:
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=70 Card=405 Bytes=15 96915)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'POCOS_TAB' (Cost=70 Card=405 Bytes=1596915)
2 1 DOMAIN INDEX OF 'POCOS_RTREE_IDX'
Many thanks,
Claudio.

Similar Messages

Spatial Queries Not Always Producing Accurate Results

Hi,
Spatial queries are not always producing accurate results. Here are the issues. We would appreciate any clarification you could provide to resolve these issues.
1. When querying for points inside a polygon that is not an MBR (minimum bounded rectangle), some of the coordinates returned are not inside the polygon. It is as though the primary filter is working, but not the secondary filter when using sdo_relate. How can we validate that the spatial query using sdo_relate is using the secondary filter?
2. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT returns true when validating geometries even though we find results that are invalid.
3. Illegal geodetic coordinates can be inserted into a table: latitude > 90.0, latitude < -90.0, longitude > 180.0 or longitude < -180.0.
4. Querying for coordinates outside the MBR for the world where illegal coordinates existed did NOT return any rows, yet there were coordinates of long, lat: 181,91.
The following are examples and information relating to the above-referenced points.
select * from USER_SDO_GEOM_METADATA
TABLE_NAME      COLUMN_NAME      DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)      SRID
LASTKNOWNPOSITIONS      THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
POSITIONS     THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
Example 1: Query for coordinates inside NON-rectangular polygon includes points outside of polygon.
SELECT l.vesselid, l.latitude, l.longitude, TO_CHAR(l.observationtime,
'YYYY-MM-DD HH24:MI:SS') as obstime FROM lastknownpositions l where
SDO_RELATE(l.the_geom,SDO_GEOMETRY(2003, 8307, NULL,
SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-98.20268,18.05079,-57.30101,18.00705,-57.08229,
54.66061,-98.59638,32.87842,-98.20268,18.05079)),'mask=inside')='TRUE'
This query returns the following coordinates that are outside of the polygon:
vesselid : 1152 obstime : 2005-08-24 06:00:00 long : -82.1 lat : 45.3
vesselid : 3140 obstime : 2005-08-28 12:00:00 long : -80.6 lat : 44.6
vesselid : 1253 obstime : 2005-08-22 09:00:00 long : -80.0 lat : 45.3
Example 2a: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select areaid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from area where
areaid=24
ResultSet:
AREAID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO,
SDO_ORDINATES) SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
24 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(-98.20268, 18.05079, -57.30101, 18.00705, -57.08229, 54.66061, -98.59638, 32.87842, -98.20268, 18.05079)) TRUE
Example 2b: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select positionid, vesselid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from positions where vesselid=1152
ResultSet:
POSITIONID VESSELID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),
SDO_ELEM_INFO, SDO_ORDINATES) DO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
743811 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743812 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743813 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
743814 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
Example 3: Invalid Coordinate values found in POSITIONS table.
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.latitude < -180.0
2 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
714915 -210.85408 -79.74449 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.74449, -210.85408, NULL), NULL, NULL)
714938 -211.13632 -79.951256 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.951256, -211.13632, NULL), NULL, NULL)
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.longitude > 180.0
3 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
588434 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589493 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589494 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
Example 4: Failure to locate illegal coordinates by querying for disjoint coordinates outside of MBR for the world:
SELECT p.vesselid, p.latitude, p.longitude, p.the_geom,
TO_CHAR(p.observationtime, 'YYYY-MM-DD HH24:MI:SS') as obstime,
SDO_GEOM.RELATE(p.the_geom, 'determine',
SDO_GEOMETRY(2003, 8307, NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,
-180.0,90.0,-180.0,-90.0)), .005) relationship FROM positions p where
SDO_GEOM.RELATE(p.the_geom, 'disjoint', SDO_GEOMETRY(2003, 8307,
NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,-80.0,90.0,
-180.0,-90.0)),.005)='TRUE'
no rows selected
Carol Saah

Hi Carol,
1) I think the results are correct. Note in a geodetic coordinate system adjacent points in a linestring or polygon are connected via geodesics. You are probably applying planar thinking to an ellipsoidal problem! I don't have time to do the full analysis right now, but a first guess is that is what is happening.
2) The query window seems to be valid. I don't think this is a problem.
3) Oracle will let you insert most anything into a table. In the index, it probably wraps. If you validate, I think the validation routines will tell you is is illegal if you use the signature with diminfo, where the coordinate system bounds are included in the validation.
4) Your query window is not valid. Your data is not valid. As the previous reply stated, you need to have valid data. If you think in terms of a geodetic coordinate system, you will realize that -180.0,-90.0 and 180.0,-90.0 are really the same point. Also, Oracle has a rule that polygon geometries cannot be greater than half the surface of the Earth.
Hope this helps.

Spatial Queries are CPU bound and show very heavy use of query buffers

Hi,
Spatial Queries:
When using tkprof to analyse spatial queries it is clear that
there are implicit queries being done by Oracle spatial which
use vast amounts of buffers, and seem unable to cache basic
information from query to query - thus resulting in our machine
being CPU bound when stress testing Oracle Spatial, for example
the example below shows how information which is fixed for a
table and not likely to change very often is being retrieved
inefficiently (note the 26729 query buffers being used to do 6
executions of what should be immediately available!!!):
TKPROF: Release 8.1.7.0.0 - Production on Tue Oct 16 09:43:38
2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SELECT ATTR_NO, ATTR_NAME, ATTR_TYPE_NAME, ATTR_TYPE_OWNER
FROM
ALL_TYPE_ATTRS WHERE OWNER = :1 AND TYPE_NAME = :2 ORDER BY
ATTR_NO
call count cpu elapsed disk query rows
Parse 6 0.00 0.01 0 0 0
Execute 6 0.00 0.01 0 0 0
Fetch 6 0.23 0.41 0 26729 5
total 18 0.23 0.43 0 26729 5
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
0 SORT ORDER BY
0 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 TABLE ACCESS FULL ATTRIBUTE$
578 TABLE ACCESS CLUSTER TYPE$
578 TABLE ACCESS CLUSTER TYPE$
578 INDEX UNIQUE SCAN (object id 255)
578 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
578 TABLE ACCESS CLUSTER USER$
578 INDEX UNIQUE SCAN (object id 11)
289 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN (object id 11)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
and again:
SELECT diminfo, nvl(srid,0)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = 'NAGYE' AND TABLE_NAME =
NLS_UPPER('TILE_MED_LINES_MBR') AND '"'||COLUMN_NAME||'"'
= '"GEOM"'
call count cpu elapsed disk query
current rows
Parse 20 0.00 0.04 0
0 0 0
Execute 20 0.00 0.00 0
0 0 0
Fetch 20 0.50 0.50 0 5960
100 20
total 60 0.50 0.54 0 5960
100 20
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE) (recursive depth: 1)
Rows Row Source Operation
1 FILTER
2 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
2 INDEX RANGE SCAN (object id 24672)
1 UNION-ALL
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS FULL OBJ$
1 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN (object id 3)
0 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX UNIQUE SCAN (object id 33)
0 INDEX UNIQUE SCAN (object id 33)
0 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
1 TABLE ACCESS CLUSTER SEG$
1 INDEX UNIQUE SCAN (object id 9)
1 TABLE ACCESS CLUSTER TS$
1 INDEX UNIQUE SCAN (object id 7)
1 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 TABLE ACCESS FULL USER$
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX RANGE SCAN (object id 34)
0 INDEX UNIQUE SCAN (object id 97)
0 INDEX UNIQUE SCAN (object id 96)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
Note: The actual query being performed is:
select a.id, a.geom
from
tile_med_lines_mbr a where sdo_relate(a.geom,mdsys.sdo_geometry
(2003,NULL,
NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') =
'TRUE'
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.08 0.08 0 4 0 0
Fetch 5 1.62 21.70 0 56 0 827
total 7 1.70 21.78 0 60 0 827
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
827 TABLE ACCESS BY INDEX ROWID TILE_MED_LINES_MBR
828 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
827 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'TILE_MED_LINES_MBR'
828 DOMAIN INDEX OF 'TILE_MLINES_SPIND'
CPU: none, I/O: none
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 92
Execute 1 0.00 0.00 0 22
Fetch 1 0.00 0.00 38 236
total 3 0.00 0.00 38 350
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
12 TABLE ACCESS BY INDEX ROWID ROADELEMENT_MBR
178 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
12 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'ROADELEMENT_MBR'
178 DOMAIN INDEX OF 'RE_MBR_SPIND'
CPU: none, I/O: none
Can Oracle improve the performance of Oracle spatial by
improving the implementation so as to perform alternative
implicit queries so as not to use these vast amounts of memory?
Cheers
Alex Eadie

Hi Ravi,
Thankyou for your reply.
Here are some more details for you:
Yes the queries are cached in that it gets its data from RAM and
not from disk however the number of buffers used internally by
Oracle RDBMS/Spatial is rather large and results in significant
CPU usage (namely > 5000 per query or >40MByte). Which I'm sure
you'd agree? Those numerous internal queries taking >10ms CPU
time each, which is culmulative.
A single real of ours query of will take between 180ms and 580ms
depending on the number of results returned.
An example query is:
select a.id, a.geom
from tile_med_lines_mbr a where sdo_relate
(a.geom,mdsys.sdo_geometry
(2003,NULL, NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') = 'TRUE'
Our 500Mhz PC Server database can only execute 3 processes
running these queries simultaneously to go to 100% CPU loaded.
The disk is hardly utilized.
The data is the main roads in Sydney, Australia.
The tables, data and indexes were created as shown below:
1.     Create the Oracle tables:
create table tile_med_nodes_mbr (
     id     number not null,
     geom     mdsys.sdo_geometry not null,
     xl     number not null,
     yl     number not null,
     xh     number not null,
     yh     number not null);
create table tile_med_lines_mbr (
     id     number not null,
     fromid     number not null,
     toid     number not null,
     geom     mdsys.sdo_geometry not null,
     xl     number not null,
     yl     number not null,
     xh     number not null,
     yh     number not null);
2.     Use the sqlldr Oracle loader utility to load the data
into Oracle.
% sqlldr userid=csiro_scats/demo control=nodes.ctl
% sqlldr userid=csiro_scats/demo control=lines.ctl
3.     Determine the covering spatial extent for the tile
mosaic and use this to create the geometry metadata.
% sqlplus
SQLPLUS>     set numw 12
SQLPLUS>     select min(xl), min(yl), max(xh), max(yh)
     from (select xl, yl, xh, yh
          from tile_med_nodes_mbr union
          select xl, yl, xh, yh
          from tile_med_lines_mbr);
insert into USER_SDO_GEOM_METADATA
     (TABLE_NAME, COLUMN_NAME, DIMINFO)
     VALUES ('TILE_MED_NODES_MBR', 'GEOM',
     MDSYS.SDO_DIM_ARRAY
     (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
               151.21205421, 0.000000050),
     MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
               -33.86234146, 0.000000050)));
insert into USER_SDO_GEOM_METADATA
     (TABLE_NAME, COLUMN_NAME, DIMINFO)
     VALUES ('TILE_MED_LINES_MBR', 'GEOM',
     MDSYS.SDO_DIM_ARRAY
     (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
               151.21205421, 0.000000050),
     MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
               -33.86234146, 0.000000050)));
4.     Validate the data loaded:
create table result
(UNIQ_ID number, result varchar2(10));
execute sdo_geom.validate_layer
('TILE_MED_NODES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
truncate table result;
execute sdo_geom.validate_layer
('TILE_MED_LINES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
drop table result;
5.     Fix any problems reported in the result table.
6.     Create a spatial index, use the spatial index advisor to
determine the sdo_level.
create index tile_mlines_spind on
tile_med_lines_mbr (geom) indextype is
mdsys.spatial_index parameters
( 'sdo_level=7,initial=1M,next=1M,pctincrease=0');
7.     Analyse table:
analyze table TILE_MED_LINES_MBR compute statistics;
8.     Find the spatial index table name:
select sdo_index_table, sdo_column_name
from user_sdo_index_metadata
where sdo_index_name in
(select index_name
from user_indexes
where ityp_name = 'SPATIAL_INDEX'
and table_name = 'TILE_MED_LINES_MBR');
9.     Analyse spatial index table:
analyze table TILE_MLINES_SPIND_FL7$
compute statistics;
I hope this helps.
Cheers
Alex Eadie

Continual library cache misses in trace file for spatial queries

Hi all,
Could somebody explain to me how the SQL parse engine works for spatial queries.
My understanding is that Oracle creates a hash value for SQL that is parsed with no errors. This hash value is then stored in the library cache ready to be matched against other incoming SQL statements. This provides one of the main reasons for using parametising SQL in languages such as PL/SQL, .Net etc and improves performance on query intensive applications.
However i have noticed that for spatial, any queries except for refreshes of identical ones already sent, the SQL engines re parses the query. This can take upto 0.2 seconds which is causing a performance bottle neck.
When looking at the full trace file of a single spatial query using SDO_FILTER with a query window the amount of additional internal queries that are performed is quiet a lot. Are these additional queries included in the total parse time?
I am wondering why for spatial queries the only way to get a hit in the library cache was to refresh an exact same SQL that had been previously sent?
Thanks
Daniel

Those additional internal queries are not included in the parse time,
if they are used in the execution time.
Edited by: yhu on Mar 4, 2011 10:52 AM

Spatial queries using Discoverer 3i

We are looking for a web reporting tool for an Oracle 8i Spatial database. Spatial queries are very important to us. Would it make sense and would it be possible to use Oracle Discoverer 3i? This product does not seem to talk the language of a 'spatial user'.

Thanks Dan,
Presumably, it would currently be possible to use Discoverer on database views with fixed spatial where-clauses. Is that right? If so, would it currently also be possible to have a parameterised spatial where-clause, allowing a user for instance to define the spatial view for his particular region. Does Discoverer somehow allow for this?
null

Combining 2 spatial queries into 1

Hi there. I want to merge two different spatial queries both of which return a single aspect of what I need. The first query returns the distinct group feature ids of all those geometries falling within a specified tolerance of a particular point, i.e. each geometry belongs to one feature id type:
select distinct a2.cfcc from GEOMETRY_MAP.GEOM_POINT$_TABLE a1,
attribute_map.landmark_table a2 where SDO_WITHIN_DISTANCE
(location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-104.9,39.9,null),NULL, NULL)), 'DISTANCE = 10000')='TRUE'
and a1.land = a2.land order by cfcc;
The following results are returned (one for each feature id) e.g. D43 is the id for schools but many schools may have fallen within the specified distance:
CFCC
D43
D44
D61
D65
The second query returns the feature ids of geometries AND their distances from the specified point and looks as follows:
select distinct a2.cfcc, sdo_geom.sdo_distance(location, b.pgeom, 0.005) distance from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2, (select MDSYS.SDO_GEOMETRY(2001,8265,MDSYS.SDO_POINT_TYPE(-104.9,39.9,null), NULL, NULL) pgeom from dual)b where a1.land = a2.land and SDO_WITHIN_DISTANCE (location, b.pgeom, 'DISTANCE = 10000')='TRUE' order by cfcc, distance;
The results of this query are:
CFCC DISTANCE
D43 4025.459
D43 5585.05361
D43 5589.70435
D61 7770.4209
D65 6223.59763
D65 7929.03858
As you can see the second query returns not just the feature id but the associated distance of each individual feature of that type. What I would like to do is to merge the two result sets so that only the closest individual feature of a particular type and its distance from the input point is returned, i.e. I only need the closest school as oppose to all the closest schools. Any ideas? Thanks a lot, Joe

Hi Richard. Thnaks for your reply. I should have mentioned that more than one feature type is returned, i.e. not just schools, and so ROWNUM = 1 would not work in this scenario. Any other ideas. Cheers, Joe

Sample SQL code ( Oracle Spatial queries)

Hi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
Anju

Hi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
AnjuHow about the spatial users guide which is available on
http://technet.oracle.com/doc/inter.815/a67295/toc.htm
It also contains example statements.
There is also a
spatial_users_guide_817.pdf available
Gerjan

Memory Leak With Spatial queries

We are using 8.1.6 on NT (4.0) for spatial data queries. We are facing memory leak problems. At the starting our job will run very fast and after some time it will start slipping. I'm monitoring PGA size from v$sessionstat/v$sysstat and it is regularly increasing. Same is the case for memory on NT machine when I'm monitoring thru performance monitor. I have already applied the spatial patch available for 8.1.6 but no improvement.
Please let me know If there is any workaround. When I'm submitting my job in parts and shutdown the database in between then It is releasing all the memory and It is working fine. Without shutting the database it is not relasing the memory even though I stop my spatial data batch job.
null

Hi,
Thanks for your responses.
This is the query:
SELECT a.geo_id, mdsys.sdo_geom.sdo_length(
mdsys.sdo_cs.transform(
mdsys.sdo_geometry(2002, 8307, null,
mdsys.sdo_elem_info_array(1,2,1),
mdsys.sdo_ordinate_array(' | |
longi | |
', ' | |
lati | |
a.geo_geometry.sdo_point.x,
a.geo_geometry.sdo_point.y )),
mdsys.sdo_dim_array(mdsys.sdo_dim_element(' | |
'''' | |
'X' | |
'''' | |
',-180,180, .00000005),
mdsys.sdo_dim_element(' | |
'''' | |
'Y' | |
'''' | |
',-90,90, .00000005)), 41004),
.00000005) * 6.213712e-04 distance_in_miles
FROM ' | |
t_name | |
' a
WHERE mdsys.sdo_nn(a.geo_geometry,
mdsys.sdo_geometry(1, 8307,
mdsys.sdo_point_type(' | |
longi | |
', ' | |
lati | |
', null),
null, null),' | |
'''' | |
'SDO_NUM_RES=5' | |
'''' | |
') = ' | |
'''' | |
'TRUE' | |
'''' | |
AND a.geo_id ' | |
filter | |
ORDER BY 2;
Here we are passing the tname and filter dynamically based on certain conditions and the memory leak is almost 100K to 200K per query.
First I tried to closing the session only but that didn't work. Database shutdown is only able to release the memory. I'm monitoring v$sysstat/v$sesstat and size of oracle.exe in NT performance monitor. Please let me know If something else need to be monitor.
Thanks.
Sandeep
null

Queries slow after upgrade to 11g from 10g

Hi experts,
I've recently installed 11g and did a full import of my 10g db into it. We are currently testing our apps in 11g and we are finding that existing queries were running slower. For example, a complex query that used to run 4secs is now taking 60secs in 11g. We surely don't want to change existing queries because there's just too many of them.
I have run statistics:
EXEC dbms_stats.gather_system_stats();
EXEC dbms_stats.gather_database_stats(estimate_percent=> 100);
I'd appreciate your suggestions to resolve this issue.
THanks
Giovanni

gvy wrote:
Hi experts,
I've recently installed 11g and did a full import of my 10g db into it. That means you've physically re-arranged all your data, and recreated (most of, but not necessarily all of) your indexes. Such changes can have an unlucky side effect.
>
I have run statistics:
EXEC dbms_stats.gather_system_stats();
EXEC dbms_stats.gather_database_stats(estimate_percent=> 100);
How does this compare with the way you collected statistics in your 10g system. Changes in statistics collection method can have a very unlucky impact on performance. (You mention in a follow-up post that you don't have histograms in 10g; your call to gather database stats will collect histograms by default in 11g - to avoid them you need to use method_opt => 'for all columns size 1')
There may be some particularly unlucky queries where the optimizer choose to do a new 11g transform that just does suit your data. One testing strategy is to set optimizer_features_enabled back to 10g (mores specifically the 10.x.x.x form it was on your previous release) to see if this bypasses the problems. If it does then you could use the optimizer_features_enable hint temporarily in just those queries that were misbehaving.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)

Oracle Spatial very slow only in CF

I have a query that runs terribly slow when executed through
ColdFusion. When I comment out the Spatial portion of the query,
the query runs quickly. When I run this same query with the Spatial
portion included in a DB client such as SQLplus then it runs
quickly as expected. The oddest thing is that in the debugging the
query supposedly runs in 0 ms. Has anyone seen this before or have
any idea in what direction I should explore?

Hey Ken,
Thank you for giving me some direction. I have not used your
suggestions yet because I have to get with some of our other guys
to do it, but I thought I would note here another aspect of this
problem. It is not just the spatial Nearest Neighbor operator. It
is the combination of the Spatial Nearest Neighbor operator and an
'IN' statement. When I have the two together the mollasses start to
freeze but when I remove one or the other (SDO_NN or the 'IN'
statement), the query flies.
I will write again after I have followed your directions
below.
Again, thank you.

Geodetic spatial queries - sdo_relate

Hello,
The following script populates a spatial table with points on a query boundary and then queries that table using the query boundary. When using a srid of 8307 not all of the points are returned using sdo_relate. If the srid is NULL then all points 'on' the query boundary are returned.
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
Thanks in advance,
Rick
========= Script follows ============
geomdetic relate test case
This script demonstrates cases where sdo_relate, in a geodetic coordate system where
"A two point line on a given meridian, doesn't necessarily follow that meridian,
so any feature touching that meridian between those two points is not necessarily
touching that line""
The script generates an input query boundary using max and min values. It inserts
point features on the query boundary at input interval into a test table. '
A spatial query is executed against the test table using the query boundary.
DECLARE
TYPE ord_type IS TABLE OF NUMBER
INDEX BY BINARY_INTEGER;
x_tab ord_type;
y_tab ord_type;
maxlon NUMBER DEFAULT 65;
minlon NUMBER DEFAULT 64;
maxlat NUMBER DEFAULT 45 ;
minlat NUMBER DEFAULT 44;
INCREMENT NUMBER DEFAULT 0.001;
offset number default 0;
srid number default 8307;
curval NUMBER;
objectnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (objectnotexists, -942);
indexnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (indexnotexists, -1418);
PROCEDURE populate_array (
p_minval IN NUMBER,
p_maxval IN NUMBER,
p_increment IN NUMBER,
p_array IN OUT ord_type
IS
i BINARY_INTEGER DEFAULT 0;
BEGIN
curval := p_minval;
LOOP
p_array (i) := curval;
curval := curval + INCREMENT;
i := i + 1;
EXIT WHEN curval > p_maxval;
END LOOP;
END populate_array;
PROCEDURE insert_points_on_tangent (
p_tangent IN NUMBER,
p_ords IN ord_type,
orientation IN VARCHAR
IS
v_geom MDSYS.SDO_GEOMETRY;
i BINARY_INTEGER;
BEGIN
i := p_ords.FIRST; -- get subscript of first element
WHILE i IS NOT NULL
LOOP
IF orientation = 'Y'
THEN
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_tangent,
p_ords (i)
ELSE
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_ords (i),
p_tangent
END IF;
EXECUTE IMMEDIATE 'insert into sdo_relate_geom_test (geom, geom_type) values (:boundary, :geom_tag)'
USING v_geom, orientation || ' ' || i;
i := p_ords.NEXT (i); -- get subscript of next element
END LOOP;
END insert_points_on_tangent;
-- Create a table to hold the geometries.
PROCEDURE TEST
IS
v_geom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_viewportgeom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
0,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_expected NUMBER;
v_relate_results NUMBER;
v_filter_results NUMBER;
v_relate_results_arc NUMBER;
v_dimino MDSYS.SDO_DIM_ARRAY;
v_count_sql VARCHAR2 (1000)
DEFAULT 'select count(*) from sdo_relate_geom_test';
v_filter_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_filter '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
v_relate_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_relate '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
BEGIN
EXECUTE IMMEDIATE v_count_sql
INTO v_expected;
EXECUTE IMMEDIATE v_filter_sql
INTO v_filter_results
USING v_geom;
EXECUTE IMMEDIATE v_relate_sql
INTO v_relate_results
USING v_geom;
DBMS_OUTPUT.put_line ( ' boundary minLat '
|| minlat
|| ' minLon '
|| minlon
|| ' maxLat '
|| maxlat
|| ' maxLon '
|| maxlon
||' increment '
|| INCREMENT
DBMS_OUTPUT.put_line ( 'expected '
|| v_expected
|| ' relate returned '
|| v_relate_results
|| ', '
|| 'filter returned '
|| v_filter_results
|| '. '
DBMS_OUTPUT.put_line('');
END TEST;
BEGIN
BEGIN
EXECUTE IMMEDIATE 'drop table sdo_relate_geom_test';
EXCEPTION
WHEN objectnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create table sdo_relate_geom_test(geom mdsys.sdo_geometry, geom_type VARCHAR2(100))';
-- generate the points we want to test
populate_array (minlon, maxlon, INCREMENT, x_tab);
populate_array (minlat, maxlat, INCREMENT, y_tab);
-- insert the points on the query boundary
insert_points_on_tangent (minlon + offset, y_tab, 'Y');
insert_points_on_tangent (maxlon - offset, y_tab, 'Y');
insert_points_on_tangent (minlat + offset, x_tab, 'X');
insert_points_on_tangent (maxlat - offset, x_tab, 'X');
DELETE user_sdo_geom_metadata
WHERE table_name = 'SDO_RELATE_GEOM_TEST';
INSERT INTO user_sdo_geom_metadata
(table_name, column_name,
diminfo,
srid
VALUES ('SDO_RELATE_GEOM_TEST', 'GEOM',
MDSYS.sdo_dim_array (MDSYS.sdo_dim_element ('x',
-180,
180,
.00000005
MDSYS.sdo_dim_element ('y',
-90,
90,
.00000005
srid
BEGIN
EXECUTE IMMEDIATE 'drop index SDO_RELATE_GEOM_TEST_spa_idx';
EXCEPTION
WHEN indexnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create index SDO_RELATE_GEOM_TEST_spa_idx on SDO_RELATE_GEOM_TEST(geom) indextype is mdsys.spatial_index';
TEST;
END;
/

In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
In Oracle Spatial's support for geodetic coordinates, the line segments connecting consecutive vertices of a polygon or line string are geodesics - the shortest paths between the vertices on the earth spheroid. The shortest path between {30, 50} and {35, 50) does not coincide with the 50 latitude parallel, but goes to higher latitude. Only at the equator does the geodesic connecting points of constant latitude coincide with the latitude parallel.

Sql queries - slow database

hi all,
is there a general but specific way to generate a list of sql queries that are consuming most resources and resulting in slow database performance?
thanks.

There are very few ways in this world that are "general but specific".
You can use "general" tools like StatsPack and AWR.
You can write "general" queries on V$SQL, V$SQLAREA, V$SQLSTATS.
You can use "specific" methods like Tracing.
You can use "specific" methods like Client side (or Application Server side) Logs.

Multiple Queries Slower

I am having an issue where the performance slows down drastically if i have multiple queries ( Running around 4 queries ) running at the same time. The performance is good when i have only one query running.
When i run the queries individually one after an another it takes about 10 secs for each of them to return.
When i run the queries together then it take more than a couple of minutes for all of them to return.
Any tips suggestions for any changes in oracle parameters to improve performance, when multiple queries are running at the same time. Another thing, the CPU is not being used to its full capacity. The CPU is somewhere in the 10 to 20% usage.
Thanks,
Jay.

Jayachandra, I think there is a good chance you need to tune one or more of the queries in question as they are probably running poorly using more resources than necessary. Individually they seem OK because total time is short but when combined the poor resource utilization is showing up.
If running CBO
run an explain plan on each query.
update the statistics
re-run the explain plans and look for differences
If different retime the queries, you may already be done
If not different or you spot something that looks wrong such as a full table scan where you think an index should be used then follow standard tuning practice to see what you can get.
Then once you know the SQL are as good as they are going to get look at the buffer pool to make sure it is just not too small. Many DBA just immediately make the buffer pool bigger if query performance is not good enough, however, this is usually not the correct solution and I believe you should never over-allocate resources because you might need them somewhere else.
HTH -- Mark D Powell --

Example Oracle Spatial Queries for NAVTEQ Data

Hi,
I recently installed NAVTEQ RDF data into an Oracle database. I am new to Oracle Spatial and am looking for some example queries using the NAVTEQ data in the Oracle database.
For example, suppose I have a point (latitude,longitude). What are the queries for each of these:
1) find roads or faces within 5 miles of that point;
2) find roads or faces that cover that point
Thanks!
Bowden

Hi,
There are a lot of of ways to license the data (county, state, country), there are different flavors (mapping, geocoding, and routing), and there are different licensing options for the Oracle platform (user based and cpu/core based). I cannot think of a use case that would approach the cost below.
Feel free to drop me an email (daniel dot abugov at navteq dot com) and we can discuss.
Dan Abugov
NAVTEQ Enterprise Business Development and Consulting

Queries slow since truncate & imprort

Hello everyone,
We truncated a table then re-imported the data.
Now our queries in Forms 6 are VERY SLOW. All other forms are fine.
We haven't changed the form at all.
Our index's seem the same, but are they still working?
Is this because our data is now in a different spot in the datafiles?
Does anyone know what I can do to remedy this?
Thanks
Lesley.

We need explain plans !
The indexes may or may not be used; but we won't know unless the SQL is traced and we get explain plans.
We also need to know if statistics have been generated.
What does num_rows in user_Tables for the table say ?
is it correct ?
if not try exec dbms_stats.gather_table_stats(USER,'your table name',cascade=>true);
note the above will put heavy load on for a while.
what does user_indexes say for the table ?

Spatial queries slow

Similar Messages

Maybe you are looking for