Difference in results of queries on same data

Hi all
I have two tables, FURNITURE which contains transactions information of the customers who come for shoping to a store. IDNO column in the table shows ID of the customer, RECEIPTNO shows the receipt number of the customer. Each single visit will depict a single visit by any customer. D_CUSTOMER table contains customers information and demographics information. A single customer IDNO may have multiple entries in D_CUSTOMER table because a single customer may have multiple membership cards and hence multiple entries in D_CUSTOMER table.
Now I want to know unique customers show did shoping during a time period and also their number of visits. So I am using following query to do this.
select  COUNT(DISTINCT IDNO) AS UNIQ, COUNT(distinct RECEIPTNO) AS VISIT
from FURNITURE
where trandate_period_skey between 946 and 1126
UNIQ         VISIT
148269       265907
Here we see that there are total 148269 distinct customer who visited total 265907 times for shoping of furniture. Each distinct receiptno shows a single visit.
In my second query I simply involving D_CUSTOMER table to find out that how many visits were males and how many were females
select GENDER, COUNT(DISTINCT A.IDNO),COUNT(distinct RECEIPTNO) AS VISIT
from FURNITURE A,
(SELECT IDNO, MAX(GENDER) AS GENDER FROM D_CUSTOMER WHERE MEMBERTYPE = 'PA' GROUP BY IDNO) b
where TRANDATE_PERIOD_SKEY between 946 and 1126
and a.IDNO = b.IDNO
group by gender
GENDER     UNIQ    VISIT
F 103876 188573
M 44393 77357
Now here comes the problem. If we sum values under UNIQ column, total is 148269 (103876 Females and 44393 Males), which is same as the value in the result of first query. But, if we sum the values under VISIT column, 188573 visits by Females and 77357 visits by Males and total is 265930 which is different from the value of COUNT(DISTINCT RECEIPT) in first query because first query says total visits are 265907.
I can't understand why I am seeing this difference. In my second query, the sum of values under VISIT column should be 265907
Any one who can point out where are things going wrong and why there is difference in result?
Salman

Thanks rp0428. Actually first table already have data based on member with membertype='PA'.
Any way, I have got the solution. Actually I had same receipt number issued to two different customers, one make and one female and hence while grouping, this type of receipts were being counted for both genders and hence total was greater during grouping.
Case is closed.
Salman

Similar Messages

  • These two queries return same data?

    select * from voucher where (unit = 'TIA4M' or unit = 'TIAFM' or unit = 'TIAWM' or unit = 'TIATW' or unit = 'TIAPA' )
    and invoice_dt >= TO_DATE('01/01/2006', 'MM/DD/YYYY')
    select * from voucher where unit in ('TIA4M', 'TIAFM', 'TIAWM', 'TIATW', 'TIAPA')
    and invoice_dt >= TO_DATE('01/01/2007', 'MM/DD/YYYY')
    Also the first is much faster right?

    The first query is using a date of Jan 1, 2006. The second query is using a date of Jan 1, 2007.
    Assuming that is a typo, the two queries are semantically identical. Since Oracle can easily transform an IN-list to a series of OR's, though, I would doubt that there would be any performance difference between them absent the 2006/2007 change.
    Justin

  • Different results for the same query and same data !  (oracle 9i)

    Hi,
    This is a mystery for me. I've got on my database exactly the same data that my customer (exported schema). We both launch the same query (generated by the software that we sold him). This query has a criteria IN (SELECT MAX()...) to get only data from the last year.
    The query gives 477 rows on my computer (correct answer), but no row on his! We have the same data! The only difference is the Oracle release : 9.2.0.6.0 for him, 9.2.0.1.0 for me.
    If he executes the subquery alone, it gives the expected result.
    If he replaces the MAX() in the subquery by the returned value (year 2016), he gets his 477 rows.
    I've rewritten the query with a NOT EXISTS, and now all is fine. (Less efficient but it works).
    I have no rational explication. Did I miss something ?
    Thanks for any answer.
    This is the query:
    SELECT ...
    FROM
    CRA, GRA, ...
    WHERE
    /* subselect */
    (CRA.COLLCOD, CRA.CRANEXE, CRA.CRANCODBUD, CRA.GRANNUM, CRA.CRANCOD1, CRA.CRANCOD2, CRA.CRANCOD3, CRA.CRANCOD4)
    IN (
    SELECT b.COLLCOD, MAX(cranexe), b.CRANCODBUD, b.GRANNUM, b.CRANCOD1, b.CRANCOD2, b.CRANCOD3, b.CRANCOD4
    FROM CRA b
    GROUP BY b.COLLCOD, b.CRANCODBUD, b.GRANNUM, b.CRANCOD1, b.CRANCOD2, b.CRANCOD3, b.CRANCOD4
    AND... /* other filters and joins */

    v9.2.0.1 was full of bugs. a lot of these bugs had to do with "incorrect results", typically associated with old stats or complex queries (certain types of subqueries were very likely to give wrong resutls, due to the way they were rewritten by the optimizer).
    apply the 9.2.0.6 patch set

  • Query result shows the same data twice

    Hello All,
    I've created UDFs like Supplier Name, Supplier Address, and (Excise Details like)Supplier ECC No,
    Supplier Range.
    And I've created Query for Supplier Name and Supplier Address, and I assigned to FMS, Its working Correctly.
    I've created Query for Supplier ECC No. the Query is,
    SELECT  T0.[ECCNo],T1.[CardName]
    FROM CRD7 T0  INNER JOIN OCRD T1 ON T0.CardCode = T1.CardCode
    WHERE T0.[ECCNo]  Like  '[%]'
    I saved the Query, and assigned to FMS.
    At this stage (i.e. Query for Supplier ECC No.) the above Query showing the same data twice.
    Please suggest to rectify the problem.
    Thanks,
    Pratheeviraj

    You can get rid of the duplicates by changing the query to
    SELECT DISTINCT T0.ECCNo,T1.CardName
    FROM CRD7 T0 INNER JOIN OCRD T1 ON T0.CardCode = T1.CardCode
    WHERE T0.ECCNo Like '[%]'
    But it is always worth understanding why you are getting multiple records to check that you are getting back what you want.  I think you may be seeing this because CRD7 can have multiple records for a business partner - maybe one for each of 'pay-to' and 'ship-to' address?

  • CBO generating different plans for the same data in similar Environments

    Hi All
    I have been trying to compare an SQL from 2 different but similar environments build of the same hardware specs .The issue I am facing is environment A, the query executes in less than 2 minutes with plan mostly showing full table scans and hash join whereas in environment B(problematic), it times out after 2 hours with an error of unable to extend table space . The statistics are up to date in both environments for both tables and indexes . System parameters are exactly similar(default oracle for except for multiblock_read_count ).
    Both Environment have same db parameter for db_file_multiblock_read_count(16), optimizer(refer below),hash_area_size (131072),pga_aggregate_target(1G),db_block_size(8192) etc . SREADTIM, MREADTIM, CPUSPEED, MBRC are all null in aux_stats in both environment because workload was never collected i believe.
    Attached is details about the SQL with table stats, SQL and index stats my main concern is CBO generating different plans for the similar data and statistics and same hardware and software specs. Is there any thing else I should consider .I generally see environment B being very slow and always plans tend to nested loops and index scan whereas what we really need is a sensible FTS in many cases. One of the very surprising thing is METER_CONFIG_HEADER below which has just 80 blocks of data is being asked for index scan.
    show parameter optimizer
    optimizer_dynamic_sampling integer 2
    optimizer_features_enable string 10.2.0.4
    optimizer_index_caching integer 0
    optimizer_index_cost_adj integer 100
    optimizer_mode string ALL_ROWS
    optimizer_secure_view_merging boolean TRUE
    **Environment**
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
    PL/SQL Release 10.2.0.4.0 - Production
    CORE     10.2.0.4.0     Production
    TNS for Solaris: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    Note: : There are slight difference in the no of records in the attached sheet.However, I wanted to tell that i have tested with exact same data and was getting similar results but I couldn't retain the data untill collecting the details in the attachment
    TEST1     COMPARE TABLE LEVE STATS  used by CBO          
    ENVIRONMENT A
    TABLE_NAME     NUM_ROWS     BLOCKS     LAST_ANALYZED
    ASSET     3607425     167760     5/02/2013 22:11
    METER_CONFIG_HEADER     3658     80     5/01/2013 0:07
    METER_CONFIG_ITEM     32310     496     5/01/2013 0:07
    NMI     1899024     33557     18/02/2013 10:55
    REGISTER     4830153     101504     18/02/2013 9:57
    SDP_LOGICAL_ASSET     1607456     19137     18/02/2013 15:48
    SDP_LOGICAL_REGISTER     5110781     78691     18/02/2013 9:56
    SERVICE_DELIVERY_POINT     1425890     42468     18/02/2013 13:54
    ENVIRONMENT B
    TABLE_NAME     NUM_ROWS     BLOCKS     LAST_ANALYZED
    ASSET     4133939     198570     16/02/2013 10:02
    METER_CONFIG_HEADER     3779     80     16/02/2013 10:55
    METER_CONFIG_ITEM     33720     510     16/02/2013 10:55
    NMI     1969000     33113     16/02/2013 10:58
    REGISTER     5837874     120104     16/02/2013 11:05
    SDP_LOGICAL_ASSET     1788152     22325     16/02/2013 11:06
    SDP_LOGICAL_REGISTER     6101934     91088     16/02/2013 11:07
    SERVICE_DELIVERY_POINT     1447589     43804     16/02/2013 11:11
    TEST ITEM 2     COMPARE INDEX STATS  used by CBO          
    ENVIRONMENT A
    TABLE_NAME     INDEX_NAME     UNIQUENESS     BLEVEL     LEAF_BLOCKS     DISTINCT_KEYS     AVG_LEAF_BLOCKS_PER_KEY     AVG_DATA_BLOCKS_PER_KEY     CLUSTERING_FACTOR     NUM_ROWS
    ASSET     IDX_AST_DEVICE_CATEGORY_SK     NONUNIQUE     2     9878     67     147     12982     869801     3553095
    ASSET     IDX_A_SAPINTLOGDEV_SK     NONUNIQUE     2     7291     2747     2     639     1755977     3597916
    ASSET     SYS_C00102592     UNIQUE     2     12488     3733831     1     1     3726639     3733831
    METER_CONFIG_HEADER     SYS_C0092052     UNIQUE     1     12     3670     1     1     3590     3670
    METER_CONFIG_ITEM     SYS_C0092074     UNIQUE     1     104     32310     1     1     32132     32310
    NMI     IDX_NMI_ID     NONUNIQUE     2     6298     844853     1     2     1964769     1965029
    NMI     IDX_NMI_ID_NK     NONUNIQUE     2     6701     1923072     1     1     1922831     1923084
    NMI     IDX_NMI_STATS     NONUNIQUE     1     106     4     26     52     211     211
    REGISTER     REG_EFFECTIVE_DTM     NONUNIQUE     2     12498     795     15     2899     2304831     4711808
    REGISTER     SYS_C00102653     UNIQUE     2     16942     5065660     1     1     5056855     5065660
    SDP_LOGICAL_ASSET     IDX_SLA_SAPINTLOGDEV_SK     NONUNIQUE     2     3667     1607968     1     1     1607689     1607982
    SDP_LOGICAL_ASSET     IDX_SLA_SDP_SK     NONUNIQUE     2     3811     668727     1     2     1606204     1607982
    SDP_LOGICAL_ASSET     SYS_C00102665     UNIQUE     2     5116     1529606     1     1     1528136     1529606
    SDP_LOGICAL_REGISTER     SYS_C00102677     UNIQUE     2     17370     5193638     1     1     5193623     5193638
    SERVICE_DELIVERY_POINT     IDX_SDP_NMI_SK     NONUNIQUE     2     4406     676523     1     2     1423247     1425890
    SERVICE_DELIVERY_POINT     IDX_SDP_SAP_INT_NMI_SK     NONUNIQUE     2     7374     676523     1     2     1458238     1461108
    SERVICE_DELIVERY_POINT     SYS_C00102687     UNIQUE     2     4737     1416207     1     1     1415022     1416207
    ENVIRONMENT B
    TABLE_NAME     INDEX_NAME     UNIQUENESS     BLEVEL     LEAF_BLOCKS     DISTINCT_KEYS     AVG_LEAF_BLOCKS_PER_KEY     AVG_DATA_BLOCKS_PER_KEY     CLUSTERING_FACTOR     NUM_ROWS
    ASSET     IDX_AST_DEVICE_CATEGORY_SK     NONUNIQUE     2     8606     121     71     16428     1987833     4162257
    ASSET     IDX_A_SAPINTLOGDEV_SK     NONUNIQUE     2     8432     1780146     1     1     2048170     4162257
    ASSET     SYS_C00116157     UNIQUE     2     13597     4162263     1     1     4158759     4162263
    METER_CONFIG_HEADER     SYS_C00116570     UNIQUE     1     12     3779     1     1     3734     3779
    METER_CONFIG_ITEM     SYS_C00116592     UNIQUE     1     107     33720     1     1     33459     33720
    NMI     IDX_NMI_ID     NONUNIQUE     2     6319     683370     1     2     1970460     1971313
    NMI     IDX_NMI_ID_NK     NONUNIQUE     2     6597     1971293     1     1     1970771     1971313
    NMI     IDX_NMI_STATS     NONUNIQUE     1     98     48     2     4     196     196
    REGISTER     REG_EFFECTIVE_DTM     NONUNIQUE     2     15615     1273     12     2109     2685924     5886582
    REGISTER     SYS_C00116748     UNIQUE     2     19533     5886582     1     1     5845565     5886582
    SDP_LOGICAL_ASSET     IDX_SLA_SAPINTLOGDEV_SK     NONUNIQUE     2     4111     1795084     1     1     1758441     1795130
    SDP_LOGICAL_ASSET     IDX_SLA_SDP_SK     NONUNIQUE     2     4003     674249     1     2     1787987     1795130
    SDP_LOGICAL_ASSET     SYS_C004520     UNIQUE     2     5864     1795130     1     1     1782147     1795130
    SDP_LOGICAL_REGISTER     SYS_C004539     UNIQUE     2     20413     6152850     1     1     6073059     6152850
    SERVICE_DELIVERY_POINT     IDX_SDP_NMI_SK     NONUNIQUE     2     3227     660649     1     2     1422572     1447803
    SERVICE_DELIVERY_POINT     IDX_SDP_SAP_INT_NMI_SK     NONUNIQUE     2     6399     646257     1     2     1346948     1349993
    SERVICE_DELIVERY_POINT     SYS_C00128706     UNIQUE     2     4643     1447946     1     1     1442796     1447946
    TEST ITEM 3     COMPARE PLANS     
    ENVIRONMENT A
    Plan hash value: 4109575732                                             
    | Id  | Operation                       | Name                   | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                             
    |   0 | SELECT STATEMENT                |                        |    13 |  2067 |       |   135K  (2)| 00:27:05 |                                             
    |   1 |  HASH UNIQUE                    |                        |    13 |  2067 |       |   135K  (2)| 00:27:05 |                                             
    |*  2 |   HASH JOIN                     |                        |    13 |  2067 |       |   135K  (2)| 00:27:05 |                                             
    |*  3 |    HASH JOIN                    |                        |     6 |   900 |       |   135K  (2)| 00:27:04 |                                             
    |*  4 |     HASH JOIN ANTI              |                        |     1 |   137 |       |   135K  (2)| 00:27:03 |                                             
    |*  5 |      TABLE ACCESS BY INDEX ROWID| NMI                    |     1 |    22 |       |     5   (0)| 00:00:01 |                                             
    |   6 |       NESTED LOOPS              |                        |     1 |   131 |       | 95137   (2)| 00:19:02 |                                             
    |*  7 |        HASH JOIN                |                        |     1 |   109 |       | 95132   (2)| 00:19:02 |                                             
    |*  8 |         TABLE ACCESS FULL       | ASSET                  | 36074 |  1021K|       | 38553   (2)| 00:07:43 |                                             
    |*  9 |         HASH JOIN               |                        | 90361 |  7059K|  4040K| 56578   (2)| 00:11:19 |                                             
    |* 10 |          HASH JOIN              |                        | 52977 |  3414K|  2248K| 50654   (2)| 00:10:08 |                                             
    |* 11 |           HASH JOIN             |                        | 39674 |  1782K|       | 40101   (2)| 00:08:02 |                                             
    |* 12 |            TABLE ACCESS FULL    | REGISTER               | 39439 |  1232K|       | 22584   (2)| 00:04:32 |                                             
    |* 13 |            TABLE ACCESS FULL    | SDP_LOGICAL_REGISTER   |  4206K|    56M|       | 17490   (2)| 00:03:30 |                                             
    |* 14 |           TABLE ACCESS FULL     | SERVICE_DELIVERY_POINT |   675K|    12M|       |  9412   (2)| 00:01:53 |                                             
    |* 15 |          TABLE ACCESS FULL      | SDP_LOGICAL_ASSET      |  1178K|    15M|       |  4262   (2)| 00:00:52 |                                             
    |* 16 |        INDEX RANGE SCAN         | IDX_NMI_ID_NK          |     2 |       |       |     2   (0)| 00:00:01 |                                             
    |  17 |      VIEW                       |                        | 39674 |   232K|       | 40101   (2)| 00:08:02 |                                             
    |* 18 |       HASH JOIN                 |                        | 39674 |  1046K|       | 40101   (2)| 00:08:02 |                                             
    |* 19 |        TABLE ACCESS FULL        | REGISTER               | 39439 |   500K|       | 22584   (2)| 00:04:32 |                                             
    |* 20 |        TABLE ACCESS FULL        | SDP_LOGICAL_REGISTER   |  4206K|    56M|       | 17490   (2)| 00:03:30 |                                             
    |* 21 |     TABLE ACCESS FULL           | METER_CONFIG_HEADER    |  3658 | 47554 |       |    19   (0)| 00:00:01 |                                             
    |* 22 |    TABLE ACCESS FULL            | METER_CONFIG_ITEM      |  7590 | 68310 |       |   112   (2)| 00:00:02 |                                             
    Predicate Information (identified by operation id):                                             
       2 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")                                             
       3 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")                                             
       4 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")                                             
       5 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))                                             
       7 - access("ASSET_CD"="EQUIP_CD" AND "SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")                                             
       8 - filter("ROW_CURRENT_IND"='Y')                                             
       9 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")                                             
      10 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")                                             
      11 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")                                             
      12 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='4' OR                                              
                  SUBSTR("REGISTER_ID_CD",1,1)='5' OR SUBSTR("REGISTER_ID_CD",1,1)='6') AND "ROW_CURRENT_IND"='Y')                                             
      13 - filter("ROW_CURRENT_IND"='Y')                                             
      14 - filter("ROW_CURRENT_IND"='Y')                                             
      15 - filter("ROW_CURRENT_IND"='Y')                                             
      16 - access("NMI_SK"="NMI_SK")                                             
      18 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")                                             
      19 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='1' OR                                              
                  SUBSTR("REGISTER_ID_CD",1,1)='2' OR SUBSTR("REGISTER_ID_CD",1,1)='3') AND "ROW_CURRENT_IND"='Y')                                             
      20 - filter("ROW_CURRENT_IND"='Y')                                             
      21 - filter("ROW_CURRENT_IND"='Y')                                             
      22 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')                                             
    ENVIRONMENT B
    Plan hash value: 2826260434                                   
    | Id  | Operation                            | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |                                   
    |   0 | SELECT STATEMENT                     |                        |     1 |   181 |   103K  (2)| 00:20:47 |                                   
    |   1 |  HASH UNIQUE                         |                        |     1 |   181 |   103K  (2)| 00:20:47 |                                   
    |*  2 |   HASH JOIN ANTI                     |                        |     1 |   181 |   103K  (2)| 00:20:47 |                                   
    |*  3 |    HASH JOIN                         |                        |     1 |   176 | 56855   (2)| 00:11:23 |                                   
    |*  4 |     HASH JOIN                        |                        |     1 |   163 | 36577   (2)| 00:07:19 |                                   
    |*  5 |      TABLE ACCESS BY INDEX ROWID     | ASSET                  |     1 |    44 |     4   (0)| 00:00:01 |                                   
    |   6 |       NESTED LOOPS                   |                        |     1 |   131 |  9834   (2)| 00:01:59 |                                   
    |   7 |        NESTED LOOPS                  |                        |     1 |    87 |  9830   (2)| 00:01:58 |                                   
    |   8 |         NESTED LOOPS                 |                        |     1 |    74 |  9825   (2)| 00:01:58 |                                   
    |*  9 |          HASH JOIN                   |                        |     1 |    52 |  9820   (2)| 00:01:58 |                                   
    |* 10 |           TABLE ACCESS BY INDEX ROWID| METER_CONFIG_HEADER    |     1 |    14 |     1   (0)| 00:00:01 |                                   
    |  11 |            NESTED LOOPS              |                        |     1 |    33 |   116   (2)| 00:00:02 |                                   
    |* 12 |             TABLE ACCESS FULL        | METER_CONFIG_ITEM      |     1 |    19 |   115   (2)| 00:00:02 |                                   
    |* 13 |             INDEX RANGE SCAN         | SYS_C00116570          |     1 |       |     1   (0)| 00:00:01 |                                   
    |* 14 |           TABLE ACCESS FULL          | SERVICE_DELIVERY_POINT |   723K|    13M|  9699   (2)| 00:01:57 |                                   
    |* 15 |          TABLE ACCESS BY INDEX ROWID | NMI                    |     1 |    22 |     5   (0)| 00:00:01 |                                   
    |* 16 |           INDEX RANGE SCAN           | IDX_NMI_ID_NK          |     2 |       |     2   (0)| 00:00:01 |                                   
    |* 17 |         TABLE ACCESS BY INDEX ROWID  | SDP_LOGICAL_ASSET      |     1 |    13 |     5   (0)| 00:00:01 |                                   
    |* 18 |          INDEX RANGE SCAN            | IDX_SLA_SDP_SK         |     2 |       |     2   (0)| 00:00:01 |                                   
    |* 19 |        INDEX RANGE SCAN              | IDX_A_SAPINTLOGDEV_SK  |     2 |       |     2   (0)| 00:00:01 |                                   
    |* 20 |      TABLE ACCESS FULL               | REGISTER               | 76113 |  2378K| 26743   (2)| 00:05:21 |                                   
    |* 21 |     TABLE ACCESS FULL                | SDP_LOGICAL_REGISTER   |  5095K|    63M| 20245   (2)| 00:04:03 |                                   
    |  22 |    VIEW                              |                        | 90889 |   443K| 47021   (2)| 00:09:25 |                                   
    |* 23 |     HASH JOIN                        |                        | 90889 |  2307K| 47021   (2)| 00:09:25 |                                   
    |* 24 |      TABLE ACCESS FULL               | REGISTER               | 76113 |   966K| 26743   (2)| 00:05:21 |                                   
    |* 25 |      TABLE ACCESS FULL               | SDP_LOGICAL_REGISTER   |  5095K|    63M| 20245   (2)| 00:04:03 |                                   
    Predicate Information (identified by operation id):                                   
       2 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")                                   
       3 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK" AND                                    
                  "SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")                                   
       4 - access("ASSET_CD"="EQUIP_CD")                                   
       5 - filter("ROW_CURRENT_IND"='Y')                                   
       9 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")                                   
      10 - filter("ROW_CURRENT_IND"='Y')                                   
      12 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')                                   
      13 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")                                   
      14 - filter("ROW_CURRENT_IND"='Y')                                   
      15 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))                                   
      16 - access("NMI_SK"="NMI_SK")                                   
      17 - filter("ROW_CURRENT_IND"='Y')                                   
      18 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")                                   
      19 - access("SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")                                   
      20 - filter((SUBSTR("REGISTER_ID_CD",1,1)='4' OR SUBSTR("REGISTER_ID_CD",1,1)='5' OR                                    
                  SUBSTR("REGISTER_ID_CD",1,1)='6') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')                                   
      21 - filter("ROW_CURRENT_IND"='Y')                                   
      23 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")                                   
      24 - filter((SUBSTR("REGISTER_ID_CD",1,1)='1' OR SUBSTR("REGISTER_ID_CD",1,1)='2' OR                                    
                  SUBSTR("REGISTER_ID_CD",1,1)='3') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')                                   
      25 - filter("ROW_CURRENT_IND"='Y')Edited by: abhilash173 on Feb 24, 2013 9:16 PM
    Edited by: abhilash173 on Feb 24, 2013 9:18 PM

    Hi Paul,
    I misread your question initially .The system stats are outdated in both ( same result as seen from aux_stats) .I am not a DBA and do not have access to gather system stats fresh.
    select * from sys.aux_stats$
    SNAME     PNAME     PVAL1     PVAL2
    SYSSTATS_INFO     STATUS     NULL     COMPLETED
    SYSSTATS_INFO     DSTART     NULL     02-16-2011 15:24
    SYSSTATS_INFO     DSTOP     NULL     02-16-2011 15:24
    SYSSTATS_INFO     FLAGS     1     NULL
    SYSSTATS_MAIN     CPUSPEEDNW     1321.20523     NULL
    SYSSTATS_MAIN     IOSEEKTIM     10     NULL
    SYSSTATS_MAIN     IOTFRSPEED     4096     NULL
    SYSSTATS_MAIN     SREADTIM     NULL     NULL
    SYSSTATS_MAIN     MREADTIM     NULL     NULL
    SYSSTATS_MAIN     CPUSPEED     NULL     NULL
    SYSSTATS_MAIN     MBRC     NULL     NULL
    SYSSTATS_MAIN     MAXTHR     NULL     NULL
    SYSSTATS_MAIN     SLAVETHR     NULL     NULL

  • Different output format on pdf,  same report same data same user Report 10g

    Hi
    I’ve recently came up with a very strange problem
    I have the same report ( DevSuite 10g ) running on a win2003 server and without any obvious reason the output format changes from the original –correct one - ( the underlined text is not correct , font size is decreased , line spacing differs)
    The report is executed with the same user, the same parameters and the same data...
    Problem is solved only after a full server restart ( restarting only the report server, web cacle will not make any difference )
    Once the report is formatted strangely we cannot run it correctly (reboot is needed)
    Trace and log files shows nothing strange about the execution.
    Can you please tell me how to start investigate or suggest a solution?
    Thank you,
    M

    This is a wild guess, but it could be the result of there being no default printer. If you're using an in-process Reports Server, this runs by default under the LocalSystem operating system account. By default, this account does not have a default printer. Without a default printer, Reports may not format fonts correctly when producing PDF output.
    For more information, see "Printing and Font Errors When Using In-process Server" in Appendix D (Troubleshooting OracleAS Reports Services) of Oracle Application Server Reports Services Publishing Reports to the Web 10g Release 2 (10.1.2). It (like Metalink note 272017.1) suggests changing the registry to set a default printer that the LocalSystem account can "see"). Metalink note 370150.1 offers a more drastic solution -- configuring the Reports Server to run under a different operating system account that does have a default printer.
    Still, the theory that this "default printer" issue is the problem is not exactly consistent with the fact that your reports do work as expected at first, although there could be explanations for why the default printer is periodically changing (startup scripts, user intervention, etc.).
    Hope this helps.

  • Difference between sy-datum and any given date

    Dear Friends;
    I have one query  regarding DATE  I wanna calculate the difference between
    SY-DATUM and ANY GIVEN DATE . Is there any function or code available that take one parameter as sy-datum and another parameter as any given date and give result as no. of days between them
    Regards;
    Parag

    DATA: DATEDIFF TYPE P.
    CALL FUNCTION 'SD_DATETIME_DIFFERENCE'
      EXPORTING
        date1                 = '20071122'
        time1                 = '000001'
        date2                 = '20070905'
        time2                 = '000001'
    IMPORTING
       DATEDIFF               = DATEDIFF
    EXCEPTIONS
       INVALID_DATETIME       = 1
       OTHERS                 = 2.
    Greetings,
    Blag.

  • Regarding multiple schedule lines in sales order with same date

    Hi All,
    we create the Orders from RFC and the orders are going to Multiple Schedule lines for the same date.
    period       delivery date          ordered quan       confirmed quantity
    D     10/11/2007                10                    0
    D     10/11/2007                 0                     10
    here for the same date in first line it is not confirming and in the second line it is confirming the quantity for the same date.
    On what conditions it is possible??????
    Any one have the solution for this Please send it to me [email protected]
    Regards,
    Prasad

    Just check the schedule line details i.e go to schedule line---shipping. You will find that although the del. date is same in both the case but the timings were different e.g material availability time etc will be different in both these lines. So though the dates may be same its time difference that's causing the second schedule line.
    Reward points if useful

  • Multiple reads of the same data from Multiprovider by Query (Bex)

    Hello, guys!
    We're having issue with performance of a query built on Multiprivider. During our investigation, we've found out that within one run of a Query, it several times refers to InfoProvider for the same data (see image attached).
    Do you have ideas what can be a reason for multiply reads of the same data from Multipvovider?

    Hello Nikita,
    By "copy of a query" i meant something like this as shown below :
    *Kindly click on the screenshot for a better view.
    1) See the highlighted portions below in the screenshot . See Query 2 highlighted and name of the BEx query highlighted.
    2) See the highlighted portions . See Query 3 highlighted and name of the BEx query highlighted.
    As you can see from the above screenshots i have used the same BEx query 2 times by the name of Query 2 & Query 3 . Infact i have not attached the complete screenhsot . In that i have used it 6 times.
    I have to analyze this a bit in detail but what i am guessing is that when this WEBi is called the single BEx is also called multiple times. And hence it hits the Info Provider multiple times resulting in a decreased performance.
    But this does not mean that this is wrong approach. There are various areas where you can improve for example :
    1) Either improve your BEx query if possible or use aggregates or something like that .
    2) Use the  Query stripping setting in WEBi so that unused dimensions and measures are not pulled resulting in an improved performance. It's switched on by default.
    Thanks!!
    Regards,
    Ashutosh Singh

  • Whats the difference between these two queries ? - for tuning purpose

    Whats the difference between these two queries ?
    I have huge amount of data for each table. its takeing such a long time (>5-6hrs).
    here whice one is fast / do we have any other option there apart from listed here....
    QUERY 1: 
      SELECT  --<< USING INDEX >>
          field1, field2, field3, sum( case when field4 in (1,2) then 1 when field4 in (3,4) then -1 else 0 end)
        FROM
          tab1 inner join tab2 on condition1 inner join tab3 on condition2 inner join tab4 on conditon3
        WHERE
         condition4..10 and
        GROUP BY
          field1, field2,field3
        HAVING
          sum( case when field4 in (1,2) then 1 when field4 in (3,4) then -1 else 0 end) <> 0;
    QUERY 2:
       SELECT  --<< USING INDEX >>
          field1, field2, field3, sum( decode(field4, 1, 1, 2, 1, 3, -1, 4, -1 ,0))
        FROM
          tab1, tab2, tab3, tab4
        WHERE
         condition1 and
         condition2 and
         condition3 and
         condition4..10
        GROUP BY
          field1, field2,field3
        HAVING
          sum( decode(field4, 1, 1, 2, 1, 3, -1, 4, -1 ,0)) <> 0;
    [pre]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

    My feeling here is that simply changing join syntax and case vs decode issues is not going to give any significant improvement in performance, and as Tubby points out, there is not a lot to go on. I think you are going to have to investigate things along the line of parallel query and index vs full table scans as well any number of performance tuning methods before you will see any significant gains. I would start with the Performance Manual as a start and then follow that up with the hard yards of query plans and stats.
    Alternatively, you could just set the gofast parameter to TRUE and everything will be all right.
    Andre

  • Is there a way to trace results of queries in components?

    This is loosely related to my unanswered question in this thread: Can I use multiline SQL commands in a query (within a component)?
    I am trying to run a sequence of queries in a component where results of one query are used as the entry parameters for the other query. However, the system does not behave as I expect, so I would like to trace it to find the flaw.
    I will post my queries here as well, even though I think they are not relevant to the reason of the query - but perhaps, there is a workaround.
    Q1:
    <tr>
         <td>QGetParentLevel</td>
         <td> WITH tree AS (select dCollectionId, CASE WHEN level > 1 then dCollectionQuota END AS EFFECTIVE_QUOTA, dParentCollectionId from collections start with dCollectionId = ? connect by nocycle dCollectionId = prior dParentCollectionId) SELECT max(level) AS PARENTLEVEL from tree t start with dCollectionId = ? connect by dCollectionId = prior dParentCollectionId and prior EFFECTIVE_QUOTA IS NULL
         </td>
         <td>dCollectionIdStored varchar
              dCollectionIdStored varchar</td>
    </tr>
    I added a new column to the table Collections. This column is called dCollectionQuota.
    This query takes one entry parameter, dCollectionId of a folder, and returns LEVEL of the parent folder whose quota is not NULL
    Q2:
    <tr>
         <td>QGetParentId</td>
         <td> WITH tree AS (select dCollectionId, dCollectionQuota, CASE WHEN level > 1 then dCollectionQuota END AS EFFECTIVE_QUOTA, dParentCollectionId from collections start with dCollectionId = ? connect by nocycle dCollectionId = prior dParentCollectionId) SELECT dCollectionId AS FOUNDPARENTID, dCollectionQuota as PARENTQUOTA from tree t where level = ? start with dCollectionId = ? connect by dCollectionId = prior dParentCollectionId and prior EFFECTIVE_QUOTA IS NULL
         </td>
         <td>dCollectionIdStored varchar
              PARENTLEVEL int
              dCollectionIdStored varchar</td>
    </tr>
    This query searches the same recursive tree as Q1. Only this time it returns dCollectionId and dCollectionQuota of the parent item - it will be the root or the first parent with a set quota.
    I use the PARENTLEVEL parameter found in the first query - I believe these two queries could be united into one - I just need the node with max level
    Q3:
    <tr>
         <td>QParentFolderUsedSpace</td>
         <td>WITH tree AS (select dCollectionId, case when level>1 then dCollectionQuota end as effective_quota from collections start with dCollectionId = ? connect by dParentCollectionId = prior dCollectionId and (prior dCollectionQuota IS NULL or level = 2)) SELECT SUM(NVL(t.effective_quota, NVL(docs.dFileSize, 0))) as PARENTQUOTABLOCKED from tree t LEFT OUTER JOIN DOCMETA meta ON t.dCollectionId = meta.xCollectionId and t.effective_quota IS NULL LEFT OUTER JOIN DOCUMENTS docs ON meta.dId = docs.dId and docs.dIsPrimary = 1 LEFT OUTER JOIN REVISIONS rev ON rev.dId = docs.dId</td>
         <td>FOUNDPARENTID int</td>
    </tr>
    This is a quite complex query which takes the parameter FOUNDPARENTID from the query 2. Its logic is to calculate portion of the quota already used (either by assignment of quotas to subfolders or storing documents to folders with no quota assigned).
    Q4:
    <tr>
         <td>QFolderQuota</td>
         <td>WITH tree AS (select dCollectionId, case when level>1 then dCollectionQuota end as effective_quota from collections start with dCollectionId = ? connect by dParentCollectionId = prior dCollectionId and (prior dCollectionQuota IS NULL or level = 2)) SELECT SUM(NVL(t.effective_quota, NVL(docs.dFileSize, 0))) as TOTALDOCUMENTSIZE from tree t LEFT OUTER JOIN DOCMETA meta ON t.dCollectionId = meta.xCollectionId and t.effective_quota IS NULL LEFT OUTER JOIN DOCUMENTS docs ON meta.dId = docs.dId and docs.dIsPrimary = 1 LEFT OUTER JOIN REVISIONS rev ON rev.dId = docs.dId</td>
         <td>dCollectionId int</td>
    </tr>
    This is the same query as Q3, only for the starting folder.
    Q5:
    <tr>
         <td>QGetMaxPossibleQuota</td>
         <td>select ? - ? + ? as MAXPOSSIBLEQUOTA from DUAL</td>
         <td>PARENTQUOTA int
              PARENTQUOTABLOCKED int
              TOTALDOCUMENTSIZE int
         </td>
    </tr>
    This query combines results from Q2, Q3 and Q4, so all the parameters PARENTQUOTA, PARENTQUOTABLOCKED, and TOTALDOCUMENTSIZE are used.
    Q6:
    <tr>
         <td>QValidateMaxQuota</td>
         <td>select * from dual where ? - ? < 0</td>
         <td>MAXPOSSIBLEQUOTA int
              dCollectionQuotaEntry varchar
         </td>
    </tr>
    The final query is the check if entered new quota is below the calculated maximum.

    Jason,
    I was thinking about something similar - though, do it in Java. However, both ways seems to me a bit overkill. Fortunately, I was advised another way on a different forum:
    turn on "systemdatabase" tracing from the System Audit Information page (http://download.oracle.com/docs/cd/E10316_01/cs/cs_doc_10/documentation/admin/troubleshooting_10en.pdf manual for more details)
    This tracks all the queries, so I'm able to see results of queries in entries of the succeeding ones.
    I prefer this way, because it requires no changes in the component.
    Yet, thanks for your effort.
    J.

  • Problem with different resultset with same data and same query in Oracle 8.1.7 and 9i

    Hello,
    I have been using this query in oracle 8.1.7
    SELECT
    ID,
    AREA_NO
    FROM MANAGER_AREA MGR
    WHERE COMPANY_ID = :id AND
    (:value < (SELECT COUNT(ROWID)
    FROM MANAGER_WORK MW
    WHERE MW.AREA_ID = MGR.ID AND
    (MW.END_WORK IS NULL OR MW.END_WORK >= SYSDATE)))
    order by AREA_NO;
    In the above query I want to see rows from MANAGER_AREA table depending upon date criteria in the table MANAGER_WORK and also upon the parameter :value i.e if I pass a value as 0 I get to see records for which their is atleast 1 record in MANAGER_WORK with the date criteria and if I pass -1 then I get all the records because minimum value that count(*) would give is 0. The resultset was as expected in 8.1.7.
    A couple of days back I installed PERSONAL 9i to test for testing the basic functionality of our program with the same data. This query fails and irrespective whether I pass -1 or 0 it returns me same dataset which I would have got in case if I pass 0.
    I do not know whether this is a bug that has got introduced in 9i. Can anybody help me with this problem. It would be difficult for me to change the parameter send to this query as the Query is called from many different places.
    Thanks in advance
    Amol.

    I cannot use a Group by and a having statement over here. The problem with 'Group by' and 'having' clause is If I have to make a join between the two tables. When I use join then I get only rows that are linked to each other in the table.
    If I use outer join to solve that problem then I have to take in consideration the other date condition. My previous query use to virtually discard the corelated query result by using -1 as the value. This will not happen in the join query.
    Amol.

  • How to load member for "sales same date last year"?

    I need to load a member in Measures named "PriorYrSales" with "Sales" for the same date last year as today's date. Thus, retrieving "PriorYrSales" for 2/10/2002 would return the sales amount for 2/10/2001. Since days roll-up to months, quarters, years, it would be easy to determine how we're doing compared to the same time last year.Data is loaded each day for a date range from the current date and the preceding x days. Substitution variables are available for the beginning and ending date and the same dates for last year.For example: Data is loaded from beginning date of 2/01/2002 through ending date of 2/10/2002.The prior year date variables contain 2/01/2001 and 2/10/2001.The time period dimension is as follows:FY01->Jan2001-->01012001 (Alias: 1/01/2001)-->01022001 (Alias: 1/02/2001)-->all the dates in Jan->Feb2001-->02012001 (Alias: 2/01/2001)-->02022001 (Alias: 2/02/2001)-->all the dates in Febetc.FY02->Jan2002-->01012002 (Alias: 1/01/2002)-->01022002 (Alias: 1/02/2002)-->all the dates in Jan->Feb2002-->02012002 (Alias: 2/01/2002) -->02022002 (Alias: 2/01/2002)-->all the dates in Febetc.Thanks your any and all suggestions.Phil

    Perhaps I wasn't clear in the first post. The intent is to easily compare sales for a current date/period to the same date/period last year. Neither Excel nor Analyzer provide a method that I'm aware of to retrieve data as follows:-------------------------------------Period Sales PriorYrSales Diff4/15/2002 1,000 900 100-------------------------------------(900 is sales for 4/15/2001)(100 is the calculated difference.)Nor can I do this:-------------------------------------Period Sales Period Sales Diff4/15/2002 1,000 4/15/2001 900 100-------------------------------------What Excel and Analyzer do allow is:-------------------------------------Period Sales 4/15/2002 1,0004/15/2001 900-------------------------------------I readily acknowledge that the data is redundant but I can't think of another option that will allow Excel and Analyzer to easily retrieve the values for comparison. If the PriorYrSales member can be loaded then the users can compare years, quarters, months and days quite easily.My challenge is knowing how use a calc script to derive prior year dates that correspond to current year dates. Something like:PriorYrSales->04152002 = Sales->04152001I've considered arrays but I've never used them and the documentation is not helpful enough for me.Thanks for your response.Phil

  • Considering buying refurbished.  Is there a big difference between a refurb with an original date this year vs. one from over a year ago??

    Considering buying refurbished.  Is there a big difference between a refurb with an original date this year vs. one from over a year ago??

    MacBook Air, 13", Mid 2013:
    On June 10, 2013, Apple released an updated MacBook Air in the same form factor as the 2012 model during the company's Worldwide Developer Conference (WWDC). The 11-inch and 13-inch models have a minimum standard 4GB RAM, with a maximum configuration of 8GB. Both models are powered by the Haswell ULT 1.3GHz dual-core Intel Core i5 processors with Turbo Boost up to 2.6GHz and 1.7GHz Dual-Core i7 with Turbo Boost up to 3.3GHz option available. Each model has a 128GB configuration and a 256GB configuration available, with the 256GB model being upgradeable to 512GB SSD.
    1.3 GHz (Core i5) or 1.7 GHz (Core i7)
    MacBook Air, 13", Early 2014:
    On April 29, 2014 Apple released an updated MacBook Air featuring faster processors and better battery life. The standard configurations also saw a price drop in most regions.
    1.4 GHz (Core i5) or 1.7 GHz (Core i7)
    MacBook Pro, 13", Retina, Late 2013:
    At the Apple Special Event on October 22, 2013, Apple announced that it had updated the 13-inch and 15-inch MacBook Pro with Retina display. Both versions feature the new Intel Haswell chipset.
    2.4 or 2.6 GHz (Core i5) or 2.8 GHz (Core i7)
    MacBook Pro, 13", Retina, Mid 2014:
    On July 29, 2014 Apple announced updated prices and processors for their Haswell Macbook Pro with Retina Display.
    2.6 or 2.8 GHz (Core i5) or 3.0 GHz (Core i7)
    I would go for the Pro Retina since the display is much better.

  • Inconsistent SDO_RELATE results when querying 2.5D data

    Oracle 11.1.0.7 with Patch 8343061 on Windows Server 2003 32bit.
    I'm getting inconsistent results from SDO_RELATE results when querying 2.5D data. Some geometries I expect to be OVERLAPBDYDISJOINT, are not always being returned by SDO_RELATE when using the OVERLAPBDYDISJOINT mask. It seems that the order of the tables makes a difference to the result.
    Here's a table with one 2.5D geometry and a 2D index:
    CREATE TABLE TEST1 (
    ID                NUMBER PRIMARY KEY,
    GEOMETRY     SDO_GEOMETRY);
    INSERT INTO TEST1 (id, geometry) VALUES (
    1,
    SDO_GEOMETRY(3002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561695.935, 834005.726, 25.865,
    561696.229, 834005.955, 25.867, 561686.278, 834015.727, 26.088, 561685.179, 834019.771, 26.226, 561680.716, 834022.389, 26.226,
    561674.434, 834025.125, 26.171, 561671.963, 834032.137, 25.667, 561670.832, 834037.185, 25.619, 561667.946, 834042.976, 25.84,
    561666.717, 834047.218, 26.171, 561664.229, 834051.781, 26.778, 561660.041, 834055.935, 26.64, 561657.514, 834061.742, 26.53,
    561658.59, 834067.116, 27.882, 561657.67, 834070.739, 28.821, 561653.028, 834073.777, 29.042, 561653.234, 834078.769, 28.379,
    561658.336, 834080.105, 29.511, 561664.582, 834079.468, 31.94, 561669.257, 834075.821, 33.707, 561672.716, 834074.456, 33.707,
    561676.875, 834077.262, 33.735, 561675.868, 834081.55, 33.707, 561673.131, 834087.641, 33.679, 561672.208, 834093.502, 33.238,
    561668.578, 834100.894, 33.735, 561666.013, 834106.399, 33.679, 561661.408, 834111.23, 33.514, 561654.854, 834117.181, 33.486,
    561651.695, 834122.292, 33.569, 561649.112, 834128.847, 33.431, 561645.982, 834134.786, 33.293, 561642.485, 834141.235, 33.072,
    561642.138, 834150.085, 33.293, 561646.072, 834159.721, 36.578, 561647.274, 834165.532, 37.02, 561646.359, 834170.867, 37.02,
    561645.42, 834175.485, 36.799, 561642.44, 834180.977, 36.826, 561638.677, 834185.419, 36.771, 561636.693, 834194.824, 37.158,
    561635.462, 834202.105, 37.241, 561631.998, 834208.745, 37.268, 561628.871, 834213.994, 37.241, 561627.554, 834220.393, 37.82,
    561625.79, 834226.697, 39.532, 561620.561, 834236.494, 39.891, 561619.265, 834249.687, 39.697, 561619.883, 834260.02, 41.326,
    561620.977, 834264.399, 43.093, 561622.557, 834270.723, 43.452, 561622.172, 834276.978, 43.452, 561621.347, 834285.541, 43.479,
    561622.214, 834292.055, 43.645, 561619.718, 834302.583, 43.755, 561616.762, 834316.47, 43.755, 561608.842, 834328.241, 43.7,
    561606.346, 834334.93, 43.7, 561605.27, 834341.929, 43.7, 561603.925, 834350.648, 43.728, 561602.462, 834358.405, 43.838,
    561599.552, 834366.629, 44.031, 561594.551, 834374.291, 43.396, 561590.644, 834383.986, 43.065, 561588.48, 834392.21, 44.942,
    561586.923, 834397.32, 46.737, 561584.608, 834402.898, 49.299, 561581.389, 834410.194, 50.077, 561580.437, 834419.49, 51.907,
    561580.438, 834427.63, 53.127, 561582.245, 834433.389, 55.791, 561586.664, 834433.397, 57.503, 561593.88, 834433.608, 57.475,
    561596.305,834439.653, 57.42, 561591.804, 834445.862, 57.309, 561589.097, 834447.689, 57.014)));
    SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST1;
    DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST1' AND column_name = 'GEOMETRY';
    INSERT INTO user_sdo_geom_metadata VALUES ('TEST1','GEOMETRY', 
         MDSYS.SDO_DIM_ARRAY(
         MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
         MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005),      
         MDSYS.SDO_DIM_ELEMENT('Z',-10000,10000,0.0005)     
    ), 2157);
    DROP INDEX TEST1_SPIND;
    CREATE INDEX TEST1_SPIND ON TEST1(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');And here's another table with a 2D geometry and a 2D index:
    CREATE TABLE TEST2 (
    ID                NUMBER PRIMARY KEY,
    GEOMETRY     SDO_GEOMETRY);
    INSERT INTO TEST2 (id, geometry) VALUES (
    1,
    SDO_GEOMETRY(2002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561816.516, 834055.581, 561819.504, 834057.173,
    561817.942, 834060.818, 561810.044, 834078.997, 561805.576, 834087.634, 561801.572, 834094.299, 561798.558, 834100.467,
    561796.254, 834107.637, 561793.754, 834115.605, 561794.049, 834123.694, 561793.698, 834130.518, 561792.905, 834138.883,
    561787.867, 834145.772, 561782.544, 834150.548, 561777.707, 834156.53, 561773.945, 834161.32, 561771.061, 834166.957,
    561768.155, 834173.131, 561764.735, 834178.744, 561759.603, 834187.782, 561756.146, 834195.493, 561753.416, 834198.821,
    561754.141, 834205.691, 561756.768, 834209.681, 561757.217, 834216.701, 561753.086, 834232.46, 561744.371, 834254.589,
    561740.936, 834263.001, 561737.198, 834272.208, 561732.231, 834284.915, 561730.52, 834297.01, 561728.339, 834310.053,
    561727.825, 834328.069, 561730.461, 834342.992, 561729.808, 834367.948, 561730.216, 834396.988, 561732.273, 834419.047,
    561732.783, 834424.668, 561731.647, 834432.212, 561731.872, 834439.436, 561731.39, 834449.269, 561732.041, 834462.813,
    561733.583, 834471.926, 561733.229, 834485.049, 561730.868, 834498.462, 561726.379, 834512.59, 561725.776, 834528.932,
    561727.488, 834555.23, 561729.357, 834577.873, 561731.05, 834595.931, 561731.163, 834611.928, 561734.057, 834637.031,
    561732.67, 834636.4, 561725.401, 834633.796, 561721.039, 834632.493, 561718.777, 834632.167, 561710.437, 834632.888,
    561647.929, 834636.658, 561644.963, 834630.085, 561632.796, 834629.813, 561625.553, 834627.647, 561620.473, 834626.711,
    561608.718, 834624.94, 561599.935, 834619.684, 561596.67, 834613.843, 561594.27, 834607.774, 561592.513, 834601.752,
    561591.349, 834593.899, 561597.265, 834584.888, 561595.956, 834571.479, 561595.075, 834556.196, 561593.997, 834539.68,
    561594.316, 834528.071, 561595.261, 834516.44, 561595.538, 834504.804, 561597.227, 834497.417, 561599.3, 834490.416,
    561601.265, 834482.61, 561605.126, 834475.502, 561599.232, 834473.683, 561593.076, 834471.379, 561599.154, 834451.112,
    561589.097, 834447.689, 561591.804, 834445.862, 561596.305, 834439.653, 561593.88, 834433.608, 561582.245, 834433.389,
    561580.438, 834427.63, 561580.437, 834419.49, 561581.389, 834410.194, 561584.608, 834402.898, 561586.923, 834397.32,
    561588.48, 834392.21, 561590.644, 834383.986, 561594.551, 834374.291, 561599.552, 834366.629, 561602.462, 834358.405,
    561603.925, 834350.648, 561605.27, 834341.929, 561606.346, 834334.93, 561608.842, 834328.241, 561616.762, 834316.47,
    561619.718, 834302.583, 561622.214, 834292.055, 561621.347, 834285.541, 561622.172, 834276.978, 561622.557, 834270.723,
    561620.977, 834264.399, 561619.883, 834260.02, 561619.265, 834249.687, 561620.561, 834236.494, 561625.79, 834226.697,
    561627.554, 834220.393, 561628.871, 834213.994, 561631.998, 834208.745, 561635.462, 834202.105, 561636.693, 834194.824,
    561638.677, 834185.419, 561642.44, 834180.977, 561645.42, 834175.485, 561646.359, 834170.867, 561647.274, 834165.532,
    561646.072, 834159.721, 561642.138, 834150.085, 561642.485, 834141.235, 561645.982, 834134.786, 561649.112, 834128.847,
    561651.695, 834122.292, 561654.854, 834117.181, 561661.408, 834111.23, 561666.013, 834106.399, 561668.578, 834100.894,
    561672.208, 834093.502,561673.131, 834087.641, 561675.868, 834081.55, 561676.875, 834077.262, 561672.716, 834074.456,
    561669.257, 834075.821, 561664.582, 834079.468, 561658.336, 834080.105, 561653.234, 834078.769, 561653.028, 834073.777,
    561657.67, 834070.739, 561658.59, 834067.116, 561657.514, 834061.742, 561660.041, 834055.935, 561664.229, 834051.781,
    561666.717, 834047.218, 561667.946, 834042.976, 561670.832, 834037.185, 561671.963, 834032.137, 561674.434, 834025.125,
    561680.716, 834022.389, 561685.179, 834019.771, 561686.278, 834015.727, 561696.229, 834005.955, 561695.935, 834005.726,
    561677.805, 833994.91, 561683.163, 833985.817, 561703.01, 833949.434, 561725.891, 833961.856, 561744.35, 833971.197,
    561768.396, 833983.86, 561777.842, 833988.883, 561798.333, 833999.743, 561797.243, 834005.725, 561783.574, 834040.515,
    561798.127, 834046.391, 561807.001, 834050.509, 561816.516, 834055.581)));
    SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST2;
    DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST2' AND column_name = 'GEOMETRY';
    INSERT INTO user_sdo_geom_metadata VALUES ('TEST2','GEOMETRY', 
         MDSYS.SDO_DIM_ARRAY(
         MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
         MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)
    ), 2157);
    DROP INDEX TEST2_SPIND;
    CREATE INDEX TEST2_SPIND ON TEST2(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');Now if I check how these two geometries relate to each other, the answer is OVERLAPBDYDISJOINT, which makes sense when inspecting the geometries.
    SQL> SELECT
      2  sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate_1_to_2,
      3  sdo_geom.relate(t2.geometry, 'determine', t1.geometry,  0.0005) relate_2_to_1
      4  FROM test2 t2, test1 t1
      5  WHERE t1.id = t2.id;
    RELATE_1_TO_2        RELATE_2_TO_1
    OVERLAPBDYDISJOINT   OVERLAPBDYDISJOINT
    1 row selected.So, I'd expect this query to return something...
    SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
    FROM test2 t2, test1 t1
    WHERE sdo_relate(t1.geometry, t2.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
    AND t1.id = 1
    AND t2.id = 1;Nada. And this...
    SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
    FROM test1 t1, test2 t2
    WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
    AND t1.id = 1
    AND t2.id = 1;Nada.
    And this...
    SQL> SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry,  0.0005) relate
      2  FROM test2 t2, test1 t1
      3  WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
      4  AND t1.id = 1
      5  AND t2.id = 1;
            ID         ID RELATE
             1          1 OVERLAPBDYDISJOINT
    1 row selected.This version gives the right answer.
    Can anyone explain this?

    Hi,-
    I think you are running into these bugs 7158518 and 7710726.
    Could you please request the patch for the bugs so that they are published on Metalink
    if they dont exist there?
    Please let us know if these fix your problem.
    Best regards
    baris

Maybe you are looking for