Inconsistent results between SDO_RELATE and SDO_GEOM.RELATE

Maybe its the Friday syndrome, but I'm getting some results that I can't get my head around...
Let say I have a table with a single line geometry...
CREATE TABLE BUFFER_TEST (
     WHAT VARCHAR2(100),
     GEOMETRY SDO_GEOMETRY);
INSERT INTO user_sdo_geom_metadata VALUES ('BUFFER_TEST','GEOMETRY', 
MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)),
262152);
CREATE INDEX BUFFER_TEST_IDX ON BUFFER_TEST (GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
INSERT INTO BUFFER_TEST (what, geometry)
VALUES ('line',
SDO_GEOMETRY(2002, 262152, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1),
SDO_ORDINATE_ARRAY(713353.165, 736165.812, 713353.449, 736165.402, 713353.849,
736164.203, 713353.85, 736162.252, 713353.087, 736149.092)));
COMMIT;Now I want to buffer this line and check if the line is inside the buffer - the actual business need is to see if other lines are in the buffer, but we'll keep it simple for now...
So in the snippet below, I'm buffering the line by 50cm and then using SDO_INSIDE to see if the line is inside the buffer - it isn't.
Then if I use SDO_GEOM.RELATE to determine the relationship, it says INSIDE, which is correct.
Then if I increase the buffer size to 1m, then SDO_INSIDE and SDO_GEOM.RELATE both return the correct result.
SQL> DECLARE
  2   l_inside  NUMBER;
  3   l_small_buffer SDO_GEOMETRY;
  4   l_determine  VARCHAR2(100);
  5   l_buffer_size  NUMBER := 0.5;
  6  BEGIN
  7
  8     SELECT  SDO_GEOM.SDO_BUFFER(b.geometry, usgm.diminfo, l_buffer_size)
  9     INTO      l_small_buffer
10     FROM    user_sdo_geom_metadata usgm, BUFFER_TEST b
11     WHERE  usgm.table_name = 'BUFFER_TEST'
12     AND      usgm.column_name = 'GEOMETRY'
13     AND      b.what = 'line';
14
15     SELECT  COUNT(*)
16     INTO    l_inside
17     FROM   BUFFER_TEST
18     WHERE SDO_INSIDE(geometry, l_small_buffer) = 'TRUE'
19     AND     what = 'line';
20
21     SELECT SDO_GEOM.RELATE(geometry, 'determine', l_small_buffer, 0.0005) relationship
22     INTO  l_determine
23     FROM BUFFER_TEST
24     WHERE what = 'line';
25
26     DBMS_OUTPUT.PUT_LINE('l_inside: ' || l_inside || ' relationship ' || l_determine);
27
28  END;
29  /
l_inside: 0 relationship INSIDEAny help would be much appreciated... I'm starting to pull my hair out on this.
This is on Oracle 10.2.0.3

I can reproduce this on 11.1.0.6 on Windows 32bit.
Would you recommend I open a support case on this? Do you think it would be possible to backport a fix to 10.2.0.4?

Similar Messages

  • SDO_RELATE AND SDO_GEOM RELATE MASK PROBLEMS

    I am trying to use the SDO_RELATE operator on my spatial table.
    I have been experiencing problems.
    I also get the same problems if I use the SDO_GEOM.RELATE geometry function.
    Background
    Table2 contains about 20 000 rows.
    Table1 contains about 1 000 000 rows.
    Both tables contain area geomteries.
    I can not get the following 'masks' to return any results.
    -- OVERLAPBDYINTERSECT
    -- COVEREDBY
    -- COVERS
    -- OVERLAPBDYDISJOINT
    The all return -
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel
    Elapsed: 00:00:20.00
    However the mask INSIDE does work!!! And it returns the correct results.
    The query syntax I am using is below. And substituting any of the above mentioned masks for INSIDE results in the ORA-03113 error.
    I have validated all the geometies in my table using SDO_GEOM.VALIDATE_LAYER. They are all valid.
    Query Syntax
    SELECT /* ORDERED */ count(g2.parcel_ref)
    FROM table2 g2
    WHERE 1 < (SELECT /*+ ORDERED */ count(*)
    FROM table1 g1
    WHERE SDO_RELATE (g1.geometry,
         g2.geom,
              'MASK=INSIDE querytype=WINDOW') ='TRUE');
    SELECT /* ORDERED ORDERED_PREDICATES */ count(g2.parcel_ref)
    FROM table2 g2
    WHERE 1 < (SELECT /*+ ORDERED */ count(*)
    FROM table1 g1
    WHERE SDO_FILTER (g1.geometry, g2.geom, 'querytype=WINDOW')='TRUE'
    AND SDO_GEOM.RELATE (g1.geometry, 'inside', g2.geom,0.001)='INSIDE');
    Does anybody have any ideas why all the masks (except INSIDE) fail?
    Thanks,
    Bob

    Dan,
    I have finally got back to looking at my problem queries.
    The first discovery I have found is that I can repeat the problem using one feature in one of the geometry tables.
    You can see the syntax that I am using below. As I stated before, the INDSIDE query works, but the COVEREDBY fails.
    OVERLAPBDYINTERSECT,COVEREDBY,COVERS,OVERLAPBDYDISJOINT also return the same ORA-03113 error.
    SELECT /* ORDERED */ count(g2.parcel_ref)
    FROM table2 g2
    WHERE g2.id = 3658
    AND 1 < (SELECT /*+ ORDERED */ count(*)
    FROM table1 g1
    WHERE SDO_RELATE (g1.geometry, g2.geom, 'MASK=INSIDE querytype=WINDOW') ='TRUE');
    *** THIS ONE WORKS!
    SELECT /* ORDERED */ count(g2.parcel_ref)
    FROM table2 g2
    WHERE g2.id = 3658
    AND 1 < (SELECT /*+ ORDERED */ count(*)
    FROM table1 g1
    WHERE SDO_RELATE (g1.geometry, g2.geom, 'MASK=COVEREDBY querytype=WINDOW') ='TRUE');
    *** THIS ONE DOES NOT WORK! The error is below.
    SELECT /* ORDERED */ count(g2.parcel_ref)
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel
    I have also been running some other queries on my data.
    Again, one query works, the other does not.
    SELECT /*+ ORDERED ORDERED_PREDICATES */ count(*)
    FROM table2 g1, table2 g2
    WHERE g1.id = 194
    AND SDO_FILTER (g2.geom, g1.geom, 'querytype=WINDOW')='TRUE'
    AND SDO_GEOM.RELATE (g2.geom, 'overlapbdyintersect', g1.geom,0.0001)='OVERLAPBDYINTERSECT';
    *** THIS ONE WORKS!
    SELECT /*+ ORDERED */ count(*)
    FROM table2 g1, table2 g2
    WHERE g1.id = 194
    AND SDO_RELATE (g2.geom, g1.geom, 'MASK=OVERLAPBDYINTERSECT querytype=WINDOW') ='TRUE';
    *** THIS ONE DOES NOT WORK! Again, the error is below.
    SELECT /*+ ORDERED */ count(*)
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel
    I have checked that the two problem geometries are 'valid'.
    SQL> select sdo_geom.validate_geometry(geom, 0.001) from table2 where id=194;
    SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.001)
    TRUE
    SQL> select sdo_geom.validate_geometry(geom, 0.001) from table2 where id=3658;
    SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.001)
    TRUE
    Below is a print of the geometry of each of the problem features.
    Have you got any ideas as to why the queries are failing?
    Thanks in advance,
    Bob
    SQL> select geom from sample_lr_prm_iacs2002 where id=3658;
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    SDO_GEOMETRY(2003, 81989, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_AR
    RAY(475710.144, 133881.126, 475714.379, 133844.065, 475723.656, 133762.89, 47572
    4.07, 133759.271, 475964.952, 133791.345, 475963, 133796.9, 475959, 133806.2, 47
    5956.8, 133812.5, 475955.2, 133816.1, 475951.3, 133824.1, 475944.3, 133838.6, 47
    5933.5, 133861.8, 475932, 133864.5, 475928.5, 133869.7, 475918.8, 133885.8, 4759
    12.5, 133897, 475907.6, 133903.9, 475898.6, 133914.2, 475888.8, 133922.7, 475824
    .2, 133974.3, 475809.9, 133976.2, 475808.1, 133974.6, 475805.5, 133972, 475796.3
    , 133955.7, 475783.99, 133933.51, 475782.67, 133931.44, 475780.87, 133927.97, 47
    5780.14, 133927, 475778.95, 133924.69, 475778.12, 133923.03, 475775.33, 133919.3
    4, 475773.51, 133917.39, 475768.42, 133913.14, 475765.56, 133911.12, 475757.25,
    133906.26, 475751.77, 133903.28, 475741.52, 133897.2, 475714.92, 133883.62, 4757
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    10.86, 133881.5, 475710.144, 133881.126))
    SQL> select geom from table2 where id=194;
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    SDO_GEOMETRY(2003, 81989, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_AR
    RAY(467345.544, 109699.287, 467345.379, 109699.279, 467345.288, 109698.752, 4673
    44.9, 109696.5, 467339.8, 109665.2, 467325.9, 109583.1, 467311.35, 109500, 46730
    9.1, 109487, 467308.27, 109482.113, 467308.242, 109482.142, 467307.491, 109478.1
    99, 467307.44, 109477.435, 467307.3, 109475.9, 467307.331, 109475.837, 467307.02
    4, 109471.295, 467306.963, 109471.307, 467306.831, 109471.334, 467306.831, 10946
    9.765, 467307.192, 109469.68, 467310.196, 109468.973, 467345.545, 109459.288, 46
    7363.626, 109453.84, 467395.576, 109447.4, 467444.616, 109440.217, 467457.247, 1
    09439.474, 467460.715, 109437.245, 467461.458, 109436.255, 467467.251, 109435.39
    6, 467468.145, 109435.264, 467468.264, 109435.663, 467481.7, 109435.2, 467487.2,
    109435.3, 467488.8, 109435.4, 467490.6, 109435.5, 467493.4, 109435.9, 467495.6,
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    109435.9, 467500, 109435.8, 467505.75, 109435.8, 467515.85, 109436.2, 467525.2,
    109436.45, 467531.95, 109436.5, 467534.7, 109436.55, 467541.45, 109436.8, 46754
    4.65, 109437.05, 467547.65, 109437.3, 467551.3, 109437.7, 467551.95, 109437.75,
    467555.6, 109438.1, 467556.4, 109438.15, 467558.6, 109438.25, 467562.95, 109438.
    35, 467585.5, 109439.1, 467593.55, 109439.35, 467597.5, 109439.35, 467600.45, 10
    9439.3, 467603.65, 109439.35, 467606.8, 109439.3, 467607, 109439.3, 467610.15, 1
    09439.2, 467613.35, 109439, 467615.7, 109438.8, 467618, 109438.55, 467620.3, 109
    438.25, 467623.3, 109437.65, 467626.2, 109437.1, 467626.85, 109437, 467629.8, 10
    9436.5, 467631.6, 109436.25, 467634.15, 109435.95, 467635.05, 109435.85, 467636.
    95, 109435.7, 467637.35, 109435.65, 467639.25, 109435.4, 467640.1, 109435.25, 46
    7641, 109435.1, 467643.7, 109434.5, 467644.3, 109434.3, 467652.15, 109432.45, 46
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    7653.35, 109432.2, 467654.4, 109431.95, 467656.8, 109431.25, 467658.35, 109430.7
    5, 467659.75, 109430.15, 467660, 109430.05, 467662.95, 109429.15, 467667.25, 109
    427.9, 467667.8, 109427.8, 467668.5, 109427.7, 467670, 109427.5, 467670.7, 10942
    7.4, 467671.45, 109427.35, 467671.7, 109427.35, 467678.95, 109427.45, 467680.4,
    109427.5, 467681.75, 109427.55, 467683.2, 109427.55, 467684.55, 109427.5, 467685
    .95, 109427.45, 467687.35, 109427.35, 467688.55, 109427.25, 467695.4, 109426.55,
    467696.8, 109426.45, 467698.15, 109426.3, 467699.55, 109426.1, 467700.75, 10942
    5.95, 467703.45, 109425.35, 467703.95, 109425.2, 467708.85, 109423.95, 467717.8,
    109421.4, 467721.2, 109420.5, 467726.4, 109419.2, 467729.8, 109418.5, 467731.45
    , 109418.15, 467735.95, 109417.45, 467737.5, 109417.25, 467742.8, 109417.05, 467
    748.2, 109416.7, 467748.95, 109416.6, 467749.7, 109416.45, 467750.5, 109416.3, 4
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    67752, 109415.9, 467752.75, 109415.65, 467753.4, 109415.45, 467753.95, 109415.2,
    467754.55, 109415, 467755.1, 109414.75, 467755.6, 109414.45, 467756.15, 109414.
    2, 467756.45, 109414, 467762.25, 109409.8, 467768.8, 109404.9, 467770.4, 109403.
    7, 467771.3, 109403.1, 467771.513, 109402.932, 467772.658, 109403.214, 467772.92
    9, 109403.281, 467777.496, 109404.803, 467790.963, 109405.789, 467804.758, 10940
    7.103, 467810.013, 109407.431, 467821.181, 109409.73, 467831.035, 109410.716, 46
    7843.188, 109412.03, 467849.757, 109412.686, 467853.992, 109414.38, 467854.15, 1
    09416.85, 467854.85, 109427.6, 467855.35, 109436.3, 467855.75, 109443.95, 467856
    .25, 109451.7, 467854.7, 109460.35, 467852.45, 109472, 467850.5, 109482.45, 4678
    48.45, 109493.25, 467847.15, 109500, 467846.25, 109505.2, 467845, 109511.7, 4678
    44.25, 109515.9, 467843.15, 109521.5, 467841.85, 109528.55, 467840.65, 109534.95
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    , 467840.05, 109538.2, 467839.65, 109542.4, 467839.05, 109548.35, 467838.55, 109
    553.6, 467837.9, 109560.6, 467837.2, 109568, 467836.45, 109576.3, 467836.05, 109
    581.45, 467835.45, 109588.4, 467834.55, 109597.9, 467833.1, 109614.5, 467832.35,
    109622, 467831.2, 109634.4, 467830.6, 109640.2, 467830.55, 109640.5, 467828.5,
    109642.15, 467824.2, 109642.3, 467821.1, 109642.35, 467819.75, 109642.4, 467818.
    9, 109642.4, 467818.6, 109642.45, 467818.4, 109642.45, 467818.25, 109642.5, 4678
    18.05, 109642.5, 467817.85, 109642.55, 467817.65, 109642.5, 467817.45, 109642.5,
    467817.2, 109642.55, 467816.95, 109642.55, 467816.7, 109642.6, 467816.45, 10964
    2.6, 467815.85, 109642.7, 467815.35, 109642.7, 467814.65, 109642.8, 467812.25, 1
    09643.05, 467811.4, 109643.1, 467810.55, 109643.2, 467809.1, 109643.4, 467807.1,
    109643.7, 467805.75, 109643.85, 467804.45, 109643.95, 467800.55, 109644.5, 4677
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    98.75, 109644.7, 467795.9, 109645, 467794.95, 109645.15, 467793.6, 109645.3, 467
    792.15, 109645.55, 467790.65, 109645.75, 467787.25, 109646.05, 467782.8, 109646.
    5, 467778.15, 109646.95, 467774.5, 109647.4, 467770.1, 109647.85, 467765.75, 109
    648.3, 467760.85, 109648.9, 467753.35, 109649.65, 467748.7, 109650.1, 467745.15,
    109650.45, 467741.05, 109650.85, 467739.95, 109650.95, 467736.45, 109651.35, 46
    7732.1, 109651.95, 467729.1, 109652.3, 467724.95, 109652.7, 467723.05, 109652.95
    , 467720.5, 109653.2, 467716.65, 109653.75, 467712.05, 109654.45, 467708.65, 109
    654.9, 467704.45, 109655.4, 467700.35, 109655.95, 467695.65, 109656.65, 467692.4
    , 109657.1, 467690.4, 109657.25, 467682.65, 109657.8, 467679, 109658.1, 467676.1
    5, 109658.35, 467674.75, 109658.5, 467674.3, 109658.5, 467674.1, 109658.55, 4676
    73.7, 109658.55, 467673.3, 109658.65, 467673, 109658.7, 467672.7, 109658.8, 4676
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    72.1, 109658.9, 467671.4, 109659, 467670.9, 109659.1, 467670, 109659.25, 467669.
    75, 109659.3, 467668.75, 109659.4, 467668.3, 109659.4, 467667.85, 109659.45, 467
    665.4, 109659.65, 467661.9, 109660.05, 467659.5, 109660.3, 467656.65, 109660.7,
    467652.55, 109661.25, 467648.35, 109661.8, 467644.65, 109662.25, 467641.7, 10966
    2.65, 467639.5, 109662.9, 467636.75, 109663.25, 467633.25, 109663.6, 467631.7, 1
    09663.75, 467631.5, 109663.8, 467631.1, 109663.8, 467630.9, 109663.85, 467630.55
    , 109663.85, 467630.35, 109663.9, 467630.2, 109663.95, 467629.85, 109663.95, 467
    629.05, 109664.05, 467628.35, 109664.15, 467628.05, 109664.2, 467627.7, 109664.3
    , 467625.95, 109664.55, 467623.15, 109665.1, 467622.85, 109665.15, 467622.6, 109
    665.25, 467622.3, 109665.3, 467622.05, 109665.35, 467621.9, 109665.35, 467621.65
    , 109665.4, 467621.4, 109665.4, 467621.15, 109665.45, 467620.95, 109665.5, 46762
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    0.7, 109665.6, 467620.5, 109665.65, 467620.3, 109665.65, 467619.8, 109665.75, 46
    7619.5, 109665.8, 467619.15, 109665.8, 467618.45, 109665.9, 467616.8, 109666.1,
    467613.2, 109666.6, 467610.15, 109667.05, 467608, 109667.3, 467605.85, 109667.5,
    467603.75, 109667.7, 467602.25, 109667.9, 467601.05, 109668, 467597.05, 109668.
    35, 467592.6, 109668.8, 467589.7, 109669.1, 467587.1, 109669.4, 467583.65, 10966
    9.75, 467580.7, 109670.1, 467576.3, 109670.65, 467567, 109671.85, 467562.25, 109
    672.4, 467556.85, 109673, 467553.95, 109673.3, 467550.35, 109671.95, 467545.1, 1
    09670, 467540.35, 109668.3, 467539.9, 109668.15, 467539.75, 109668.15, 467539.6,
    109668.1, 467539.5, 109668.05, 467539.35, 109668, 467539.2, 109668, 467539, 109
    667.95, 467538.75, 109667.95, 467538.55, 109667.9, 467538.35, 109667.9, 467534.8
    , 109667.7, 467530.65, 109667.35, 467523.9, 109666.75, 467519.5, 109666.4, 46751
    GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    6.2, 109666.1, 467511.8, 109665.65, 467508.1, 109665.3, 467504.85, 109664.9, 467
    501.35, 109664.5, 467500, 109664.4, 467498.7, 109664.3, 467480.5, 109673.4, 4674
    73.7, 109677, 467468.4, 109680, 467461.5, 109683.8, 467453.2, 109688.1, 467448.1
    , 109690.4, 467441.4, 109693, 467439.6, 109693.6, 467430, 109696.2, 467424, 1096
    97.7, 467420.3, 109698.5, 467419.444, 109698.653, 467419.409, 109698.708, 467397
    .983, 109702.395, 467373.562, 109709.767, 467362.964, 109719.213, 467362.94, 109
    718.668, 467362.504, 109719.213, 467347.528, 109705.39, 467346.459, 109701.945,
    467346.01, 109700.498, 467345.636, 109699.291, 467345.544, 109699.287))

  • Inconsistent results with SDO_RELATE and boundary conditions

    Hello,
    I am using SDO_RELATE to find all points in one table with any interaction with a polygon selected from a second table. Pretty basic stuff. I noticed one point which exactly matches a vertex on the query polygon was not getting selected as expected. Experimenting a bit I found if I embedded the polygon geometry in the query (rather than selecting it from its table) the query selected the point in question! Experimenting further I found if I changed the query relation from ANYINTERACT to TOUCH the point in question was not selected. So my 2 questions are:
    1) What would cause this to fail when the query polygon is being selected from the table?
    2) How can ANYINTERACT be true but TOUCH be false?
    Here is the first query that fails:
    SELECT a.point_id
    FROM point_table a, poly_table b
    WHERE a.point_id = <point which matches poly vertex>
    AND b.poly_id = <poly_id>
    AND SDO_RELATE (a.geom, b.geom, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
    Here is the query that works:
    SELECT a.point_id
    FROM point_table a, poly_table b
    WHERE a.point_id = <point which matches poly vertex>
    AND SDO_RELATE (a.geom,
    MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323,
    -82.387158, 28.0116258, -82.378891, 28.0131216,
    -82.377988, 28.0133894, -82.37555, 28.0143994,
    -82.329352, 28.0661089, -82.313207, 28.1006725,
    -82.362246, 28.1261981, -82.445319, 28.1139363,
    -82.428389, 28.0245891, -82.422103, 28.0117697,
    -82.421382, 28.0109085, -82.419096, 28.0099741,
    -82.414884, 28.0094323)),
    'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
    Here is the second query that fails (ANYINTERACT -> TOUCH):
    SELECT a.point_id
    FROM point_table a, poly_table b
    WHERE a.point_id = <point which matches poly vertex>
    AND SDO_RELATE (a.geom,
    MDSYS.SDO_GEOMETRY(1003, 8265, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1, 2003, 1),
    MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323,
    -82.387158, 28.0116258, -82.378891, 28.0131216,
    -82.377988, 28.0133894, -82.37555, 28.0143994,
    -82.329352, 28.0661089, -82.313207, 28.1006725,
    -82.362246, 28.1261981, -82.445319, 28.1139363,
    -82.428389, 28.0245891, -82.422103, 28.0117697,
    -82.421382, 28.0109085, -82.419096, 28.0099741,
    -82.414884, 28.0094323)),
    'mask=TOUCH querytype=WINDOW') = 'TRUE';
    The point geometry being selected from the point_table looks like this:
    MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
    MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363))
    The metadata for these 2 tables looks like this:
    POINT_TABLE
    GEOM
    SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05),
    SDO_DIM_ELEMENT('Y', -90, 90, .05))
    8265
    POLY_TABLE
    GEOM
    SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05),
    SDO_DIM_ELEMENT('Y', -90, 90, .05))
    8265
    Both tables have R-tree indexes built.
    System is Oracle9i Enterprise Edition Release 9.2.0.5.0 with sdo_version = 9.2.0.5.0
    Is it a problem that my points are stored as SDO_ORDINATES? Is the tolerance a factor? Is geodetic data a factor?
    Let me know if any other information would be useful and thank you for your help!
    James

    I am continuing to struggle with this one. I gave up on the SDO_RELATE function under the assumption the tolerance does not come into play for this function (is this true?).
    Now I am trying to use the SDO_GEOM.RELATE function with a tolerance to make this work and it is not working as I would expect.
    The following 2 queries show the distance between this point and this polygon is 0 yet they are disjoint. How can this be??
    Thanks, James
    SQL> SELECT SDO_GEOM.SDO_DISTANCE(
    2 MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
    3 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
    4 MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363)),
    5 MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
    6 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    7 MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323, -82.387158, 28.0116258,
    8 -82.378891, 28.0131216, -82.377988, 28.0133894, -82.37555, 28.0143994,
    9 -82.329352, 28.0661089, -82.313207, 28.1006725, -82.362246, 28.1261981,
    10 -82.4453185022412,28.1139363297581, -82.428389, 28.0245891, -82.422103, 28.0117697,
    11 -82.421382, 28.0109085, -82.419096, 28.0099741, -82.414884, 28.0094323)),
    12 10)
    13 FROM DUAL;
    SDO_GEOM.SDO_DISTANCE(MDSYS.SDO_GEOMETRY(2001,8265,NULL,MDSYS.SDO_ELEM_INFO_ARRA
    .00000000000000000000
    SQL>
    SQL> SELECT SDO_GEOM.RELATE(
    2 MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
    3 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
    4 MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363)),
    5 'determine',
    6 MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
    7 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    8 MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323, -82.387158, 28.0116258,
    9 -82.378891, 28.0131216,-82.377988, 28.0133894, -82.37555, 28.0143994,
    10 -82.329352, 28.0661089, -82.313207, 28.1006725,
    11 -82.362246, 28.1261981, -82.4453185022412, 28.1139363297581,
    12 -82.428389, 28.0245891, -82.422103, 28.0117697,
    13 -82.421382, 28.0109085, -82.419096, 28.0099741, -82.414884, 28.0094323)),
    14 10)
    15 FROM DUAL;
    SDO_GEOM.RELATE(MDSYS.SDO_GEOMETRY(2001,8265,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,
    DISJOINT

  • Can you explain SDO_RELATE and SDO_GEOM.RELATE differences?

    Ok, so I'm doing some spatial queries identifying geometries that interact with each other, and everything's groovy until the customer says, ok, get rid of the ones that just touch, which means that a call to SDO_RELATE with an ANYINTERACT mask no longer does the trick. First we tried setting a multiple mask and those queries ran like 9 hours. I figured that since we're burning that much time, we might as well build a table that stores the interaction as identified by DO_GEOM.RELATE with a DETERMINE mask.
    Then I noticed an odd thing happening on the way to the forum. For some geometries I get SDO_RELATE with ANYINTERACT returning TRUE and then SDO_GEOM.RELATE returns DISJOINT with the same tolerance that is coded in the metadata (0.5). When tolerance is bumped up to 27, I get TOUCH back. The funny thing is that there are 3 geometries involved here, the reference geom, one that yields TOUCH, and the one that yields DISJOINT.
    Stepping back from this behavior, doing some head-scratching and chin-stroking, I ran accross this statement in the Oracle® Spatial User's Guide and Reference 10g Release 2 (10.2) [here.|http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#i78531]
    Unlike with the SDO_GEOM.RELATE function, DISJOINT and DETERMINE masks are not allowed in the relationship mask with the SDO_RELATE operator. This is because SDO_RELATE uses the spatial index to find candidates that may interact, and the information to satisfy DISJOINT or DETERMINE is not present in the index.
    Now, how can a function that cannot determine DISJOINT relationships be reliable in determining ANYINTERACT relationships? Actually in this case, the answer we needed is given by SDO_RELATE, as we were looking for a touch relationship for all 3 geometries, except we got the DISJOINT with the SDO_GEOM.RELATE until we cranked up the tolerance.
    These are the geometries involved:
    Base geom:
    SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.4002777777778, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
    Geom that yields ANYINTERACT and TOUCH:
    SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.77888889, 31.3330555608386, -81.59972222, 31.4252777808399, -81.99972222, 31.7997222208455, -81.99972222, 31.4002777808396, -81.88777778, 31.3330555608386, -81.77888889, 31.3330555608386))
    Geom that yields ANYINTERACT and DISJOINT:
    SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.39166667, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222, 31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
    Both should touch the base geom along the -81.99972222 or at least both should be disjoint at a tolerance of 0.5 but one is and the other isn't.
    So how do I know when to trust SDO_RELATE? How do I know what tolerance will give me consistency?
    Oh, yeah, we have the query down to about 45 mins, by using SDO_GEOM.RELATE with DETERMINE and SDO_FILTER in the where clause. (comparing each geometry to each geometry in a table of about 10K rows)

    ConSolTed,
    It looks to me like the geometries in question are disjoint by 0.000247 meters.
    Check my math:
    -81.9997222222222 - -81.99972222 = -0.0000000022222 degrees
    111,000 meters/degree @equator * -0.0000000022222 * cos(31.4) = -0.000247
    So I would expect sdo_geom.relate to return TOUCH for both geometries, and sdo_anyinteract to return TRUE for both, when the tolerance is around .0005 and up. But I've never been good at this math stuff.
    Anyone know why ConSolTed's query below, now with a tolerance of 26 meters, returns Disjoint?
    SQL> select version from v$instance;
    VERSION
    10.2.0.4.0
    SQL> SELECT
    2 SDO_GEOM.RELATE(
    3 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497
    222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.400277777777
    8, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
    4 , 'determine',
    5 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.391666
    67, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222,
    31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5
    419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
    6 , 26) relationship
    7 FROM dual;
    RELATIONSHIP
    DISJOINT

  • SDO_RELATE OR SDO_GEOM.RELATE

    hii. i want to get an information that for example districts in a specified city.i try to use sdo_relate and sdo_geom.relate but i could not get true result.
    SELECT * FROM DISTRICTS WHERE SDO_RELATE(DISTRICTS .OGC_GEOMETRY,(SELECT OGC_GEOMETRY FROM CITY WHERE CITY_ID=2),'MASK=ANYINTERACT')='TRUE'
    or
    select * from DISTRICTS where sdo_geom.relate((select ogc_geometry from CİTY where CİTY_ID=2),'ANYINTERACT',DISTRICTS .ogc_geometry,0000000001)='TRUE'
    WHEN i use these statement i get some results but it contains also neighbours. therefore i try to use
    select * from DISTRICTS where sdo_geom.relate((select ogc_geometry from city where city_ID=2),'CONTAINS',DISTRICTS .ogc_geometry,0000000001)='TRUE'
    or
    SELECT * FROM DISTRICTS WHERE SDO_RELATE(DISTRICTS.OGC_GEOMETRY,(SELECT OGC_GEOMETRY FROM city WHERE city_ID=2),'MASK=ANYINTERACT')='TRUE'
    but when i use these i could not get any information. result set is empty. why? where is the problem. thanks to everyone for help.

    The point here is to figure out what is going on.
    1. If you would union your 9 items you expect to be returned, would that be exactly the same geometry as the city (id=2)?
    No? In that case you need to clarify how the districts and the city are related to each other. In this case it make sense you have the result using
    ('mask=covers+covererby')
    Yes? In that case I see 2 options.
    A. The geometry is not correctly continously formed.
    B. The tolerance set in the user_sdo_geom_metadata for the districts does not suit its geometries.
    I assusme also you validated your data.

  • Inconsistent results for SDO_RELATE

    Using SDO_VERSION = 10.2.0.2.0
    I am getting inconsistent results using SDO_RELATE. If I do the whole table (over 200,000 records), one particular record that I know of is skipped while if I pick a smaller range of records ie. 4 records in this case, the record is not skipped. The particular relationship with this record is "touch". Is there any limitation on table size or is this something else? Here is the example :
    -- The column is set to null
    SQL> update nad_als_fixed_stn_10G_HQ set insidecheck = null;
    231484 rows updated.
    -- SDO_RELATE on a few records which actually finds the correct relationship
    SQL> UPDATE nad_als_fixed_stn_10G_HQ C SET C.insidecheck = '1'
    2 WHERE EXISTS (SELECT 1 FROM MetroRegions A, nad_als_fixed_stn_10G_HQ B
    3 WHERE SDO_RELATE(B.location83r, A.geoloc, 'mask=anyinteract') = 'TRUE'
    4 AND C.lic_no = B.lic_no and C.lic_no between 4687157 and 4687223 )
    5 ;
    3 rows updated.
    -- Displays the correct relationship for that record (this is a "touch")
    SQL> select insidecheck from nad_als_fixed_stn_10G_HQ where lic_no = 4687161;
    Inside
    check
    1
    -- Reset the column to null
    SQL> update nad_als_fixed_stn_10G_HQ set insidecheck = null;
    231484 rows updated.
    -- SDO_RELATE on the complete table
    SQL> UPDATE nad_als_fixed_stn_10G_HQ C SET C.insidecheck = '1'
    2 WHERE EXISTS (SELECT 1 FROM MetroRegions A, nad_als_fixed_stn_10G_HQ B
    3 WHERE SDO_RELATE(B.location83r, A.geoloc, 'mask=anyinteract') = 'TRUE'
    4 AND C.lic_no = B.lic_no );
    48488 rows updated.
    -- This particular record which was located correctly earlier appears to be skipped
    SQL> select insidecheck from nad_als_fixed_stn_10G_HQ where lic_no = 4687161;
    Inside
    check
    SQL>
    François Sigouin

    Thanks but it did not solve the problem of inconsistent results. The response time for the first update is much improved though. When I added the hint on the second update (which is about 600 records), it never came back so I tested without it. Any other ideas ?
    François.
    TEST
    SQL> update nad_als_fixed_stn_10G_HQ set insidecheck = null;
    231484 rows updated.
    -- First update with hint, response time is improved but same results obtained
    SQL> UPDATE nad_als_fixed_stn_10G_HQ C SET C.insidecheck = '1'
    2 WHERE EXISTS (SELECT /*+ ORDERED */ 1 FROM MetroRegions A, nad_als_fixed_stn_10G_HQ B
    3 WHERE SDO_RELATE(B.location83r, A.geoloc, 'mask=anyinteract') = 'TRUE'
    4 AND C.lic_no = B.lic_no );
    48488 rows updated.
    SQL> select insidecheck from nad_als_fixed_stn_10G_HQ where lic_no = 4687161;
    Inside
    check
    SQL> update nad_als_fixed_stn_10G_HQ set insidecheck = null;
    231484 rows updated.
    --The second update has to be without the hint otherwise it does not come back.                                                                                                  
    SQL> UPDATE nad_als_fixed_stn_10G_HQ C SET C.insidecheck = '1'
    2 WHERE EXISTS (SELECT 1 FROM MetroRegions A, nad_als_fixed_stn_10G_HQ B
    3 WHERE SDO_RELATE(B.location83r, A.geoloc, 'mask=anyinteract') = 'TRUE'
    4 AND C.lic_no = B.lic_no and C.lic_no between 4687157 and 4687223 )
    5 ;
    3 rows updated.
    SQL> select insidecheck from nad_als_fixed_stn_10G_HQ where lic_no = 4687161;
    Inside
    check
    1

  • Inconsistent results with localtimestamp and current_timestamp

    Running XE on Windows XP with the system timezone to GMT rebooted, restarted XE)
    Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
    PL/SQL Release 10.2.0.1.0 - Production
    CORE     10.2.0.1.0     Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    I'm getting incorrect and inconsistent results with current_timestamp and localtimestamp:
    With SQL, localtimestamp computes the wrong offset (appears to use 1987-2006 DST rules):
    select
    dbtimezone
    , sessiontimezone
    , current_timestamp
    , current_timestamp + numtodsinterval(18,'day') as current_timestamp18
    , localtimestamp
    from dual;
    +00:00     
    US/Eastern     
    17-MAR-10 10.27.17.376000000 AM US/EASTERN     
    04-APR-10 10.27.17.376000000 AM US/EASTERN     
    17-MAR-10 09.27.17.376000000 AM
    however, in PL/SQL, both current_timestamp and localtimestamp return the wrong hour value, and adding 18 to current_timestamp shows it is using 1987-2006 DST rules (1st sunday of april)/ note that this happens in straight PL/SQL and in embedded SQL (same results selecting from tables other than DUAL):
    begin
    for r1 in (
    select
    dbtimezone
    , sessiontimezone
    , current_timestamp
    , current_timestamp + numtodsinterval(18,'day') as current_timestamp18
    , localtimestamp
    from dual
    loop
    dbms_output.put_line('SQL dbtimezone = ' || r1.dbtimezone);
    dbms_output.put_line('SQL sessiontimezone = ' || r1.sessiontimezone);
    dbms_output.put_line('SQL current_timestamp = ' || r1.current_timestamp);
    dbms_output.put_line('SQL current_timestamp +18 = ' || r1.current_timestamp18);
    dbms_output.put_line('SQL localtimestamp = ' || r1.localtimestamp);
    end loop;
    dbms_output.put_line('dbtimezone = ' || dbtimezone);
    dbms_output.put_line('sessiontimezone = ' || sessiontimezone);
    dbms_output.put_line('systimestamp = ' || systimestamp);
    dbms_output.put_line('current_timestamp = ' || current_timestamp);
    dbms_output.put_line('current_timestamp +18 = ' || (current_timestamp + numtodsinterval(18,'day')));
    dbms_output.put_line('localtimestamp = ' || localtimestamp);
    end;
    SQL dbtimezone = +00:00
    SQL sessiontimezone = US/Eastern
    SQL current_timestamp = 17-MAR-10 09.29.32.784000 AM US/EASTERN
    SQL current_timestamp +18 = 04-APR-10 10.29.32.784000000 AM US/EASTERN
    SQL localtimestamp = 17-MAR-10 09.29.32.784000 AM
    dbtimezone = +00:00
    sessiontimezone = US/Eastern
    systimestamp = 17-MAR-10 02.29.32.784000000 PM +00:00
    current_timestamp = 17-MAR-10 09.29.32.784000000 AM US/EASTERN
    current_timestamp +18 = 04-APR-10 10.29.32.784000000 AM US/EASTERN
    localtimestamp = 17-MAR-10 09.29.32.784000000 AM
    dbtimezone = +00:00
    sessiontimezone = US/Eastern
    systimestamp = 17-MAR-10 02.16.21.366000000 PM +00:00
    current_timestamp = 17-MAR-10 09.16.21.366000000 AM US/EASTERN
    current_timestamp +18 = 04-APR-10 10.16.21.366000000 AM US/EASTERN
    localtimestamp = 17-MAR-10 09.16.21.366000000 AM
    is this a known bug?
    is there a patch or a work-around for XE?
    are other datasbase versions affected?

    Can't patch XE, unfortunately it comes with pre-2007 DST rules.
    There is a metalink note describing how to fix the DST changes, and while it's not really a "supported" method, neither is XE- if you can get updated timezone files from a later patch set for the same release, 10gR2, on the right operating system, shutdown/startup the database the updated DST rules will be in place. The timezone files are in $ORACLE_HOME/oracore/zoneinfo.
    Another unfortunately, any values already stored in the database using timestamp with local timezone datatypes for the affected period of the DST changes won't be correct, i.e. there is no 2010-03-14 02:01 (?) but with older timezone rules in place that would be a valid timestamp. The data has to be saved before updating the timezone file, and re-translated to timestamp w/local tz datatypes after the update.
    IMHO storing literal timezone info isn't an ideal practice, let the client settings do the time interpretation, time is always changing. Its the interpretation of the time that gets changed. From time to time. :(

  • Tuning : Inconsistent result between Explain plan VS Execution Time

    Dear Experts,
    Need your suggestions belongs to contrary result between Explain plan VS Execution Time
    Environment :_
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
    PL/SQL Release 10.2.0.4.0 - Production
    CORE     10.2.0.4.0     Production
    TNS for Linux: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    Red Hat Enterprise Linux 5.4
    There's same query but : 1st query access Loan_Account, 2nd query access Loan_Account_Han
    *1st.*
    Query Access Via : Loan_account (Partition Type : Hash (5) with column Contract_Number)
    Explain Plan : cost: 4,432, bytes: 716, cardinality: 2
    Execution Time : 13 seconds
    *2nd.*
    Query Access Via : Loan_Account_Han (Partition Type : List(5) with column Loan_Status)
    Explain Plan : cost:188,447 bytes: 1,661,088, cardinality: 4,719
    Execution Time : 10 seconds
    Note :_
    all tables and all indexes belong to the table which included in query has been analyzed.
    my question :
    1. why it could become like this ? I even confusing with Jonathan Lewis Theory : Cost-Based Fundamental Book.
    with this result, I even not believed with the result from Explain Plan anymore.
    2. If analyze tables and indexes to update statistics which help CBO to choose the best path as part of Daily Performance Tuning,
    is there a way that could do in enviroment 24x7 ?
    Note : if original query is needed, I'll posting it here.
    Any help is very appreciated and thanks very much.
    Regards,
    Sigcle

    The DBMS_XPLAN.DISPLAY_CURSOR output
    Query no 1
    PLAN_TABLE_OUTPUT
    SQL_ID  bq7avs72xvmkv, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 4011856754
    | Id  | Operation                                  | Name                           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   1 |  TABLE ACCESS BY INDEX ROWID               | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |       9 |      2 |       |       |          |
    |*  2 |   INDEX SKIP SCAN                          | UNQ_COLLECTIBILITY_CODE        |      3 |      1 |      3 |00:00:00.01 |       6 |      1 |       |       |          |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    501 |      1 |    501 |00:00:00.03 |    2004 |    796 |       |       |          |
    |*  4 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    501 |      1 |    501 |00:00:00.02 |    1503 |    377 |       |       |          |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.10 |    3220 |   1074 |       |       |          |
    |*  6 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.09 |    2887 |   1074 |       |       |          |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.05 |    1464 |    495 |       |       |          |
    |*  8 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.05 |    1297 |    495 |       |       |          |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 10 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 12 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 14 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 16 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID        | MF_SCH_INSTALLMENT             |    333 |      1 |    333 |00:00:00.06 |    3167 |      0 |       |       |          |
    |* 18 |   INDEX UNIQUE SCAN                        | UNQ_MF_SCH_INSTALLMENT1        |    333 |      1 |    333 |00:00:00.06 |    2834 |      0 |       |       |          |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID       | CUST_SCH_INSTALLMENT           |    168 |      1 |    167 |00:00:00.03 |    1447 |      0 |       |       |          |
    |* 20 |    INDEX UNIQUE SCAN                       | UNQ_CUST_SCH_INSTALLMENT1      |    168 |      1 |    167 |00:00:00.03 |    1280 |      0 |       |       |          |
    |* 21 |  TABLE ACCESS FULL                         | COLLECTIBILITY_CODE            |      3 |      1 |      3 |00:00:00.01 |      12 |      1 |       |       |          |
    |  22 |  NESTED LOOPS OUTER                        |                                |      1 |      2 |    501 |00:00:01.02 |   96112 |  20091 |       |       |          |
    |  23 |   NESTED LOOPS                             |                                |      1 |      2 |    501 |00:00:00.28 |   13445 |   5358 |       |       |          |
    |  24 |    NESTED LOOPS                            |                                |      1 |      2 |    501 |00:00:00.26 |   11441 |   5071 |       |       |          |
    |  25 |     NESTED LOOPS OUTER                     |                                |      1 |      2 |    501 |00:00:00.24 |    9433 |   5014 |       |       |          |
    |* 26 |      HASH JOIN                             |                                |      1 |      2 |    501 |00:00:00.03 |     329 |    325 |  1206K|  1206K|  341K (0)|
    |* 27 |       TABLE ACCESS FULL                    | CURRENCY                       |      1 |      1 |      1 |00:00:00.01 |       3 |      2 |       |       |          |
    |* 28 |       HASH JOIN                            |                                |      1 |     61 |    501 |00:00:00.02 |     326 |    323 |   868K|   868K|  947K (0)|
    |* 29 |        HASH JOIN                           |                                |      1 |     10 |     13 |00:00:00.01 |       7 |      6 |   947K|   947K| 1030K (0)|
    |  30 |         TABLE ACCESS BY INDEX ROWID        | MULTIFINANCE                   |      1 |      5 |      9 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 31 |          INDEX RANGE SCAN                  | IDX_STATUS_MF                  |      1 |      5 |      9 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 32 |         TABLE ACCESS FULL                  | AGREEMENT                      |      1 |     18 |     13 |00:00:00.01 |       5 |      4 |       |       |          |
    |  33 |        VIEW                                |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |       |       |          |
    |* 34 |         HASH JOIN RIGHT OUTER              |                                |      1 |    110 |    501 |00:00:00.02 |     319 |    317 |  1011K|  1011K|  317K (0)|
    |  35 |          TABLE ACCESS BY INDEX ROWID       | TENANT_PARAMETER               |      1 |      1 |      1 |00:00:00.01 |       2 |      2 |       |       |          |
    |* 36 |           INDEX UNIQUE SCAN                | PK_TENANT_PARAMETER            |      1 |      1 |      1 |00:00:00.01 |       1 |      1 |       |       |          |
    |* 37 |          TABLE ACCESS BY GLOBAL INDEX ROWID| LOAN_ACCOUNT                   |      1 |    110 |    501 |00:00:00.02 |     317 |    315 |       |       |          |
    |* 38 |           INDEX RANGE SCAN                 | IDX_STATUS_LA1                 |      1 |   4394 |   3025 |00:00:00.01 |      15 |     14 |       |       |          |
    |* 39 |      TABLE ACCESS BY INDEX ROWID           | TX_PAYMENT                     |    501 |      1 |      0 |00:00:00.16 |    9104 |   4689 |       |       |          |
    |* 40 |       INDEX RANGE SCAN                     | FK_TX_PAY_LOAN_ACCT            |    501 |     12 |   8799 |00:00:00.02 |    1038 |    207 |       |       |          |
    |  41 |     TABLE ACCESS BY INDEX ROWID            | DL_CL_OUTSTANDING              |    501 |      1 |    501 |00:00:00.02 |    2008 |     57 |       |       |          |
    |* 42 |      INDEX RANGE SCAN                      | IDXLO_CNUM                     |    501 |      1 |    501 |00:00:00.01 |    1507 |     37 |       |       |          |
    |* 43 |    TABLE ACCESS BY INDEX ROWID             | MF_CUSTOMER                    |    501 |      1 |    501 |00:00:00.02 |    2004 |    287 |       |       |          |
    |* 44 |     INDEX UNIQUE SCAN                      | MF_CUSTOMER_PK                 |    501 |      1 |    501 |00:00:00.01 |    1503 |     24 |       |       |          |
    |* 45 |   TABLE ACCESS BY INDEX ROWID              | TX_INTEREST_ACCRUE             |    501 |      1 |      0 |00:00:00.73 |   82667 |  14733 |       |       |          |
    |* 46 |    INDEX RANGE SCAN                        | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    501 |     67 |  40581 |00:00:00.14 |   42084 |    451 |       |       |          |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      27 - filter(UPPER("CURR"."STATUS")='A')
      28 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      29 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      31 - access("MF"."SYS_NC00052$"='A')
      32 - filter(UPPER("A"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID")
      36 - access("TENANT_PARAMETER_ID"=23)
      37 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR ("LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  UPPER("LA"."LOAN_STATUS")='CN')))
      38 - access("LA"."SYS_NC00118$"='A')
      39 - filter(("TP"."APPROVAL_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"=152 AND UPPER("TP"."APPROVAL_STATUS")='A'))
      40 - access("TP"."LOAN_ACCOUNT_ID"="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      42 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      43 - filter(UPPER("MC"."STATUS")='A')
      44 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")
      45 - filter("IA"."ACCRUE_DATE"="XX"."PREV_DATE")
      46 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID")
    The DBMS_XPLAN.DISPLAY_CURSOR output after : alter system flush buffer_cache; alter system flush shared_pool;
    Query no 2
    PLAN_TABLE_OUTPUT
    SQL_ID  cxmg4jfvr9pz0, child number 0
    SELECT /*+ gather_plan_statistics */ la.office_code, la.currency_code AS currency, mf.NAME multifinance_id,        la.contract_number, mc.customer_name,       
    dco.os_principal_on_schedule AS os_principal_on_schedule,        f_get_param_value (la.financing_type,                           'FinancingType'                  
           ) AS financing_type,        CASE la.financing_type           WHEN 11                    -- Asset Purchase              THEN NVL (tp.os_principal_cust,     
                      la.os_principal_cust                       )           WHEN 12                                            -- JF Channelling              THEN
    NVL (tp.os_principal_mf, la.os_principal)        END AS os_principal_actual,        CASE           WHEN dco.bi_collectibility_with_gp >= 3              THEN 0    
          ELSE CASE           WHEN la.financing_type = '12'              THEN   NVL (ia.accrue_interest_pl, 0)                   + NVL (ia.accrue_interest_npl, 0)    
          ELSE   NVL (ia.accrue_
    Plan hash value: 2072372033
    | Id  | Operation                            | Name                           | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                     |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |   1 |  TABLE ACCESS BY INDEX ROWID         | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |*  2 |   INDEX SKIP SCAN                    | UNQ_COLLECTIBILITY_CODE        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   3 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  4 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   5 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  6 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   7 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |*  8 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |   9 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 10 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  11 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    15 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 12 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  13 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 14 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  15 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 16 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  17 |  TABLE ACCESS BY GLOBAL INDEX ROWID  | MF_SCH_INSTALLMENT             |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 18 |   INDEX UNIQUE SCAN                  | UNQ_MF_SCH_INSTALLMENT1        |     1 |       |     2   (0)| 00:00:01 |       |       |
    |  19 |   TABLE ACCESS BY GLOBAL INDEX ROWID | CUST_SCH_INSTALLMENT           |     1 |    17 |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 20 |    INDEX UNIQUE SCAN                 | UNQ_CUST_SCH_INSTALLMENT1      |     1 |       |     2   (0)| 00:00:01 |       |       |
    |* 21 |  TABLE ACCESS FULL                   | COLLECTIBILITY_CODE            |     1 |    12 |     3   (0)| 00:00:01 |       |       |
    |  22 |  NESTED LOOPS                        |                                |  4719 |  1622K|   188K (32)| 00:37:42 |       |       |
    |  23 |   NESTED LOOPS                       |                                |  4719 |  1460K|   183K (33)| 00:36:45 |       |       |
    |  24 |    NESTED LOOPS OUTER                |                                |  4719 |  1354K|   180K (33)| 00:36:07 |       |       |
    |  25 |     NESTED LOOPS OUTER               |                                |  4719 |  1225K|   130K (46)| 00:26:01 |       |       |
    |* 26 |      HASH JOIN                       |                                |  4719 |  1106K| 23591   (2)| 00:04:44 |       |       |
    |  27 |       TABLE ACCESS BY INDEX ROWID    | MULTIFINANCE                   |     5 |   130 |     2   (0)| 00:00:01 |       |       |
    |* 28 |        INDEX RANGE SCAN              | IDX_STATUS_MF                  |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 29 |       HASH JOIN                      |                                |  8494 |  1775K| 23589   (2)| 00:04:44 |       |       |
    |* 30 |        TABLE ACCESS FULL             | AGREEMENT                      |    18 |   360 |     3   (0)| 00:00:01 |       |       |
    |* 31 |        HASH JOIN                     |                                |  8494 |  1609K| 23585   (2)| 00:04:44 |       |       |
    |* 32 |         TABLE ACCESS FULL            | CURRENCY                       |     1 |     4 |     3   (0)| 00:00:01 |       |       |
    |  33 |         VIEW                         |                                |   212K|    38M| 23579   (2)| 00:04:43 |       |       |
    |* 34 |          HASH JOIN RIGHT OUTER       |                                |   212K|    32M| 23579   (2)| 00:04:43 |       |       |
    |  35 |           TABLE ACCESS BY INDEX ROWID| TENANT_PARAMETER               |     1 |    74 |     1   (0)| 00:00:01 |       |       |
    |* 36 |            INDEX UNIQUE SCAN         | PK_TENANT_PARAMETER            |     1 |       |     0   (0)| 00:00:01 |       |       |
    |  37 |           PARTITION LIST ALL         |                                |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |* 38 |            TABLE ACCESS FULL         | LOAN_ACCOUNT_HAN               |   212K|    17M| 23575   (2)| 00:04:43 |     1 |     5 |
    |  39 |      TABLE ACCESS BY INDEX ROWID     | TX_INTEREST_ACCRUE             |     1 |    26 |   130K (46)| 00:26:01 |       |       |
    |  40 |       BITMAP CONVERSION TO ROWIDS    |                                |       |       |            |          |       |       |
    |  41 |        BITMAP AND                    |                                |       |       |            |          |       |       |
    |  42 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 43 |          INDEX RANGE SCAN            | FK_TX_INTEREST_ACCRUE_LOAN_ACC |    67 |       |     0   (0)| 00:00:01 |       |       |
    |  44 |         BITMAP CONVERSION FROM ROWIDS|                                |       |       |            |          |       |       |
    |* 45 |          INDEX RANGE SCAN            | IDX_TX_INTEREST_ACCRUE         |    67 |       |    12 (100)| 00:00:01 |       |       |
    |* 46 |     TABLE ACCESS BY INDEX ROWID      | TX_PAYMENT                     |     1 |    28 |    11   (0)| 00:00:01 |       |       |
    |* 47 |      INDEX RANGE SCAN                | FK_TX_PAY_LOAN_ACCT            |    12 |       |     0   (0)| 00:00:01 |       |       |
    |  48 |    TABLE ACCESS BY INDEX ROWID       | DL_CL_OUTSTANDING              |     1 |    23 |     1   (0)| 00:00:01 |       |       |
    |* 49 |     INDEX RANGE SCAN                 | IDXLO_CNUM                     |     1 |       |     0   (0)| 00:00:01 |       |       |
    |* 50 |   TABLE ACCESS BY INDEX ROWID        | MF_CUSTOMER                    |     1 |    35 |     1   (0)| 00:00:01 |       |       |
    |* 51 |    INDEX UNIQUE SCAN                 | MF_CUSTOMER_PK                 |     1 |       |     0   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
       2 - access("XX"."COLLECTIBILITY_CODE"=:B1)
           filter("XX"."COLLECTIBILITY_CODE"=:B1)
       4 - access("LOAN_ACCOUNT_ID"=:B1 AND "INSTALLMENT_NUMBER"=1)
       6 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
       8 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      10 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      12 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      14 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      16 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      18 - access("MFSCH"."LOAN_ACCOUNT_ID"=:B1 AND "MFSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      20 - access("CUSTSCH"."LOAN_ACCOUNT_ID"=:B1 AND "CUSTSCH"."INSTALLMENT_NUMBER"="F_NEXT_INSTALLMENT_NUMBER"(:B2,TO_DATE('
                  2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss'),:B3))
      21 - filter(TO_NUMBER("COL"."COLLECTIBILITY_CODE")=:B1)
      26 - access("A"."MULTIFINANCE_ID"="MF"."MULTIFINANCE_ID")
      28 - access(UPPER("STATUS")='A')
      29 - access("from$_subquery$_016"."AGREEMENT_ID"="A"."AGREEMENT_ID")
      30 - filter(UPPER("A"."STATUS")='A')
      31 - access("from$_subquery$_016"."CURRENCY_CODE"="CURR"."CURRENCY_CODE")
      32 - filter(UPPER("CURR"."STATUS")='A')
      34 - access("LA"."TENANT_ID"="TENANT_ID"(+))
      36 - access("TENANT_PARAMETER_ID"(+)=23)
      38 - filter((UPPER("LA"."LOAN_STATUS")='AC' OR "LA"."CLOSED_DATE"=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                  AND UPPER("LA"."LOAN_STATUS")='CN') AND UPPER("LA"."STATUS")='A')
      43 - access("LA"."LOAN_ACCOUNT_ID"="IA"."LOAN_ACCOUNT_ID"(+))
      45 - access("IA"."ACCRUE_DATE"(+)="XX"."PREV_DATE")
      46 - filter("TP"."APPROVAL_DATE"(+)=TO_DATE(' 2013-02-18 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "TP"."DATA_SOURCE"(+)=152
                  AND UPPER("TP"."APPROVAL_STATUS"(+))='A')
      47 - access("TP"."LOAN_ACCOUNT_ID"(+)="from$_subquery$_016"."LOAN_ACCOUNT_ID")
      49 - access("DCO"."LOAN_CONTRACT_NUMBER"="from$_subquery$_016"."CONTRACT_NUMBER")
      50 - filter(UPPER("MC"."STATUS")='A')
      51 - access("from$_subquery$_016"."MF_CUSTOMER_ID"="MC"."MF_CUSTOMER_ID")Typically both query running on 10-12 seconds (or same execution time).
    And I can't provide autotrace and tkprof output cause I cannot access via sqlplus.
    Thanks very much for the link HOW TO: Post a SQL statement tuning request - template posting
    Regards,
    Sigcle
    Edited by: SigCle on Feb 25, 2013 4:22 AM

  • Confusing result between 'to_date' and 'long to date' in oracle query

    I have a table called "subscription" as below.
    desc subscription;
    Name Null Type
    SUBSCRIPTION_ID NOT NULL NUMBER(38)
    EXPIRATIONDATE DATE
    And output of a query as below.
    select subscription_id,expirationdate from subscription where subscription_id = 41919;
    SUBSCRIPTION_ID EXPIRATIONDATE
    41919 18-JAN-14 13:45:56
    And I am trying to execute following query in different ways.
    1st Query:
    select s.subscription_id from subscription$active s where s.expirationdate - (116/24) between TO_DATE('13-JAN-14 11:38:22', 'dd/mm/yyyy hh24:mi:ss') and TO_DATE('13-JAN-14 18:30:00', 'dd/mm/yyyy hh24:mi:ss') and s.subscription_id=41919
    Output:
    SUBSCRIPTION_ID
    41919
    2nd Query:
    select s.subscription_id from subscription$active s where s.expirationdate - (116/24) between (trunc(1389613102220 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy') and (trunc(1389637800000 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy') and s.subscription_id=41919
    Output:
    SUBSCRIPTION_ID
    Here both the above where clause are same. 1st one is trying to use "to_date" and 2nd one converts "long to date". But when I see the out put, the first one returns a row and 2nd doesnot return any result. I couldn't find out what is difference the 'long to date' conversion makes here.
    The conversion between long to date is also correct.
    select (trunc(1389613102220 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy') from dual
    Output:
    (TRUNC(1389613102220/(1000),0)/(24*60*60))+TO_DATE('01/01/1970','MM/DD/YYYY') -------------------------
    13-JAN-14 11:38:22
    And
    select (trunc(1389637800000 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy') from dual
    Output:
    (TRUNC(1389637800000/(1000),0)/(24*60*60))+TO_DATE('01/01/1970','MM/DD/YYYY') -------------------------
    13-JAN-14 18:30:00
    Can someone help me to understand the difference between the 1st and 2nd query ?

    Hi,
    Not sure what exactly you asking for. What is the requirement?
    Just formatted for better readability:
    -->-- Query 1
    SELECT
      s.subscription_id
    FROM subscription$active s
    WHERE
      s.expirationdate - (116/24) BETWEEN
           to_date('13-JAN-14 11:38:22', 'dd/mm/yyyy hh24:mi:ss')
           AND
           to_date('13-JAN-14 18:30:00', 'dd/mm/yyyy hh24:mi:ss')
      AND s.subscription_id=41919;
    -->-- Query 2
    SELECT
      s.subscription_id
    FROM subscription$active s
    WHERE
      s.expirationdate - (116/24) BETWEEN
           (trunc(1389613102220 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy')
           AND
           (trunc(1389637800000 / (1000), 0) / (24 * 60 * 60)) + to_date('01/01/1970','mm/dd/yyyy')
      AND s.subscription_id=41919;

  • Export to text procuding different results between SDK and Report Viewer.

    We have a 3rd party app that uses Report Viewer v2.5.991 to generate reports. We use the export to text feature and specify 60 lines per page. This produces a report with 60 detail lines and a footer that comes after the sixty for a total of 64 lines per page.
    I am a .NET developer and am using the CrystalDecisions SDK version 13.0.2000.0. I am using the same rpt file and automatically generating the text export using C# .NET. I am specifying TextFormatOptions LinesPerPage of 60. This is producing 60 lines total including the footer.
    Is there an option I am missing in my code to produce the desired results?

    No such thing as Report Viewer v2.5.991. Not as far as I know anyhow...
    Looking at the description of the TextFormatOptions property in the SAP Crystal Reports .NET API Guide:
    Gets or Sets the number of lines per page to use when you export to text.
    So, it looks to me like the property is behaving as expected. E.g.; it is the 3rd party that does something to get 64 lines per page. Perhaps setting the property to 64 will do the trick?
    - Ludek
    Senior Support Engineer AGS Product Support, Global Support Center Canada
    Follow us on Twitter

  • Inconsistent results from AlphaComposite and AffineTransform

    I'm developing a game using Java, and I've run into a fairly major issue. On my primary development machine, I can use combinations of AlphaComposite.SRC_IN and AffineTransforms with rotation just fine (I'm using the composite to create a lighting overlay for the game by drawing light beams onto the alpha channel of an all-black image buffer). On my other computer, while the image itself rotates and draws on the alpha channel fine, the computer also completely clears a bounding rectangle around the rotated image.
    The first computer (the one for which this works) has a GeForce 8800GTS video card, while the second has an older Radeon 9700. The first computer also has the most recent version of the JDK (6). Could either of these factors make the difference?
    edit: Upgrading to JDK 6 fixed it. Will need to include a notice about upgrading to JDK 6 with the game, probably.
    Message was edited by:
    Hyouko

    Hi
    Yes I have a debug line that prints them out in the doAutoLoadBalancing method - this is the point where I am diagnosing the problem. It only prints the correct results after I have already run the procedure from the SQL command line.
    public UserNumber[] doAutoLoadBalancing () throws SQLException {
    autoLBNumbersNeeded.clearParameters();
    autoLBNumbersNeeded.execute();
    mwFF = autoLBNumbersNeeded.getLong(1);
    mwHF = autoLBNumbersNeeded.getLong(2);
    wmFF = autoLBNumbersNeeded.getLong(3);
    wmHF = autoLBNumbersNeeded.getLong(4);
    autoLBNumbersNeeded.clearParameters();
    if (m_cat.isDebugEnabled()) {m_cat.debug("mwFF: "+mwFF+"; mwHF: " +mwHF+"; wmFF: "+wmFF+"; wmHF: "+wmHF);}
    </pre>

  • Print Problem: inconsistent density between sizes and Lightroom/Photoshop

    In the past I printed using only Photoshop. I recently made a batch of prints from Lightroom, using the same paper, printer profile, rendering intent, and noticed that the output does not match the output from Photoshop. The Lightroom prints have noticeably more density. I then noticed that large Lightroom prints, for example 16 x 24, have noticeably more density than smaller size Lightroom 6 inch x 9 inch prints. I find no difference in print density when printing from Photoshop regardless of the print size. I can not determine why I am experiencing these variations in print output.
    All prints are made using an Epson 7900 on Museo Portfolio Rag, same ICC profiles, same exact setup in the Epson printer driver (off no color adjustment), PS: PS manage color and same icc profile specified in both  Lightroom and Photoshop. The computer is a Windows 7 machine.
    Has any one else experienced these problems? My first thought is that this is some sort of bug in Lightroom's color management. But if that was true, then it seems like a lot of people would be having this problem. I have been using a color managed workflow for a number of years and have gotten very satisfactory results. My prints are a close match to the soft proof in Photoshop. Since printing from Lightroom the prints do not match prints made from Photoshop, plus the prints made by Lightroom vary in density depending on the size. Bizarre.
    Please help

    Solved. Somehow the custom media setting for the Museo Portfolio Rag paper was lost when I set up the LR template. The custom media setting reduced the color density by -20 in the Epson Printer driver. With out this setting the color density was at the default zero and the density was greater.
    This brings up another question that I will have to explore. I arrived at the -20 color density setting when testing various Epson Driver media settings for the 7900 prior to profiling this paper after Epson replaced the nozzle heads on my 7900 printer. I found at the default zero color density I encountered banding. Prior to the replacement of the nozzle heads the default zero color density worked fine and there was no banding. Interestingly, on the 16 x 32 print that mistakenly used the zero color density setting there was no banding. Now I want to go back and redo my media tests. Is it possible that the new print heads needed a breaking in period and that is why I encountered banding on both the Museo Portfolio Rag and the Epson mat paper?

  • Inconsistant Security Between EAS and App Man

    Has anybody seen differences between what App manager and EAS show for security information. In App Mangager I have Supervisor rights explicitly, not through a group. EAS lists me as a user with no rights to anything when I look at the same server. I also found that if I click on some Groups and select the user tab there are no users in the list to add to the group. I have 500 users under the user list. I also don't get any groups to add when I try to add a user to a group by editing the properties of the user.

    What version of EAS are you o get then?I am currently using 6.5.0 and 6.5.1 and I do not have any issues like you descibe.You described the user having Supervisor access, are you loging into EAS as that person and getting no lists of users etc. If you login as the Essbase Admin, (id from the original instal) do you get the same response?Regards,Corey BidmeadClarity Systems

  • Inconsistent entries between driver_aliases and path_to_inst

    Hi,
    I see the following in my solaris intel box.
    bash-2.03# grep iprb /etc/driver_aliases
    iprb "pci8086,1229"
    iprb "pci8086,1029"
    bash-2.03# grep iprb /etc/path_to_inst
    "/pci@0,0/pci8086,100c@6" 0 "iprb"
    bash-2.03#
    100c is the inte pro/1000 gig NIC and 1229/1029 are pro/100 fast ethernet NICs.
    The following are my questions:
    1. How can iprb bind to 100c when the aliases do not exist for it?
    2. The iprb is actually binding to the pro/100 NIC(I know this since I can ssh into the box etc, pro1000 card has no connectivity). Does this mean the what ever is in path_to_inst cannot be trusted?
    3. After solaris boots, how do we know what NIC is bound to which driver(assuming a case when we different NICs managed by different drivers.)
    4. What the contention resolution algorithm for driver binding. In other words what does solaris do when more then one driver says it can manage a particular device.
    any help is greatly appreciated,
    Vijay
    ps: BTW, everytime I reboot I do a reconfiguration reboot so that path_to_inst gets updated.

    Here's the long and short of it...
    entries like this in the lpfc.conf file:
    fcp-bind-WWPN="50060482ccb4bbbb:lpfc3t6",
    "50060482ccb4bccc:lpfc5t7",
    "50060482ccb4bddd:lpfc8t9",
    "5006048accb4beee:lpfc9t10",
    "5006048accb4bfff:lpfc10t25",
    "5006048accb4bggg:lpfc11t24",
    "50060482ccb4bhhh:lpfc15t8",
    "50060482ccb4biii:lpfc16t12",
    "5006048accb4bjjj:lpfc20t38",
    "5006048accb4bkkk:lpfc21t13",
    "5006048accb4bmmm:lpfc22t40",
    [snip]
    "5006048accb4bnnn:lpfc25t23";
    and these in the sd.conf file:
    # Start of SD.CONF Entries for DMX
    name="sd" parent="lpfc" target=6 lun=16;
    name="sd" parent="lpfc" target=6 lun=17;
    name="sd" parent="lpfc" target=6 lun=18;
    name="sd" parent="lpfc" target=6 lun=19;
    name="sd" parent="lpfc" target=6 lun=20;
    name="sd" parent="lpfc" target=7 lun=68;
    name="sd" parent="lpfc" target=7 lun=69;
    name="sd" parent="lpfc" target=7 lun=70;
    name="sd" parent="lpfc" target=7 lun=71;
    name="sd" parent="lpfc" target=7 lun=72;
    [snip]
    name="sd" parent="lpfc" target=9 lun=133;
    name="sd" parent="lpfc" target=9 lun=134;
    name="sd" parent="lpfc" target=9 lun=135;
    name="sd" parent="lpfc" target=9 lun=136;
    will create /etc/path_to_inst entries for each LUN, for each TARGET, for each LPFC instance. Normally it's not a problem. In my case I have 44 Emulex LPFC instances, a TON of targets (an average of 1.5 per FA<->HBA mappings) and a TON of LUNS.
    # of HBA(lpfc) x total # of Lun ((sum of lpfc lun/target) + sum of scsi lun/target)) ~ 32,767
    Anyway, by using the hba="..." format in the sd.conf file, we were able to eliminate all of the extra /etc/path_to_inst entries created. This reduced the "sd" entries in /etc/path_to_inst to just over 3,000. Example
    name="sd" parent="lpfc" target=33 hba="lpfc17" lun=123;
    If the instance numbers on my HBA's ever change, I'm in trouble. Of course, this could have been avoided with the latest lpfc driver, or by using leadvill because they don't require entries in sd.conf.
    Thanks to all who assisted.

  • Different results between DD03L and the same structure in transaction SE11

    Hi Experts,
    I created a 'Z' structure and when I see this structure using trx se11 are displayed 10 fields but when I see this same structure through the table DD03L are displayed 15 fields.
    I created again 2 of 5 fields that were missing and the register was duplicated for that field in the table DD03L .
    Someone already see anything like this??
    Best regards and thanks in advance.
    Caíque Escaler

    hi check this...
    dd03l is for the tables and i didnt think for the structures..and give  the structure name  in the DATA TYPE it will show the structure you had created ..see the header text for the dd03l and u will get  what it is exactly
    se11->data type  zstructure->f7(display)..
    regards,
    venkat

Maybe you are looking for

  • Adobe Reader for Windows Phone cannot open older PDF versions?

    I've found that Adobe Reader for Windows Phone displays the following error when I try to open certain PDF documents: "There was an error opening the document". After doing some limited testing I found that it can successfully open PDF documents whic

  • Year Transfer

    Happy New Year ! I am using SAP 2005A Patch level 29 and I have successfully done a transfer using the Year transfer on UK localizations. I got an error on the balances transfer section though but I didn't get deep into the cause of the error, all ot

  • List of SQL tables and attributes used in SSRS reports

    Hi, I have around 450-500 reports deployed in SSRS reporting server. All these reports are built on SQL from multiple databases, and these databases are having unnecessary tables and attributes. My requirement is to clean the unused tables and attrib

  • How to add  new column in VA02?

    I want to add a new column before the column posnr in VA02/VA03 which will be non editable.

  • Applet viewer / mozills / netscape6 hang from time to time

    hi list! we are using a 3 tier setup (db <--> forms server <--> client with appletviewer) the database server runs on solaris, the forms server and the clients are running debian stable (woody) (clients use j2sdk1.3) the forms server is version 9.2.