Optimizing query

SELECT
XREF.MEDICAID_NO,
XREF.PLAN_CODE,
XREF.REVENUE_YEAR,
XREF.REVENUE_MONTH
FROM
table1 a,
table2 b
WHERE
(a.MEDICAID_NO = b.MEDICAID_NO
OR a.EMPLOYEE_NO=b.EMPLOYEE_NO)
AND COMPANY_CODE = 'ACMD'
MINUS
SELECT
A.MEDICAID_NO,
A.PLAN_CODE,
A.REVENUE_YEAR,
A.REVENUE_MONTH
FROM
table1 a,
table2 b
WHERE
TO_CHAR (A.REVENUE_YEAR || LPAD(A.REVENUE_MONTH,2,0)) >= TO_CHAR (B.EFFECTIVE_DATE,'YYYYMM')
AND (B.TERM_DATE IS NULL OR TO_CHAR (A.REVENUE_YEAR || LPAD(A.REVENUE_MONTH,2,0)) <= TO_CHAR (B.TERM_DATE,'YYYYMM'))
AND A.PLAN_CODE = B.PLAN_CODE
AND (A.MEDICAID_NO = B.MEDICAID_NO
OR A.EMPLOYEE_NO=B.EMPLOYEE_NO)
AND A.COMPANY_CODE = 'ACMD';
no of record table1=400000
table2=300000
Basically it takes long time to run this query can you please suggest some ways so that time taken can be reduced to some extent.

As per your idea there are no indexes on revenue_year,revenue_month as such.
Datatypes of the column are varchar2 and date datatypes.
00:05:31.07
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=48357 Card=494339 By
tes=24717016)
1 0 MINUS
2 1 SORT (UNIQUE) (Cost=38413 Card=494336 Bytes=24716800)
3 2 CONCATENATION
4 3 MERGE JOIN (Cost=9043 Card=5497 Bytes=274850)
5 4 SORT (JOIN) (Cost=983 Card=65556 Bytes=1180008)
6 5 TABLE ACCESS (FULL) OF 'MRR_INVOICE_ELIG_TEMP' (
Cost=218 Card=65556 Bytes=1180008)
7 4 SORT (JOIN) (Cost=8060 Card=243521 Bytes=7792672)
8 7 TABLE ACCESS (FULL) OF 'MRR_PAYMENT_INVOICE_XREF
' (Cost=1884 Card=243521 Bytes=7792672)
9 3 MERGE JOIN (Cost=9043 Card=5497 Bytes=274850)
10 9 SORT (JOIN) (Cost=983 Card=65556 Bytes=1180008)
11 10 TABLE ACCESS (FULL) OF 'MRR_INVOICE_ELIG_TEMP' (
Cost=218 Card=65556 Bytes=1180008)
12 9 FILTER
13 12 SORT (JOIN)
14 13 TABLE ACCESS (FULL) OF 'MRR_PAYMENT_INVOICE_XR
EF' (Cost=1884 Card=243521 Bytes=7792672)
15 1 SORT (UNIQUE) (Cost=9944 Card=3 Bytes=216)
16 15 MERGE JOIN (Cost=9943 Card=3 Bytes=216)
17 16 SORT (JOIN) (Cost=1883 Card=65556 Bytes=2622240)
18 17 TABLE ACCESS (FULL) OF 'MRR_INVOICE_ELIG_TEMP' (Co
st=218 Card=65556 Bytes=2622240)
19 16 FILTER
20 19 SORT (JOIN)
21 20 TABLE ACCESS (FULL) OF 'MRR_PAYMENT_INVOICE_XREF
' (Cost=1884 Card=243521 Bytes=7792672)
what can be done next??
Kindly suggest some solutions

Similar Messages

  • Optimized query to find Min and max of a col in a table

    I have a table doc_boe_rec with record count 12375934
    the primary key columns are (boe_rec_id,psd_serial_num).
    No other ndexes are present on this table.
    I want an optimized query which will give both the results :
    1.Min boe_rec_id (boe_rec_id from 1st record)
    2.Max boe_rec_id from this table with rows limited to a value say 5000.
    i.e (boe_rec_id from 5000th column value from table )
    Thanks
    Manoj

    1.Min boe_rec_id (boe_rec_id from 1st record)It is confusing for me. The min value for the first, hmmm...
    2.Max boe_rec_id from this table with rows limited to a value say 5000.Not more clear...
    Please details your requirements.
    Nicolas.

  • Conversion away from column type may result in sub-optimal query plan

    Hello all,
    I have the following select statement in a cursor compiled in a package.
    SELECT id
    FROM table
    WHERE TRUNC(ts) >= TRUNC(SYSDATE - p_days)
    However I get 4 warnings that read:
    PLW-07204: conversion away from column type may result in sub-optimal query plan
    Does anyone know of a way to rewrite the query to avoid the compilation warnings?
    I'm just trying to compare the date without the time...
    Thanks in advance
    Dan

    For what it is worth, whenever you compare a date column to either sysdate or any built-in function returning a date you will get that warning.
    SQL> desc t
    Name                                      Null?    Type
    ID                                                 NUMBER
    DT                                                 DATE
    SQL> SELECT DUMP(dt), DUMP(trunc(dt)), dump(sysdate)
      2  FROM t;
    DUMP(DT)                            DUMP(TRUNC(DT))                  DUMP(SYSDATE)
    Typ=12 Len=7: 120,107,7,12,15,16,43 Typ=13 Len=8: 7,215,7,12,0,0,0,0 Typ=13 Len=8: 7,215,7,12,14,16,11,0But,
    SQL> CREATE FUNCTION f(p_v IN VARCHAR2) RETURN DATE AS
      2  BEGIN
      3     RETURN TO_DATE(p_v, 'dd-mon-yyyy');
      4  END;
      5  /
    Function created.
    SQL> SELECT DUMP(f('01-jan-2000')) FROM dual;
    DUMP(F('01-JAN-2000'))
    Typ=12 Len=7: 120,100,1,1,1,1,1John

  • PLW-07204: conversion away from column type may result in sub-optimal query

    I have the following query in the package that created using sql developer. I am receiving the error 'PLW-07204: conversion away from column type may result in sub-optimal query plan' when try to compile the package. The issue is happen to be in the last line where the date is. Any help? Thanks
    select count(*) into n_cnt
    from tmp_order
    where sgn_off_dt is null and cmt_dt is not null
    and sysdate - cmt_dt > 90;

    Sy:
    Try doing as a procedure instead of an anonymous block. It looks like warnings do not apply to blocks.
    SQL> create table tmp_order(sgn_off_dt date,cmt_dt date);
    Table created.
    SQL> alter session set plsql_warnings='ENABLE:ALL';
    Session altered.
    SQL> create procedure p as
      2     n_cnt number;
      3  begin
      4     select count(*) into n_cnt
      5     from tmp_order
      6     where sgn_off_dt is null and
      7           cmt_dt is not null and
      8           sysdate - cmt_dt > 90;
      9  end;
    10  /
    SP2-0804: Procedure created with compilation warnings
    SQL> show err
    Errors for PROCEDURE P:
    LINE/COL ERROR
    8/18     PLW-07204: conversion away from column type may result in
             sub-optimal query planlindalop:
    In this case, you can ignore the warning, as it is not correct. Sysdate and a date column have different internal data types (note the type 13 for sysdate and type 12 for the date column), and whatever internally generates the warnings seems to just compare the type number.
    SQL> insert into tmp_order values(sysdate, sysdate);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> select dump(sysdate) sdate, dump(cmt_dt) cmt_dt from tmp_order;
    SDATE                             CMT_DT
    Typ=13 Len=8: 7,219,2,3,15,44,4,0 Typ=12 Len=7: 120,111,2,3,16,44,12However, Oracle is perfectly capable of using an index on a date column with sysdate as a predicate. I would agree with Sy's suggestion to re-work the predicate to be something like cmt_dt < sysdate - 90.
    John

  • Help optimizing query with function

    Hello experts,
    I need your help optmizing this query which has a condition that matches on results of non-deterministic function. The non-deterministic functino is fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY. Values that it returns depends on contents of a table, so I can't really create a function index.
    Any input will be appreciated. Thanks in advance!
    Sorry I couln't format the query plan properly. Can somebody advise how? Thanks again!
    Giovanni
    explain plan for
    WITH tg AS
    (SELECT taxgroup_code FROM taxgroup
    WHERE taxgroup_code = 'TAXGROUP2' --?
    AND taxgroup_delete_ind = 'N' AND taxgroup_active_ind = 'A'),
    le_hb AS
    (SELECT tgi.taxgroup_code, tgi.legalentity_id, tgi.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
    FROM tg, taxgroupitem tgi, orgunit_vw ou
    WHERE tg.taxgroup_code = tgi.taxgroup_code
    AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id = ou.hyperionbase_id
    UNION
    SELECT tgi.taxgroup_code, tgi.legalentity_id, ou.hyperionbase_id, ou.orgunit_code, ou.hyperionbase_code
    FROM tg, taxgroupitem tgi, orgunit_vw ou
    WHERE tg.taxgroup_code = tgi.taxgroup_code
    AND tgi.legalentity_id = ou.legalentity_id AND tgi.hyperionbase_id IS NULL),
    au AS
    (SELECT appusage_code FROM appusage WHERE appusage_code = 'CONSOLIDATION'),
    prs AS
    (SELECT prs_key,
    (CASE WHEN instr(prs_key, ':') = 0 THEN prs_key
    ELSE SUBSTR(prs_key, 1, (instr(prs_key, ':')-1) ) END) first_val
    FROM
    (SELECT fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(164415 --?
    ) prs_key
    FROM dual
    grs AS
    (SELECT prs.*, fd.fielddata_group_sequence fd_grpseq
    FROM prs, fielddata fd, le_hb
    WHERE prs.first_val = fd.fielddata_value
    AND le_hb.legalentity_id = fd.legalentity_id
    AND le_hb.hyperionbase_id = fd.hyperionbase_id),
    fdk AS
    (SELECT
    cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
    fd.fielddata_value fd_val, fd.fielddata_group_sequence fd_grpseq,
    ROW_NUMBER() OVER (PARTITION BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence)
    ORDER BY fd.fielddata_group_sequence) rn,
    grs.prs_key
    FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td, appusage au
    WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
    AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
    AND cd.tabledef_id = td.tabledef_id
    AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
    and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
    AND cd.celldef_key_ind = 'Y'
    AND fd.fielddata_delete_ind = 'N'
    AND td.tabledef_id = 2265
    fda AS
    (SELECT
    cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence) fd_key,
    TO_CHAR(TO_NUMBER(SUM(fd.fielddata_value))) fd_val,
    MIN(fd.fielddata_group_sequence) fd_grpseq,
    grs.prs_key
    FROM le_hb, grs, fielddata fd, tablecell tc, celldef cd, tabledef td
    WHERE le_hb.legalentity_id = fd.legalentity_id AND le_hb.hyperionbase_id = fd.hyperionbase_id
    AND fd.fielddata_id = tc.fielddata_id AND tc.celldef_id = cd.celldef_id
    AND cd.tabledef_id = td.tabledef_id
    AND grs.fd_grpseq = fd.fielddata_parent_row_sequence
    and grs.prs_key = fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_parent_row_sequence)
    AND cd.celldef_adjustable_ind = 'Y'
    AND fd.fielddata_delete_ind = 'N'
    AND td.tabledef_id = 2265
    GROUP BY cd.celldef_id, fedtaxpk.fedtaxpk_pkg.GETFIELDDATAGROUPSEQKEY(fd.fielddata_group_sequence),
    grs.prs_key
    SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fdk.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
    'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
    cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
    cd.celldef_column_sequence, cd.celldef_column_label,
    cd.celldef_column_sort_order, NULL tablecell_id, fdk.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
    'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
    TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
    fdk.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
    fdk.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
    TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
    fdk.fd_key
    FROM fdk, celldef cd, appusageaccess aua, au
    WHERE fdk.celldef_id = cd.celldef_id
    AND cd.celldef_id = aua.celldef_id
    AND aua.appusage_code = au.appusage_code
    AND fdk.rn = 1
    UNION ALL
    SELECT NULL LEGALENTITY_ID, NULL hyperionbase_id, fda.celldef_id, TO_CHAR(NULL) role_code, NULL userinfo_id, cd.celldef_adjustable_ind,
    'N' celldef_editable_ind, cd.celldef_filter_code, cd.celldef_validate_rule, cd.celldef_list_code,
    cd.celldef_longstring_ind, aua.appusageaccess_visible_ind celldef_viewable_ind,
    cd.celldef_column_sequence, cd.celldef_column_label,
    cd.celldef_column_sort_order, NULL tablecell_id, fda.fd_grpseq tablecell_row_sequence, NULL tablecell_row_label,
    'N' tablecell_delete_ind, NULL tablecell_create_by, TO_DATE(NULL) tablecell_create_dt, TO_CHAR(NULL) tablecell_update_by,
    TO_DATE(NULL) tablecell_update_dt, NULL fielddata_id, TO_CHAR(NULL) datatype_code, NULL fielddata_adjref_id,
    fda.fd_grpseq fielddata_group_sequence, NULL fielddata_parent_row_sequence, NULL lookup_id,
    fda.fd_val fielddata_value, 'N' fielddata_delete_ind, TO_CHAR(NULL) fielddata_create_by,
    TO_DATE(NULL) fielddata_create_dt, TO_CHAR(NULL) fielddata_update_by, TO_DATE(NULL) fielddata_update_dt,
    fda.fd_key
    FROM fda, celldef cd, appusageaccess aua, au
    WHERE fda.celldef_id = cd.celldef_id
    AND cd.celldef_id = aua.celldef_id
    AND aua.appusage_code = au.appusage_code
    ORDER BY fielddata_group_sequence, celldef_column_sequence
    Query Plan:
    Plan hash value: 522363234
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 6227 | 249 (2)| 00:00:03 |
    | 1 | TEMP TABLE TRANSFORMATION | | | | | |
    | 2 | LOAD AS SELECT | | | | | |
    |* 3 | TABLE ACCESS BY INDEX ROWID | TAXGROUP | 1 | 14 | 1 (0)| 00:00:01 |
    |* 4 | INDEX UNIQUE SCAN | PK_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    | 5 | LOAD AS SELECT | | | | | |
    | 6 | SORT UNIQUE | | 4 | 224 | 12 (59)| 00:00:01 |
    | 7 | UNION-ALL | | | | | |
    | 8 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 1 | 29 | 2 (0)| 00:00:01 |
    | 9 | NESTED LOOPS | | 1 | 56 | 5 (0)| 00:00:01 |
    | 10 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
    | 11 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
    | 12 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    |* 13 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
    |* 14 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    |* 15 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 1 | | 1 (0)| 00:00:01 |
    | 16 | TABLE ACCESS BY INDEX ROWID | ORGUNIT | 3 | 87 | 2 (0)| 00:00:01 |
    | 17 | NESTED LOOPS | | 3 | 168 | 5 (0)| 00:00:01 |
    | 18 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
    | 19 | VIEW | | 1 | 10 | 2 (0)| 00:00:01 |
    | 20 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B51_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    |* 21 | TABLE ACCESS BY INDEX ROWID | TAXGROUPITEM | 1 | 17 | 1 (0)| 00:00:01 |
    |* 22 | INDEX RANGE SCAN | XF1_TAXGROUPITEM_TAXGROUP | 1 | | 0 (0)| 00:00:01 |
    |* 23 | INDEX RANGE SCAN | XF1_ORGUNIT_ID | 3 | | 1 (0)| 00:00:01 |
    | 24 | LOAD AS SELECT | | | | | |
    |* 25 | INDEX UNIQUE SCAN | PK_APPUSAGE | 1 | 10 | 0 (0)| 00:00:01 |
    | 26 | LOAD AS SELECT | | | | | |
    |* 27 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 7 | 147 | 28 (0)| 00:00:01 |
    | 28 | NESTED LOOPS | | 27 | 1269 | 117 (1)| 00:00:02 |
    | 29 | NESTED LOOPS | | 4 | 104 | 4 (0)| 00:00:01 |
    | 30 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 |
    | 31 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 32 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 33 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 34 | SORT ORDER BY | | 2 | 6227 | 248 (51)| 00:00:03 |
    | 35 | UNION-ALL | | | | | |
    | 36 | NESTED LOOPS | | 1 | 4110 | 125 (2)| 00:00:02 |
    | 37 | MERGE JOIN CARTESIAN | | 1 | 4093 | 124 (2)| 00:00:02 |
    | 38 | NESTED LOOPS | | 1 | 4076 | 122 (2)| 00:00:02 |
    |* 39 | VIEW | | 1 | 4043 | 121 (2)| 00:00:02 |
    |* 40 | WINDOW SORT PUSHED RANK | | 1 | 2099 | 121 (2)| 00:00:02 |
    | 41 | MERGE JOIN CARTESIAN | | 1 | 2099 | 120 (1)| 00:00:02 |
    | 42 | NESTED LOOPS | | 1 | 2099 | 119 (1)| 00:00:02 |
    | 43 | NESTED LOOPS | | 1 | 2088 | 118 (1)| 00:00:02 |
    |* 44 | HASH JOIN | | 1 | 2077 | 117 (1)| 00:00:02 |
    |* 45 | TABLE ACCESS BY INDEX ROWID| FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
    | 46 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
    | 47 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
    |* 48 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
    | 49 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 50 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 51 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 52 | VIEW | | 27 | 54405 | 2 (0)| 00:00:01 |
    | 53 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
    | 54 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
    |* 55 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
    |* 56 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
    |* 57 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 58 | BUFFER SORT | | 5 | | 120 (2)| 00:00:02 |
    | 59 | INDEX FULL SCAN | PK_APPUSAGE | 5 | | 1 (0)| 00:00:01 |
    | 60 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
    |* 61 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 62 | BUFFER SORT | | 1 | 17 | 123 (2)| 00:00:02 |
    | 63 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
    | 64 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    | 65 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
    |* 66 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
    | 67 | NESTED LOOPS | | 1 | 2117 | 124 (2)| 00:00:02 |
    | 68 | MERGE JOIN CARTESIAN | | 1 | 2100 | 123 (2)| 00:00:02 |
    | 69 | NESTED LOOPS | | 1 | 2083 | 121 (2)| 00:00:02 |
    | 70 | VIEW | | 1 | 2050 | 120 (2)| 00:00:02 |
    | 71 | HASH GROUP BY | | 1 | 2091 | 120 (2)| 00:00:02 |
    | 72 | NESTED LOOPS | | 1 | 2091 | 119 (1)| 00:00:02 |
    | 73 | NESTED LOOPS | | 1 | 2080 | 118 (1)| 00:00:02 |
    |* 74 | HASH JOIN | | 1 | 2069 | 117 (1)| 00:00:02 |
    |* 75 | TABLE ACCESS BY INDEX ROWID | FIELDDATA | 117 | 3744 | 28 (0)| 00:00:01 |
    | 76 | NESTED LOOPS | | 466 | 28892 | 114 (0)| 00:00:02 |
    | 77 | NESTED LOOPS | | 4 | 120 | 2 (0)| 00:00:01 |
    |* 78 | INDEX UNIQUE SCAN | PK_TABLEDEF | 1 | 4 | 0 (0)| 00:00:01 |
    | 79 | VIEW | | 4 | 104 | 2 (0)| 00:00:01 |
    | 80 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B52_2EBE182 | 4 | 388 | 2 (0)| 00:00:01 |
    |* 81 | INDEX RANGE SCAN | XF11_DATA_LE_HB | 117 | | 12 (0)| 00:00:01 |
    | 82 | VIEW | | 27 | 54189 | 2 (0)| 00:00:01 |
    | 83 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B54_2EBE182 | 27 | 1269 | 2 (0)| 00:00:01 |
    | 84 | TABLE ACCESS BY INDEX ROWID | TABLECELL | 1 | 11 | 1 (0)| 00:00:01 |
    |* 85 | INDEX UNIQUE SCAN | XF1_TBLCEL_DATA | 1 | | 0 (0)| 00:00:01 |
    |* 86 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 11 | 1 (0)| 00:00:01 |
    |* 87 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 88 | TABLE ACCESS BY INDEX ROWID | CELLDEF | 1 | 33 | 1 (0)| 00:00:01 |
    |* 89 | INDEX UNIQUE SCAN | PK_CELLDEF | 1 | | 0 (0)| 00:00:01 |
    | 90 | BUFFER SORT | | 1 | 17 | 122 (2)| 00:00:02 |
    | 91 | VIEW | | 1 | 17 | 2 (0)| 00:00:01 |
    | 92 | TABLE ACCESS FULL | SYS_TEMP_0FD9D9B53_2EBE182 | 1 | 10 | 2 (0)| 00:00:01 |
    | 93 | TABLE ACCESS BY INDEX ROWID | APPUSAGEACCESS | 1 | 17 | 1 (0)| 00:00:01 |
    |* 94 | INDEX UNIQUE SCAN | AK_APPUSAGEACCESS | 1 | | 0 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
    4 - access("TAXGROUP_CODE"='TAXGROUP2')
    13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
    14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
    15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
    21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
    22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
    23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
    25 - access("APPUSAGE_CODE"='CONSOLIDATION')
    27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
    THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
    SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
    5),':')-1) END )
    33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    39 - filter("FDK"."RN"=1)
    40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
    ."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
    44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
    "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
    45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
    48 - access("TD"."TABLEDEF_ID"=2265)
    51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
    56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
    57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
    61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
    66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
    74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
    "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
    75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
    78 - access("TD"."TABLEDEF_ID"=2265)
    81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
    "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
    85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
    86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
    87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
    89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
    94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")

    Thanks cd.
    Here's the query plan:
    Query Plan:
    Plan hash value: 522363234
    | Id  | Operation                               | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                        |                            |     2 |  6227 |   249   (2)| 00:00:03 |
    |   1 |  TEMP TABLE TRANSFORMATION              |                            |       |       |            |          |
    |   2 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |*  3 |    TABLE ACCESS BY INDEX ROWID          | TAXGROUP                   |     1 |    14 |     1   (0)| 00:00:01 |
    |*  4 |     INDEX UNIQUE SCAN                   | PK_TAXGROUP                |     1 |       |     0   (0)| 00:00:01 |
    |   5 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |   6 |    SORT UNIQUE                          |                            |     4 |   224 |    12  (59)| 00:00:01 |
    |   7 |     UNION-ALL                           |                            |       |       |            |          |
    |   8 |      TABLE ACCESS BY INDEX ROWID        | ORGUNIT                    |     1 |    29 |     2   (0)| 00:00:01 |
    |   9 |       NESTED LOOPS                      |                            |     1 |    56 |     5   (0)| 00:00:01 |
    |  10 |        NESTED LOOPS                     |                            |     1 |    27 |     3   (0)| 00:00:01 |
    |  11 |         VIEW                            |                            |     1 |    10 |     2   (0)| 00:00:01 |
    |  12 |          TABLE ACCESS FULL              | SYS_TEMP_0FD9D9B51_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |* 13 |         TABLE ACCESS BY INDEX ROWID     | TAXGROUPITEM               |     1 |    17 |     1   (0)| 00:00:01 |
    |* 14 |          INDEX RANGE SCAN               | XF1_TAXGROUPITEM_TAXGROUP  |     1 |       |     0   (0)| 00:00:01 |
    |* 15 |        INDEX RANGE SCAN                 | XF1_ORGUNIT_ID             |     1 |       |     1   (0)| 00:00:01 |
    |  16 |      TABLE ACCESS BY INDEX ROWID        | ORGUNIT                    |     3 |    87 |     2   (0)| 00:00:01 |
    |  17 |       NESTED LOOPS                      |                            |     3 |   168 |     5   (0)| 00:00:01 |
    |  18 |        NESTED LOOPS                     |                            |     1 |    27 |     3   (0)| 00:00:01 |
    |  19 |         VIEW                            |                            |     1 |    10 |     2   (0)| 00:00:01 |
    |  20 |          TABLE ACCESS FULL              | SYS_TEMP_0FD9D9B51_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |* 21 |         TABLE ACCESS BY INDEX ROWID     | TAXGROUPITEM               |     1 |    17 |     1   (0)| 00:00:01 |
    |* 22 |          INDEX RANGE SCAN               | XF1_TAXGROUPITEM_TAXGROUP  |     1 |       |     0   (0)| 00:00:01 |
    |* 23 |        INDEX RANGE SCAN                 | XF1_ORGUNIT_ID             |     3 |       |     1   (0)| 00:00:01 |
    |  24 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |* 25 |    INDEX UNIQUE SCAN                    | PK_APPUSAGE                |     1 |    10 |     0   (0)| 00:00:01 |
    |  26 |   LOAD AS SELECT                        |                            |       |       |            |          |
    |* 27 |    TABLE ACCESS BY INDEX ROWID          | FIELDDATA                  |     7 |   147 |    28   (0)| 00:00:01 |
    |  28 |     NESTED LOOPS                        |                            |    27 |  1269 |   117   (1)| 00:00:02 |
    |  29 |      NESTED LOOPS                       |                            |     4 |   104 |     4   (0)| 00:00:01 |
    |  30 |       FAST DUAL                         |                            |     1 |       |     2   (0)| 00:00:01 |
    |  31 |       VIEW                              |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  32 |        TABLE ACCESS FULL                | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 33 |      INDEX RANGE SCAN                   | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  34 |   SORT ORDER BY                         |                            |     2 |  6227 |   248  (51)| 00:00:03 |
    |  35 |    UNION-ALL                            |                            |       |       |            |          |
    |  36 |     NESTED LOOPS                        |                            |     1 |  4110 |   125   (2)| 00:00:02 |
    |  37 |      MERGE JOIN CARTESIAN               |                            |     1 |  4093 |   124   (2)| 00:00:02 |
    |  38 |       NESTED LOOPS                      |                            |     1 |  4076 |   122   (2)| 00:00:02 |
    |* 39 |        VIEW                             |                            |     1 |  4043 |   121   (2)| 00:00:02 |
    |* 40 |         WINDOW SORT PUSHED RANK         |                            |     1 |  2099 |   121   (2)| 00:00:02 |
    |  41 |          MERGE JOIN CARTESIAN           |                            |     1 |  2099 |   120   (1)| 00:00:02 |
    |  42 |           NESTED LOOPS                  |                            |     1 |  2099 |   119   (1)| 00:00:02 |
    |  43 |            NESTED LOOPS                 |                            |     1 |  2088 |   118   (1)| 00:00:02 |
    |* 44 |             HASH JOIN                   |                            |     1 |  2077 |   117   (1)| 00:00:02 |
    |* 45 |              TABLE ACCESS BY INDEX ROWID| FIELDDATA                  |   117 |  3744 |    28   (0)| 00:00:01 |
    |  46 |               NESTED LOOPS              |                            |   466 | 28892 |   114   (0)| 00:00:02 |
    |  47 |                NESTED LOOPS             |                            |     4 |   120 |     2   (0)| 00:00:01 |
    |* 48 |                 INDEX UNIQUE SCAN       | PK_TABLEDEF                |     1 |     4 |     0   (0)| 00:00:01 |
    |  49 |                 VIEW                    |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  50 |                  TABLE ACCESS FULL      | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 51 |                INDEX RANGE SCAN         | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  52 |              VIEW                       |                            |    27 | 54405 |     2   (0)| 00:00:01 |
    |  53 |               TABLE ACCESS FULL         | SYS_TEMP_0FD9D9B54_2EBE182 |    27 |  1269 |     2   (0)| 00:00:01 |
    |  54 |             TABLE ACCESS BY INDEX ROWID | TABLECELL                  |     1 |    11 |     1   (0)| 00:00:01 |
    |* 55 |              INDEX UNIQUE SCAN          | XF1_TBLCEL_DATA            |     1 |       |     0   (0)| 00:00:01 |
    |* 56 |            TABLE ACCESS BY INDEX ROWID  | CELLDEF                    |     1 |    11 |     1   (0)| 00:00:01 |
    |* 57 |             INDEX UNIQUE SCAN           | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  58 |           BUFFER SORT                   |                            |     5 |       |   120   (2)| 00:00:02 |
    |  59 |            INDEX FULL SCAN              | PK_APPUSAGE                |     5 |       |     1   (0)| 00:00:01 |
    |  60 |        TABLE ACCESS BY INDEX ROWID      | CELLDEF                    |     1 |    33 |     1   (0)| 00:00:01 |
    |* 61 |         INDEX UNIQUE SCAN               | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  62 |       BUFFER SORT                       |                            |     1 |    17 |   123   (2)| 00:00:02 |
    |  63 |        VIEW                             |                            |     1 |    17 |     2   (0)| 00:00:01 |
    |  64 |         TABLE ACCESS FULL               | SYS_TEMP_0FD9D9B53_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |  65 |      TABLE ACCESS BY INDEX ROWID        | APPUSAGEACCESS             |     1 |    17 |     1   (0)| 00:00:01 |
    |* 66 |       INDEX UNIQUE SCAN                 | AK_APPUSAGEACCESS          |     1 |       |     0   (0)| 00:00:01 |
    |  67 |     NESTED LOOPS                        |                            |     1 |  2117 |   124   (2)| 00:00:02 |
    |  68 |      MERGE JOIN CARTESIAN               |                            |     1 |  2100 |   123   (2)| 00:00:02 |
    |  69 |       NESTED LOOPS                      |                            |     1 |  2083 |   121   (2)| 00:00:02 |
    |  70 |        VIEW                             |                            |     1 |  2050 |   120   (2)| 00:00:02 |
    |  71 |         HASH GROUP BY                   |                            |     1 |  2091 |   120   (2)| 00:00:02 |
    |  72 |          NESTED LOOPS                   |                            |     1 |  2091 |   119   (1)| 00:00:02 |
    |  73 |           NESTED LOOPS                  |                            |     1 |  2080 |   118   (1)| 00:00:02 |
    |* 74 |            HASH JOIN                    |                            |     1 |  2069 |   117   (1)| 00:00:02 |
    |* 75 |             TABLE ACCESS BY INDEX ROWID | FIELDDATA                  |   117 |  3744 |    28   (0)| 00:00:01 |
    |  76 |              NESTED LOOPS               |                            |   466 | 28892 |   114   (0)| 00:00:02 |
    |  77 |               NESTED LOOPS              |                            |     4 |   120 |     2   (0)| 00:00:01 |
    |* 78 |                INDEX UNIQUE SCAN        | PK_TABLEDEF                |     1 |     4 |     0   (0)| 00:00:01 |
    |  79 |                VIEW                     |                            |     4 |   104 |     2   (0)| 00:00:01 |
    |  80 |                 TABLE ACCESS FULL       | SYS_TEMP_0FD9D9B52_2EBE182 |     4 |   388 |     2   (0)| 00:00:01 |
    |* 81 |               INDEX RANGE SCAN          | XF11_DATA_LE_HB            |   117 |       |    12   (0)| 00:00:01 |
    |  82 |             VIEW                        |                            |    27 | 54189 |     2   (0)| 00:00:01 |
    |  83 |              TABLE ACCESS FULL          | SYS_TEMP_0FD9D9B54_2EBE182 |    27 |  1269 |     2   (0)| 00:00:01 |
    |  84 |            TABLE ACCESS BY INDEX ROWID  | TABLECELL                  |     1 |    11 |     1   (0)| 00:00:01 |
    |* 85 |             INDEX UNIQUE SCAN           | XF1_TBLCEL_DATA            |     1 |       |     0   (0)| 00:00:01 |
    |* 86 |           TABLE ACCESS BY INDEX ROWID   | CELLDEF                    |     1 |    11 |     1   (0)| 00:00:01 |
    |* 87 |            INDEX UNIQUE SCAN            | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  88 |        TABLE ACCESS BY INDEX ROWID      | CELLDEF                    |     1 |    33 |     1   (0)| 00:00:01 |
    |* 89 |         INDEX UNIQUE SCAN               | PK_CELLDEF                 |     1 |       |     0   (0)| 00:00:01 |
    |  90 |       BUFFER SORT                       |                            |     1 |    17 |   122   (2)| 00:00:02 |
    |  91 |        VIEW                             |                            |     1 |    17 |     2   (0)| 00:00:01 |
    |  92 |         TABLE ACCESS FULL               | SYS_TEMP_0FD9D9B53_2EBE182 |     1 |    10 |     2   (0)| 00:00:01 |
    |  93 |      TABLE ACCESS BY INDEX ROWID        | APPUSAGEACCESS             |     1 |    17 |     1   (0)| 00:00:01 |
    |* 94 |       INDEX UNIQUE SCAN                 | AK_APPUSAGEACCESS          |     1 |       |     0   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
       3 - filter("TAXGROUP_DELETE_IND"='N' AND "TAXGROUP_ACTIVE_IND"='A')
       4 - access("TAXGROUP_CODE"='TAXGROUP2')
      13 - filter("TGI"."HYPERIONBASE_ID" IS NOT NULL)
      14 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
      15 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID" AND "TGI"."HYPERIONBASE_ID"="OU"."HYPERIONBASE_ID")
      21 - filter("TGI"."HYPERIONBASE_ID" IS NULL)
      22 - access("TG"."TAXGROUP_CODE"="TGI"."TAXGROUP_CODE")
      23 - access("TGI"."LEGALENTITY_ID"="OU"."ORGUNIT_ID")
      25 - access("APPUSAGE_CODE"='CONSOLIDATION')
      27 - filter("FD"."FIELDDATA_VALUE"=CASE INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),':') WHEN 0
                  THEN "FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415) ELSE
                  SUBSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(164415),1,INSTR("FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"(16441
                  5),':')-1) END )
      33 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      39 - filter("FDK"."RN"=1)
      40 - filter(ROW_NUMBER() OVER ( PARTITION BY "CD"."CELLDEF_ID","FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"
                  ."FIELDDATA_GROUP_SEQUENCE") ORDER BY "FD"."FIELDDATA_GROUP_SEQUENCE")<=1)
      44 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
                  "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
      45 - filter("FD"."FIELDDATA_DELETE_IND"='N')
      48 - access("TD"."TABLEDEF_ID"=2265)
      51 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      55 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
      56 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_KEY_IND"='Y')
      57 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
      61 - access("FDK"."CELLDEF_ID"="CD"."CELLDEF_ID")
      66 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")
      74 - access("GRS"."FD_GRPSEQ"="FD"."FIELDDATA_PARENT_ROW_SEQUENCE" AND
                  "GRS"."PRS_KEY"="FEDTAXPK_PKG"."GETFIELDDATAGROUPSEQKEY"("FD"."FIELDDATA_PARENT_ROW_SEQUENCE"))
      75 - filter("FD"."FIELDDATA_DELETE_IND"='N')
      78 - access("TD"."TABLEDEF_ID"=2265)
      81 - access("LE_HB"."LEGALENTITY_ID"="FD"."LEGALENTITY_ID" AND
                  "LE_HB"."HYPERIONBASE_ID"="FD"."HYPERIONBASE_ID")
      85 - access("FD"."FIELDDATA_ID"="TC"."FIELDDATA_ID")
      86 - filter("CD"."TABLEDEF_ID"=2265 AND "CD"."CELLDEF_ADJUSTABLE_IND"='Y')
      87 - access("TC"."CELLDEF_ID"="CD"."CELLDEF_ID")
      89 - access("FDA"."CELLDEF_ID"="CD"."CELLDEF_ID")
      94 - access("AUA"."APPUSAGE_CODE"="AU"."APPUSAGE_CODE" AND "CD"."CELLDEF_ID"="AUA"."CELLDEF_ID")

  • Optimizing query against Dictionary views

    I have some tables which contain varray of objects. I need a quick way to get a list of the attributes of each of those objects, and the data types they are.
    I came up with this query. It runs in 16 seconds in my database for a table with 2 varrays, each of an object with 2 attributes (4 rows returned). In the PL/SQL program needing this info, I have implemented a 3 cursors manual nested loop version of this that runs in sub-second.
    Just curious for curiosity's sake if anybody had any tips on how to speed the single query version?
    select
    dtc.owner table_owner
    ,dtc.table_name table_name
    ,dtc.column_name column_name
    ,dtc.data_type varray_type
    ,dct.elem_type_owner varray_element_owner
    ,dct.elem_type_name varray_element_type
    ,dct.upper_bound max_element_count
    ,dta.attr_name attribute_name
    ,dta.attr_type_name
    from all_tab_columns dtc
    ,all_coll_types dct
    ,all_type_attrs dta
    where dtc.owner = :OWNER
    and dtc.table_name = :TABLE_NAME
    and dtc.data_type_owner is not null
    and dtc.data_type_owner = dct.owner
    and dtc.data_type = dct.type_name
    and dct.elem_type_owner = dta.owner
    and dct.elem_type_name = dta.type_name;

    1. You can check if your current optimizer setting affects this query: Just set for your particular session the "optimizer_features_enable" back to the default "10.2.0.4" using ALTER SESSION or use the "OPTIMIZER_FEATURES_ENABLE('10.2.0.4')" hint (undocumented, so better use the ALTER SESSION command) as part of your statement to check if the execution is any different.
    2. Are you aware of any other optimizer related parameters that are set to non-default values?
    3. Can you check in the DBA_SCHEDULER_JOBS view if the GATHER_STATS_JOB is ENABLED and the LAST_START_DATE of the job?
    4. Sometimes you can help the optimizer by providing more information, although in this case it's a bit inaccurate, because the TYPE owner might of course be different from the table owner:
    select
    dtc.owner table_owner
    ,dtc.table_name table_name
    ,dtc.column_name column_name
    ,dtc.data_type varray_type
    ,dct.elem_type_owner varray_element_owner
    ,dct.elem_type_name varray_element_type
    ,dct.upper_bound max_element_count
    ,dta.attr_name attribute_name
    ,dta.attr_type_name
    from all_tab_columns dtc
    ,all_coll_types dct
    ,all_type_attrs dta
    where dtc.owner = :OWNER
    and dtc.table_name = :TABLE_NAME
    and dtc.data_type_owner is not null
    and dtc.data_type_owner = dct.owner
    and dct.owner = :OWNER
    and dtc.data_type = dct.type_name
    and dct.elem_type_owner = dta.owner
    and dta.owner = :OWNER
    and dct.elem_type_name = dta.type_name;As already mentioned, this is only applicable if the owner is the same for all the objects. You could also try to omit the join on the owner and use only the bind variables as shown.
    5. Can you post your "tuning" attempt? I assume you tried to use the WITH-clause and the (undocumented) MATERIALIZE hint to materialize a part of the query?
    6. Are you aware of any unusual high number of dictionary objects in your database, e.g. thousands of tables, types, synonyms etc. that might lead to partially large SYS base tables, like SYS.OBJ$?
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • BITAND optimized query

    Hi,
    I need to optimize this simple query:
    select * from tabl1 where bitand(x, col1) != 0;
    col1 is just an integer type that contains a bit map value.
    An index on col1 does not do the job I always end up with full table scan. Does an Function Based Index help me out?
    I need a helping hand,
    Thanks,
    Dieter

    Did you try a function based index?
    Something like
    CREATE INDEX IDX_TABLE1_BITAND_COL1 ON TABLE1 BITAND(X, COL1);
    Anyway, the execution plan depends on many parameters. You need to add details.
    Maybe the full table scan is the best strategy (or the only one available)
    Warning: create an index for just one query can impact your inserts, updates and deletes.

  • Can anyone give me a optimized Query replaced by This query::

    SELECT user.user_id
    FROM user
    where user.group_id =1
    and user.user_id IN (SELECT user_id FROM technician_schedule WHERE day_id IN (1,2) GROUP BY user_id HAVING count( day_id ) =2)
    AND user.user_id IN (SELECT user_id FROM technician_certification WHERE certification_id=33)
    AND user.user_id IN (SELECT user_id FROM technician_sc WHERE service_category_id IN ( 1, 5, 8, 9, 10 ) GROUP BY user_id HAVING count( service_category_id)=5)
    AND user.user_id IN (SELECT user_id FROM technician_tool WHERE tool_id IN ( 1, 3, 4, 5 ) GROUP BY user_id HAVING count( tool_id ) =4)
    ORDER BY user.user_id
    Message was edited by:
    [email protected]

    No guarantees, but this may be faster:
    SELECT user_id
    FROM user
    WHERE group_id = 1
    INTERSECT
    SELECT user_id
    FROM technician_schedule
    WHERE day_id IN (1,2)
    GROUP BY user_id
    HAVING COUNT(*) = 2
    INTERSECT
    SELECT user_id
    FROM technician_certification
    WHERE certification_id = 33
    INTERSECT
    SELECT user_id
    FROM technician_sc
    WHERE service_category_id IN ( 1, 5, 8, 9, 10 )
    GROUP BY user_id
    HAVING COUNT(*) = 5
    INTERSECT
    SELECT user_id
    FROM technician_tool
    WHERE tool_id IN ( 1, 3, 4, 5 )
    GROUP BY user_id
    HAVING COUNT(*) = 4
    ORDER BY user_idTTFN
    John

  • How to measure the performance of sql query?

    Hi Experts,
    How to measure the performance, efficiency and cpu cost of a sql query?
    What are all the measures available for an sql query?
    How to identify i am writing optimal query?
    I am using Oracle 9i...
    It ll be useful for me to write efficient query....
    Thanks & Regards

    psram wrote:
    Hi Experts,
    How to measure the performance, efficiency and cpu cost of a sql query?
    What are all the measures available for an sql query?
    How to identify i am writing optimal query?
    I am using Oracle 9i... You might want to start with a feature of SQL*Plus: The AUTOTRACE (TRACEONLY) option which executes your statement, fetches all records (if there is something to fetch) and shows you some basic statistics information, which include the number of logical I/Os performed, number of sorts etc.
    This gives you an indication of the effectiveness of your statement, so that can check how many logical I/Os (and physical reads) had to be performed.
    Note however that there are more things to consider, as you've already mentioned: The CPU bit is not included in these statistics, and the work performed by SQL workareas (e.g. by hash joins) is also credited only very limited (number of sorts), but e.g. it doesn't cover any writes to temporary segments due to sort or hash operations spilling to disk etc.
    You can use the following approach to get a deeper understanding of the operations performed by each row source:
    alter session set statistics_level=all;
    alter session set timed_statistics = true;
    select /* findme */ ... <your query here>
    SELECT
             SUBSTR(LPAD(' ',DEPTH - 1)||OPERATION||' '||OBJECT_NAME,1,40) OPERATION,
             OBJECT_NAME,
             CARDINALITY,
             LAST_OUTPUT_ROWS,
             LAST_CR_BUFFER_GETS,
             LAST_DISK_READS,
             LAST_DISK_WRITES,
    FROM     V$SQL_PLAN_STATISTICS_ALL P,
             (SELECT *
              FROM   (SELECT   *
                      FROM     V$SQL
                      WHERE    SQL_TEXT LIKE '%findme%'
                               AND SQL_TEXT NOT LIKE '%V$SQL%'
                               AND PARSING_USER_ID = SYS_CONTEXT('USERENV','CURRENT_USERID')
                      ORDER BY LAST_LOAD_TIME DESC)
              WHERE  ROWNUM < 2) S
    WHERE    S.HASH_VALUE = P.HASH_VALUE
             AND S.CHILD_NUMBER = P.CHILD_NUMBER
    ORDER BY ID
    /Check the V$SQL_PLAN_STATISTICS_ALL view for more statistics available. In 10g there is a convenient function DBMS_XPLAN.DISPLAY_CURSOR which can show this information with a single call, but in 9i you need to do it yourself.
    Note that "statistics_level=all" adds a significant overhead to the processing, so use with care and only when required:
    http://jonathanlewis.wordpress.com/2007/11/25/gather_plan_statistics/
    http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • What are the best design requisites for a Query design?

    Hi Guru's
    Could you please let me know,which item will execute first when you run a query,I mean Calculated keyfigure,restricted keyfigure or formula  e,t,c...How does it effects the Query performance?What are the design requisites to optimise better query performance?
    Thanks in advance,
    rgds,
    Srini.

    Hi Srinivas....
    The design of queries can have a significant impact on the performance.
    Sometimes long running queries are the result of poor design, not just the amount
    of data. There are a number of design techniques that developers can use to
    provide optimal query performance.
    For example, in most cases characteristics should be placed in the rows and key
    figures in the columns. A characteristic should only be used in the columns in
    certain circumstances (like time). Characteristics having potentially many values
    (such as 0MATERIAL) must not be added to the columns without a filter or
    variables. Alternatively, it can be integrated into the query as a free characteristic
    – enabling it to be used in navigation.
    If a relatively detailed time characteristic, such as calendar day (0CALDAY) is
    added to the rows, the more aggregated time characteristics (such as calendar
    month (0CALMONTH)) and calendar year (0CALYEAR) should also be included
    in the free characteristics of the query. For most reports, a current period of time
    (current month, previous or current calendar year) is useful. For this reason, the
    use of variables is particularly relevant for time characteristics.
    To improve query performance
    1) Variables and drop down lists can improve query performance by making the
    data request more specific. This is very important for queries against Data Store
    Objects and InfoSets, which are not aggregated like InfoCubes.
    2) When using restricted key figures, filters or selections, try to avoid the Exclusion
    option if possible. Only characteristics in the inclusion can use database indexes.
    Characteristics in the exclusion cannot use indexes.
    3) When a query is run against a MultiProvider, all of InfoProviders in that
    MultiProvider are read. The selection of the InfoProviders in a MultiProvider
    query can be controlled by restricting the virtual characteristic 0INFOPROVIDER
    to only read the InfoProviders that are needed. In this way, there will be no
    unnecessary database reads.
    4) Defining calculated key figures at the InfoProvider level instead
    of the query level will improve query runtime performance, but may add
    time for data loads.
    5) Cell calculation by means of the cell editor generates separate queries at query
    runtime. Be cautious with cell calculations.
    6) Customer-specific code is necessary for virtual key figures and characteristics.
       Check Code in Customer Exits.
    7)Using graphics in queries, such as charts, can have a performance impact.
    Hope this helps.........
    Regards,
    Debjani.........

  • Issue While executing the Query for Pagination using ROWNUM with like

    Issue While executing the Query for Pagination using ROWNUM with like.
    Database is Oracle11G.
    Oracle Database Table contains 8-9 lakh records
    1) SQL equal (=)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE = 'KMF22600920'
    Execution Time:- 0.00869245 seconds
    Returns 2 resultsets
    2) SQL like (one %)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE = 'KMF22600920%'
    Execution Time:- 0.01094301 seconds
    Returns 2 resultsets
    3) SQL like (two%)
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE A.REFERENCE like '%KMF22600920%'
    Execution Time:- 6.43989658 seconds
    Returns 2 resultsets
    In Pagination, we are using Modified version of SQL Query 3) with ROWNUM as mentioned below :-
    4) SELECT * FROM (
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE REFERENCE like '%KMF22600920%' AND ROWNUM <= 20 ) WHERE RNUM > 0
    Execution Time:- Infinite
    ResultSets:- No as execution time is infinite
    a) Instead of like if we use = in the above query it is returning the 2 resultsets (execution time 0.02699282 seconds)
    b) Instead of two % in the above query, if use one example REFERENCE like 'KMF22600920%' it is returning the 2 resultsets (execution time 0.03313019 seconds)
    Issue:- When using two % in like in the above query i.e. REFERENCE like '%KMF22600920%' AND ROWNUM <= 20 ) , it is going to infinite.
    Could you please let us know what is the issue with two % used in like and rownum
    5) Modified version of Option1 query (move out the RNUM condition AND RNUM <= 20)
    SELECT * FROM (
    SELECT /*+ FIRST_ROWS(n) */ ROWNUM RNUM, A.* FROM LINE A
    WHERE REFERENCE like '%KMF22600920%' ) WHERE RNUM > 0 AND RNUM <= 20
    Execution Time:- 7.41368914 seconds
    Returns 2 resultsets
    Is the above query is best optimized query which should be used for the Pagination or still can improve on this ?

    This would be easier to diagnose if there was an explain plan posted for the 'good' and 'bad' queries. Generally speaking using '%' on both sides precludes the use of any indexes.

  • Querying data from 2 tables

    Hi, 
    I have two SCD Type 2 tables, as described below. 
    Table A
    [ID] [Name]
    [Internal UserID] [StartID] [EndID]
    1 John1
    1
    1 2
    2  John1-2
    1
    2
    4
    3 John1
    1
    4 10000
    Table B
    [ID] [Name]
      [Internal UserID] [StartID] [EndID]
    1 India
    1
    1 2
    2 China
    1
    2 4
    3 India
    1
    4 10000
    Can someone please suggest me what will be the optimal query to extract data from a particular ID (e.g. id between StartID &  EndID), by joining above 2 tables with join condition as "Internal UserID" equal in both the tables.
    Thanks,
    -Jack

    Hi,
    Sample code as follows :  
    CREATE TABLE [dbo].[tableA](
    [id] [int] NULL,
    [name] [varchar](50) NULL,
    [internaluserid] [int] NULL,
    [startid] [int] NULL,
    [endid] [int] NULL
    CREATE TABLE [dbo].[tableB](
    [id] [int] NULL,
    [addresss] [varchar](50) NULL,
    [internaluserid] [int] NULL,
    [startid] [int] NULL,
    [endid] [int] NULL
    insert into tableA values(1,'John1',1,1,2)
    insert into tableA values(2,'John1-2',1,2,4)
    insert into tableA values(3,'John1',1,4,10000)
    insert into tableB values(1,'India',1,1,2)
    insert into tableB values(2,'China',1,2,4)
    insert into tableB values(3,'India',1,4,10000)
    -----------OUTPUT expected for ID=3
    SELECT A.id,A.internaluserid,A.name,B.addresss
    from 
    (SELECT * FROM tableA WHERE 3 BETWEEN startid AND endid)A
    join 
    (SELECT * FROM tableB WHERE 3 BETWEEN startid AND endid) B
    on A.internaluserid = B.InternaluseriD
    Hi Russel, 
    Time taken by above query is very large if there are millions of rows involved, so i was hoping for any other way of extracting data, in optimal way.
    Thanks, 
    -Jack

  • Guidelines to create an optimized SQL queries

    Dear all,
    what is the basic strategy to create an optimized query? In the FAQ SQL and PL/SQL FAQ , it shows how to post a question on a query that needs to be optimized, but it doesn't tell how to with it. The Performance Tuning Guide for 11g rel 2 doc shows how access path works and how to read explain plan, but I cannot really find a basic guidelines to optimize query in general.
    Say I have a complex query that I need to optimized, I get all the info that the thread advise to like optimizer info, explain plan, tkprof dump, and so on. I determine the nature of the data that are being queried with their index. At this point what else I need to do? I cannot just post my query to OTN every time I bump into slow query.
    Best regards,
    Val

    I think that some of the most important guidelines are:
    1. ALWAYS create documentation that explains
    a. what the query is supposed to do - 'selects all records for employees that have stock options that are due to expire within 60 days'
    b. any special constructs/tricks used in the query. For example if you added one or more hints to the query explain why. If the query has
    a complex/compound CASE or DECODE statement add a one line comment explaining what it does.
    2. Gather as much information about the context the query runs in as possible.
    a. how much source data are we dealing with? Large tables or small?
    b. how large is the result set expected to be? A few records, thousands, millions?
    c. are they regular tables or partitioned tables?
    d. are the tables local or on remote servers?
    e. how often is the query executed? once in a blue moon or concurrently by large numbers of users?
    3. For existing queries always confirm that it is the query that actually needs to be tuned before trying to tune it. Too many times I have seen people trying to tune a query when it is actually another part of the process that needs to be tuned.
    4. Always test queries using realistic data - data and environment as close as possible to that which will be used in production.
    5. Always run an explain plan before, during and after you test the query. Save the final plan in a repository so that it is available for comparison if a problem later occurs that you suspect might be related to the query. It is easier to diagnose a possible degradation of performance if you have a previous execution plan to compare the current one to.
    6. Use common sense when writing/evaluating you query - if it looks too complicated it probably is. If you have trouble understanding or testing it the next person that comes along will probably have even more trouble.
    Hope that adds some to what the docs provide.

  • Query taking longtime to run

    Hi Gurus,
    We have created a query on a InfoCube and when I run it in query designer its taking long time to get the results and final report.
    How can I optimize the performance ? Please let me know what would be the measures for optimizing query performance.
    Thanks in advance,
    sudhakar.

    Hi,
    Query performance can be tuned once you have an idea of its potential usage pattern.
    Starting from query properties (Read mode - very important setting, and cache settings) to drill down pattern, everything matters.
    On DB level (your data model - Cube/Aggregate/Indices) can impact the query performance. Some help can be had by using turning on DB statistics.
    On OLAP level - your olap level processing (conditions/exceptions/virtualKF/Char/Variable processing/Global cache etc) adds to the performance overhead and you can finetune these to improve query performance.
    On GUI level - Definition of query (too much data will load the network) may impact the performance. In addition (this is from Teched session I attended), Excel has more overhead on GUI level as compared to http, and so at times, using a wb based report may perform better than excel based queries.
    In addition, you can think of pre-calculated web templates to provide faster reports to users (if drill-down is not required). Also, some other techniques (eg if a report is executed many times and is resource intensive, you can schedule this report once after the data refresh and keep its global cache on, so this report is available in the main memory and every subsequent execution will fetch it from OLAP itself and will be much faster).
    In addition to RSRT, ST05 (sql trace), SE30 (runtime analysis) and system statistics (ST03) may help you in identifying performance issues with a report.
    Also check this thread:
    Query BW tahckes too much time to runn
    Regards
    Lavanya

  • How to test SQL query performance - realiably?

    I have certain queries and I want to test which one is faster, and how big is the difference.
    How can I do this reliably?
    The problem is, when I execute the queries, Oracle does it's caching and execution planning and whatnot, and results of the queries are dependent on the order I execute them.
    Example: query A and query B, supposed to return same data.
    query A, run 1: 587 seconds
    query A, run 2: 509 seconds
    query B, run 1: 474 seconds
    query B, run 2: 451 seconds
    It would seem that A is somewhat faster than B, but if I change the order and execute B before A, results are different.
    Also I'm running the queries in SQL Developer, and it only returns 100 first lines, how can I remove this effect and simulate real scenario where all lines are fetched?
    I can also use EXPLAIN PLANs and look at the costs but I'm not sure how much I can trust those either. I understand they are only estimations and even if cost(a) = 1.5 * cost (b), b could still end up executing faster in practise due to inaccuracies in the cost calculation....right? EDIT: actually event if cost(a) = 5000 * cost(b), b can still execute faster.....seems like query A's cost is 15836 and B's cost is 3 while A seems to be faster in practise.
    Edited by: user620914 on 19-Jan-2010 01:42

    user620914 wrote:
    I have to say I don't understand your point either :)
    What are you saying, that people should not test their SQL performance? That tools such as autotrace are useless?No.. what I'm saying is that you need a baseline to make an informed decision about SQL performance.
    What does a 4 second SQL performance mean for query foo ? Nothing really.. wearing my dba cap I would point at that this is actually utterly useless for me to determine the impact of your query on production, or use it to determine how to scale it.
    If instead you tell me that is hits that table using an index range scan.. I know what it is doing and have a far better idea what it will do to the production instance.
    Thus my questioning this "+elapsed time+" measurement approach. I as a dba cannot use it... and I'm not sure what benefit (wearing my developer hat) you will find from it either.
    You can form your SQL queries better or worse, or select your table structure / indexes better or worse. Some choices may end up executing orders of magnitude slower than others. Obviously you can't get exact measurements "this query executes in 43123 ns" and there are a lot of unpredictable variables that affect the end performance. Still, it's often better to test your querie's / table's performance before implementing them in the application than not.Exactly. I'm not questioning the fact that optimising your code (and ALL your code, not just SQL) is a Good Thing (tm) - but how you go about that optimisation process.
    For example, your PL/SQL code fires off a query. It returns on average 10,000 rows, hits a single partition (SQL enables partitioning pruning) and then uses a local bitmap index to identify the rows.
    An optimal query by the sounds of it, and one that will perform and scale well.. even when the database instance needs to service a 100 clients using your code and running this query.
    Only, the code does a single bulk collect of all the rows and stuff it into dedicated process memory (PGA). Servicing a 100 clients means that dedicated server memory is now needed for 100x10000 rows - there's insufficient free memory, causing the kernel to start swapping pages in and out of memory heavily as all 100 client sessions are active and wanting to process the rows returned by the optimal query.
    What happens to scalability and performance now?
    Testing for performance is not simply measuring a query and then trying to use that or extrapolate that to determine application performance and the impact on production.
    It starts with the design of the tables, the design of the application, the writing of the code (application and SQL). It is not something that should be done after the fact as in "+okay, application all done, let's see how she performs!+".. and especially not using time as the baseline for performance measurement.

Maybe you are looking for

  • How to create multiple outecomes in workflow

    Hi Gurus, I am developing the PR workflow. and in that I want to create 2 different nodes for signle activity. how can I create those multiple outcomes for signel activity in workflow. Thanks in Advcance. Moderator message : Wrong forum, post the que

  • "You don't have write access"

    I'm trying to import a CD into my iTunes, and it tells me, "You don't have write access for your iTunes Media Folder or a folder within it. To change permissions..." blah blah blah. I've tried a few things I've googled, but nothing has worked. I thin

  • OrcaConfig - Good for SpiceHeads?

    Hey SpiceHeads - What do you think about OrcaConfig as a potential partner of Spiceworks? They have a software tool meant to help configuration management easy for your Windows web based applications. Please and Thank You This topic first appeared in

  • When approving email notifications the FireFox reply box has a 'K' in it..

    hi all.. As above. It is generates an email reply box but with a 'K' as recipient, and not linking to anything.. The user is using Firefox email app. Is it some setting? A pop-up blocker? Has anybody experienced this where users have been trying to a

  • System Refresh with HANA & HANA live (side-car) data

    In a scenario where HANA live co-exists with HANA DB (aka side-car approach), trying to understand the impact of system refreshes to HANA Live content. Is there a method to choose only HANA DB specific data for the refresh i.e. excluding HANA Live da