Explain Plan - Parallel Processing Degree of 2 and CPU_Cost

Explain Plan - Parallel Processing Degree of 2 and CPU_Cost
When I use a hint to use parallel processing with a degree of 2
the I/O cost seems consistently divided by (1.8) but the cpu cost
adjustment is inconsistent(between 2.17 and 2.62).
Any ideas on why the cpu cost varies with each table ?
Is there a formula to adjust the cpu_cost ?
Thanks,
Summary:
The i/o cost reduction is consistent (divide by 1.8)
Table 1: 763/424 = 1.8
Table 2: 18774/10430 = 1.8
Table 3(not shown): 5/1.8 = 3
But the cpu cost reduction varies:(between 2.17 and 2.62)
Table 1: 275812018/122353500 = 2.25
Table 2: 7924072407/3640755000 = 2.17
Table 3(not shown): 791890/301467 = 2.62
Example:
Oracle Database 10.2.0.4.0
Table 1:
1.) Full table scan on Table 1 without parallel processing.
EXPLAIN PLAN FOR select/*+ CPU_COSTING
PARALLEL(table_1,1)*/
* from table_1
SQL> select cost,io_cost,cpu_cost from plan_table;
IO_COST CPU_COST
763 275812018
2.) Process Table 1 in parallel with a degree of 2.
EXPLAIN PLAN FOR select/*+ CPU_COSTING
PARALLEL(table_1,2)*/
* from table_1
IO_COST CPU_COST
424 122353500
Table 2:
3.) Full table scan on Table 2 without parallel processing.
EXPLAIN PLAN FOR select/*+ CPU_COSTING
PARALLEL(table_2,1)*/
* from table_2
IO_COST CPU_COST
18774 7924072407
4.) Process Table 2 in parallel with a degree of 2.
EXPLAIN PLAN FOR select/*+ CPU_COSTING
PARALLEL(table_2,2)*/
* from table_2
IO_COST CPU_COST
10430 3640755000

The COST value is for the benefit of the CBO; not YOU.
What should be more important to you is the elapsed run time for the SQL

Similar Messages

  • Parallel process with a queue and file?

    Hello, first of all sorry for my bad english^^:
    I am working for days on my project where I have to show the parallel process while transfering information by different ways and their problems (like timing and so on). 
    I chose the transmission of information to a parallel process by (1) a queue, and by (2) a file (.txt). (other ways are welcome, do you have 1-2 other ideas?)
    To solve this problem I made three while loops, the first one is the original one, where the original information (as a signal) is created and send by queue and file to the other two while loops, where this information is getting evaluted to create the same signal.
    so in the end you can compare all signals, if they are the same - so that you can answer the question with the parallelity of process.
    but in my vi file i have some problems:
    the version with the queue works pretty fine - it's almost parallel
    but the version with file doesn't work parallel, and i have no idea how i can solve it - -
    i'm a newbie^^
    can someone correct my file, so both (file and queue version) run parallel with the original one, or tell me what i can or must do?
    Attachments:
    Queue_Data_Parallel_FORUM.vi ‏23 KB

    LapLapLap wrote:
    Hello, first of all sorry for my bad english^^:
    I am working for days on my project where I have to show the parallel process while transfering information by different ways and their problems (like timing and so on). 
    I chose the transmission of information to a parallel process by (1) a queue, and by (2) a file (.txt). (other ways are welcome, do you have 1-2 other ideas?)
    To solve this problem I made three while loops, the first one is the original one, where the original information (as a signal) is created and send by queue and file to the other two while loops, where this information is getting evaluted to create the same signal.
    so in the end you can compare all signals, if they are the same - so that you can answer the question with the parallelity of process.
    but in my vi file i have some problems:
    the version with the queue works pretty fine - it's almost parallel
    but the version with file doesn't work parallel, and i have no idea how i can solve it - -
    i'm a newbie^^
    can someone correct my file, so both (file and queue version) run parallel with the original one, or tell me what i can or must do?
    A queue is technically never parallell, though you can have several if you really need parallellism. Other methods include Events, Action Engines, Notifiers (and why not webservices) for information transfer between processes.
    Due to limitations in the disk system you can only read/write one file at a time from one process, so i wouldn't recommend that. If you use a ramdisk it might work.
    /Y
    LabVIEW 8.2 - 2014
    "Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
    G# - Free award winning reference based OOP for LV

  • Different explain plan between 10.2.0.3 and 10.2.0.4

    Had a problem with an explain plan changing after upgrade from 10.2.0.3 to 10.2.0.4. Managed to simplify as much as possible for now:
    Query is :
    SELECT * FROM m_promo_chk_str
    WHERE (m_promo_chk_str.cust_cd) IN (
    SELECT cust_cd
    FROM s_usergrp_pda
    GROUP BY cust_cd)
    On 10.2.0.3 explain plan is:
    | 0 | SELECT STATEMENT | | 1 | 1227 | 26 (16)| 00:00:01 |
    |* 1 | HASH JOIN SEMI | | 1 | 1227 | 26 (16)| 00:00:01 |
    | 2 | TABLE ACCESS FULL | M_PROMO_CHK_STR | 1 | 1185 | 14 (0)| 00:00:01 |
    | 3 | VIEW | VW_NSO_1 | 137 | 5754 | 11 (28)| 00:00:01 |
    | 4 | HASH GROUP BY | | 137 | 548 | 11 (28)| 00:00:01 |
    | 5 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 9 (12)| 00:00:01 |
    On 10.2.0.4 with same data is:
    | 0 | SELECT STATEMENT | | 1 | 1201 | 46 (5)| 00:00:01 |
    | 1 | HASH GROUP BY | | 1 | 1201 | 46 (5)| 00:00:01 |
    |* 2 | HASH JOIN | | 1 | 1201 | 45 (3)| 00:00:01 |
    | 3 | TABLE ACCESS FULL| M_PROMO_CHK_STR | 1 | 1197 | 29 (0)| 00:00:01 |
    | 4 | TABLE ACCESS FULL| S_USERGRP_PDA | 5219 | 20876 | 15 (0)| 00:00:01 |
    Explain plan is reasonable for when M_PROMO_CHK_STR is empty, however we have the case where stats are gathered when table is empty, but table is then populated and the query runs slowly. I understand that this is not a problem with the database exactly, but want to try to understand why the different behaviour.
    Will look into CBO trace tommorrow, but for now anyone want to share any thoughts?

    PatHK wrote:
    Here is further simplification to reproduce the different behaviour - I think about as simple as I can get it!
    SELECT * FROM dual WHERE (dummy) IN (SELECT dummy FROM dual GROUP BY dummy);
    On 10.2.0.3
    |   0 | SELECT STATEMENT     |          |     1 |     4 |     5  (20)| 00:00:01 |
    |   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     5  (20)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     2   (0)| 00:00:01 |
    |*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     3  (34)| 00:00:01 |
    |   4 |    SORT GROUP BY     |          |     1 |     2 |     3  (34)| 00:00:01 |
    |   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     2   (0)| 00:00:01 |On 10.2.0.4
    |   0 | SELECT STATEMENT     |      |     1 |     4 |     4   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     4   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS       |      |     1 |     4 |     4   (0)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    Timur's suggestion to look at a 10053 trace file is a good idea. It might be the case that someone disabled complex view merging in the 10.2.0.3 database instance. See the following:
    _complex_view_merging
    http://jonathanlewis.wordpress.com/2007/03/08/transformation-and-optimisation/
    Here is a test you might try on both database versions:
    ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=TRUE;
    ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST1';
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
    ALTER SESSION SET "_COMPLEX_VIEW_MERGING"=FALSE;
    ALTER SESSION SET TRACEFILE_IDENTIFIER = 'TEST2';
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    SELECT * FROM DUAL WHERE (DUMMY) IN (SELECT DUMMY FROM DUAL GROUP BY DUMMY);
    SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
    ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';The first plan output:
    | Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |      |       |       |     8 (100)|          |
    |   1 |  SORT GROUP BY NOSORT|      |     1 |     4 |     8   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS       |      |     1 |     4 |     8   (0)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL | DUAL |     1 |     2 |     4   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - filter("DUMMY"="DUMMY")The second plan output:
    | Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |          |       |       |     9 (100)|          |
    |   1 |  NESTED LOOPS SEMI   |          |     1 |     4 |     9  (12)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL  | DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
    |*  3 |   VIEW               | VW_NSO_1 |     1 |     2 |     5  (20)| 00:00:01 |
    |   4 |    SORT GROUP BY     |          |     1 |     2 |     5  (20)| 00:00:01 |
    |   5 |     TABLE ACCESS FULL| DUAL     |     1 |     2 |     4   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("DUMMY"="$nso_col_1")From the first 10053 trace file:
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      _pga_max_size                       = 368640 KB
    pgamax_size is the only parameter non-default value which could affect the optimizer.
    From the second 10053 trace file:
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      _pga_max_size                       = 368640 KB
      _complex_view_merging               = false
      *********************************This section in the first 10053 trace seems to show the complex view merging:
    SU: Considering interleaved complex view merging
    SU:   Transform an ANY subquery to semi-join or distinct.
    CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
    CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
    CVM: CBQT Marking query block SEL$683B0107 (#2)as valid for CVM.
    CVM:   Merging complex view SEL$683B0107 (#2) into SEL$5DA710D3 (#1).
    qbcp:******* UNPARSED QUERY IS *******
    SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM  (SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY") "VW_NSO_2","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    vqbcp:******* UNPARSED QUERY IS *******
    SELECT /*+ */ DISTINCT "DUAL"."DUMMY" "$nso_col_1" FROM "SYS"."DUAL" "DUAL" GROUP BY "DUAL"."DUMMY"
    CVM: result SEL$5DA710D3 (#1).
    ******* UNPARSED QUERY IS *******
    SELECT /*+ */ "DUAL"."DUMMY" "DUMMY" FROM "SYS"."DUAL" "DUAL","SYS"."DUAL" "DUAL" WHERE "DUAL"."DUMMY"="DUAL"."DUMMY" GROUP BY "DUAL"."DUMMY","DUAL".ROWID,"DUAL"."DUMMY"
    Registered qb: SEL$C9C6826C 0x155e2020 (VIEW MERGE SEL$5DA710D3; SEL$683B0107)
      signature (): qb_name=SEL$C9C6826C nbfros=2 flg=0
        fro(0): flg=0 objn=258 hint_alias="DUAL"@"SEL$1"
        fro(1): flg=0 objn=258 hint_alias="DUAL"@"SEL$2"
    FPD: Considering simple filter push in SEL$C9C6826C (#1)
    FPD:   Current where clause predicates in SEL$C9C6826C (#1) :
             "DUAL"."DUMMY"="DUAL"."DUMMY"
    kkogcp: try to generate transitive predicate from check constraints for SEL$C9C6826C (#1)
    predicates with check contraints: "DUAL"."DUMMY"="DUAL"."DUMMY"
    after transitive predicate generation: "DUAL"."DUMMY"="DUAL"."DUMMY"
    finally: "DUAL"."DUMMY"="DUAL"."DUMMY"
    CVM: Costing transformed query.
    kkoqbc-start
                : call(in-use=25864, alloc=65448), compile(in-use=115280, alloc=118736)
    kkoqbc-subheap (create addr=000000001556CD70)This is the same section from the second 10053 trace:
    SU: Considering interleaved complex view merging
    SU:   Transform an ANY subquery to semi-join or distinct.
    CVM: Considering view merge (candidate phase) in query block SEL$5DA710D3 (#1)
    CVM: Considering view merge (candidate phase) in query block SEL$683B0107 (#2)
    FPD: Considering simple filter push in SEL$5DA710D3 (#1)
    FPD:   Current where clause predicates in SEL$5DA710D3 (#1) :
             "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
    predicates with check contraints: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    after transitive predicate generation: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    finally: "DUAL"."DUMMY"="VW_NSO_2"."$nso_col_1"
    FPD: Considering simple filter push in SEL$683B0107 (#2)
    FPD:   Current where clause predicates in SEL$683B0107 (#2) :
             CVM: Costing transformed query.
    kkoqbc-start
                : call(in-use=25656, alloc=65448), compile(in-use=113992, alloc=114592)
    kkoqbc-subheap (create addr=00000000157E9078)Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Career and Succession Planning Business Process

    Dear Friends,
    Can anyone send me anyone client Model Career and Succession Planning Business Process.
    Regards,
    M

    Career and succession planning are generally different business proceses.
    Generally you would need to map the client's own processes; as using a standardised approach here might not serve the purpose
    Suggest that you check with your client to share with you their ISO / EPM documentation for these processes.
    Else, ask the process owner to shared with you a PFD for the process.
    Hope this helps.

  • Explain plan cost it increases after migrating Oracle 9.2.0 to 10.2.0.3

    Hi:
    Recently the migration was made, we are testing (I'm developer) the performance in some querys, but the majority is but slow,I do not understand the reason because the new equipment has processing capacity much more.
    for example , a report , in 9i it is executed in 45 segs, in 10G it is executed in 10 minutes!!!
    Another example: the next explain plan, it's the same query and the same parameters . In oracle 9i COST=799 In Oracle 10G COST=2337
    What happens? Any idea?
    In oracle 9i COST=799
    SELECT STATEMENT Hint=HINT: FIRST_ROWS 1 799
    SORT GROUP BY 1 74 799
    VIEW 1 74 786
    SORT GROUP BY 1 100 786
    TABLE ACCESS BY INDEX ROWID SMRPCMT 1 27 1
    NESTED LOOPS 1 100 774
    NESTED LOOPS 3 219 773
    NESTED LOOPS 3 177 772
    NESTED LOOPS 3 171 771
    NESTED LOOPS 3 123 770
    TABLE ACCESS BY INDEX ROWID SFBETRM 7 K 73 K 22
    INDEX RANGE SCAN SFBETRM_KEY_INDEX2 7 K 24
    TABLE ACCESS BY INDEX ROWID SGBSTDN 1 31 1
    INDEX UNIQUE SCAN PK_SGBSTDN 1
    TABLE ACCESS BY INDEX ROWID STVMAJR 1 16 1
    INDEX UNIQUE SCAN PK_STVMAJR 1
    TABLE ACCESS BY INDEX ROWID STVCAMP 1 2 1
    INDEX UNIQUE SCAN PK_STVCAMP 1
    INDEX RANGE SCAN SMRPATR_KEY_INDEX 1 14 1
    INDEX RANGE SCAN SMRPCMT_KEY_INDEX 1 1
    In Oracle 10G COST=2337
    SELECT STATEMENT Hint=FIRST_ROWS 1 2337
    SORT GROUP BY 1 66 2337
    VIEW 1 66 2336
    SORT GROUP BY 1 158 2336
    NESTED LOOPS 1 158 2335
    NESTED LOOPS 1 142 2334
    NESTED LOOPS 1 140 2333
    NESTED LOOPS 1 126 2332
    NESTED LOOPS 3 297 2330
    TABLE ACCESS BY INDEX ROWID SFBETRM 7 K 73 K 67
    INDEX RANGE SCAN SFBETRM_KEY_INDEX2 7 K 6
    TABLE ACCESS BY INDEX ROWID SGBSTDN 1 89 1
    INDEX UNIQUE SCAN PK_SGBSTDN 1 1
    TABLE ACCESS BY INDEX ROWID SMRPCMT 1 27 1
    INDEX RANGE SCAN SMRPCMT_KEY_INDEX 1 1
    INDEX RANGE SCAN SMRPATR_KEY_INDEX 1 14 1
    TABLE ACCESS BY INDEX ROWID STVCAMP 1 2 1
    INDEX UNIQUE SCAN PK_STVCAMP 1 1
    TABLE ACCESS BY INDEX ROWID STVMAJR 1 16 1
    INDEX UNIQUE SCAN PK_STVMAJR 1 1
    Thank you so much by advance.
    (sorry by my bad english)

    "Cost", as determined by the CBO, is a relative number, not an absolute number. A "cost" of 799 in 9i is not the same as a "cost" of 799 in 10g.
    The CBO is 10g is substantially different as compared to 9i. Performance issues encountered after the upgrade are not uncommon. Pl refer to these MOS Doc to help troubleshoot your issue -
    754931.1 - Cost Based Optimizer - Common Misconceptions and Issues - 10g and Above
    466181.1 - 10g Upgrade Companion
    I would also recommend you upgrade to 10.2.0.4, as it is the latest and most stable version of 10g.
    HTH
    Srini

  • Query with Explain Plan

    Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
    i.e.
    Explain Plan for : Select * from emp a;
    and Explain for : Select * from emp b;
    Will remain same always, or it will differ?
    Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
    Thanks in Advance.
    Regards,
    Sudipta.

    user13513014 wrote:
    Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
    i.e.
    Explain Plan for : Select * from emp a;
    and Explain for : Select * from emp b;
    Will remain same always, or it will differ? By simply switching alias, the optimizer is unlikely to develop a new plan.
    Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
    Thanks in Advance.
    Regards,
    Sudipta.There is no way you can actally see the parsing of SQL. It is done internally by oracle in a process caled Hard Parse or Soft Parse. A Hard Parse is where the optimizer must go through all the steps of parsing from the beggining, where as a soft parse, oracle uses the cached results from a hard parsed query that is in the shared pool.
    How the optimizer works is a subject of ample documentation and several books. As a general over view, here are the general steps at parsing an SQL:
    1. Optimizer evaluates your statement, checks it for grammar errors, grants to objects, etc.
    2. Statement Transformation: Optimizer evaluates your statement for possible optimization regarding rewrite, in cases you have view or correlated subqueries.
    3. Choice of optimizer goals.
    4. Choice of acccess paths.
    5. Choice of Join Orders.
    Suggest you try a google search, it will give you a lot of material, or check the Oracle Database Performance Tuning Guide 11.2, which is free by oracle.

  • Too  many parallel processes

    Hi
    I will have to build process chain to cube 0SD_C03 and the datasources are
    2LIS_12_VCITM
    2LIS_12_VCHDR
    2LIS_12_V_ITM
    2LIS_12_VDHDR
    2LIS_12_VAITM
    2LIS_12_VDITM
    2LIS_12_VADHDR
    Now the question is after providing the links between " Delete index" process and individual  loading process (Infopackages),the message I am getting in the checking view is " Too many parallel processes for chosen server " and furthe,r the suggested procedure by system is " Reduce the number of parallel processes in the chain or include sub-chains :
    How can I reduce the processes? Is there any alterante method of building this flow to avoid warning messages..
    Though these are warning messages ,what is the correct flow of building process chain for this without getting any warning messages.

    Hi,
    Based on dependency better you can go for 3 parellel process at a time as what we are doing in our project. 
    check schedule time for each your process chain which fetchs data from source system (Info Package) and re schedule them which should not execute at a time (make it max 3) and try again
    Regards
    BVR

  • Explain Plan vs. V$SQL_PLAN

    Hello everyone,
    I'm trying to understand the difference between those two, I'm relying on the following Tom Kyte article :
    http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
    In my following example I didn't use TKPROF as he did but AUTOTRACE / V$SQL_PLAN instead (since EXPLAIN PLAN shows a theoretical plan that can be used if this statement were to be executed and V$SQL_PLAN contains the actual plan used)
    That's my code :
    >
    HR> ALTER SYSTEM FLUSH shared_pool ;
    HR>
    HR> create table test
    2 as
    3 select a.*, 1 id
    4 from all_objects a
    5 where rownum = 1;
    Table created.
    HR>
    HR> create index t_idx on test(id);
    Index created.
    HR>
    HR> -- AUTOTRACE vs V$SQL round 1 ...
    HR> ---------------------------------
    HR>
    HR> SET AUTOTRACE ON EXPLAIN
    HR>
    HR> select id, object_name from test where id = 1;
    ID OBJECT_NAME
    1 ICOL$
    Execution Plan
    Plan hash value: 2783519773
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 30 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
    |* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - access("ID"=1)
    Note
    - dynamic sampling used for this statement (level=2)
    HR>
    HR> SET AUTOTRACE OFF
    HR>
    HR>
    HR> select operation, options, object_name, cost
    2 from v$sql_plan
    3 where hash_value= ( SELECT hash_value
    4 FROM v$sqlarea
    5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
    6 AND sql_text NOT LIKE '%v_sql%');
    OPERATION OPTIONS OBJECT_NAME COST
    SELECT STATEMENT 2
    TABLE ACCESS BY INDEX ROWID TEST 2
    INDEX RANGE SCAN T_IDX 1
    >
    Ok so in round 1, the optimizer decided to get the 1 row back using Index Range Scan both in "theory" and in "reality", it make sense.
    Now its time for round 2 ... :)
    >
    HR> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
    1000 rows created.
    HR>
    HR> commit ;
    Commit complete.
    HR>
    HR>
    HR> -- AUTOTRACE vs V$SQL round 2 ...
    HR> ---------------------------------
    HR>
    HR> SET AUTOTRACE ON EXPLAIN
    HR>
    HR> select id, object_name from test where id = 1;
    ID OBJECT_NAME
    1 ICOL$
    1 I_VIEWTRCOL1
    1001 rows selected.
    Execution Plan
    Plan hash value: 2783519773
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1001 | 30030 | 6 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1001 | 30030 | 6 (0)| 00:00:01 |
    |* 2 | INDEX RANGE SCAN | T_IDX | 1001 | | 5 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - access("ID"=1)
    Note
    - dynamic sampling used for this statement (level=2)
    HR>
    HR> select operation, options, object_name, cost
    2 from v$sql_plan
    3 where hash_value= ( SELECT hash_value
    4 FROM v$sqlarea
    5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
    6 AND sql_text NOT LIKE '%v_sql%');
    OPERATION OPTIONS OBJECT_NAME COST
    SELECT STATEMENT 2
    TABLE ACCESS BY INDEX ROWID TEST 2
    INDEX RANGE SCAN T_IDX 1
    HR>
    >
    since explain plan is using always Hard Parse (and it used dynamic sampling) I would expect to see FTS in "theory"
    can anyone explain me why in round 2 they both presented Index Range Scan.
    Thanks ! :)

    Explain plan can lie, autotrace - which just does an explain plan - can lie.
    See:
    http://oracle-randolf.blogspot.com/2012/01/autotrace-polluting-shared-pool.html
    http://kerryosborne.oracle-guy.com/2010/02/autotrace-lies/
    http://hoopercharles.wordpress.com/2010/01/11/explain-plan-lies-autotrace-lies-tkprof-lies-what-is-the-plan/
    V$SQL_PLAN is the truth.
    You didn't mention version but DBMS_XPLAN is the most convenient way to get your plan.
    If the plan is cached, inserting 1000 rows is not going to change the plan.
    SQL> create table test
      2  as
      3  select a.*, 1 id
      4  from all_objects a
      5  where rownum = 1;
    Table created.
    SQL>
    SQL> create index t_idx on test(id);
    Index created.
    SQL>
    SQL> select id, object_name from test where id = 1;
            ID OBJECT_NAME
             1 ORA$BASE
    SQL>
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    SQL_ID  3qan6s0j3uab5, child number 0
    select id, object_name from test where id = 1
    Plan hash value: 2783519773
    | Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST  |     1 |    30 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("ID"=1)
    Note
       - dynamic sampling used for this statement (level=4)
    23 rows selected.
    SQL> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
    1000 rows created.
    SQL> commit;
    Commit complete.
    SQL> select id, object_name from test where id = 1;
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    SQL_ID  3qan6s0j3uab5, child number 0
    select id, object_name from test where id = 1
    Plan hash value: 2783519773
    | Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST  |     1 |    30 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("ID"=1)
    Note
       - dynamic sampling used for this statement (level=4)
    23 rows selected.
    SQL>

  • ORA-01438 occurred during "Explain plan"!

    Here is my query:
    SELECT
    rtrim(T1.col_id) Field0
    , count(T2.col_id) Field2
    , count(T3.col_id) Field3
    FROM SS.Table1 T1
    LEFT JOIN SS.Table2 T2
    ON (rtrim(T1.col_id) = rtrim(T2.col_id))
    LEFT JOIN SS.Table3 T3
    ON (rtrim(T1.col_id) = rtrim(T2.col_id))
    GROUP BY T1.col_id
    When I try to explain it plan I receive an error:
    "ORA-01438: value larger than specified precision allowed for this column"
    Can someone explain this?
    Thanks for the help in advance
    Regards,
    Beroetz

    Hi,
    Not sure how u r getting the explain plan...is it via a third party tool of SQLPLUS. Anyway by looking at the error it doesno tlook like there is a problem in explain plan.Did u run the script and check whether there is any error???There is a datatype error i guess.Please check ur script and the data in it.
    Regards
    Bharath

  • Query regarding Partition table Explain plan

    Hello,
    We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
    The snippet from explain plan looks like:
    | Id  | Operation                                | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 |  9083K|       |  1386   (1)| 00:00:17 | ROWID | ROWID |
    On another similar query it looks like:
    | Id  | Operation                             | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 |  4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
    I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
    Oracle Version:- 10.2.0.4
    Regards,
    Purvesh.

    Hi Purvesh.
    Great explanation and example on this this topic...
    Ask Tom &amp;quot;explain plan on range-partitioned table&amp;quot;
    Hope this help.

  • Strange explain plan when query SYS tables

    Oracle Version 9.2.0.7
    We have an application that runs the following query on Oracle 9.2.0.7
    SELECT T1.TABLE_NAME,T1.COLUMN_NAME, T1.SRID, T2.SDO_UB, T2.SDO_LB, T1.OWNER FROM ALL_SDO_GEOM_METADATA T1, TABLE(T1.DIMINFO) T2 WHERE T1.OWNER=UPPER(:"SYS_B_0") AND T1.TABLE_NAME=UPPER(:"SYS_B_1")
    Without the self join the query is fine, but with the self join on our customers database the explain plan is doing full table scans and Hash Joins on SYS tables and takes 2 minutes.
    Rows Row Source Operation
    2 FILTER
    2 NESTED LOOPS
    1 TABLE ACCESS FULL SDO_GEOM_METADATA_TABLE
    2 COLLECTION ITERATOR PICKLER FETCH
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    37 TABLE ACCESS FULL TS$
    0 HASH JOIN OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    54 TABLE ACCESS FULL USER$
    0 HASH JOIN
    29447 TABLE ACCESS FULL OBJ$
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS FULL USER$
    0 TABLE ACCESS FULL OBJ$
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    On our development database it takes 0.07 sec with no full table scans and no hash joins.
    Rows Row Source Operation
    2 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
    1 INDEX RANGE SCAN SDO_GEOM_IDX (object id 36753)
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX RANGE SCAN I_OBJ3 (object id 38)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    2 COLLECTION ITERATOR PICKLER FETCH
    ALL_SDO_GEOM_METADATA is a view in the MDSYS schema (generated by Oracle ).
    SELECT SDO_OWNER OWNER,
    SDO_TABLE_NAME TABLE_NAME,
    SDO_COLUMN_NAME COLUMN_NAME,
    SDO_DIMINFO DIMINFO,
    SDO_SRID SRID
    FROM SDO_GEOM_METADATA_TABLE
    WHERE
    (exists
    (select table_name from all_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select table_name from all_object_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select view_name table_name from all_views
    where view_name=sdo_table_name
    and owner = sdo_owner))
    Statistics have been gathered for the MDSYS user.
    If this had not been SYS schema I would have immediately concluded that fresh statistics are required. The SYS objects concerend are valid with all indexes
    From my understanding you are not meant to gather stats for the SYS schema in Oracle 9 as Data Dictionary queries still uses RBO?
    Any ideas as to why Oracle is doing full table scans when querying SYS tables? The optimizer_mode is set to FIRST_ROWS.
    Any ideas greatly recevied.
    Thanks

    Maybe I'm missing something but this:
    INDEX FULL SCAN     SISESTAT     I0_ESTRUTURA_COMERCIALindicates that one of those indexes is being used.
    This:
    T_ESTRUTURA_COMERCIALIs nowhere to be found in your Explain Plan. It appears that either you have posted the wrong plan
    or Oracle is doing a query rewrite to a materialized view.

  • Understanding CBO decisions, explain plan instability

    Hi,
    I have a situation where the explain plan for a SELECT statement changes
    and performance takes a turn for the worse. The statement in question
    executes well and has the desired explain plan but after an insertion
    having a new eventtype ID the explain plan changes (doing lots of IO)
    and remains bad until the SGA is flushed.
    I would really like to know how to figure out how the CBO makes its
    decisions and why it changes its mind over a 2min period. Any pointers
    to get me started would be greatly appreciated.
    Table has columns C_ID, R_ID, EVENTTYPE, ...
    Regular indexes on (R_ID,C_ID) and EVENTTYPE.
    The SELECT runs well as long as the compound index is used first
    and runs poorly once a new EVENTTYPE is introduced (there are
    approx 10 event types and a new one is being introduced) and its
    index consulted first.
    Thansk,
    Darren

    Delayed block cleanout really confused me. I don't see how
    the details of block updates, SCNs and what is on disk relates
    to explain plans and a SQL statement that changes from
    performing well using the intended index to poorly using an index
    on a column having low cardinality.
    The SQL is actually quite trivial and a merely a lookup on this
    single table.
    SELECT * FROM table
    WHERE c_id = :1 and r_id = :2 and eventtype = :3
    Most of the time Oracle uses the intended index (r_id, c_id) and
    performs well. As long as both columns are used in the condition
    I don't think that ordering of them is an issue.
    If the CBO uses stats which get updated nightly after sufficient
    changes to the table then how can a statement change its execution
    plans (for the same user) following a addition of a row having a
    new EVENTTYPE value over a 2min period.
    That is the reason that I want to see/understand what the CBO
    is doing.
    It turns out that adding a new index (C_ID, R_ID, EVENTTYPE) was
    the bandaid needed to fix the problem but I'd like to get rid of
    it if its not needed.
    I'll look at these posts and try to get the differing plans back.
    At this point I'll need to drop the new index and break the app
    again and might receive some resistance to that.
    Thanks for your input,
    Darren

  • How Explain Plan Calculates the Bytes

    Hi All,
    I am using Oracle 10g edition 10.2.0.3.0.
    Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
    1) How bytes are calculcated?
    2) What "Cost = 1" means?
    3) What "%CPU = 0 means?
    SQL> desc t_pdur_insulin_prof
    Name
    SAK_RECIP NOT NULL NUMBER(9)
    SAK_CLAIM NOT NULL NUMBER(9)
    SAK_DRUG NOT NULL NUMBER(9)
    DTE_DISPENSE NOT NULL NUMBER(8)
    CDE_PROF_TYPE NOT NULL CHAR(1)
    SQL> explain plan for
    2 select * from t_pdur_insulin_prof
    3 where sak_recip = 10013819;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 438947110
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
    |* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - access("SAK_RECIP"=10013819)
    13 rows selected.
    Thanks!

    user2081225 wrote:
    Hi All,
    I am using Oracle 10g edition 10.2.0.3.0.
    Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
    1) How bytes are calculcated?
    2) What "Cost = 1" means?
    3) What "%CPU = 0 means?
    SQL> desc t_pdur_insulin_prof
    Name
    SAK_RECIP NOT NULL NUMBER(9)
    SAK_CLAIM NOT NULL NUMBER(9)
    SAK_DRUG NOT NULL NUMBER(9)
    DTE_DISPENSE NOT NULL NUMBER(8)
    CDE_PROF_TYPE NOT NULL CHAR(1)
    SQL> explain plan for
    2 select * from t_pdur_insulin_prof
    3 where sak_recip = 10013819;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 438947110
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
    |* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - access("SAK_RECIP"=10013819)
    13 rows selected.
    Thanks!consider Reading The Fine Manual
    http://docs.oracle.com/cd/E11882_01/server.112/e16638/optimops.htm#sthref981

  • Please help to understand 10g explain plan

    Hello
    I am trying to optimize one query. I have taken explain plan of this query in 9i and 10g database both.
    Explain plan for index scan is different in 9i and 10g. In 9i inedex was scaned with INDEX RANGE SCAN NON-UNIQUE and in 10g index is scanned with
    INDEX RANGE SCAN.
    Can anybody explain the difference of scanning an index in 9i and 10g? Cost in 9i was 74 and now in 10g it is 1134.
    Thanks in advance

    Well, if you tables structures and indexes are the same in both databases then that's unlikely to be an issue, however you need to check other factors such as whether statistics have been gathered for the data recently.
    For helpful info on optimising queries and what to look out for read the following thread...
    [When your query takes too long|http://forums.oracle.com/forums/thread.jspa?messageID=1812597#1812597]

  • Parallel Processing : How to Handle Resource failure?

    Hi,
    I have implemented the parallel processing/ asynchronous rfc call in my system because we have to process millions of records and processing is important. My Program does work fine in Development and quality for small number of records but during SVT I am encountering RESOURCE_FAILURE exception. As of now I have tried to wait for more time and then process it again and also on failure I have tried to process sequential but nothing worked with second approach that is on resource_failure execute normal FM call it is resulting in terminating Parallel processing.
    Any Pointer on how to handle it is appreciated.
    Regards,
    Deepak Bhalla

    <b>Handling the RESOURCE_FAILURE exception:</b> As each parallel processing task is dispatched, the SAP system counts down the number of resources (dialog work processes) available for processing additional tasks. This count goes up again as each parallel processing task is completed and returns to your program.
    Should your parallel processing tasks take a long time to complete, then the parallel processing resources may temporarily run out. In this case, CALL FUNCTION returns the exception RESOURCE_FAILURE. This means simply that all dialog work processes in the RFC group that your program is using are in use.
    Your program must now wait until resources become available and then re-issue the CALL FUNCTION that failed. In the sample program, we use a simple, reasonably failsafe wait mechanism. The program waits for parallel processing tasks to return, freeing up resources. The WAIT also specifies a initial timeout of 1 second. If the CALL FUNCTION again fails, the WAIT is repeated with a longer time-out. You can increase the time-outs if you expect that your parallel tasks will take longer to complete. You should also add code to exit from the retry loop after a suitable number of iterations.
    Use WAIT statement.
    Hope this resolves u r issue.
    - Raj

Maybe you are looking for

  • How to restore AND REPLACE mail folders (don't want duplicates etc)?

    Bad OS X 10.5.7 upgrade has made my machine real slow doing many things. So I want to revert to my superduper backup: the only new data since the OS upgrade is my email (and my Aperture data, but I can just restore from my vault for that). If I use M

  • MacBook Pro is randomly shutting off.

    When it restarts the date and time reset to something like January 1, 2000 before changing back to the correct date and time several minutes later. Two months ago I had a problem with overheating with my Macbook that the Apple Store took care of. Any

  • What to do with a file in the top of finder

    I accidently droped an MP3 file onto the top of the finder. Now there is a little file up by the minimize button. When I click on it it opens the file, but I don't know how to make it go away. I'm a new convert from the PC world but enjoying things f

  • Problems loading 0FIAR_C03 infoprovider

    The load to ODS is ok, but when i tried to "Upload ODS data in data target" i got the error message: "Data source 80FIAR_O03 has to be replicated" to fix this error the help says: "Copy data source again and then activate the transfer rules..." I did

  • SAP HR component upgrade

    Hi Friends, We have SAP_HR 600 SP18 level 58 and same EA_HR. We want to upgrade it to SAP_HR 602 and EA_HR602. We ahve tried it on service market place but not getting. Please send the link from where we can download the same. Regards Ganesh Datt Tiw