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!
    null

    Ops, 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
    Krzysztof

    It 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,
    J

    Hi,
    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
    James

    something 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

  • Slow running spatial query

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

    Hi,
    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,
    John

    John,,
    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 Tasmania

    Dan
    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.
    Gunter

    Hi 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
    Luigi

    Are 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.
    Joerg

    Hi,
    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