Mdsys.sdo_relate slow, waiting on ALL_SDO_GEOM_METADATA
Database Oracle 8.1.7 Server Windows NT
Hello,
I have a query that uses sdo_relate which I have tested on two different oracle instances. On both instances I am testing the query on the same data. On one instance the query takes less that 10 seconds while on the second instance the query takes longer than then minutes.
Tracing the query on the second, slow instance shows many wait events while the server is executing the following query
PARSING IN CURSOR #3 len=126 dep=1 uid=346 oct=3 lid=346 tim=69164025 hv=1087985607 ad='48217d4'
SELECT DIMINFO FROM ALL_SDO_GEOM_METADATA WHERE OWNER = 'TESTUSER' AND TABLE_NAME = 'SPATIALTABLE' AND COLUMN_NAME = 'GEOM'
END OF STMT
PARSE #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164025
BINDS #3:
EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164029
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=319 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=325 p3=2
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=1515 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=1518 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=1528 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7295 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7298 p3=6
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12051 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12055 p3=8
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12063 p3=3
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=12651 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12654 p3=1
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12656 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12663 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13307 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13311 p3=8
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13319 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13766 p3=8
WAIT #3: nam='db file sequential read' ela= 4 p1=1 p2=13774 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13776 p3=3
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14163 p3=7
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14171 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14173 p3=4
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14178 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14643 p3=8
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14651 p3=1
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=14653 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=15065 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16323 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16326 p3=3
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16334 p3=3
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16338 p3=1
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=18275 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=18277 p3=3
Is there some configuration change and tuning that I can do that will optimize this internal mdsys query?
It may be significant to note that the instance that the query is fast on is a 8.1.7.4 database, while the other is a 8.1.7.0. As well on the slow instance there are many more spatial indexes and many more entries in the table ALL_SDO_GEOM_METADATA.
Any suggestions?
Thanks in advance,
Rick
Hi Rick,
I looked to see if there were any bug fixes between 8.1.7 and 8.1.7.4 regarding metadata fetching, and I didn't see anything that jumped out at me. That's not to say there weren't, however - I know there have been several metadata improvements that have been done over time.
Can you upgrade your 8.1.7 version to 8.1.7.4?
Thanks,
Dan
Similar Messages
-
Error using mdsys.sdo_relate()
Hi, I am using Oracle 8.1.5 and i am trying to execute the following sql statement
SQL> select p.name
2 from parks p
3 where mdsys.sdo_relate(p.shape,
mdsys.sdo_geometry(
3,null,null,
mdsys.sdo_elem_info_array(1,3,3),
4 mdsys.sdo_ordinate_array(10,10,20,20)),
5 'mask=anyinteract querytype=window')
= 'true';
But i recieved the following error message
ERROR at line 1:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 73
ORA-06512: at line 1
Do anyone know how to recify this?
Thanks!
nullOps, sorry it's TRUE not true
I managed to solved it. Thanks:>
brian
null -
Can mdsys.sdo_relate return FALSE?
I have the following query:
SELECT MIN (dtczas) dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48'
AND mdsys.sdo_relate(
geom,
MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
3735261.90177227, 5568277.30732063 )
'mask=ANYINTERACT querytype=WINDOW') = 'FALSE'
while executing this query I receive:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 84
ORA-06512: at line 1
so, is it possible to use sdo_relate in such way? When I try "<> 'TRUE'" or "AND NOT .... = 'TRUE'" index is not used.
Thanks in advance for help.
regards
KrzysztofIt is not possible. You must use ='TRUE'.
The reason for this is related to how the operators work.
First they do an index lookup to return the data that is
likely to interact, then they do further filtering to find the
data that actually interacts. All operators use the index
in this way.
If ='FALSE' was allowed, you'd get an answer that includes
only the geometries that were likely to interact (returned from
the index query), but that didn't interact, i.e. wrong answer.
You might be able to do something like this:
select min (dtczas) from
SELECT dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48
MINUS
SELECT dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48'
AND mdsys.sdo_relate(
geom,
MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
3735261.90177227, 5568277.30732063 ) ),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE');
Hope this helps,
Dan -
Mdsys.sdo_relate Problem
Hi!
I'va got two Tables, one of them ("kante") has a Geometry - Column in it and a Quad - Tree Index is
Created, the other one ("kabelabschnitt") is linked to "kante" via a foreign key.
This Query is very fast:
SELECT k.* FROM kante k
where sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
But this takes about 20 s:
SELECT k.*, ka.* FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
Can anynone tell me why??
Thanx in advance,
JHi,
It could be slower because the optimizer is choosing to use an index associated
with the join key between the tables instead of the spatial index.
Try adding the /*+ no_index (, index_name) */ hint, i.e.
SELECT /*+ no_index (K name_of_id_kante_index) k.*, ka.*
FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)),
'mask=ANYINTERACT querytype=window') = 'TRUE';
Hope this helps,
Dan -
SDO_FILTER and SDO_RELATE combined in the same query
Is it possible to combine these two operations?
I have a query that ideally should use SDO_RELATE for polygon data (some 25 million records). However it takes too long to run.
For curiosity's sake I tried using SDO_FILTER and again this takes hours. Again for curiosity's sake I combined the two and records are returned in about 2 mins. Please see the query below (to simplify matters I have used point data).
SELECT
FROM
table t
WHERE
MDSYS.SDO_RELATE(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
AND MDSYS.SDO_FILTER(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
As I see it, in this case SDO_FILTER is doing the primary filtering part. SDO_RELATE is doing primary filtering again followed by secondary filtering the resulting data which is why it is quicker. The data does appear to be correct.
Now am I barking up the wrong tree? Whether I am or not, why is this combination faster than individual use? I would appreciate any thoughts on this please.
Cheers guys
Jamessomething else is going on, although without seeing the real query it is hard to know.
SDO_RELATE is a supoerset of SDO_FILTER. With SDO_FILTER and index query is done, with SDO_RELATE an index query is done, then the relate is done on the geometries returned by the filter query.
What kind of index are you using?
What version of spatial are you using?
Can you post the query window?
Are your geometries valid? -
ORA-00932 Error using 11g and the SDO_RELATE function. Works fine in 10g
Hello,
If I run this query in Oracle 11g:
SELECT M.FID, MAX(M.VERSION) AS VERSION
FROM SW_PB.A_ROADNODEINFORMATION M, SW_PB.ROADNODE N
WHERE M.REFERENCETOROADNODE = N.FID
AND M.NODEVERSION = N.VERSION
AND M.CATALOGUEID <= 477
AND MDSYS.SDO_RELATE( N.GEOM, MDSYS.SDO_GEOMETRY(2003,81989,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(120000,0,160000,40000)),'MASK=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE'
GROUP BY M.FID;
I get an error regarding the N.GEOM field. The error is as follows:
ORA-00932: inconsistent datatypes: expected - got MDSYS.SDO_ELEM_INFO_ARRAY
The same query runs fine on a 10g database with the same data. I've even truncated the N table and still get the error. I've rebuilt the index but it makes no difference and the metadata is exactly the same for this table as it is for other tables that are involved in a similar query.
It looks like a bug to me but just wondered if anyone else had come across this?
Thanks,
Peter.Thanks for the reply. I'm really sorry but I haven't created trace files like this for a very long time and have forgotten the best way to read them. This is the start of the trace file, any help with reformatting it would be greatly appreciated.
Thanks,
Peter.
*** 2009-04-23 17:09:22.902
----- Error Stack Dump -----
*** 2009-04-23 17:09:22.917
ORA-00932: inconsistent datatypes: expected - got MDSYS.SDO_ELEM_INFO_ARRAY
----- Current SQL Statement for this session (sql_id=br02jqdwy2utk) -----
SELECT M.FID, MAX(M.VERSION) AS VERSION
FROM SW_PB.A_ROADNODEINFORMATION M, SW_PB.ROADNODE N
WHERE M.REFERENCETOROADNODE = N.FID
AND M.NODEVERSION = N.VERSION
AND M.CATALOGUEID <= 477
AND MDSYS.SDO_RELATE( N.GEOM, MDSYS.SDO_GEOMETRY(2003,81989,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(120000,0,160000,40000)),'MASK=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE'
GROUP BY M.FID
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
skdstdst()+114 CALLrel kgdsdst()+0 FB783A0 2
ksedst1()+91 CALLrel skdstdst()+0
ksedst()+50 CALLrel ksedst1()+0 0 1
dbkedDefDump()+298 CALLrel ksedst()+0 0
5
ksedmp()+40 CALLrel dbkedDefDump()+0 3 0
_dbkdaKsdActDriver( CALLreg 00000000 3
)+841
_dbgdaExecuteAction CALLreg 00000000 7B50420 FB79A4C
()+63
dbgdaRunAction()+3 CALLrel dbgdaExecuteAction 7B50420 4D4C148 20C0002
02 ()+0 FB79A4C
dbgdRunActions()+4 CALLrel dbgdaRunAction()+0 7B50420 A789E54
4
dbgdProcessEventAc CALLrel dbgdRunActions()+0 7B50420 A789E74
tions()+446
__VInfreq__dbgdChkE CALLrel _dbgdProcessEventAc 7B50420 120A3370 A789F64
ventKgErr()+237 tions()+0
dbkdChkEventRdbmsE CALLrel dbgdChkEventKgErr( 7B50420 A7C06F4 3A4
rr()+33 )+0
__PGOSF99__ksfpec() CALLrel _dbkdChkEventRdbmsE 3A4
+110 rr()+0
_dbgePostErrorKGE() CALLreg 00000000 120A3370 3A4
+1601
dbkePostKGEkgsf() CALLrel _dbgePostErrorKGE() 120A3370 A772020 3A4
+49 +0
_kgeade()+268 CALLreg 00000000 120A3370 A772020 3A4
kgesev()+54 CALLrel kgeade()+0
kgesec2()+18 CALLrel kgesev()+0 120A3370 A772020 3A4 2
FB7A200
qctErr932()+217 CALLrel kgesec2()+0 120A3370 A772020 3A4 1 1
FB7A468 1 19 FB7A218
qctErrConvertDataT CALLrel qctErr932()+0 995FBCC0 120A3370 F6 FB7A468
ype()+82 7B C2E85B4 995FBCC0 120A3370
FB7A468 0 0 FB7A468 0 204
qecgby()+240 CALLrel qctErrConvertDataT 995FBCC0 120A3370 F6 0 0 7B
ype()+0 C2E85B4
qecpqbcheck()+75 CALLrel qecgby()+0
qecdrv()+161 CALLrel qecpqbcheck()+0 C2ECD7C 0 0 0
qecdrv()+74 CALLrel qecdrv()+0
kkqcttcalo()+383 CALLrel qecdrv()+0 C2EFBAC
kkqctdrvGBP()+1841 CALLrel kkqcttcalo()+0 C2EFBAC 0 C2EFBAC 166A5D4 0 2
__VInfreq__kkqgbpTr CALLrel _kkqctdrvGBP()+0 A730DD8
avChkTran()+193
_qksqbApplyToQbcLoc CALLreg 00000000 A730DD8 FB7A9BC
()+536
qksqbApplyToQbc()+ CALLrel qksqbApplyToQbcLoc
67 ()+0
kkqctdrvTD()+1000 CALLrel qksqbApplyToQbc()+ A730DD8 2EF2DA0 FB7A9BC 0
0
kkqgbpdrv()+88 CALLrel kkqctdrvTD()+0 A754820 995FBDF4 6
kkqdrv()+1520 CALLrel kkqgbpdrv()+0 A754820 995FBDF4
kkqctdrvIT()+698 CALLrel kkqdrv()+0 A754820 0
apadrv()+1205 CALLrel kkqctdrvIT()+0 A754820 995FBDF4
opitca()+1841 CALLrel apadrv()+0 995FBDF4
__PGOSF435__kksFull CALLrel _opitca()+0 A7CC9E4 995FBDF4
TypeCheck()+15
_rpiswu2()+560 CALLreg 00000000 FB7B718
kksLoadChild()+860 CALLrel rpiswu2()+0 AF495220 5 A77DCBB4 16
8 94591E54 5 A77DCBE0 0 FB7B670
615F44 0 FB7B718 0
kxsGetRuntimeLock( CALLrel kksLoadChild()+0 120A3370 AE9130D8 FB7C090
)+1421
kksfbc()+8954 CALLrel kxsGetRuntimeLock( 120A3370 A7CC9E4 FB7C090 3 1
)+0
kkspsc0()+1882 CALLrel kksfbc()+0 A7CC9E4 3 108 FB7D2D8 1BB 0 0
0
kksParseCursor()+1 CALLrel kkspsc0()+0
43
opiosq0()+2028 CALLrel kksParseCursor()+0 FB7C610
kpooprx()+273 CALLrel opiosq0()+0 3 E FB7C734 A4
kpoal8()+729 CALLrel kpooprx()+0 FB7F214 FB7D2D8 1BA 1 0 A4
_opiodr()+1224 CALLreg 00000000 5E 1C FB7F210
_ttcpip()+2733 CALLreg 00000000 5E 1C FB7F210 0
_opitsk()+1278 CALL??? 00000000
opiino()+1067 CALLrel opitsk()+0 0 0
_opiodr()+1224 CALLreg 00000000 3C 4 FB7FC28
opidrv()+807 CALLrel opiodr()+0 3C 4 FB7FC28 0
sou2o()+45 CALLrel opidrv()+0 3C 4 FB7FC28
opimaireal()+130 CALLrel _sou2o()+0 FB7FC1C 3C 4 FB7FC28
opimai()+92 CALLrel opimai_real()+0 2 FB7FC54
OracleThreadStart@ CALLrel opimai()+0
4()+764
77E6482C CALLreg 00000000
00000000 CALL??? 00000000 -
I am hoping someone can help. I am writing alot of spatial queries but I am having a hard time figuring out what is wrong with this one and maybe someone can give me some advise. Here is my query
select count(inc) from public_crimeshapes.aggassault2004 h, spatial.tracts2000 t
where mdsys.sdo_relate(h.geom, t.geom,'mask = anyinteract querytype=window') = 'TRUE'
and tract2000 = 012300 and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') >= '01/01/2004') and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') <= '12/31/2004')
This one runs fast in less than 3 secs but if I added multiple tract2000 numbers like this
select count(inc) from public_crimeshapes.aggassault2004 h, spatial.tracts2000 t
where mdsys.sdo_relate(h.geom, t.geom,'mask = anyinteract querytype=window') = 'TRUE'
and tract2000 in (012300,012400,012500,014300,014400,016600,016700,016800,016900,017000,017100,017200,017300,017400) and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') >= '01/01/2004') and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') <= '12/31/2004')
it will take like 5 mins to run. Is there another way to run a spaital query on multiplue polygons? Tracts2000 is a polygon and aggassault2004 is a point file. Thanks for the help I am running Oracle Spatial 9i.
MattHi,
Can you try the following:
select /*+ ordered */ count(inc)
from spatial.tracts2000 t, public_crimeshapes.aggassault2004 h
where mdsys.sdo_relate(h.geom, t.geom,'mask = anyinteract querytype=window') = 'TRUE'
and tract2000 in (012300,012400,012500,014300,014400,016600,016700,016800,016900,017000,017100,017200,017300,017400) and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') >= '01/01/2004') and
(to_char(to_date(h.fr_date,'yyyymmdd'), 'MM/DD/YYYY') <= '12/31/2004');
Note I added the ordered hint, AND reversed the order of the tables in the from clause. What this will hopefully tell the optimizer is:
find the tract2000 from the tracts2000 table (hopefully you have a non-spatial index here) using the in clause. Do this first, then:
for each of those, use the spatial index to find the assault cases.
Hopefully this will be fast.
If the assault cases are stored as point data, when you create the spatial index use layer_gtype=point to ensure best performance. -
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. -
Problem with sdo_relate returning unexpected results
I am having a problem with an oracle spatial query not returning what I feel is an appropriate result.
I have a bounding box that has 6 points from a table that should be inside it. There are several hundred points total in this table. I perform the following query and oracle returns only 4 points, well 5 but we will get to that later, within the area of the search.
SQL> Select feature_id
From city_points A
where (MDSYS.SDO_RELATE(A.GEOM, mdsys.sdo_geometry(2003, 8307, NULL, mdsys.sdo_elem_info_array(1,1003,1), mdsys.sdo_ordinate_array(-101.8417,-52.8083,-23.8417,-52.8083,-23.8417,-13.8083,-101.8417,-13.8083,101.8417,-52.8083)), 'mask=ANYINTERACT querytype=join') = 'TRUE');
I used a different application to perform the same type of query. The difference is that the application does the spatial query, not oracle. Further the application gets all of the points and performs this query on the client. What the application returns is correct both visually and spatially.
Two of the points not returned in the oracle spatial query are 300km inside the bounding box. This far exceeds the .5 m tolerance used in our decimal degrees data set (SRID 8307).
I have experienced this problem on 9.2.0.1. I then patched that instance to 9.2.0.7 and duplicated the problem. I then exported the data and imported into a 10g release 1 database and again duplicated the problem. I have tried to re-index the data to no avail.
I have also tried different querytypes also yielding less than expected results.
The data looks like this:
243
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-58.45, -34.6, NULL),NULL, NULL)
254
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-56.18333, -34.883334, NULL), NULL, NULL)
377
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-70.666671, -33.449999, NULL), NULL, NULL)
385
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-68.149999, -16.5, NULL), NULL, NULL)
388
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-47.916667, -15.783333, NULL), NULL, NULL)
427
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-57.640066, -25.270295, NULL), NULL, NULL)
The number is the id field, the rest is the geometry.
The oracle spatial query above only returns id #s 359, 377,243,254,427
There are five returned records. The extra value is outside the bounding area. So it should not have been returned at all. It is all too strange.
I have seen this with different geometry types (points lines and area) as well.
If anyone has suggestions, I would appreciate your comments.
Thanks,
JohnJohn,,
What you are seeing is the behavior you should expect in the geodetic space.
When you have a very long line connecting from longitude -101 to -23, that line
does not follow the same latitude value.
Since these points are in southern hemisphere, the line connecting them
will curve downward (this is the great circle line).
If you really want a line connecting with constant latitude, you should
use the MBR type for the window geometry which densifies the
lines along constant latitude before passing it into relate.
SDO_GEOMETRY(2003, 8307, NULL,
sdo_elem_info_array(1,1003,3),
sdo_ordinate_array(-101.8417,-52.8083, 23.8417,-13.8083))
siva -
ORA-21779: duration not active error line 25 of MDSYS.AGGRUNION
I execute the following pl/sql (line 56/57 in
a procedure called RebuildSMZLabels)....
v_query := 'SELECT /*+ INDEX ( A BASE_SMZ_A_SHAPE ) NO_INDEX ( A BASE_SMZ_A_RETIREDATE ) */ MDSYS.SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(a.s
hape,:1)) FROM &owner.base_smz_a A WHERE MDSYS.SDO_RELATE(a.shape,:2,''mask=ANYINTERACT querytype=window'') = ''TRUE'' and retiredate is
null';
EXECUTE IMMEDIATE v_query INTO v_union_shape USING v_diminfo(1).sdo_tolerance, v_trans_shape ;
And I get...
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
DECLARE
ERROR at line 1:
ORA-21779: duration not active
ORA-06512: at "MDSYS.AGGRUNION", line 25
ORA-06512: at "MDSYS.AGGRUNION", line 25
ORA-06512: at line 1
ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 57
ORA-06512: at line 5
Got me beat... anyone got any ideas?
Simon Greener
GIS Manager
Forestry TasmaniaDan
I reverted to the old 8i code (with individual
UNIONS) and it still fails:
DECLARE
ERROR at line 1:
ORA-21779: duration not active
ORA-06512: at "MDSYS.SDO_3GL", line 439
ORA-06512: at "MDSYS.SDO_GEOM", line 3096
ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 74
ORA-06512: at line 5
Line 74 is:
v_union_shape := MDSYS.SDO_GEOM.SDO_UNION(v_union_shape,v_diminfo,v_shape,v_diminfo);
Any ideas as I need this to work in 9i ASAP (as it
doesn't work in 8i)?
PS Dan, it is the same database/code problem I sent
to you earlier this year. It is getting to the point
that I am going to have to rebuild all this database
centric code (which is where it needs to be in the
business process) within our GIS (ArcInfo) which is going
to be far more complex and not sustainable in the medium
term.
regards
Simon -
Sdo_relate in alternate user with views.
Hello,
I am using Oracle 8.1.7.2 and creating a view as follows.
CREATE OR REPLACE VIEW REPORT_STREETINFO AS
SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
MAX(ST.TONRLE) MAX_TONRLE,
NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
MAX(ST.TONRRI) MAX_TONRRI,
MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET MKT_STREET,
MKT.CITY MKT_CITY,
MKT.ZIP MKT_ZIP,
MKT.PO_BOX MKT_POBOX
FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
WHERE PRIM_NAME IS NOT NULL AND
(ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
DTWA.DISTAREA_ID = DT.ID AND
WA.WASID = DTWA.WASID AND
MKT.SRNO = DT.MARKET_ID AND
MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
querytype=window') = 'TRUE'
GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP, MKT.PO_BOX
ORDER BY PRIM_NAME
I grant the rights to this above view to an alternate user. When
I fire a query like
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 22;
from the owner of the view I have no problems but when I fire
this query from alternate user I get error
ORA-03113 end-of-file on communication channel.
I checked out the documentation which states from physical
failure but this is definately not the case.
Any help on this problem will be appretiated.
Amol.Hello Ravi,
I am posting a spool file which shows the steps I have followed
and error that I get. I have taken care with the grants from
mdsys for the SDO_RELATE and all the other operators.
DEV>SHO USER
USER ist "GEODIS"
DEV>CREATE OR REPLACE VIEW REPORT_STREETINFO AS
2 SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
3 NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
4 MAX(ST.TONRLE) MAX_TONRLE,
5 NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
6 MAX(ST.TONRRI) MAX_TONRRI,
7 MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET
MKT_STREET, MKT.CITY MKT_CITY,
8 MKT.ZIP MKT_ZIP,
9 MKT.PO_BOX MKT_POBOX
10 FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
11 WHERE PRIM_NAME IS NOT NULL AND
12 (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
13 ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
14 DTWA.DISTAREA_ID = DT.ID AND
15 WA.WASID = DTWA.WASID AND
16 MKT.SRNO = DT.MARKET_ID AND
17 MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
18 querytype=window') = 'TRUE'
19 GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
20 MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP,
MKT.PO_BOX
21 ORDER BY PRIM_NAME
22 /
View wurde angelegt.
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
PRIM_NAME
Altenhagener
Weg
Alter
Zollweg
Am
Knill
Am
Kroog
Am
Lehmberg
Babenstieg
Bargteheider
Strasse
Bekassinenau
Blomeweg
Boltenhagener
Strasse
Bublitzer
Strasse
Carlssonweg
Farmsener
Zoll
Finkenfurth
Grvmitzer
Weg
Grundherrenstrasse
Herwardistrasse
Hohenkamp
Hoher
Berg
Im
Wiesengrund
Jacobshagener
Weg
Kohvvedstrasse
Kvsliner
Strasse
Krohnsheide
K|hlungsborner
Strasse
Nienhagener
Strasse
Pfefferstrasse
Rahlstedter
Stieg
Rahlstedter
Weg
Raschweg
R|genwalder
Strasse
Rummelsburger
Strasse
Sandkule
Scharbeutzer
Strasse
Sierksdorfer
Strasse
Stargarder
Strasse
Thiessenweg
Timmendorfer
Stieg
Timmendorfer
Strasse
Treptower
Strasse
Wolliner
Strasse
41 Zeilen ausgewdhlt.
DEV>GRANT SELECT ON REPORT_STREETINFO TO PWEIH;
Benutzerzugriff (Grant) wurde erteilt.
DEV>CREATE SYNONYM PWEIH.REPORT_STREETINFO FOR
GEODIS.REPORT_STREETINFO;
Synonym wurde angelegt.
DEV>CONN PWEIH/PWEIH@DEVELOP
Connect durchgef|hrt.
DEV>DESC REPORT_STREETINFO;
Name Null? Typ
ID NOT NULL NUMBER(10)
MKT_CODE VARCHAR2(10)
PRIM_NAME VARCHAR2(40)
MIN_FROMNRLE VARCHAR2(40)
MAX_TONRLE NUMBER
MIN_FROMNRRI VARCHAR2(40)
MAX_TONRRI NUMBER
MKT_NAME VARCHAR2(40)
MKT_NAME2 VARCHAR2(40)
MKT_STREET VARCHAR2(40)
MKT_CITY VARCHAR2(40)
MKT_ZIP VARCHAR2(9)
MKT_POBOX VARCHAR2(40)
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108
FEHLER in Zeile 1:
ORA-03113: Unerwartetes \bertragungsende in Kommunikation
DEV>SPOOL OFF;
Regards,
Amol. -
SDO_RELATE and ORA-03113 error
Hello,
I am trying to use the SDO_RELATE function and I receive the following error:
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Using the following SQL
SELECT ufi FROM ROADLINE A
WHERE MDSYS.SDO_RELATE(
A.GEOMETRY, mdsys.sdo_geometry( 2003,null,null,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
A similar search using the SDO_FILTER instead of SDO_RELATE and removing the mask=ANYINTERACT works ok.
Can anyone suggest anything?
Thanks in advance.
GunterHi Gunter,
It looks like there may be other issues. Can you post the version of Oracle you are using, and try debugging just a little bit more to try to narrow the problem down?
This might help to determine which geometry the failure is occuring at:
create table tt as select ufi,geometry
from roadline where rownum < 1;
declare
ufi number ;
window_geom mdsys.sdo_geometry := mdsys.sdo_geometry( 2003,null,null, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11));
theGeom mdsys.sdo_geometry ;
TYPE geomcursor is REF CURSOR ;
aCursor geomcursor;
relationship varchar2(30);
begin
open aCursor FOR 'SELECT ufi, geometry from roadline A WHERE SDO_filter( A.GEOMETRY,:WINDOW_GEOM, ''querytype=WINDOW'') = ''TRUE''' using window_geom;
loop
FETCH aCursor INTO ufi, theGeom ;
EXIT WHEN aCursor%NOTFOUND ;
execute immediate 'insert into tt values (:ufi,:theGeom)'
using ufi,theGeom;
execute immediate 'commit';
relationship := sdo_geom.relate(theGeom,'anyinteract',window_geom,0.05);
end loop;
end;
If you see the same error, hopefully it will be determining the relationship between the last geometry in the table tt and the query window. If you can check this, and if this is the case post the geometry that is failing as well as the contents of user_sdo_geom_metadata for roadline that would be great.
Dan -
Geomtry to mdsys.sdo_geometry
Hi, i'm a newbie of Oracle Spatial, i'm working with sdoapi, i need to convert
geometries encoded with GML into valid geometries encoded in msdsys.sdo_geometry
to perform query throug SQL over other geoemtries stored into a table.
For example, if i've a box geometry in GML like this:
<gml:Box>
<gml:coord>
<gml:X>-103</gml:X>
<gml:Y>31</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>-103.5</gml:X>
<gml:Y>31.5</gml:Y>
</gml:coord>
</gml:Box>
I would make a query like:
SELECT a.geometry
FROM My_Spatial_Table a
WHERE mdsys.sdo_relate(a.geometry, mdsys.sdo_geometry (2003, null, null,mdsys.sdo_elem_info_array (1,1003,3),mdsys.sdo_ordinate_array (-103,31,-103.5,31.5)),'querytype=WINDOW layer_gtype=notpoint') = 'TRUE';
I've look in sdoapi's samples that i can make an adapter from my
GML (XML) to Oracle's geometry, now i would know if i can map
this geometry into a mdsys.sdo_geometry form.
For geometries like point, box, there's no problems, but for geometries
like polygon, linestring, multipolygon i don't know how do this! :-(
Any tips or documentation for my problem?
Best Regards
LuigiAre you positive that the data is only being saved
with 6 places of precisions ?
As far as I remember SQLPlus only displays up to 6
decimal points, although there are more in the data.
I remember a similar thread on this before where
there was a Tip that suggested setting the SQLPlus
number format highr in order to display the full
coordinates.
e.g. SET NUMFORMAT 9999999999999999.99999999999999999999999;
Ro -
Sdo_relate: combined masks
Hi,
I would like to execute a sdo_relate operation with a combined mask like (CONTAINS+COVERS+OVERLAPBDYINTERSECT)
but it gives me not all results (I checked
it with sdo_geom.relate). Furthermore when I
swap the masks in the parenthesis it gives
me no results at all.
I think I have seen an information somewhere
which said that this is a known bug.
If this is a bug is there a patch available
for it?
I'm working with 8.1.7.
JoergHi,
the solution I am using is as follows:
SELECT x.*
FROM (SELECT sdo_geom.relate(a.geo, m.diminfo, 'determine', b.geo, m.diminfo) rel,
FROM a, b, user_sdo_geo_metadata m
WHERE mdsys.sdo_relate(a.geo,b.geo,
'MASK=ANYINTERACT QUERYTYPE=JOIN') = 'TRUE'
...) x
WHERE x.rel != 'TOUCH'
This finds all objects which have common area. I use a relate operator with the ANYINTERACT mask to find all object which
have a spatial relationship. Then I determine
the relationship with the relate function. In
the surrounding SELECT I filter out all objects
with a 'TOUCH' relationship.
For me this is much faster than the Query
with a UNION.
Anyway, this is just a workaround.
Joerg -
HELP!! SDO_RELATE inside Oracle procedure - ORA-13207: incorrect use of the
Hello,
I need help !
I have a problem with queries inside procedures/packages.
When execute sql
SQL> SELECT LOC_OBJ_ID
2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
LOC_OBJ_ID
2211379
i have results - it's OK
The next sql is same, but with agregation
SQL> SELECT COUNT(*) ILOSC
2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
ILOSC
1
it's OK
But when i want use this SQL inside proedurees in store result in variable i have problem
SQL> declare
2 V_NUMBER_NEI_LOC number;
3 begin
4 SELECT COUNT(*) ILOSC
5 INTO V_NUMBER_NEI_LOC
6 FROM VORO_LOC X, LBS_OZ_AREAS OZ
7 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
8 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
9 end;
10 /
declare
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
ORA-06512: at line 4
ORA-06512: at line 4
Please help!This might be some issue with SQL in PL/SQL. We will check into this.
In the meantime, can you try the dynamic SQL to execute that
sdo_relate query to see if it works?
Here is the example with dynamic SQL:
declare
V_NUMBER_NEI_LOC number;
begin
EXECUTE IMMEDIATE
' SELECT COUNT(*) ILOSC ' ||
' FROM VORO_LOC X, LBS_OZ_AREAS OZ ' ||
' WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, ' ||
' ''MASK=ANYINTERACT'') = ''TRUE'' ' ||
' AND OZ.OZ_NAME=''PTK'' AND OZ.OZ_GROUP=''GORCZEWSKA'' '
INTO V_NUMBER_NEI_LOC;
end;
/
Maybe you are looking for
-
Can you pay 2 player games over a wifi network between 2 ipad 2's
can i play an app game over a wifi network with another ipad user, to save having to pass the device between players
-
HT1727 is there any easy way to authorize this computer to play my purchased tunes
how do i authorize this computer for my purchased tunes
-
Ocspd issue, causing repeated log errors.
I'm fairly new to Apple servers and have recently installed a new mac mini server with Lion OS Server. The server seems to intermittently slow down or refuse to send receive email for a while. Looking at the log files I have noticed the following er
-
How to create text box where input is time only.
Hi , How can I create a textBox which accept Time only. Or how can i create a text Box so that it take two numbers before and after ":" Like -> 12 : 34. User can see : however have permission to edit numbers. Any suggestions. Regards Richa
-
EndSeparator: '0x0D''0x0A'
Hi, I am using file content conversion with fixed width in my receiver file communication channnel. In the endSeparator, I am using '0x0D''0x0A'. This is end separator is not working. Your help will be appreciated. Thanks