Explain Plan from TKPROF trace file.

Hello,
My procedure is taking time for that i have trace on in procedure fo find explain plan of particular query.
Using below statement Trace is on.
   EXECUTE IMMEDIATE 'ALTER SESSION SET SQL_TRACE = TRUE';
   EXECUTE IMMEDIATE 'ALTER SESSION SET TIMED_STATISTICS = TRUE';Now for getting expalin plan from TKPROF i have used below statement but for some query i have found explain paln and some case i cant found explain plan.
tkprof mf_ora_23773.trc mf_ora_23773.txt explain =abc/abc
can u please help me to analyze where i m wrong?
Thanks.

First of all, you should best avoid using the explain= clause on the tkprof command line.
This will run explain plan on the statement in the trace file, and that explain plan can even be wrong, as there is no information on datatypes in the trace file.
The real explain plan data is flushed to the trace file, when the program issues commit or rollback. Oracle always issues an implicit commit when the program disconnects, so when you run the program to completion you should have explain plan output in your trace files.
You won't get explain plan output if you don't have access to the objects in the SQL statement. Also recursive SQL won't produce explain plan result.
One would need to see part of your trace file to verify your assertion the explain clause doesn't always work.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

  • Need help understanding Explain Plan from 10046 trace

    Below is a query and Explain Plan from a 10046 trace shown with trcanlzr.sql.
    In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
    SELECT cp.cred_process_id, cp.provider_id,
           brdg_credentialing.get_appl_specialist(cp.cred_process_id,'R') specialist_name,
           brdg_cred_report_pkg.provider_name(cp.cred_process_id) provider_name,
           ctc_apptype.description appl_type_desc,
           TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)) init_received_dt,
           brdg_code_util.code_descr(brdg_credentialing.get_appl_status_cd_ctc_id(cp.cred_process_id)) appl_status_desc,
           brdg_credentialing.get_appl_prac_specialties(cp.cred_process_id,'Y') primary_specialty,
           cwh.city practice_city,
           UPPER (cwh.state) practice_state,
           TRUNC (ch.event_dt) specialist_assign_dt,
           DECODE (ctc_apptype.code,'INITPPO', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'REAPP', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'SPECCRED', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'TRANS', TRUNC (brdg_credentialing.get_appl_received_dt(cp.cred_process_id)),
                   'RECPPO', p.next_recred_dt,
                   'RECAPP', p.next_recred_dt, NULL) sort_date,
                   p.next_recred_dt
      FROM brdg_cred_app_open_vw cp,
           brdg_cat_type_codes ctc_apptype,
           brdg_cred_work_history cwh,
           brdg_cred_history ch,
           brdg_providers p
    WHERE cp.type_cd_ctc_id = ctc_apptype.cat_type_code_id
       AND ctc_apptype.category_cd = 'CRED'
       AND ctc_apptype.type_cd = 'APPTYPE'
       AND cp.cred_process_id = cwh.cred_process_id (+)
       AND cwh.primary_practice_flag (+) = 'Y'
       AND cp.cred_process_id = ch.cred_process_id
       AND ch.cred_history_id = (SELECT MAX(cred_history_id)
                                   FROM brdg_cred_history
                                  WHERE cred_process_id = cp.cred_process_id
                                    AND event_cd_ctc_id = brdg_credentialing.get_event_ctc_id ('SEVENT','SPESTCHG'))
       AND cp.provider_id = p.provider_id (+)
       and brdg_credentialing.get_appl_specialist_id(cp.cred_process_id) = 5
    ORDER BY 3 ASC, 3, 5, 12, 6
            Explain Plan Operation
    ID   PID    Card     Rows    Cost      SearchCols  /   Indexed Cols     Predicates 
    0:    1                       36   SELECT STATEMENT   
    1:    0     1       139       36    SORT ORDER BY   
    2:    1             139            . FILTER   [+]  
    3:    2     1       311       11   .. NESTED LOOPS OUTER   
    4:    3     1       311       10   ... NESTED LOOPS OUTER   
    5:    4     1       311        9   .... NESTED LOOPS   
    6:    5     1       311        8   ....+ NESTED LOOPS   
    7:    6     4        16        1   ....+. TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    8:    7     4        16        1   ....+.. INDEX RANGE SCAN CAT_TYPE_CODE_UK 2/3 [+]   [+]  
    9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]  
    10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]  
    11:   10     1         3        2   ....+... NESTED LOOPS   
    12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]  
    14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]  
    15:    5     1        11        1   ....+ TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    16:   15     1       311        1   ....+. INDEX UNIQUE SCAN CDHT_PK 1/1 [+]   [+]  
    17:   16     1       311            ....+.. SORT AGGREGATE   
    18:   17     1       526        2   ....+... TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    19:   18    23      9950        1   ....+.... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]  
    20:    4     1       219        1   .... TABLE ACCESS BY INDEX ROWID PROVIDERS   
    21:   20     1       219        1   ....+ INDEX UNIQUE SCAN PROV_PK 1/1 [+]  [+]  
    22:    3     1       311        1   ... TABLE ACCESS BY INDEX ROWID CRED_WORK_HISTORY   [+] 
    23:   22     3      1057        1   .... INDEX RANGE SCAN CDWH_CDPR_FK 1/1 [+]   [+]  
    24:    2   172                      .. INLIST ITERATOR   
    25:   24     1       172        1   ... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]  
    26:    2     1         0        2   .. TABLE ACCESS BY INDEX ROWID CRED_HISTORY   [+]  
    27:   26    23      2004        1   ... INDEX RANGE SCAN CDHT_CDPR_FK 1/1 [+]   [+]  
    (1) X/Y: Where X is the number of searched columns from index, which has a total of Y columns.
    (2) Actual rows returned by operation (average if there were more than 1 execution).
       2 - filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES" "BRDG_CAT_TYPE_CODES" WHERE
                  "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIALING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)) AND
                  ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND
                  "CATEGORY_CD"='APPSTAT') AND  NOT EXISTS (SELECT 0 FROM "PPO"."CRED_HISTORY" "BRDG_CRED_HISTORY"
                  WHERE "CRED_PROCESS_ID"=:B2 AND "EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC
       8 - access("CTC_APPTYPE"."CATEGORY_CD"='CRED' AND "CTC_APPTYPE"."TYPE_CD"='APPTYPE')
       9 - filter("BRDG_CREDENTIALING"."GET_APPL_SPECIALIST_ID"("CP"."CRED_PROCESS_ID")=5 AND
                  ("CP"."INS_DT">=TO_DATE(' 2007-12-20 17:00:00', 'syyyy-mm-dd hh24:mi:ss') OR
                  "CP"."TYPE_CD_CTC_ID"<>"BRDG_CODE_UTIL"."GET_ID"('CRED','APPTYPE','RECPPO')))
      10 - access("CP"."TYPE_CD_CTC_ID"="CTC_APPTYPE"."CAT_TYPE_CODE_ID")
           filter( NOT EXISTS (SELECT 0 FROM "PPO"."CAT_TYPE_CODES"
                  "CTC_APPTYPE","PPO"."CAT_TYPE_CODES" "CTC_TYPE" WHERE "CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1 AND
                  "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE" AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
                  "CTC_APPTYPE"."CATEGORY_CD"='APPTYPE'))
      13 - access("CTC_TYPE"."CAT_TYPE_CODE_ID"=:B1)
      14 - access("CTC_APPTYPE"."CATEGORY_CD"='APPTYPE' AND "CTC_APPTYPE"."TYPE_CD"='APPSENT' AND
                  "CTC_TYPE"."CODE"="CTC_APPTYPE"."CODE")
      15 - filter("CP"."CRED_PROCESS_ID"="CH"."CRED_PROCESS_ID")
      16 - access("CH"."CRED_HISTORY_ID"= (SELECT MAX("CRED_HISTORY_ID") FROM "PPO"."CRED_HISTORY"
                  "BRDG_CRED_HISTORY" WHERE "CRED_PROCESS_ID"=:B1 AND
                  "EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG')))
      18 - filter("EVENT_CD_CTC_ID"="BRDG_CREDENTIALING"."GET_EVENT_CTC_ID"('SEVENT','SPESTCHG'))
      19 - access("CRED_PROCESS_ID"=:B1)
      21 - access("CP"."PROVIDER_ID"="P"."PROVIDER_ID"(+))
      22 - filter("CWH"."PRIMARY_PRACTICE_FLAG"(+)='Y')
      23 - access("CP"."CRED_PROCESS_ID"="CWH"."CRED_PROCESS_ID"(+))
      25 - access("CATEGORY_CD"='APPSTAT' AND ("TYPE_CD"='APPROVAL' OR "TYPE_CD"='DENIED' OR
                  "TYPE_CD"='INACTIVE' OR "TYPE_CD"='TERMED') AND "CODE"="BRDG_CODE_UTIL"."ID_CODE"("BRDG_CREDENTIAL
                  ING"."GET_APPL_STATUS_CD_CTC_ID"(:B1)))
      26 - filter("EVENT_CD_CTC_ID"="BRDG_CODE_UTIL"."GET_ID"('CRED','SEVENT','MSODC'))
      27 - access("CRED_PROCESS_ID"=:B1)

    Welcome to the forums!
    user11987210 wrote:
    In the explain plan I don't understand what's happining at line ID 10 and 11. Specifically, is the result at line 11 rowids from lines 12 & 14? and then what? Are those rowids somehow used in line ID 10?
    9:    6     1       311        2   ....+. TABLE ACCESS BY INDEX ROWID CRED_PROCESSES   [+]  
    10:    9   183     61927        1   ....+.. INDEX RANGE SCAN CDPR_CTCD_FK1 1/1 [+]   [+]  
    11:   10     1         3        2   ....+... NESTED LOOPS   
    12:   11     1        16        1   ....+.... TABLE ACCESS BY INDEX ROWID CAT_TYPE_CODES   
    13:   12     1        16        1   ....+....+ INDEX UNIQUE SCAN CTCD_PK 1/1 [+]   [+]  
    14:   11     1         3        1   ....+.... INDEX UNIQUE SCAN CAT_TYPE_CODE_UK 3/3 [+]   [+]   The NESTED LOOPS operation (ID #11) has two children, ID #12 sometimes called the driving source, and ID #14 the inner loop. ID #14 is executed once for each row returned by ID #12. The results of ID #11 are then fed to ID #10 which performs an INDEX RANGE SCAN.
    Hope this helps!

  • Oem explain plan produced doesn't correspond to explain plan with tkprof

    Hello all,
    I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
    I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
    Then I did a trace file and ran it throught tkprof.
    When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
    As anybody had these kind of results?
    Shall I have more confidence in TKprof then OEM?
    It is very important to me since I am being chalanged by an external DBA.

    I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
    If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
    However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
    If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
    Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
    Regards,
    Martin
    www.ora-solutions.net

  • Extract SQL history from 10046 trace files

    Hi all,
    I need to extract the complete sql history from sql trace files to "debug" a client application.
    I know I can read the raw trc file and rebuild the sql history looking for the PARSING / EXEC / FETCH entries.
    However, this is a very long and boring manual task: do you know if there is some free tool to automate this task?
    thanks
    Andrea

    user585511 wrote:
    I agree that the 10046 trace captures everything. If I do read the raw trc file I see the DML. The problem is that tkprof's record does not record the DML (maybe it thinks that some DML is recursive sql and it gets misleaded... I am not sure) so I am looking for an alternate tool to process 10046 trace files
    Regards
    AndreaReally?
    Generate a trace of some dml:
    oracle:orcl$
    oracle:orcl$ sqlplus /nolog
    SQL*Plus: Release 11.2.0.1.0 Production on Thu May 16 08:28:55 2013
    Copyright (c) 1982, 2009, Oracle.  All rights reserved.
    SQL> conn snuffy/snuffy
    Connected.
    SQL> alter session set tracefile_identifier = "snuffy_session";
    Session altered.
    SQL> alter session set events '10046 trace name context forever, level 12';
    Session altered.
    SQL> insert into mytest values (sysdate);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> ALTER SESSION SET EVENTS '10046 trace name context off';
    Session altered.
    SQL> exitrun tkprof on the trace
    oracle:orcl$ ls -l $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/*snuffy
    *.trc
    -rw-r----- 1 oracle asmadmin 3038 May 16 08:29 /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    oracle:orcl$ tkprof /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snu
    ffy_session.trc snuffy.rpt waits=YES sys=NO explain=system/halftrack
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.Look at the report:
    oracle:orcl$ cat snuffy.rpt
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.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
    SQL ID: 938dgt554gu98
    Plan Hash: 0
    insert into mytest           <<<<<<<<<<<<<<<< oh my!  Here is the insert statement
    values
    (sysdate)
    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          1          5           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          1          5           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 86  (SNUFFY)
    Rows     Row Source Operation
          0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=0 us)
    error during execute of EXPLAIN PLAN statement
    ORA-00942: table or view does not exist
    parse error offset: 83
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        3.35          3.35
    SQL ID: 23wm3kz7rps5y
    Plan Hash: 0
    commit
    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          1           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          1           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2        4.72          8.50
      log file sync                                   1        0.00          0.00
    SQL ID: 0kjg1c2g4gdcr
    Plan Hash: 0
    ALTER SESSION SET EVENTS '10046 trace name context off'
    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        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    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      0.00       0.00          0          1          6           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        6      0.00       0.00          0          1          6           1
    Misses in library cache during parse: 0
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       3        0.00          0.00
      SQL*Net message from client                     3        4.72         11.86
      log file sync                                   1        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        3  user  SQL statements in session.
        0  internal SQL statements in session.
        3  SQL statements in session.
        0  statements EXPLAINed in this session.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    Trace file compatibility: 11.1.0.7
    Sort options: default
           1  session in tracefile.
           3  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           3  SQL statements in trace file.
           3  unique SQL statements in trace file.
          58  lines in trace file.
           8  elapsed seconds in trace file.
    oracle:orcl$

  • Does bigger explain plan in TKPROF output indicate something wrong with SQL

    We were tracing some database sessions.
    Using TKPROF we were able to read the trace file.
    we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
    150 lines of explain plan.
    So we realized that the sql statements are badly written.
    Based on that above can we come into the following conclusion:
    - for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
    is wrongly written ?

    johnpau2013 wrote:
    We were tracing some database sessions.
    Using TKPROF we were able to read the trace file.
    we have noticed that some of the SQL ( 1-2 lines SQL statements) were showing up atleast
    150 lines of explain plan.
    So we realized that the sql statements are badly written.
    Based on that above can we come into the following conclusion:
    - for 1-2 lines of SQL Statement if there is 100+ lines of explain plan in TKPROF report, it indicates the SQL statement
    is wrongly written ?The only rule that is always true for tuning SQL, is that NO rule is ALWAYS true for every SQL statement &
    every data distribution.
    it depends
    post actual example, so we can see what you see.

  • 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 |
    --------------------------------------------------------------------------

  • Explain plan only in spool file

    Hi there,
    I am trying to spool only my explain plan to a file, at the moment i can only return all the results and then explain plan to the file. This is a bit of a problem as i am running some rather long queries and some of them return over 80MB of data. this is what i have so far:
    set termout off
    timing start
    set autotrace on
    set heading off
    spool h:\test1.lst
    select unique1 from table1;
    timing stop
    spool off
    set autotrace off
    set termout on
    any help on this would be great.
    Thanks!

    Or for a handy way to preview the expected plan without executing the query, try www.williamrobertson.net/code/xplan.sql
    SQL> SELECT COUNT(*) FROM dept d
      2  WHERE  EXISTS
      3         ( SELECT NULL FROM emp e
      4           WHERE  e.deptno = d.deptno )
      5 
    SQL> -- Note we did not execute anything...
    SQL> @xplan
    Plan hash value: 4196393176
    | Id  | Operation            | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |         |     1 |     6 |     4  (25)| 00:00:01 |
    |   1 |  SORT AGGREGATE      |         |     1 |     6 |            |          |
    |   2 |   NESTED LOOPS       |         |     3 |    18 |     4  (25)| 00:00:01 |
    |   3 |    SORT UNIQUE       |         |    14 |    42 |     3   (0)| 00:00:01 |
    |   4 |     TABLE ACCESS FULL| EMP     |    14 |    42 |     3   (0)| 00:00:01 |
    |*  5 |    INDEX UNIQUE SCAN | PK_DEPT |     1 |     3 |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       5 - access("E"."DEPTNO"="D"."DEPTNO")
    SQL> -- And the query is still there:
    SQL> l
      1  SELECT COUNT(*) FROM dept d
      2  WHERE  EXISTS
      3         ( SELECT NULL FROM emp e
      4*          WHERE  e.deptno = d.deptno )

  • Max wait from a trace file...what does it mean

    Hi,
    following is a part of an extended sql trace file :
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    library cache lock 5 0.00 0.00
    row cache lock 7 0.00 0.00
    library cache pin 3 0.00 0.00
    rdbms ipc reply 2 0.00 0.00
    SQL*Net message to client 8185 0.00 0.01
    SQLNet message from client 8185 1671.98 1688.26*
    here what does the column max.wait mean? this is a trace file when a proc was run remotely to a database - it has lots of dbms_output statements, it creates an output file (on the remote pc from which it runs) the proc calls several sql scrips, does lot of query and dml
    Now when teh same script is run locally from the server those sql net waits are not there. and the interesting fact is: when run locally it takes 4 mins
    and remotely it takes 1 hour. How can we interpret this? and what does teh max wait indiccate?
    thanks,

    Can you explain more on this? the same proc when run locally does not have this wait and when run from remote ip it has this wait - so does that mean that this is due to network issue?
    should we for example - remove the dbms_output statements from this and try ? what should we do to be able to run the script from remote ip and run it in 6-7 minutes- when the scritp is run locally from the from server it takes 4 minutes and from a remote ip it takes one hour. the script also has a spool statement as it has to log its output. Is it that spoling that may be causing this?
    Thanks again,
    Edited by: orausern on Jan 18, 2010 7:09 AM

  • Need information from the Trace file.

    Hi
    I have enabled the trace file for the query and found that the below contents in top of the query in trace file .Could you please explain what are the below values and need explanation.
    **PARSING IN CURSOR #2 len=82 dep=1 uid=0 oct=3 lid=0 tim=52772641300291 hv=3873422482 ad='3a40cc8c8' sqlid='0k8522rmdzg4k'**
    Note : Please provide the notes if have any.
    Thanks
    Lio

    This is of course right but TKPROF has also some limitations: for example TKPROF does not report values for bind variables but you can find them in raw trace file.

  • Cant reclaim free space from deleted trace file in bdump

    Hi ,
    Os : IBM aix 5.3
    Oracle : oracle 10.2.0.3 enterprise edition
    My /oracle space is only 2gb remaining .
    i deleted more 2gb trace files from bdump folder but when i check on os for free space its still showing that only 2gb is remaining for /oracle
    plz help me guys................

    Hi,
    You need to kill the OS PID's accessing the dump directory FS to get space released ..Refer below, how it can be done
    [oracle9i@M6UAT-DB:/home/oracle9i>]pwd
    /oracle/product/admin/M6CORP/udump
    [oracle9i@M6UAT-DB:/home/oracle9i>]fuser -c /oracle/product/admin/M6CORP/udump
    /oracle/product/admin/M6CORP/udump:   102612c  213018c  278544  327850c  340170c  356426c  466986c  495782c  516276c  565368c  610416c  626822c  647266c  696352c  704692c  708632c  745654c  753666c  766036c  778448c  794750c  798966c  852002c  864438c  880678c  884826c  892980c  905248c  925944c  938066c  950490c  958478c  966900c  974924c  979180c  991400c 1007816c 1015990c 1028342c 1032316c 1040494c 1044584c 1048790c 1064962c 1069198c 1077448c 1114204c 1130594c 1143014c 1146978c 1175638c 1191982c 1196276c 1216524c 1241106c 1249470c 1253520c 1261794c 1278186c 1290380c 1302720c 1306640c 1343604c 1347682c 1351874c 1355950c 1359928c 1372280c 1380602c 1384452c 1405106c 1454216c 1458424c 1462418c 1474594c 1482906c 1511456c 1515552c 1523846c 1527914c 1544408c 1548308c 1552392c 1560670c 1564732c 1568938c 1581288c 1597468c 1601616c 1630268c 1634464c 1650836c 1654816c 1667186c 1679502c 1683656c 1687722c 1695962c 1700028c 1703952c 1712276c 1720546c 1728524c 1732832c 1736736c 1744946c 1749098c 1757358c 1761474c 1769496c 1777784c 1781850c 1785944c 1789966c 1798162c 1806568c 1822912c 1851628c 1855700c 1867794c 1871934c 1892562c 1900660c 1904794c 1908936c 1917174c 1921244 1929398c 1937446c 1945762c 1957936c 1962036c 1994984c 1998914c 2039896c 2044122c 2060456c 2064548c 2068632c 2072672c 2076892c 2084908c 2089162c 2101466c 2105384c 2109494c 2125952c 2130136c 2134050c
    [oracle9i@M6UAT-DB:/home/oracle9i>]kill -9 102612  213018  278544  327850  340170  356426  466986  495782  516276  565368  610416  626822  647266Thanks,
    Ajay More
    http://moreajays.blogspot.com

  • Unable to generate explain plan from toad

    HI,
    Toad Version:8.6
    I was unable to generate the explain plan in the toad.Here i create PLAN_TOAD table also but it is still getting the same error
    ORA-00942: table or view does not exist

    Hello,
    You created the Table PLAN_TABLE but you must check the configuration of TOAD.
    It seems to me that by default TOAD use the Table TOAD_PLAN_TABLE.
    So, you must set the right name of the Table (or rename the Table PLAN_TABLE).
    Best regards,
    Jean-Valentin Lubiez

  • How to get the real table information of a structure from the trace file?

    I user the ST05 to trace a program to find the real table information of a structure in this program. But I found so many sql trace information in the trace file. So how can I find which information is useful for me to find the real table of a structure?

    Hi!
    If you don't recognize some tables, because they belong to same application, then it's difficult.
    Try to change interesting value. Afterwards you can search for 'INSERT', 'UPDATE' (and 'MODIFY'?) - that will leave only a small number of lines, which have to be analyzed in detail (e.g. have a look at them with SE16).
    Regards,
    Christian

  • 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

  • Explain plan change

    9.2.0.8 on solaris 10
    What are the scenarios that an explain plan will change when using RBO as optimizer_mode
    we have a query like :
    select * emp where empno=101;
    For this query , the explain plan uses the index in the column empno where as the query :
    select * emp where empno=501;
    doesn't use a index . the time taken for retreival is the same . but why does the explain plan change ?.
    Do we have to collect stats when using RBO ?
    I tried tracing the above sessions, but couldn't find any diff (just to let you know that I tried )
    Edited by: user12046873 on Feb 28, 2010 10:43 PM

    It appears you are not using RBO, because using RBO would have resulted in the same execution plans. PERIOD.
    Nor should you use RBO, as CBO provides way better execution plans.
    You don't post these execution plans, nor how you retrieved them, so no comments are possible.
    They need to be the live execution plan from a trace file,+not using explain=+ as that will have tkprof calculate the explain plan.
    Sybrand Bakker
    Senior Oracle DBA

  • Interpreting Trace File.

    Hi i am using 10.2.0.4.0 version of oracle.
    I am having trace file info as below, for one of the query. So how should i interpret the trace file? What is the issue in the query, and the scope of improvement in the query? please note that , i have removed the query and its plans from the trace file, i have only posted the wait sections.
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.14       0.13          0          0          1           0
    Execute      1      6.63     162.12      33540      72921        383           0
    Fetch    17272    178.89    1933.95     274835    3147603         20      259063
    total    17274    185.66    2096.21     308375    3220524        404      259063
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 36 
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      control file sequential read                    4        0.00          0.00
      db file sequential read                    302812        0.62       1913.89
      latch: cache buffers chains                     3        0.04          0.04
      direct path write temp                        501        0.01          0.30
      SQL*Net message to client                   17272        0.00          0.04
      db file scattered read                        120        0.02          0.63
      direct path read temp                         608        0.14          1.71
      SQL*Net message from client                 17272       44.81      31865.74
      SQL*Net more data to client                    15        0.00          0.00
      latch: object queue header operation            1        0.00          0.00
      latch: library cache                            3        0.03          0.04
      latch: library cache pin                        1        0.00          0.00
      latch: cache buffer handles                     1        0.00          0.00
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.14       0.13          0          0          1           0
    Execute      1      6.63     162.12      33540      72921        383           0
    Fetch    17272    178.89    1933.95     274835    3147603         20      259063
    total    17274    185.66    2096.21     308375    3220524        404      259063
    Misses in library cache during parse: 1
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                   17275        0.00          0.04
      SQL*Net message from client                 17274       75.57      31941.39
      SQL*Net more data from client                   2        0.00          0.01
      db file sequential read                    302812        0.62       1913.89
      control file sequential read                    4        0.00          0.00
      latch: cache buffers chains                     3        0.04          0.04
      direct path write temp                        501        0.01          0.30
      db file scattered read                        120        0.02          0.63
      direct path read temp                         608        0.14          1.71
      SQL*Net more data to client                    15        0.00          0.00
      latch: object queue header operation            1        0.00          0.00
      latch: library cache                            3        0.03          0.04
      latch: library cache pin                        1        0.00          0.00
      latch: cache buffer handles                     1        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse       11      0.02       0.01          0          0          0           0
    Execute    348      0.20       0.17          0          0          1           0
    Fetch      367      0.06       0.37         59       1187          0        3806
    total      726      0.28       0.56         59       1187          1        3806
    Misses in library cache during parse: 11
    Misses in library cache during execute: 10
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                        59        0.01          0.32
        1  user  SQL statements in session.
      348  internal SQL statements in session.
      349  SQL statements in session.
    ********************************************************************************

    below is the estimate and actual results.
    | Id  | Operation                              | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Us
    ed-Mem | Used-Tmp|
    |*  1 |  COUNT STOPKEY                         |                             |  13475 |        |  13475 |00:01:32.33 |     134K|  11357 |      0 |       |       |
        |         |
    |   2 |   NESTED LOOPS                         |                             |  13475 |      2 |  13475 |00:01:31.66 |     134K|  11357 |      0 |       |       |
        |         |
    |   3 |    NESTED LOOPS                        |                             |  13475 |      1 |  13475 |00:01:29.22 |   94325 |  11357 |      0 |       |       |
        |         |
    |*  4 |     INDEX RANGE SCAN                   |                |  13475 |      1 |  13475 |00:00:26.63 |   40425 |   4014 |      0 |       |       |
        |         |
    |   5 |     TABLE ACCESS BY INDEX ROWID        | |  13475 |      1 |  13475 |00:01:02.46 |   53900 |   7343 |      0 |       |       |
        |         |
    |*  6 |      INDEX RANGE SCAN                  ||  13475 |      1 |  13475 |00:00:16.80 |   40425 |   2056 |      0 |       |       |
        |         |
    |*  7 |    TABLE ACCESS FULL                   | |  13475 |      2 |  13475 |00:00:02.26 |   40425 |      0 |      0 |       |       |
        |         |
    |   8 |  TABLE ACCESS BY INDEX ROWID           ||  94399 |      1 |  94399 |00:06:17.09 |     389K|  32207 |      0 |       |       |
        |         |
    |*  9 |   INDEX UNIQUE SCAN                    | |  94399 |      1 |  94399 |00:02:59.79 |     294K|  15488 |      0 |       |       |
        |         |
    |  10 |  TEMP TABLE TRANSFORMATION             |                             |      1 |        |    170K|00:35:11.08 |    1575K|    195K|   6158 |       |       |
        |         |
    |  11 |   LOAD AS SELECT                       |                             |      1 |        |      1 |00:04:49.06 |   53704 |  28653 |    264 |   525K|   525K|  5
    25K (0)|              |
    |  12 |    PARTITION RANGE ALL                 |                             |      1 |  55430 |  16097 |00:06:26.06 |   53433 |  28651 |      0 |       |       |
        |         |
    |  13 |     PARTITION HASH ALL                 |                             |     54 |  55430 |  16097 |00:09:20.69 |   53433 |  28651 |      0 |       |       |
        |         |
    |* 14 |      TABLE ACCESS BY LOCAL INDEX ROWID | INV                         |    432 |  55430 |  16097 |00:06:11.42 |   53433 |  28651 |      0 |       |       |
        |         |
    |* 15 |       INDEX SKIP SCAN                  | |    432 |    125K|  16097 |00:00:39.90 |    4642 |   4508 |      0 |       |       |
        |         |
    |  16 |   TABLE ACCESS BY INDEX ROWID          | |      1 |      2 |    170K|00:30:21.66 |    1522K|    166K|   5894 |       |       |
        |         |
    |  17 |    NESTED LOOPS                        |                             |      1 |     97 |    276K|34:55:49.92 |    1470K|    150K|   5894 |       |       |
        |         |
    |  18 |     NESTED LOOPS                       |                             |      1 |     55 |    105K|00:22:14.57 |    1128K|    134K|   5894 |       |       |
        |         |
    |  19 |      NESTED LOOPS OUTER                |                             |      1 |     52 |    105K|00:16:32.91 |     694K|    105K|   5894 |       |       |
        |         |
    |* 20 |       HASH JOIN                        |                             |      1 |     52 |    105K|00:16:19.68 |     402K|    102K|   5894 |  9641K|  2205K| 16
    27K (1)|        10240 |
    |  21 |        VIEW                            |                             |      1 |  65234 |    105K|00:16:16.46 |     402K|    101K|   4655 |       |       |
        |         |
    |  22 |         SORT UNIQUE                    |                             |      1 |  65234 |    105K|00:16:16.46 |     402K|    101K|   4655 |  8724K|  1161K| 61
    8K (48)|         9216 |
    |  23 |          UNION-ALL                     |                             |      1 |        |    105K|00:14:59.93 |     402K|  97342 |    252 |       |       |
        |         |
    |  24 |           NESTED LOOPS OUTER           |                             |      1 |  19975 |    105K|00:14:10.24 |     395K|  94655 |      0 |       |       |
        |         |
    |  25 |            NESTED LOOPS                |                             |      1 |  19975 |    105K|00:13:58.47 |     140K|  93616 |      0 |       |       |
        |         |
    |  26 |             VIEW                       |                             |      1 |  55430 |  16097 |00:00:00.43 |     270 |    531 |      0 |       |       |
        |         |
    |  27 |              TABLE ACCESS FULL         | |      1 |  55430 |  16097 |00:00:00.19 |     270 |    531 |      0 |       |       |
        |         |
    |* 28 |             TABLE ACCESS BY INDEX ROWID| |  16097 |      1 |    105K|00:13:59.70 |     140K|  93085 |      0 |       |       |
        |         |
    |* 29 |              INDEX RANGE SCAN          |     |  16097 |     10 |    145K|00:00:40.42 |   32685 |   8237 |      0 |       |       |
        |         |
    |  30 |            TABLE ACCESS BY INDEX ROWID | |    105K|      1 |  84716 |00:00:16.78 |     254K|   1039 |      0 |       |       |
        |         |
    |* 31 |             INDEX UNIQUE SCAN          | |    105K|      1 |  84716 |00:00:13.05 |     169K|    982 |      0 |       |       |
        |         |
    |  32 |           NESTED LOOPS                 |                             |      1 |  45259 |      0 |00:00:17.19 |    7336 |   2687 |    252 |       |       |
        |         |
    |* 33 |            HASH JOIN RIGHT OUTER       |                             |      1 |  45259 |      0 |00:00:17.19 |    7336 |   2687 |    252 |   884K|   884K|  3
    09K (0)|              |
    |  34 |             TABLE ACCESS FULL          | |      1 |   1673 |   1677 |00:00:00.01 |      24 |      8 |      0 |       |       |
        |         |
    |* 35 |             HASH JOIN                  |                             |      1 |  45259 |      0 |00:00:17.13 |    7310 |   2678 |    252 |  3318K|  1235K|  4
    47K (1)|         2048 |
    |* 36 |              TABLE ACCESS FULL         | |      1 |  45259 |  49043 |00:00:07.41 |    7043 |   2170 |      0 |       |       |
        |         |
    |  37 |              VIEW                      |                             |      1 |  55430 |  16097 |00:00:00.14 |     267 |    256 |      0 |       |       |
        |         |
    |  38 |               TABLE ACCESS FULL        ||      1 |  55430 |  16097 |00:00:00.12 |     267 |    256 |      0 |       |       |
        |         |
    |  39 |            TABLE ACCESS BY INDEX ROWID | |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |
        |         |
    |* 40 |             INDEX UNIQUE SCAN          | |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |
        |         |
    |  41 |        VIEW                            |                             |      1 |  55430 |  16097 |00:00:00.02 |     267 |      0 |      0 |       |       |
        |         |
    |  42 |         TABLE ACCESS FULL              | |      1 |  55430 |  16097 |00:00:00.01 |     267 |      0 |      0 |       |       |
        |         |
    |  43 |       TABLE ACCESS BY INDEX ROWID      | |    105K|      1 |  93385 |00:00:24.90 |     291K|   2104 |      0 |       |       |
        |         |
    |* 44 |        INDEX UNIQUE SCAN               | |    105K|      1 |  93385 |00:00:16.45 |     196K|   1405 |      0 |       |       |
        |         |
    |  45 |      TABLE ACCESS BY INDEX ROWID       | |    105K|      1 |    105K|00:05:49.82 |     434K|  29495 |      0 |       |       |
        |         |
    |* 46 |       INDEX UNIQUE SCAN                ||    105K|      1 |    105K|00:02:54.37 |     328K|  14644 |      0 |       |       |
        |         |
    |* 47 |     INDEX RANGE SCAN                   | |    105K|      2 |    170K|00:03:01.14 |     342K|  15690 |      0 |       |       |
        |         |
    Predicate Information (identified by operation id):
       1 - filter(1>=ROWNUM)
       4 - access("XS"."SITEPK"=:B1)
       6 - access("XS"."VENDORPK"="XB"."VENDORPK")
       7 - filter(("XB"."BUYERCOMPANYPK"="CC"."PARENTCOMPANYPK" OR "XB"."BUYERCOMPANYPK"="CC"."CHILDCOMPANYPK"))
       9 - access("INVOICEPK"=:B1 AND "LINENUM"=:B2)
      14 - filter(("IH"."INVOICEORIGIN"='APP' AND "IH"."PO_PK" IS NULL AND "IH"."ISPOSTED"='Y'))
      15 - access("IH"."PAYPK"=3914297352 AND "IH"."POSTDATE">=1338508800000 AND "IH"."POSTDATE"<1341014400000)
           filter(("IH"."POSTDATE">=1338508800000 AND "IH"."PAYPK"=3914297352 AND "IH"."POSTDATE"<1341014400000))
      20 - access("NEWVIEW"."PRIMARYKEY"="TAB"."INVOICEPK")
      28 - filter(TO_NUMBER("RAT"."AUDITTYPE")<2)
      29 - access("INNERTAB1"."INVOICEPK"="RAT"."INVOICEPK")
           filter("RAT"."INVOICEPK" IS NOT NULL)
      31 - access("RAT"."USERPK"="UR"."USERPK")
      33 - access("RA"."QUEUEPK"="Q"."QUEUEPK")
      35 - access("INNERTAB2"."INVOICEPK"="RA"."INVOICEPK")
      36 - filter(("RA"."INVOICEPK" IS NOT NULL AND "RA"."RECEIVERPK" IS NOT NULL))
      40 - access("RA"."RECEIVERPK"="UR"."USERPK")
      44 - access("TAB"."ENTEREDBY"="UR"."USERPK")
      46 - access("TAB"."INVOICEPK"="ISUM"."INVOICEPK")
      47 - access("IDD"."INVOICEPK"="TAB"."INVOICEPK")
    87 rows selected.
    Elapsed: 00:00:04.10
    SQL>Edited by: 930254 on Aug 7, 2012 9:33 AM

Maybe you are looking for

  • Mixed results on iPad and iPhone 6 Plus with background image. How to fix this?

    Flash Professional CC I'm having an issue with adding images on iPhone 6 plus and iPad. I'm getting mixed results with two items: 1) a background image and 2) a button that should appear at the bottom left-hand corner on any device. In one case the b

  • Tiger 10.4.11 to SL...What am I up against?

    I'm a bit confused. I have a MacBook running 10.4.11. Can I even do an "upgrade" install from Tiger 10.4.11 to SL or do I need to do a "clean" install? If so, how does one go about a clean install? How do I backup my Mail if I need to do a clean inst

  • Has anyone tried using their keyboard dock on iPad 2?

    I'm trying mine out as I write ... it seems to be fine?? Anyone? Anyone?!

  • No Music Player on Myspace? The player doesn't display anymore!

    Hello everyone I have a PowerBook G4 & the last several days I've notice that when I go to myspace.com the music player on artist page will not show up at all, even on my artist page the player is missing. At the bottom of the page it says "There was

  • Timesten and odbc driver

    i installed timesten 7.00.01, and created a mfc application(mfc 7.1). CDatabase is mfc class, see the following fraction code CDatabase     m_db; m_db.Open("mysql");//connect to mysql //m_db.Open("tt");//connect to timestamp CString sql("create table