Interpreting the Explain plan

DB version : 10.2.0.4
After looking for Full Table Scan (in Large tables) , what is the next thing i should be looking for in an Explain Plan?

Take the explain plan as an idea a tourist has to collect a bunch of stuff in your hometown. You ( as a local guy) will see quite quickly if the idea of collecting everything on the main routes in big shops by car (hash join) or doing a walk in one or two streets with small shops (nested loop) will perform better. Stangers will not.
ORACLE already knows more about the data than a tourist about your hometome, so if it uses a method which is "suboptimal" it needs someone with good knowlage about the data to do better. So make sure you know your datamodel, contents, indexes, data and then you can help ORACLE with additional indexes, hints etc. without knowlege every plan of ORACLE can not be juged.

Similar Messages

  • How to change the explain plan for currently running query?

    Hi All,
    I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
    in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
    [code]
    SELECT /*+ USE_HASH (c,e,b,a) */
    d.att_fcc extrt_prod_dim_id,
    d.att_fcc compr_prod_dim_id,
      a.glbl_uniq_id glbl_uniq_id,
      to_date(c.dit_code,'RRRRMMDD')STRT_DT,
      (to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
      a.pat_nbr pat_id,
      a.rxer_id       rxer_id,
      e.rxer_geog_id  rxer_geog_id,
      a.pharmy_id pharmy_id,
      a.pscr_pack_id pscr_pack_id,
      a.dspnsd_pack_id dspnsd_pack_id,
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
      COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
    d.att_fcc
      ORDER BY c.dit_code) prodrank,
      DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
    d.att_fcc
      ORDER BY c.dit_code DESC) stoprank
      FROM
      pd_dimitems c,
       pd_pack_attribs   d ,
        lrx_tmp_rxer_geog e,
        lrx_tmp_pat_daterank p,
        lrx_tmp_valid_fact_link     a
        WHERE c.dit_id = a.tm_id
        AND   e.rxer_id = a.rxer_id
        AND   a.glbl_uniq_id = p.glbl_uniq_id
        AND   p.daterank > 1
      AND   a.pscr_pack_id = d.att_dit_id
    [/code]
    The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?

    Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
    Regards,

  • DECODE is changing the explain plan

    I have a statement with a decode function in the where clause like this:
    AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)When I a pass -1 as parameter for cropgroup the filter would result in "AND '-1' = '-1' and the statement is executed in less than 2 seconds. When I leave out this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan is so much different and why not using index scans in the statement without decode.
    Below the explain plans and tkprofs for 1 (without decode) and 2 (with decode).
    *explain 1*
    {code}
    SQL Statement which produced this data:
    select * from table(dbms_xplan.display)
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 7080 | 2413K| | 43611 (2)|
    | 1 | SORT ORDER BY | | 7080 | 2413K| 5224K| 43611 (2)|
    |* 2 | FILTER | | | | | |
    |* 3 | HASH JOIN | | 7156 | 2438K| | 43075 (2)|
    | 4 | TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745 | 363K| | 83 (0)|
    |* 5 | HASH JOIN OUTER | | 7156 | 2292K| | 42991 (2)|
    |* 6 | HASH JOIN | | 7156 | 1355K| | 42907 (2)|
    |* 7 | HASH JOIN | | 6987 | 1187K| | 19170 (2)|
    |* 8 | HASH JOIN | | 6947 | 963K| | 10376 (1)|
    |* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3 | 144 | | 3 (0)|
    | 10 | NESTED LOOPS | | 6907 | 897K| | 8577 (1)|
    |* 11 | HASH JOIN | | 2264 | 187K| | 1782 (2)|
    | 12 | TABLE ACCESS BY INDEX ROWID | SAMPLE | 190 | 4370 | | 17 (0)|
    | 13 | NESTED LOOPS | | 2264 | 152K| | 107 (1)|
    | 14 | NESTED LOOPS | | 12 | 552 | | 25 (0)|
    |* 15 | TABLE ACCESS FULL | SDG_USER | 12 | 288 | | 13 (0)|
    | 16 | TABLE ACCESS BY INDEX ROWID| SDG | 1 | 22 | | 1 (0)|
    |* 17 | INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0)|
    |* 18 | INDEX RANGE SCAN | FK_SAMPLE_SDG | 597 | | | 2 (0)|
    | 19 | TABLE ACCESS FULL | SAMPLE_USER | 1078K| 16M| | 1669 (1)|
    |* 20 | INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0)|
    | 21 | TABLE ACCESS FULL | ALIQUOT_USER | 3403K| 29M| | 1781 (3)|
    | 22 | TABLE ACCESS FULL | TEST | 3423K| 104M| | 8775 (2)|
    |* 23 | TABLE ACCESS FULL | RESULT | 3435K| 65M| | 23718 (2)|
    | 24 | VIEW | PLATE | 21787 | 2851K| | 84 (2)|
    |* 25 | FILTER | | | | | |
    | 26 | TABLE ACCESS FULL | PLATE | 21787 | 574K| | 84 (2)|
    |* 27 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
    |* 28 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
    |* 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
    |* 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
    |* 31 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
    Predicate Information (identified by operation id):
    2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
    "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID" IS NULL
    OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
    "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+
    */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND
    "GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
    "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
    3 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
    5 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
    6 - access("TEST_ID"="TEST_ID")
    7 - access("ALIQUOT_ID"="ALIQUOT_ID")
    8 - access("ALIQUOT_ID"="ALIQUOT_ID")
    9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
    11 - access("SAMPLE_ID"="SAMPLE_ID")
    15 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
    "U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR))
    17 - access("SDG_ID"="SDG_ID")
    18 - access("SDG_ID"="SDG_ID")
    20 - access("SAMPLE_ID"="SAMPLE_ID")
    23 - filter("NAME"='End result')
    25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
    "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
    27 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    28 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    30 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    31 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    Note
    - 'PLAN_TABLE' is old version
    {code}
    *tkprof 1*
    {code}
    TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Sort options: default
    count = number of times OCI procedure was executed
    cpu = cpu time in seconds executing
    elapsed = elapsed time in seconds executing
    disk = number of physical reads of buffers from disk
    query = number of buffers gotten for consistent read
    current = number of buffers gotten in current mode (usually for update)
    rows = number of rows processed by the fetch or execute call
    SELECT sdu.u_crop_group,
    sd.name as sdg_name,
    ad.variety_name,
    ad.batch_number,
    a.name as aliquot_name,
    sau.u_box_code as box_code,
    sau.u_box_position as box_position,
    t.name as test_name,
    r.original_result,
    plt.name as plate_name,
    concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
    au.u_replicate_number as replicate_number
    FROM lims_sys.sdg sd,
    lims_sys.sdg_user sdu,
    lims_sys.sample sa,
    lims_sys.sample_user sau,
    lims_sys.aliquot a,
    lims_sys.aliquot_user au,
    lims_sys.test t,
    lims_sys.result r,
    lims_sys.plate plt,
    lims_sys.abs_determination ad
    WHERE sd.sdg_id = sdu.sdg_id
    AND sd.sdg_id = sa.sdg_id
    AND sa.sample_id = sau.sample_id
    AND sau.sample_id = a.sample_id
    AND a.aliquot_id = au.aliquot_id
    AND au.aliquot_id = t.aliquot_id
    AND t.test_id = r.test_id
    AND plt.plate_id (+) = a.plate_id
    AND sdu.u_abs_determination = ad.determination_assignment
    AND a.status IN ('V','P','C')
    AND r.name = 'End result'
    AND sdu.u_client_type = 'QC'
    AND sdu.u_year_of_sample_delivery = (:year)
    AND sdu.u_week_of_processing = (:week)
    --AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    ORDER BY box_code, box_position, replicate_number
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 1.15 1.16 0 0 0 0
    Fetch 1 8.53 16.10 227649 241266 0 500
    total 3 9.68 17.27 227649 241266 0 500
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 97
    Rows Row Source Operation
    500 SORT ORDER BY (cr=241266 pr=227649 pw=0 time=16104631 us)
    21311 FILTER (cr=241266 pr=227649 pw=0 time=16246749 us)
    21311 HASH JOIN (cr=241266 pr=227649 pw=0 time=16225434 us)
    17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr=374 pr=0 pw=0 time=69 us)
    21311 HASH JOIN RIGHT OUTER (cr=240892 pr=227649 pw=0 time=16170607 us)
    21895 VIEW PLATE (cr=316 pr=0 pw=0 time=43825 us)
    21895 FILTER (cr=316 pr=0 pw=0 time=43823 us)
    21895 TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=31 us)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    21311 HASH JOIN (cr=240576 pr=227649 pw=0 time=16106174 us)
    21311 HASH JOIN (cr=133559 pr=121596 pw=0 time=9594130 us)
    21311 HASH JOIN (cr=94323 pr=83281 pw=0 time=6917067 us)
    21311 HASH JOIN (cr=86383 pr=75547 pw=0 time=5509672 us)
    7776 HASH JOIN (cr=8134 pr=0 pw=0 time=285364 us)
    7776 TABLE ACCESS BY INDEX ROWID SAMPLE (cr=572 pr=0 pw=0 time=27152 us)
    7876 NESTED LOOPS (cr=377 pr=0 pw=0 time=488287 us)
    99 HASH JOIN (cr=160 pr=0 pw=0 time=4168 us)
    99 TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1209 us)
    5719 TABLE ACCESS FULL SDG (cr=107 pr=0 pw=0 time=17 us)
    7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=623 us)(object id 45990)
    1079741 TABLE ACCESS FULL SAMPLE_USER (cr=7562 pr=0 pw=0 time=24 us)
    3307948 TABLE ACCESS FULL ALIQUOT (cr=78249 pr=75547 pw=0 time=3331129 us)
    3406836 TABLE ACCESS FULL ALIQUOT_USER (cr=7940 pr=7734 pw=0 time=556 us)
    3406832 TABLE ACCESS FULL TEST (cr=39236 pr=38315 pw=0 time=3413192 us)
    3406832 TABLE ACCESS FULL RESULT (cr=107017 pr=106053 pw=0 time=6848487 us)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    select 'x'
    from
    dual
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 0.00 0.00 0 0 0 1
    total 3 0.00 0.00 0 0 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 97
    Rows Row Source Operation
    1 FAST DUAL (cr=0 pr=0 pw=0 time=3 us)
    begin :id := sys.dbms_transaction.local_transaction_id; end;
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 1
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.00 0.00 0 0 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 97
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 3 0.00 0.00 0 0 0 0
    Execute 3 1.15 1.16 0 0 0 1
    Fetch 2 8.53 16.10 227649 241266 0 501
    total 8 9.68 17.27 227649 241266 0 502
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call count cpu elapsed disk query current rows
    Parse 30 0.00 0.00 0 0 0 0
    Execute 30 0.00 0.00 0 0 0 0
    Fetch 30 0.00 0.00 0 40 0 10
    total 90 0.00 0.00 0 40 0 10
    Misses in library cache during parse: 0
    3 user SQL statements in session.
    30 internal SQL statements in session.
    33 SQL statements in session.
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
    Trace file compatibility: 10.01.00
    Sort options: default
    8 sessions in tracefile.
    3 user SQL statements in trace file.
    30 internal SQL statements in trace file.
    33 SQL statements in trace file.
    6 unique SQL statements in trace file.
    633 lines in trace file.
    23 elapsed seconds in trace file.
    {code}

    explain 2
    SQL Statement which produced this data:
      select * from table(dbms_xplan.display)
    PLAN_TABLE_OUTPUT
    | Id  | Operation                               | Name                     | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                        |                          |    71 | 24779 |   857   (1)|
    |   1 |  SORT ORDER BY                          |                          |    71 | 24779 |   857   (1)|
    |*  2 |   FILTER                                |                          |       |       |            |
    |*  3 |    TABLE ACCESS BY INDEX ROWID          | RESULT                   |     1 |    20 |     4   (0)|
    |   4 |     NESTED LOOPS                        |                          |    72 | 25128 |   856   (1)|
    |   5 |      NESTED LOOPS                       |                          |    70 | 23030 |   576   (1)|
    |*  6 |       HASH JOIN OUTER                   |                          |    69 | 20493 |   369   (1)|
    |   7 |        NESTED LOOPS                     |                          |    69 | 11247 |   285   (0)|
    |   8 |         NESTED LOOPS                    |                          |    69 | 10626 |   147   (0)|
    |   9 |          NESTED LOOPS                   |                          |    23 |  2438 |    78   (0)|
    |  10 |           NESTED LOOPS                  |                          |    23 |  2070 |    32   (0)|
    |  11 |            NESTED LOOPS                 |                          |     1 |    67 |    15   (0)|
    |  12 |             NESTED LOOPS                |                          |     1 |    45 |    14   (0)|
    |* 13 |              TABLE ACCESS FULL          | SDG_USER                 |     1 |    24 |    13   (0)|
    |  14 |              TABLE ACCESS BY INDEX ROWID| DWH_ABS_DETERMINATION    |     1 |    21 |     1   (0)|
    |* 15 |               INDEX UNIQUE SCAN         | PK_DWH_ABS_DETERMINATION |     1 |       |     0   (0)|
    |  16 |             TABLE ACCESS BY INDEX ROWID | SDG                      |     1 |    22 |     1   (0)|
    |* 17 |              INDEX UNIQUE SCAN          | PK_SDG                   |     1 |       |     0   (0)|
    |  18 |            TABLE ACCESS BY INDEX ROWID  | SAMPLE                   |   190 |  4370 |    17   (0)|
    |* 19 |             INDEX RANGE SCAN            | FK_SAMPLE_SDG            |   597 |       |     2   (0)|
    |  20 |           TABLE ACCESS BY INDEX ROWID   | SAMPLE_USER              |     1 |    16 |     2   (0)|
    |* 21 |            INDEX UNIQUE SCAN            | PK_SAMPLE_USER           |     1 |       |     1   (0)|
    |* 22 |          TABLE ACCESS BY INDEX ROWID    | ALIQUOT                  |     3 |   144 |     3   (0)|
    |* 23 |           INDEX RANGE SCAN              | FK_ALIQUOT_SAMPLE        |     3 |       |     2   (0)|
    |  24 |         TABLE ACCESS BY INDEX ROWID     | ALIQUOT_USER             |     1 |     9 |     2   (0)|
    |* 25 |          INDEX UNIQUE SCAN              | PK_ALIQUOT_USER          |     1 |       |     1   (0)|
    |  26 |        VIEW                             | PLATE                    | 21787 |  2851K|    84   (2)|
    |* 27 |         FILTER                          |                          |       |       |            |
    |  28 |          TABLE ACCESS FULL              | PLATE                    | 21787 |   574K|    84   (2)|
    |* 29 |          INDEX UNIQUE SCAN              | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
    |  30 |       TABLE ACCESS BY INDEX ROWID       | TEST                     |     1 |    32 |     3   (0)|
    |* 31 |        INDEX RANGE SCAN                 | FK_TEST_ALIQUOT          |     1 |       |     2   (0)|
    |* 32 |      INDEX RANGE SCAN                   | FK_RESULT_TEST           |     2 |       |     2   (0)|
    |* 33 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
    |* 34 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
    |* 35 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
    |* 36 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
    Predicate Information (identified by operation id):
       2 - filter(("GROUP_ID" IS NULL OR  EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
                  "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID"
                  IS NULL OR  EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
                  "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR  EXISTS
                  (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
                  "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR  EXISTS
                  (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
                  "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
       3 - filter("NAME"='End result')
       6 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
      13 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
                  "U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR) AND
                  DECODE(:CROPCODE,(-1),'-1',"U_CROP_GROUP")=DECODE(:CROPCODE,(-1),'-1',:CROPCODE))
      15 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
      17 - access("SDG_ID"="SDG_ID")
      19 - access("SDG_ID"="SDG_ID")
      21 - access("SAMPLE_ID"="SAMPLE_ID")
      22 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
      23 - access("SAMPLE_ID"="SAMPLE_ID")
      25 - access("ALIQUOT_ID"="ALIQUOT_ID")
      27 - filter("GROUP_ID" IS NULL OR  EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
                  "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
      29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
      31 - access("ALIQUOT_ID"="ALIQUOT_ID")
      32 - access("TEST_ID"="TEST_ID")
      33 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
      34 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
      35 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
      36 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
    Note
       - 'PLAN_TABLE' is old version
    tkprof 2
    TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:28:26 2009
    Copyright (c) 1982, 2005, Oracle.  All rights reserved.
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SELECT sdu.u_crop_group,
           sd.name as sdg_name,
           ad.variety_name,
           ad.batch_number,
           a.name as aliquot_name,
           sau.u_box_code as box_code,
           sau.u_box_position as box_position,
           t.name as test_name,
           r.original_result,
           plt.name as plate_name,
           concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
           au.u_replicate_number as replicate_number
    FROM lims_sys.sdg sd,
         lims_sys.sdg_user sdu,
         lims_sys.sample sa,
         lims_sys.sample_user sau,
         lims_sys.aliquot a,
         lims_sys.aliquot_user au,
         lims_sys.test t,
         lims_sys.result r,
         lims_sys.plate plt,
         lims_sys.abs_determination ad
    WHERE sd.sdg_id = sdu.sdg_id
      AND sd.sdg_id = sa.sdg_id
      AND sa.sample_id = sau.sample_id
      AND sau.sample_id = a.sample_id
      AND a.aliquot_id = au.aliquot_id
      AND au.aliquot_id = t.aliquot_id
      AND t.test_id = r.test_id
      AND plt.plate_id (+) = a.plate_id
      AND sdu.u_abs_determination = ad.determination_assignment
      AND a.status IN ('V','P','C')
      AND r.name = 'End result'
      AND sdu.u_client_type = 'QC'
      AND sdu.u_year_of_sample_delivery = (:year)
      AND sdu.u_week_of_processing = (:week)
      AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
    ORDER BY box_code, box_position, replicate_number
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.01       0.00          0          0          0           0
    Execute      1      0.45       0.87          0          0          0           0
    Fetch        1      1.00       0.99          0     221420          0         500
    total        3      1.46       1.86          0     221420          0         500
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 97 
    Rows     Row Source Operation
        500  SORT ORDER BY (cr=221420 pr=0 pw=0 time=992364 us)
      21311   FILTER  (cr=221420 pr=0 pw=0 time=1128970 us)
      21311    TABLE ACCESS BY INDEX ROWID RESULT (cr=221420 pr=0 pw=0 time=1086345 us)
      42623     NESTED LOOPS  (cr=217549 pr=0 pw=0 time=30006317 us)
      21311      NESTED LOOPS  (cr=174880 pr=0 pw=0 time=809278 us)
      21311       NESTED LOOPS  (cr=110117 pr=0 pw=0 time=553538 us)
      21311        HASH JOIN OUTER (cr=46182 pr=0 pw=0 time=319102 us)
      21311         TABLE ACCESS BY INDEX ROWID ALIQUOT (cr=45866 pr=0 pw=0 time=193037 us)
      29088          NESTED LOOPS  (cr=39885 pr=0 pw=0 time=320084 us)
       7776           NESTED LOOPS  (cr=24267 pr=0 pw=0 time=156721 us)
       7776            NESTED LOOPS  (cr=937 pr=0 pw=0 time=78954 us)
         99             NESTED LOOPS  (cr=454 pr=0 pw=0 time=3826 us)
         99              NESTED LOOPS  (cr=253 pr=0 pw=0 time=2833 us)
         99               TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1531 us)
         99               TABLE ACCESS BY INDEX ROWID DWH_ABS_DETERMINATION (cr=200 pr=0 pw=0 time=956 us)
         99                INDEX UNIQUE SCAN PK_DWH_ABS_DETERMINATION (cr=101 pr=0 pw=0 time=438 us)(object id 46965)
         99              TABLE ACCESS BY INDEX ROWID SDG (cr=201 pr=0 pw=0 time=707 us)
         99               INDEX UNIQUE SCAN PK_SDG (cr=101 pr=0 pw=0 time=330 us)(object id 46071)
       7776             TABLE ACCESS BY INDEX ROWID SAMPLE (cr=483 pr=0 pw=0 time=16261 us)
       7776              INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=562 us)(object id 45990)
       7776            TABLE ACCESS BY INDEX ROWID SAMPLE_USER (cr=23330 pr=0 pw=0 time=64710 us)
       7776             INDEX UNIQUE SCAN PK_SAMPLE_USER (cr=15554 pr=0 pw=0 time=33728 us)(object id 46012)
      21311           INDEX RANGE SCAN FK_ALIQUOT_SAMPLE (cr=15618 pr=0 pw=0 time=43423 us)(object id 45346)
      21895         VIEW  PLATE (cr=316 pr=0 pw=0 time=43833 us)
      21895          FILTER  (cr=316 pr=0 pw=0 time=21936 us)
      21895           TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=37 us)
          0           INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      21311        TABLE ACCESS BY INDEX ROWID ALIQUOT_USER (cr=63935 pr=0 pw=0 time=182479 us)
      21311         INDEX UNIQUE SCAN PK_ALIQUOT_USER (cr=42624 pr=0 pw=0 time=99160 us)(object id 45386)
      21311       TABLE ACCESS BY INDEX ROWID TEST (cr=64763 pr=0 pw=0 time=219096 us)
      21311        INDEX RANGE SCAN FK_TEST_ALIQUOT (cr=42669 pr=0 pw=0 time=129354 us)(object id 46222)
      21311      INDEX RANGE SCAN FK_RESULT_TEST (cr=42669 pr=0 pw=0 time=125893 us)(object id 45940)
          0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
          0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
          0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
          0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
    select 'x'
    from
    dual
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.00       0.00          0          0          0           1
    total        3      0.00       0.00          0          0          0           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 97 
    Rows     Row Source Operation
          1  FAST DUAL  (cr=0 pr=0 pw=0 time=6 us)
    begin :id := sys.dbms_transaction.local_transaction_id; end;
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          2           0
    Execute      1      0.00       0.00          0          0          0           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          2           1
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 97 
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        3      0.01       0.00          0          0          2           0
    Execute      3      0.45       0.87          0          0          0           1
    Fetch        2      1.00       0.99          0     221420          0         501
    total        8      1.46       1.87          0     221420          2         502
    Misses in library cache during parse: 2
    Misses in library cache during execute: 2
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse       43      0.01       0.00          0          0         12           0
    Execute    128      0.00       0.01          0          0          0           0
    Fetch      178      0.00       0.00          0        383          0         465
    total      349      0.01       0.02          0        383         12         465
    Misses in library cache during parse: 5
    Misses in library cache during execute: 5
        3  user  SQL statements in session.
      128  internal SQL statements in session.
      131  SQL statements in session.
    Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
    Trace file compatibility: 10.01.00
    Sort options: default
           1  session in tracefile.
           3  user  SQL statements in trace file.
         128  internal SQL statements in trace file.
         131  SQL statements in trace file.
          19  unique SQL statements in trace file.
        1352  lines in trace file.
         287  elapsed seconds in trace file.

  • How to proceed further once the explain plan and trace files are generated?

    Hi Friends,
    I need to improve the performance of on of the views that i am working on.
    As suggested in the thread - http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0 , i gave generated the explain plan and the trace file.
    From the explain plan, we can see the expensive operations for the query.
    Can any one please tell, how to proceed further from here on i.e. how to make this expensive operations less expensive?
    For ex: FULL TABLE SCAN might be an expensive operation when the table has indexes.In such cases, how can we avoid such operations to make query faster?
    Regards,
    Sreekanth Munagala.

    Hi Veena,
    An earlier post by you regarding P45 is as below
    Starter report P45(3) / P46 efiling for UK
    from my understanding though i have not worked on GB Payroll you have said that you deleted IT 65 details of leaver,however there must be clusters generated in system from where the earlier data needs to be deleted and may be that is why you are facing the issue.
    In Indian payroll when we execute text file for efiling of tax after challan mapping all the data compiles and sits in PCL cluster and therefore we are unable to generate form 16 with proper output,here we delete the clusters and rerun again the mappings and then check form 16.
    Hope this might help you,Experts have suggested you earlier also,they may correct me for this.
    Salil

  • Help to understand the explain plan

    Hi, Everyone,
    i have query :
    INSERT INTO ICM_UPSEL_1_ALL
    select  a.customer_no,a.pr_code_bbl,min(b.pr_code_pmm) pr_code_pmm,a.score,a.price_diff,a.flag
    from ICM_UPSEL_MIN_PRDIFF_1 a, icm_pre b
    where a.customer_no = b.customer_no
    and a.pr_code_bbl=b.pr_code_bbl
    and a.score = b.score
    and a.flag = b.flag
    and a.price_diff = b.price_diff
    and b.price_diff > 0
    and b.score >=0.5
    and b.flag = 1
    and b.price_diff >  0 and b.price_diff <= 10
    group by  a.customer_no,a.pr_code_bbl,a.score,a.price_diff,a.flag
    This query is running in a pl/sql procedure.  The explain plan for this query is :
    Plan hash value: 3124235498
    | Id  | Operation                       | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | INSERT STATEMENT                |                                |     1 |   143 |     4  (25)| 00:00:01 |
    |   1 |  LOAD TABLE CONVENTIONAL        | ICM_UPSEL_1_ALL        |       |       |            |          |
    |   2 |   HASH GROUP BY                 |                                |     1 |   143 |     4  (25)| 00:00:01 |
    |   3 |    NESTED LOOPS                 |                                |       |       |            |          |
    |   4 |     NESTED LOOPS                |                                |     1 |   143 |     3   (0)| 00:00:01 |
    |*  5 |      TABLE ACCESS BY INDEX ROWID| ICM_UPSEL_MIN_PRDIFF_1 |     1 |    65 |     1   (0)| 00:00:01 |
    |*  6 |       INDEX RANGE SCAN          | MPD_1_FLAG_IDX                 |     1 |       |     1   (0)| 00:00:01 |
    |*  7 |      INDEX RANGE SCAN           | ICM_PRE_FLAG_IDX               |     1 |       |     2   (0)| 00:00:01 |
    |*  8 |     TABLE ACCESS BY INDEX ROWID | ICM_PRE                |     1 |    78 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       5 - filter("A"."PRICE_DIFF">0 AND "A"."SCORE">=0.5 AND "A"."PRICE_DIFF"<=10)
       6 - access("A"."FLAG"=1)
       7 - access("B"."FLAG"=1)
       8 - filter("B"."PRICE_DIFF"<=10 AND "B"."SCORE">=0.5 AND "B"."PRICE_DIFF">0 AND
                  "A"."CUSTOMER_NO"="B"."CUSTOMER_NO" AND "A"."PR_CODE_BBL"="B"."PR_CODE_BBL" AND "A"."SCORE"="B"."SCORE"
                  AND "A"."PRICE_DIFF"="B"."PRICE_DIFF")
    This query is running for 10 hours now and no result yet.  Could anyone please help me where is going wrong... why is it taking so much time to insert the data...
    The number of rows in ICM_UPSEL_MIN_PRDIFF_1 : 84,858
    The number of rows in icm_pre :  455,500,944
    All the columns are indexed.
    My database version is 11.1.0.6 running on windows server 2003 R2.
    Thanks in advance

    Hi, Nikolay,
    Please see the results below;
    SELECT * FROM DBA_TAB_COL_STATISTICS
    WHERE OWNER = 'SAST' AND TABLE_NAME = 'ICM_UPSEL_MIN_PRDIFF_1' AND COLUMN_NAME = 'FLAG';
    TABLE_NAME
    COLUMN_NAME
    NUM_DISTINCT
    LOW_VALUE
    HIGH_VALUE
    DENSITY
    NUM_NULLS
    NUM_BUCKETS
    LAST_ANALYZED
    SAMPLE_SIZE
    GLOBAL_STATS
    USER_STATS
    AVG_COL_LEN
    HISTOGRAM
    SAST    ICM_UPSEL_MIN_PRDIFF_1    FLAG    1    C102    C102    0.00000584543291182618    0    1    16/07/13 10:01:42    5544    YES    NO    3    FREQUENCY
    SELECT * FROM DBA_TAB_STATISTICS WHERE OWNER = 'SAST' AND TABLE_NAME = 'ICM_UPSEL_MIN_PRDIFF_1';
    TABLE_NAME
    PARTITION_NAME
    PARTITION_POSITION
    SUBPARTITION_NAME
    SUBPARTITION_POSITION
    OBJECT_TYPE
    NUM_ROWS
    BLOCKS
    EMPTY_BLOCKS
    AVG_SPACE
    CHAIN_CNT
    AVG_ROW_LEN
    AVG_SPACE_FREELIST_BLOCKS
    NUM_FREELIST_BLOCKS
    AVG_CACHED_BLOCKS
    AVG_CACHE_HIT_RATIO
    SAMPLE_SIZE
    LAST_ANALYZED
    GLOBAL_STATS
    USER_STATS
    STATTYPE_LOCKED
    STALE_STATS
    SAST    ICM_UPSEL_MIN_PRDIFF_1 
    TABLE    84858    874    0    0    0    62    0    0 
    84858    16/07/13 10:02:00    YES    NO 
    NO
    Thanks & Regards
    Su

  • How can i paste the explain plan from toad..

    Hello all
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please help

    964145 wrote:
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please helpI don't know, but it is a waste of time since explain plans from Toad are not useful.
    Please read the forum FAQ on providing information for a tuning request, it describes how to generate an explain plan that can be shared.
    {message:id=9360003}
    This is an example.
    SQL> explain plan for
      2  select * from dual;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3543395131
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    --------------------------------------------------------------------------

  • Facing Merge Join Cartersian in the explain plan after adding gl periods

    Hi All
    I have added gl periods table to the below query , checked the explain plan and it shows merge join cartesian. This query is taking long time to fetch the results.
    Need help ASAP , Please let me know where i am going wrong . Any suggestions will be appreciated.
    SELECT gljh.period_name, gljh.ledger_id, gljh.je_source,
    glcc.segment2,
    SUM ( NVL (gljl.accounted_dr, 0)
    - NVL (gljl.accounted_cr, 0)
    ) total_amt,
    gljh.currency_code
    FROM gl_je_headers gljh,
    gl_je_lines gljl,
    gl_code_combinations glcc,
    gl_periods gps
    WHERE 1=1
    AND gljh.period_name = gps.period_name
    AND gljl.period_name = gps.period_name
    AND gps.period_set_name = 'MCD_MONTH_'
    AND gps.start_date >= :p_from_date
    AND gps.start_date <= :p_to_date
    AND gljh.ledger_id = :p_ledger_id
    AND gljh.je_header_id = gljl.je_header_id
    AND gljl.code_combination_id = glcc.code_combination_id
    AND glcc.segment2 = '10007'--get_segment2_rec.flex_value
    AND gljh.currency_code <> 'STAT'
    GROUP BY gljh.je_source,
    gljh.period_name,
    glcc.segment2,
    gljh.ledger_id,
    gljh.currency_code
    HAVING SUM ( NVL (gljl.accounted_dr, 0)
    - NVL (gljl.accounted_cr, 0)
    ) <> 0;
    Plan
    SELECT STATEMENT ALL_ROWSCost: 73,146 Bytes: 2,266 Cardinality: 22                                              
         15 FILTER                                         
              14 HASH GROUP BY Cost: 73,146 Bytes: 2,266 Cardinality: 22                                    
                   13 FILTER                               
                        12 NESTED LOOPS Cost: 73,145 Bytes: 61,079 Cardinality: 593                          
                             9 NESTED LOOPS Cost: 31,603 Bytes: 1,452,780 Cardinality: 20,754                     
                                  6 MERGE JOIN CARTESIAN Cost: 2,108 Bytes: 394,181 Cardinality: 9,167                
                                       2 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_PERIODS Cost: 4 Bytes: 31 Cardinality: 1           
                                            1 INDEX RANGE SCAN INDEX (UNIQUE) GL.GL_PERIODS_U2 Cost: 1 Cardinality: 64      
                                       5 BUFFER SORT Cost: 2,104 Bytes: 683,988 Cardinality: 56,999           
                                            4 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 2,104 Bytes: 683,988 Cardinality: 56,999      
                                                 3 INDEX RANGE SCAN INDEX GL.GL_CODE_COMBINATIONS_N2 Cost: 155 Cardinality: 56,999
                                  8 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_LINES Cost: 18 Bytes: 54 Cardinality: 2                
                                       7 INDEX RANGE SCAN INDEX GL.GL_JE_LINES_N1 Cost: 3 Cardinality: 37           
                             11 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_HEADERS Cost: 2 Bytes: 33 Cardinality: 1                     
                                  10 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_JE_HEADERS_U1 Cost: 1 Cardinality: 1                
    Thanks
    Chandra

    Lots of things come into play when you're tuning a query.
    An (unformatted) execution plan isn't enough.
    Tuning takes time and understanding how (a lot of) things work, there is no ASAP in the world of tuning.
    Please post other important details, like your database version, optimizer settings, how/when are table statistics gathered etc.
    So, read the following informative threads (and please take your time, this really is important stuff), and adust your thread as needed.
    That way you'll have a bigger chance of getting help that makes sense...
    Your DBA should/ought to be able to help you in this as well.
    Re: HOW TO: Post a SQL statement tuning request - template posting
    http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html

  • Calculating the Size(KB) in the explain plan....

    Hi
    I executed a sql statement in SQL*PLUS and having enabled the tracing in OEM , among others , I read the Size in KiloBytes which the 'TABLE ACCESS FULL' segment of the explain plan returned.....
    This number is 5.998,193KB
    I used the vsize built-in function in order to get the total number in bytes of the physical representation of all the rows (about 53500) ....
    So , I wrote :
    select nvl(sum(vsize(farmak_code)),0)+nvl(sum(vsize(emp_name)),0)+nvl(sum(vsize(category)),0)+ .....+.....
    from mitroo_farmakou
    The result was 5794544 in bytes which is close to 5.998,193KB.
    My question is :
    The computation of the bytes in the explain plan (TABLE ACCESS FULL segment) is done by adding the vsize of all columns....????
    Does anybody Knows...????
    Thanks , a lot
    Simon

    I doubt it. For a large table that would be an incredibly expensive calculation.
    I suspect that it is something closer to:
    SQL> SELECT * FROM incident;
    Execution Plan
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=137 Card=15603 Bytes=6818511)
       1    0   TABLE ACCESS (FULL) OF 'INCIDENT' (Cost=137 Card=15603 Bytes=6818511)
    SQL> SELECT ROUND(num_rows * avg_row_len)
      2  FROM user_tables
      3  WHERE table_name = 'INCIDENT';
    ROUND(NUM_ROWS*AVG_ROW_LEN)
                        6818449HTH
    John

  • Wich rules are based the explain plan

    Hi!
    Please some one can tell me, which are the specific ranges to say one data base function is acceptable?
    I mean, i know with the explain plan, can get the values of a transaction, but i need to know which ranges are considered good or besides when the range are over value
    If i can't get values, i need to know the limits or general rules, to specify if transaction or procedure is acceptable or no.

    If, by "ranges", you mean "execution" time then the answer to your question
    is "It depends" !
    It is user requirements that specify acceptable response time for things like
    a. Data Entry and Validation in a Form
    b. Query in a Form
    c. Running a Report
    For a., user acceptance might be a few seconds only.
    For b., acceptability might be anywhere from 10seconds to a minute, depending on the nature of the query.
    For c., acceptability might be a few minutes to a day (24hours), depending on
    the nature of the report.
    As the designer, developer and dba, your responsibility would to to ensure
    that all the database operations required to be executed are completed
    within the acceptable time.
    Type a might consist of 3 queries and 1 insert.
    Type b might consist of 1 or 2 queries (or variable queries !)
    Type c might consist of 2 to 200 queries, some DML, temporary tables.

  • What privileges or role is required for user to acces the explain plan?

    Hi mates,
    Can anyone pls tell me what privileges or roles(grants) are requred for a user to access the explain plan in oORACLE 8i 8174..
    I think the select any dictionary is not valid for explain plan accessibility in 8i.
    Cheers.

    I already had that... Just that a user (not a dba) requires access to the explain plan and I dont want to grant him a dba role.
    Are you aware of any other grant I can give to the user?

  • Why can the explain plan be different from 2 exact set of structures

    hi,
    i have from a view some base tables let's say A , B, C & D
    this query is running very slow . so from the same database , i created tables A1 , B1, C1,& D1 from the above tables.
    i created some new indexes on A1 to D1 tables and the results returned to me is fast.
    i did an exlain plan
    so i drop the indexes on the original A to D table and created the new indexes as per A1 to D1 and analyzed them. and i also did an explain plan
    but the query is still running slow and also the explain plan is different to the one from A1 to D1 (the one that running fast)
    pls help me to understand how/why can this happen ?
    tks & rdgs

    hi,
    precisely i could have been providing insufficient information but i am too inexperienced to be able to give you the required information and i am also not very sure where i could get the info so that you all can advise me further.
    but this is from the user_tables , the only difference i see is that
    under LOGGING table A to E is 'YES'
    TABLE_NAME     TABLESPACE_NAME     PCT_FREE     LOGGING     BACKED_UP     NUM_ROWS     BLOCKS     CACHE     TABLE_LOCK     PARTITIONED
    A1          OWNER1          10          NO          N     37332          883         N     ENABLED     NO
    B1          OWNER1          10          NO          N     43458          861         N     ENABLED     NO
    C1          OWNER1          10          NO          N     823828          7826         N     ENABLED     NO
    D1          OWNER1          10          NO          N     881176          14646         N     ENABLED     NO
    E1          OWNER1          10          NO          N     18868          223         N     ENABLED     NO
    A          OWNER1          10          YES          N     37040          880         N     ENABLED     NO
    B          OWNER1          10          YES          N     43386          880         N     ENABLED     NO
    C          OWNER1          10          YES          N     823820          7684         N     ENABLED     NO
    D          OWNER1          50          YES          N     880948          26624         N     ENABLED     NO
    E          OWNER1          10          YES          N     18690          244         N     ENABLED     NOtks & rdgs

  • Why the explain plan incorrent?

    I have a sql in oracle10.2.03:
    select *
    from (select a.*
    from t_user a, t_message b
    where b.user_id = a.row_id and a.user_type = 1
    order by b.happen_time desc)
    where rownum <= 5
    there are indexes on column a.user_type,b.user_id,b.happen_time, and has been analyzed. a.user_type=1 only have 1/1000 records
    the explain plan is below:
    cost Cardinary Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 30 5 3790
    COUNT STOPKEY
    VIEW BMTEST 30 6 4548
    NESTED LOOPS 30 6 1158
    TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 13 1524118 24385888
    INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
    TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 1 177
    INDEX UNIQUE SCAN BMTEST PK_USER 1 1
    Oracle use the index full scan descending on the happen_time. the cost only has 30.
    After I add hint on the sql on the user_id of t_message
    select *
    from (select /*+index (b idx_message_1)*/  a.*
    from t_user a, t_message b
    where b.user_id = a.row_id and a.user_type = 1
    order by b.happen_time desc)
    where rownum <= 5
    the explain plan change to:
    cost Cardinary Bytes
    SELECT STATEMENT, GOAL = ALL_ROWS 5020 5 3790
    COUNT STOPKEY
    VIEW BMTEST 5020 54707 41467906
    SORT ORDER BY STOPKEY 5020 54707 10558451
    TABLE ACCESS BY INDEX ROWID BMTEST T_MESSAGE 26 515 8240
    NESTED LOOPS 2707 54707 10558451
    TABLE ACCESS BY INDEX ROWID BMTEST T_USER 1 106 18762
    INDEX RANGE SCAN BMTEST IDX_USER_2 1 106
    INDEX RANGE SCAN BMTEST IDX_MESSAGE_1 1 515
    INDEX UNIQUE SCAN BMTEST PK_USER 1 1
    The cost is 5020, but the execute usage time only is 100ms, and the first SQL does not add hint usage 20s.
    Why the lower cost waste more time, if the cost caculate is incorrect?
    Edited by: [email protected] on Sep 11, 2008 9:14 PM

    [email protected] wrote:
    But i am afraid i use a misunderstand title for this post,my doubt is why oracle get a large cost with the sql execute few time but get a small cost with the sql execute long time.The cost of a query isn't a particularly good proxy for runtime. It is perfectly reasonable for a query with a cost of 1000 to run more quickly than a query with a cost of 100. The cost of queries is only directly comparable between different plans in the same 10053 trace file.
    [email protected] wrote:
    All the indexed columns are both analyzed by the command or by DBMS_STATS package and the cpu costing is enabled.But what order are the commands being run? And why is the ANALYZE command being used to gather optimizer stats.
    In the first plan:
    INDEX FULL SCAN DESCENDING BMTEST IDX_MESSAGE_2 1 168
    Why this index full scan cost only 1? how did oracle get this number? Is there formula to caculate the cost of index full scan? I have read the article named "Cost Based Oracle Fundamentals" and there is no introduce how to caculate it.
    I think this abnormality cost makes the cost of next step "NESTED LOOPS" very smal and finally lead this abnormality result.1) Which article are you talking about? Are you talking about Jonathan Lewis's book "Cost Based Oracle Fundamentals"? Or are you referring to a different article somewhere?
    2) Can you post the query plans formatted via DBMS_XPLAN.DISPLAY (including the predicate information and enclose the output in the \[pre\] and \[pre\] tags to preserve white space?
    Justin
    Justin

  • Why the content of the Explain Plan not show out?

    Why the content of the Explain Plan not show out?
    I am using Oracle 11g.
    I already ran the utlxplan.sql sctipt and I also set serveroutput on.
    SQL> set autotrace on
    SQL> EXPLAIN PLAN FOR SELECT*FROM DEMO_TABLE WHERE OWNER='HR';
    Explained.
    Elapsed: 00:00:00.67

    When you say:
    My release 10.2 database display the Explain Plan automatically.
    How to make 11.1.0.6 Oracle database to display the Explain Plan automatically.What do you mean? Specifically, what commands are you executing in the 10.2 database, that displays the execution plan "automatically"?
    Are you saying that if you execute the same command in 11.1.0.6, you don't get a similar result? What happens? Do you get an error?
    For both the 10.2 case and the 11.1.0.6 case, post the full output of the commands you're executing, and the result you are seeing.
    Then, maybe someone can help you.
    When you post the output, please encapsulate it in a pair "code" tags, which is the word "code" without the quotes, surrounded by a pair of curly braces {}.
    When you do this correctly, the output looks like:
    This is output from my execution plan run.and is much easier to read.
    Don't be afraid to use the preview tab to see if your message will be posted with the correct formatting.
    -Mark

  • *** Interpreting this explain plan ***

    Hi,
    Please find the explain plan for following: I dont understand why rows = 1 in step 4 and 5 of explain plan?? There are 6 rows corresponding to the condition in join that is satisfied in service def table. Still it shows 1??
    explain plan for SELECT costpools.cost_pool_id, servicedef.service_name,
    costpools.special_calc
    FROM cost_pools costpools, service_definitions servicedef
    WHERE costpools.service_def_id = servicedef.service_def_id
    AND costpools.special_calc = 'Y'
    ORDER BY servicedef.service_name;
    PLAN_TABLE_OUTPUT
    Plan hash value: 3404549211
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 6 | 270 | 15 (7)| 00:00:01 |
    | 1 | SORT ORDER BY | | 6 | 270 | 15 (7)| 00:00:01 |
    | 2 | NESTED LOOPS | | 6 | 270 | 14 (0)| 00:00:01 |
    |* 3 | TABLE ACCESS FULL | COST_POOLS | 6 | 60 | 8 (0)| 00:00:01 |
    | 4 | TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS | 1 | 35 | 1 (0)| 00:00:0
    |* 5 | INDEX UNIQUE SCAN | SERVICE_DEFINITIONS_PK | 1 | | 0 (0)| 00:00:01
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
    3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
    5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
    18 rows selected.
    regds,
    s

    I mean how is it executed.....there are 6 rows in the
    service_def table that satisfies the join condition
    right.....so the cardinlity shud be 6 instead of 1
    ..isnt it??That's not the way it works in an explain plan. It works as SomeoneElse said: an index unique scan as the second step inside a nested loop will retrieve 1 row (index unique scan) but 6 times (nested loop). In the plan you'll see a "1". However, if you look at the row source operation in tkprof, it will tell you how many rows were flowing through this step in total, so here it reports 6.
    SQL> create table cost_pools
      2  as
      3   select level cost_pool_id
      4        , 'Y' special_calc
      5        , level service_def_id
      6     from dual
      7  connect by level <= 6
      8  /
    Tabel is aangemaakt.
    SQL> create table service_definitions
      2  as
      3   select 'A' service_name
      4        , level service_def_id
      5     from dual
      6  connect by level <= 10000
      7  /
    Tabel is aangemaakt.
    SQL> alter table service_definitions add constraint service_definitions_pk primary key (service_def_id)
      2  /
    Tabel is gewijzigd.
    SQL> exec dbms_stats.gather_table_stats(user,'cost_pools')
    PL/SQL-procedure is geslaagd.
    SQL> exec dbms_stats.gather_table_stats(user,'service_definitions',cascade=>true)
    PL/SQL-procedure is geslaagd.
    SQL> explain plan
      2  for
      3  SELECT costpools.cost_pool_id, servicedef.service_name,
      4  costpools.special_calc
      5  FROM cost_pools costpools, service_definitions servicedef
      6  WHERE costpools.service_def_id = servicedef.service_def_id
      7  AND costpools.special_calc = 'Y'
      8  ORDER BY servicedef.service_name
      9  /
    Uitleg is gegeven.
    SQL> select * from table(dbms_xplan.display)
      2  /
    PLAN_TABLE_OUTPUT
    | Id  | Operation                     |  Name                   | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT              |                         |     6 |    78 |     5  (20)|
    |   1 |  SORT ORDER BY                |                         |     6 |    78 |     5  (20)|
    |   2 |   NESTED LOOPS                |                         |     6 |    78 |     4   (0)|
    |*  3 |    TABLE ACCESS FULL          | COST_POOLS              |     6 |    48 |     3  (34)|
    |   4 |    TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS     |     1 |     5 |     2  (50)|
    |*  5 |     INDEX UNIQUE SCAN         | SERVICE_DEFINITIONS_PK  |     1 |       |            |
    Predicate Information (identified by operation id):
       3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
       5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
    17 rijen zijn geselecteerd.
    SQL> alter session set sql_trace true
      2  /
    Sessie is gewijzigd.
    SQL> SELECT costpools.cost_pool_id, servicedef.service_name,
      2  costpools.special_calc
      3  FROM cost_pools costpools, service_definitions servicedef
      4  WHERE costpools.service_def_id = servicedef.service_def_id
      5  AND costpools.special_calc = 'Y'
      6  ORDER BY servicedef.service_name
      7  /
                              COST_POOL_ID S S
                                         1 A Y
                                         2 A Y
                                         3 A Y
                                         4 A Y
                                         5 A Y
                                         6 A Y
    6 rijen zijn geselecteerd.
    SQL> disconnectAnd now tkprof shows you:
    SELECT costpools.cost_pool_id, servicedef.service_name,
    costpools.special_calc
    FROM cost_pools costpools, service_definitions servicedef
    WHERE costpools.service_def_id = servicedef.service_def_id
    AND costpools.special_calc = 'Y'
    ORDER BY servicedef.service_name
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        4      0.00       0.00          1         17          0           6
    total        6      0.00       0.00          1         17          0           6
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 9833
    Rows     Row Source Operation
          6  SORT ORDER BY
          6   NESTED LOOPS
          6    TABLE ACCESS FULL OBJ#(2702816)
          6    TABLE ACCESS BY INDEX ROWID OBJ#(2702817)
          6     INDEX UNIQUE SCAN OBJ#(2702818) (object id 2702818)
    ********************************************************************************Regards,
    Rob.

  • Interpreting Predicate  and Filter information from the explain plan

    Can somebody help in understanding how does the predicate and filter operation effects the execution plan.or how can I conclude the predicate or filter operation chosen by optimizer is not optimized.

    User445775,
    The paraphrase that I provided in my previous post was from page 74 of "Cost-Based Oracle Fundamentals".
    How to word the explanation...
    Assume that you have a database table which contains all of the phone numbers and addresses for people in a state. A query is executed to find user445775 in the city named "Redmond". Assume that the query looks like this:
    SELECT
      PHONE
    FROM
      PHONE_NUMBERS
    WHERE
      CITY = 'Redmond'
      AND FULL_NAME = 'user445775';Assume that there are no indexes on the table. The DBMS_XPLAN would show two filter predicates applied during a full tablescan - this probably indicates an inefficient access path, especially if there are a very small percentage of people matching the WHERE clause restrictions on the table.
    Now, assume that an index is created on the CITY column. The DBMS_XPLAN would show an access predicate applied to the index on the CITY column, and a filter predicate on the table access by index for the FULL_NAME. We eliminated a large number of possible rows by applying the access predicate to jump directly to the rows with the city of interest, and then filtered out those names which were not 'user445775'. This is not terribly efficient, especially if there are a large number of people in 'Redmond' that need to be filtered out.
    Now, assume that we drop the index on the CITY column and create an index on the FULL_NAME column. The DBMS_XPLAN would show an access predicate applied to the index on the FULL_NAME column, and a filter predicate on the table access by index for the CITY column. This could be a fairly efficient plan if there are only a couple rows in the table with FULL_NAME of 'user445775', as few rows will be discarded after the index access to find those with CITY = 'Redmond'.
    Now, assume that we drop the index on the FULL_NAME column and create a composite index on CITY,FULL_NAME. The DBMS_XPLAN would show an access predicate applied to the index on the CITY and FULL_NAME columns and there would not be a filter predicate on the table access by index - in this case, we will not discard any rows once retrieved by the index access.
    Page 211 of "Troubleshooting Oracle Performance" also shows a clear explanation of access and filter predicates.
    Think of access predicates (on indexes at least) as throwing out rows before they are retrieved from disk (or memory), and filter predicates as throwing out rows after they are retrieved from disk (or memory).
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

Maybe you are looking for

  • The Home Button on my iPhone 3GS is working off and on.

    Sometimes when I press the Home Button it works immediately. Other times it does not work at all,or I have to press it three or four times,and quite hard,to get to the next screen. It is an intermittent problem but is not happening more often. Any ad

  • Time capsule painfully slow wifi

    New time capsule , painfully slow wifi , cisco works lightning fast so the issue is with the TC. Looked at forums and I see it's a common isssue. Any ideas that actually work?

  • The file name img 1234 is missing or offline is on all images on screen

    all my images have a bar accross the top which says 'the file name is missing or offline' this is on the screen, does anybody know what is going on here. Thankyou peter...

  • Bought song: where did it go ?

    This should be easy: Never purchased a song before, So just purchased the perverbial 99 cent song, clicked on "buy" it shows up on my bank account: so where's the song ???? When I click on "available downloads" it says all purchases have been downloa

  • Ipod will not charge up

    ipod touch will not charge up .. . . have tried other chargers, and rebooting it - still wont work it is 1 year and 1 month old any suggestions to getting it working again? is it worth taking it into Apple? can they change the battery? how much would


HashFlare