Interpretation of TKPROF output

Hello colleagues

IM reviews the performance of one of our DBs (10.2.0.2 on MS 2003 SP1). I found a table called ACCESS_INAB that was called frequently. This table in the buffer to keep pinning, we improved demand owerall reaction time.
There is still a question Im fighting with. Still, a specific operation takes a long time (30-45 sec.) to display a comment field. I tried to trace the session and got following the result:

********************************************************************************

Select *.
Of
(select rownum rn, a.* (SELECT TL.id, TL.process_id, TL.event_time,
TL.severity, TL.short_description, TPG.process_group_text, TP.process_text.
Transaction_Log TL, Transaction_Process_Groups TPG, u.display_user_name
Transaction_Process TP, u users WHERE TP.process_group_id is
TPG.process_group_id and TL.process_id = TP.process_id and TL.pguid =
(u.pguid (+) ORDER BY desc gravity, event_time) a) where rn between 1 and
10

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Run 1 0.00 0.00 0 0 0 0
Fetch 1 5.09 73.06 60248 47768 55 10
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 3 5.09 73.07 60248 47768 55 10

Chess in the library during parsing cache: 1
Optimizer mode: ALL_ROWS
The analysis of the user id: 45

Rows Row Source operation
------- ---------------------------------------------------
10 REVIEWS (cr = 47768 pr = pw 60248 = 14888 times = 62516706 en)
COUNTY 582169 (cr = 47768 60248 14888 times = en 91625035 = pr = pw)
VIEW 582169 (cr = 47768 60248 14888 times = en 91042864 = pr = pw)
582169 SORT ORDER BY (cr = 47768 pr = pw 60248 = 14888 times = 90460690 en)
582169 HASH JOIN (cr = 47768 pr = pw 52211 = 6851 times = 92165669 en)
8 TABLE ACCESS FULL TRANSACTION_PROCESS_GROUPS (cr = 7 pr = 0 pw = time 0 = 52 fr)
582169 HASH JOIN (cr = 47761 pr = pw 52211 = 6851 times = 91000485 en)
62 TABLE ACCESS FULL TRANSACTION_PROCESS (cr = 7 pr = 0 pw = time 0 = 86 en)
582169 HASH JOIN RIGHT OUTER (cr = 47754 pr = pw 52211 = 6851 times = 89252852 en)
618316 MAT_VIEW FULL ACCESS_INAB ACCESS (cr = 12656 pr = pw 10308 = time 0 = 21098797 en)
582169 TABLE ACCESS FULL TRANSACTION_LOG (cr = 35098 pr 35052 pw = time = 0 = 28542620 en)

Elapsed time are waiting on the following events:
Event waited on times max wait for the Total WHEREAS
---------------------------------------- Waited ---------- ------------
file scattered read 3808 db 41.01 0.26
DB file sequential read 361 0.15 1.78
trip direct writing temp 616 2.09 0.10
direct path read 2023 temp 0.34 13.95
SQL * Net message to client 1 0.00 0.00
SQL * Net client message 1 0.01 0.01
********************************************************************************

Can you help me to correctly interpret this result?

Kind regards

Tony

PS: I used [this | http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#i34268] reference.

Published by: TonyDBA on August 26, 2008 02:19

Tony,

'so many physical reads' regarding: the most obvious reason is that your pool to KEEP is poorly calibrated. Check the view of BH V$ to find out how many blocks of your objects is actually cached. Note, however, that an indexed as appropriate approach is much better in terms of use of resources and performance.

With regard to the modification of the SQL: I think you should go and say your software vendor or that their use of ROWNUM is inappropriate and does not work the way it is intended for application developers. You can use a simple query like this to show them the difference that makes it potentially:

-- any large table will do, sys.source$ is usually among the biggest in a fresh test/demo database
select * from (select * from sys.source$ order by line) where rownum <= 10;

select * from (select * from sys.source$ order by line) where rownum between 1 and 10;

select * from v$sql_workarea
where sql_id in (
select sql_id from v$sql where sql_text = 'select * from (select * from sys.source$ order by line) where rownum <= 10'
);

select * from v$sql_workarea
where sql_id in (
select sql_id from v$sql where sql_text = 'select * from (select * from sys.source$ order by line) where rownum between 1 and 10'
);

If you carefully check the output taken from V$ SQL_WORKAREA you will find the sort of the first operation query using the "appropriate" ROWNUM<= 10"="" used="" a="" very="" small="" memory="" footprint,="" whereas="" the="" second="" one="" using="" the="" between="" operator="" consumes="" a="" lot="" more="" memory="" and="" quite="" often="" even="" spills="" to="">

You can also spot the difference in the execution plan, because the first uses the "ORDER of SORTING BY STOPKEY" operation that is using the optimization that only top n rows must be kept in memory and sorted, while the second is a "SORT ORDER BY" ordinary sort the result set.

If they want to stick to the approach 'between' then an analytical function as ROW_NUMBER() can be used to achieve a similar optimization for sorting of the WINDOW.

See Tom Kyte notes on how to correctly use top-n queries and pagination with ROWNUM or analytical functions.

See for example here: http://www.oracle.com/technology/oramag/oracle/07-jan/o17asktom.html
and here: http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html

Regarding the index: given that you order by a descending column and the other a growing, I think you need to create an appropriate index composite tree conventional in order to be able to avoid all sorts to take place on the TRANSACTION_LOG table. This means that you need an index on (GRAVITY DESC, EVENT_TIME) and you should have clues on all columns of the other tables join.

Note, however, that this approach NOSORT works easy if you aren't sorting on columns \*CHAR\*. If you sort by them your current client/session NLS_SORT setting determines the sort order, which is usually not the BINARY sort order used to create indexes on columns of default \*CHAR\*. Despite differently described in the Oracle documentation (where it is said that the use of a NLS_SORT setting! = BINARY will always use a full table scan) there is a solution to this by creating an index based on a function appropriate with the NLSSORT function if most / all clients share the same NLS_SORT setting.

Kind regards
Randolf

Oracle related things:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle:
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Tags: Database

Similar Questions

the trace of tkprof output

Hello

I need clarification on the costing

I have the following query

DECLARE
        type array is table of t%ROWTYPE index by binary_integer;
        l_data array;
        l_rec t%rowtype;
BEGIN
        SELECT
                a.*
                ,RPAD('*',4000,'*') AS PADDING1
                ,RPAD('*',4000,'*') AS PADDING2
        BULK COLLECT INTO
        l_data
        FROM ALL_OBJECTS a;
        DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
        FOR rs IN 1 .. l_data.count
        LOOP
                BEGIN
                        SELECT * INTO l_rec FROM t WHERE object_id = l_data(rs).object_id;
                EXCEPTION
                  WHEN NO_DATA_FOUND THEN NULL;
                END;
        END LOOP;
END;

tkprof output shows

SQL ID: 78kxqdhk1ubvq
Plan Hash: 3995659421
SELECT * 
FROM
 T WHERE OBJECT_ID = :B1 


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          1         63          0           0
Execute  72184      0.34       1.03          9         54          0           0
Fetch    72184      0.46     157.98      81365     368657          0       71726
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   144369      0.82     159.02      81375     368774          0       71726

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID T (cr=5 pr=11 pw=0 time=0 us cost=4 size=8092 card=1)
      1   INDEX UNIQUE SCAN T_PK (cr=3 pr=6 pw=0 time=0 us cost=2 size=0 card=1)(object id 83085)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Disk file operations I/O                        3        0.00          0.00
  db file sequential read                     12464        0.07         92.18
  db file scattered read                      14590        0.07         63.10
********************************************************************************

Now looking at stat line, does that mean the cost to retrieve one single record via unique index scan is 11 Physical block reads? The loop did fetch 72,726 rows and there were 81,375 physical block reads.


*** 2012-01-27 10:18:51.978
SELECT * FROM T WHERE 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          5          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          5          0           1

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93     (recursive depth: 1)
********************************************************************************

DECLARE
        type array is table of t%ROWTYPE index by binary_integer;
        l_data array;
        l_rec t%rowtype;
BEGIN
        SELECT
                a.*
                ,RPAD('*',4000,'*') AS PADDING1
                ,RPAD('*',4000,'*') AS PADDING2
        BULK COLLECT INTO
        l_data
        FROM ALL_OBJECTS a;
        DBMS_MONITOR.SESSION_TRACE_ENABLE ( waits=>true );
        FOR rs IN 1 .. l_data.count
        LOOP
                BEGIN
                        SELECT * INTO l_rec FROM t WHERE object_id = l_data(rs).object_id;
                EXCEPTION
                  WHEN NO_DATA_FOUND THEN NULL;
                END;
        END LOOP;
END;

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1      6.77      11.53        318      48684          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        1      6.77      11.53        318      48684          0           1

The summary statistics above do refers to the execution of the whole of the PL/SQL block? That means that the 318 blocks read above referred to.

Thank you very much

In addition to the excellent response of Rene, you will want to note that

SELECT *
FROM
 T WHERE OBJECT_ID = :B1 

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.00          1         63          0           0
Execute  72184      0.34       1.03          9         54          0           0
Fetch    72184      0.46     157.98      81365     368657          0       71726
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   144369      0.82     159.02      81375     368774          0       71726

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID T (cr=5 pr=11 pw=0 time=0 us cost=4 size=8092 card=1)
      1   INDEX UNIQUE SCAN T_PK (cr=3 pr=6 pw=0 time=0 us cost=2 size=0 card=1)(object id 83085)

This means that the cost to retrieve a record by making table T scan limited unique index is 11 physical blocks that includes 6 from the unique index of object_id. The execution plan has a hierarchical structure, and parents I/O, cost, schedule, etc. is a sum of measures for all of its children and the parameters of the operation itself. In the light of the foregoing, "ACCESS BY ROWID TABLE INDEX" operation is the operation of parent and the "INDEX UNIQUE SCAN" is the operation of the child. Statistics of the child are rolled in the statistics of the parent. This calculation of rail costs to retrieve a line are the same for each 71726 rows. So if you look at your original trace file (it's a good idea to understand the functioning of the trace file) you will see a stat to retrieve this record as noted in the report of tkprof.

To retrieve the 71726 lines it cost 0.82 s CPU and time elapsed 159,02 dry. There was 368774 logical block IO 81375 were block physical readings.
Note the CPU and wait for the temporal offsets.

 Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Disk file operations I/O                        3        0.00          0.00
  db file sequential read                     12464        0.07         92.18
  db file scattered read                      14590        0.07         63.10
********************************************************************************

Thus to retrieve these files altogether, they were physical i/o 12 464 'db file sequential read' taking 92,18 dry (note e/s physical does NOT block!) and e/s in physics 14 590 'file db scattered read' taking 63,10 sec, each contributing to the wait time. "the db file sequential read" is usually a single e/s block, it's index reading. 'db file scattered read' is an e/s multiple blocks read and in this case, it represents the blocks read from table to retrieve a line. It seems that every row of the table t occupies more than one block.

HTH,

Mich

Published by: Mich Talebzadeh on January 27, 2012 06:01

TKPROF output - lines processed / rows in the table anomaly?

Hello

TKPROF confusion for me more...

Oracle 10.2.0.4 on Windows Server 2003.

I formatted my Trace SQL with TKPROF file and the first query that I am focusing me causes some confusion. It's here (the names have been changed to protect the innocent, but everything remains intact):

********************************************************************************

SELECT A.COL1, A.COL2, MIN(A.COL3) AS 
  COL_SYNONYM 
FROM
 OUR_TABLE A WHERE NVL(A.COL4, NVL(:B4 , -1)) = NVL(:B4 , 
  NVL(A.COL4, -1)) AND NVL(A.COL5, NVL(:B3 , -1)) = NVL(:B3 , 
  NVL(A.COL5, -1)) AND A.COL6 = NVL(:B2 , A.COL6) AND 
  A.COL7 = NVL(:B1 , 1) GROUP BY A.COL1, A.COL2 ORDER 
  BY A.COL1, A.COL2


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     83      0.01       0.01          0          0          0           0
Fetch       83      1.01       1.11         12       3154          0      260371
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      167      1.03       1.13         12       3154          0      260371

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 148  (OUR_SCHEMA)   (recursive depth: 2)

Rows     Row Source Operation
-------  ---------------------------------------------------
 260371  SORT GROUP BY (cr=3154 pr=12 pw=0 time=956798 us)
 260371   CONCATENATION  (cr=3154 pr=12 pw=0 time=1072560 us)
 260371    FILTER  (cr=3154 pr=12 pw=0 time=630121 us)
 260371     TABLE ACCESS FULL OUR_TABLE (cr=3154 pr=12 pw=0 time=306867 us)
      0    FILTER  (cr=0 pr=0 pw=0 time=201 us)
      0     TABLE ACCESS FULL OUR_TABLE (cr=0 pr=0 pw=0 time=0 us)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
 260371   SORT (GROUP BY)
 260371    CONCATENATION
 260371     FILTER
 260371      TABLE ACCESS   MODE: ANALYZED (FULL) OF 'OUR_TABLE' 
                 (TABLE)
      0     FILTER
      0      TABLE ACCESS   MODE: ANALYZED (FULL) OF 'OUR_TABLE' 
                 (TABLE)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file scattered read                          2        0.01          0.02
********************************************************************************

What confuses me is that 'lines' (column 'lines' for the operation "Fetch" = * 260371 *, also 'lines' in the 'line Source operation' and "The execution Plan" = * 260371 *).

Actual number of rows in the table = * 3138 *.

I think that because we have performed 83 times, then the value of "lines" should be:
83 x number_of_rows_in_table = 83 x 3138 = * 260454 *.

What we have is 260371, who looks like me:
3137 = 83 x 83 x ( number_of_rows_in_table - 1 )

I misinterpreted the news (I guess I!)?

Why seems to be number_of_rows_in_table - 1 ? (Or is it pure coincidence?)

Kind regards

ADOS

That remains a record satisfied with the given list of a predicate in the WHERE clause?

If this isn't the case, then I don't see anything wrong here.

Time CPU > TKPROF output out of time

Hello

SELECT N_ORIGIN, SUB_ACC_ID, STAT_DATE, TYPE, PAGE_TOT, PAGE_NO, OP_BAL, CL_BAL
P02576 AND SUB_ACC_ID = O_950P WHERE N_ORIGIN =:: P02579 AND
STAT_DATE > = PRO4_TO_ORA_DATE (: P02599) AND TYPE =: P02863

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 9 0.00 0.00 0 0 4 0
Run 9 0.02 0.01 0 0 0 0
Search 1379482-158.32 150,61 0 2759085 0 1379473
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 1379500 158.34 150,63 0 2759085 4 1379473

Chess in the library during parsing cache: 1

Lack in the library during execution cache: 1
The analysis of the user id: 13074

Elapsed time are waiting on the following events:
Event waited on times max wait for the Total WHEREAS
---------------------------------------- Waited ---------- ------------
SQL * Net message to client 1379492 2.49 0.00
SQL * Net client message 1379491 1042.23 0.39

Here the time (158.34) of the CPU is more than the elapsed time (150.63) ?. How could it be?

Documentation said...

`CPU`	Time CPU in a few seconds to analyze all the total, run or to search for the statement. This value is zero (0) If `TIMED_STATISTICS` is not enabled.
`ELAPSED`	Total time in seconds for all parse, execute, or fetch calls for the statement. This value is zero (0) If `TIMED_STATISTICS` is not enabled.

Could you please help me understand who is the elapsed time can be higher in time CPU?

in most cases the time CPU will be smaller than the elapsed time. I think it is useful to compare the information to see if an operation is CPU related (like your request) or if the elapsed time is associated with waiting (IO, competition etc.). But I would not count on the exact number.

high coherent reading during call analysis | TKProf output

Hi all

Platform:-Oracle 10.2.0 on windows 32-bit

I need your help to understand the following trace file.
If you look at this file trace there are a high number of consistent reading for prase call block. I want to know why Oracle go for that much consistent reading for analysis call?

select u.DISPLAY_NAME,u.PASSWORD,u.user_type 
FROM
 USER_ACCOUNT u,STATUS s WHERE u.status_id=s.status_id and 
  Lower(u.DISPLAY_NAME) like Lower('admin') and s.STATUS_NAME='Available'


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.85       1.07          0       3599          0           0
Execute      4      0.00       0.00          0          0          0           0
Fetch        4      0.01       0.05         14         36          0           4
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       12      0.86       1.13         14       3635          0           4

Misses in library cache during parse: 4
Optimizer mode: ALL_ROWS
Parsing user id: 72  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  NESTED LOOPS  (cr=9 pr=8 pw=0 time=33821 us)
      1   TABLE ACCESS BY INDEX ROWID STATUS (cr=2 pr=2 pw=0 time=21787 us)
      1    INDEX UNIQUE SCAN STATUS_CON21 (cr=1 pr=1 pw=0 time=20957 us)(object id 58618)
      1   TABLE ACCESS FULL USER_ACCOUNT (cr=7 pr=6 pw=0 time=11978 us)

Thank you.

Yasir Hashmi wrote:

Hemant K Chitale wrote:
During a hard Parse, if Oracle is unable to find the required information (user, the Table definition privileges, index, discover the definitions, table, column, Index Statistics) the dictionary Cache, which is located in the shared pool, to reread the information from the System Tablespace.

Hemant K Collette

meaning that he must get the disc o t to extract data. So why there is no disc readings?

Data dictionary tables (tab$, ind$, $ col etc.) are blocks of these tables and tables just like any other table - enter the buffer cache.

The dictionary cache is also called the rowcache, because he puts in cache the data dictionary lines - but even if lines were emptied of the rowcache blocks table from these lines can still be in the buffer cache - where the rowcache can be updated without reading disc.

Concerning
Jonathan Lewis

Query is not using the index. (Included execution plan. TKPROF output not available)

Hi all

Version of DB: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

Here is the description of the problem:
(The statistics are up to date for all tables).

The query below does not use the index on ACCOUNTS_LIVE (ID). (Unique index)

SQL> explain plan for
  2  select txn.account_number,to_number(txn.amount_lcy) txn_amt,to_date(booking_date,'YYYYMMDD') TXN_DATE,
  3        sal.latest_sal,sal.sal_date,customer_name,employer_name,
  4       decode(COMMUNICATION_TYPE_1,'MOBILE',COMMUNICATION_NO_1,
  5            decode(COMMUNICATION_TYPE_2,'MOBILE',COMMUNICATION_NO_2)) mob,
  6       txn.CURRENCY, CHEQUE_NUMBER,trans_dets,trans_reference,target,teller_id,acc.category,acc.inactive_marker,
  7            acc.posting_restrict,cus.sector,cus.industry
  8  from coreadmin.Gtxn_dtl_v1 txn,
  9                     (select account_number,round(to_number(nvl(amount_lcy,0)),2) latest_sal,TXN_DATE sal_date,rr
 10                      from
 11                        (select to_date(booking_date,'YYYYMMDD') TXN_DATE,batch_id,account_number,amount_lcy
 12                             ,row_number() over (partition by account_number
 13                                                     order by to_date(booking_date,'YYYYMMDD') desc NULLS LAST,
 14                                                     batch_id desc nulls last) rr,
 15                                     CURRENCY, CHEQUE_NUMBER,trans_dets,trans_reference
 16                             from coreadmin.Gtxn_dtl_v1
 17                             where transaction_code in ('204','938')
 18                  and to_number(amount_lcy) > 0)
 19                             where rr = 1
 20                       ) sal,accounts_live acc,customers_live cus
 21  where to_date(booking_date,'YYYYMMDD') between to_date('030109','DDMMRR') and to_date('020209','DDMMRR')
 22  and txn.account_number = sal.account_number
 23  and txn.account_number = acc.id
 24  and txn.CUSTOMER_ID = cus.CUSTOMER_number
 25  and target in ('30','31','32')
 26  /

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT                                                                                                                                     
------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 920245766                                                                                                                            
                                                                                                                                                      
-----------------------------------------------------------------------------------------------------------                                           
| Id  | Operation                        | Name           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                           
-----------------------------------------------------------------------------------------------------------                                           
|   0 | SELECT STATEMENT                 |                |   363M|   121G|       |   223K  (4)| 00:44:47 |                                           
|*  1 |  HASH JOIN                       |                |   363M|   121G|  6232K|   223K  (4)| 00:44:47 |                                           
|*  2 |   VIEW                           |                | 34453 |  5820K|       |   147K  (1)| 00:29:36 |                                           
|*  3 |    WINDOW SORT PUSHED RANK       |                | 34453 |  1480K|  4072K|   147K  (1)| 00:29:36 |                                           
|*  4 |     FILTER                       |                |       |       |       |            |          |                                           
|   5 |      INLIST ITERATOR             |                |       |       |       |            |          |                                           
|*  6 |       TABLE ACCESS BY INDEX ROWID| GTXN_DTL_V1    | 34453 |  1480K|       |   147K  (1)| 00:29:31 |                                           
|*  7 |        INDEX RANGE SCAN          | IDX_TXN5       |   707K|       |       |  1815   (2)| 00:00:22 |                                           
|*  8 |   HASH JOIN                      |                |   598K|   106M|    20M| 63724   (1)| 00:12:45 |                                           
|*  9 |    MAT_VIEW ACCESS FULL          | CUSTOMERS_LIVE |   227K|    17M|       |  2239   (4)| 00:00:27 |                                           
|* 10 |    HASH JOIN                     |                |   598K|    59M|  9504K| 57157   (1)| 00:11:26 |                                           
|  11 |     MAT_VIEW ACCESS FULL         | ACCOUNTS_LIVE  |   249K|  6577K|       |  1832   (2)| 00:00:22 |                                           
|* 12 |     TABLE ACCESS BY INDEX ROWID  | GTXN_DTL_V1    |   597K|    43M|       | 52319   (1)| 00:10:28 |                                           
|* 13 |      INDEX RANGE SCAN            | IDX_TXN11_V1   |  1204K|       |       |  3931   (2)| 00:00:48 |                                           
-----------------------------------------------------------------------------------------------------------                                           
                                                                                                                                                      
Predicate Information (identified by operation id):                                                                                                   
---------------------------------------------------                                                                                                   
                                                                                                                                                      
   1 - access("TXN"."ACCOUNT_NUMBER"="ACCOUNT_NUMBER")                                                                                                
   2 - filter("RR"=1)                                                                                                                                 
   3 - filter(ROW_NUMBER() OVER ( PARTITION BY "ACCOUNT_NUMBER" ORDER BY                                                                              
              TO_DATE("BOOKING_DATE",'YYYYMMDD') DESC  NULLS LAST,INTERNAL_FUNCTION("BATCH_ID") DESC  NULLS                                           
              LAST)<=1)                                                                                                                               
   4 - filter(TO_DATE('030109','DDMMRR')<=TO_DATE('020209','DDMMRR'))                                                                                 
   6 - filter(TO_NUMBER("AMOUNT_LCY")>0)                                                                                                              
   7 - access("TRANSACTION_CODE"='204' OR "TRANSACTION_CODE"='938')                                                                                   
   8 - access("TXN"."CUSTOMER_ID"="CUS"."CUSTOMER_NUMBER")                                                                                            
   9 - filter("TARGET"='30' OR "TARGET"='31' OR "TARGET"='32')                                                                                        
  10 - access("TXN"."ACCOUNT_NUMBER"="ACC"."ID")                                                                                                      
  12 - filter("TXN"."CUSTOMER_ID" IS NOT NULL)                                                                                                        
  13 - access(TO_DATE("BOOKING_DATE",'YYYYMMDD')>=TO_DATE('030109','DDMMRR') AND                                                                      
              TO_DATE("BOOKING_DATE",'YYYYMMDD')<=TO_DATE('020209','DDMMRR'))                                                                         

38 rows selected.

SQL> select index_name
  2  from dba_ind_columns
  3  where table_name = 'ACCOUNTS_LIVE'
  4  and column_name = 'ID';

INDEX_NAME                                                                                                                                            
------------------------------                                                                                                                        
IDX_ACCLIVE

Line 23 of the query uses accounts_live.id.

11 the order ID explain plan shows that the index does not use.

Please suggest.

Thanks in advance,
Jac

What happens when you force the index by using hint and use the hash between txn and acc join?

See you soon
Sarma.

Help for interpretation explains the release of the plan (dbms_xplan)

Hi all

I am trying to familiarize themselves with the reading and interpretation of the output of explain plan command or dbms_xplan, and so I hope someone can help with the output below.

With the command explain below, means that...

(a) he began to step 8 and sends all the lines of the loop nested in step 5
(b) but sends (or think it sends) 1 row in step 5 to step 8
(c) for each line that is provided in step 5, there will be a search index in step 8 to access the table in step 6
(d) step 8 gets only (or think it gets) 1 row

If that means that only 1 row is expected by the optimizer and yet the full table scan must return to 150 000 documents, and table a statistiucs to date, what else would cause the cardinality be far off?
If she does not mean it will return 1 row, then does that mean?

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                                |       |       |   945 (100)|          |
|   1 |  SORT GROUP BY                      |                                |     1 |   283 |   945   (3)| 00:00:05 |
|*  2 |   FILTER                            |                                |       |       |            |          |
|   3 |    NESTED LOOPS                     |                                |       |       |            |          |
|   4 |     NESTED LOOPS                    |                                |     1 |   283 |   944   (3)| 00:00:05 |
|   5 |      NESTED LOOPS                   |                                |     1 |   108 |   929   (3)| 00:00:05 |
|*  6 |       MAT_VIEW ACCESS FULL          | DEMOGRAPHICS_MV                |     1 |    97 |   927   (3)| 00:00:05 |
|*  7 |       MAT_VIEW ACCESS BY INDEX ROWID| NAMES_MV                       |     1 |    11 |     2   (0)| 00:00:01 |
|*  8 |        INDEX RANGE SCAN             | ORG_MV_IDX1                    |     1 |       |     1   (0)| 00:00:01 |
|*  9 |      INDEX RANGE SCAN               | PAY_IDX8                       |   252 |       |     4   (0)| 00:00:01 |
|* 10 |     TABLE ACCESS BY INDEX ROWID     | PAY_ALL                        |     1 |   175 |    15   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

      8 - access("ORG_MV"."ORG_ID"="DEMO_MV"."ORG_ID")

Thanks a lot for your help.

SQL execution starts at ID = 6 with full scan on DEMOGRAPHICS_MV. This analysis should return 1 row.
Then, he expects to lead a nested loop to scan via the Index ORG_MV_IDX1 a NAMES_MV once (for 1 line, extracted from DEMOGRAPHICS_MV).
It then goes to PAY_IDX8 once where he expects to get 252 ROWID.
Finally, it accesses the table PAY_ALL.

You should also post the main information because it is very important to understand access and FILTER operations for each operation.

Hemant K Collette

the meaning of "motion" in tkprof.
Hello world

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.00 0.00 0 0 0 0
Run 31 0.00 0.00 0 0 0 0
Pick up 73 0.01 0.02 0 310 0 42
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 108 0.01 0.02 0 310 0 42

above is the tkprof output:

I want to know what is the meaning of "application"?
What is the effect of the value is very high this "request"?

Thank you.
You should learn the interpting of tkproof...
Link below gives an overview on tkpoof.

http://hourim.WordPress.com/2012/09/14/tuning-by-TKPROF-a-case-study/

Tuning PL/SQL - tkprof still shows a lot of work for the RECURSIVE STATEMENTS

Hello

First of all I don't know if this should be in the "database - general' or 'SQL and PL/SQL. Given that it is more a question specifically on the PL/SQL performance, I'll put here in 'database - general. " I hope that doesn't offend anyone.

I just started watching a performance in our application issue. One of the developers establish me a procedure that replicates the question, I ran by tracing the session and then fed the tkprof on trace file. The results at the bottom of my eyes like this tkprof output file:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        3      0.01       0.07         10         60          0           0
Execute      3      0.01       0.01          0          3          0           3
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6      0.03       0.08         10         63          0           3

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                       5        0.00          0.00
  SQL*Net message from client                     4        1.68          1.70
  db file sequential read                        18        0.01          0.10


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse      416      0.00       0.01          0          0          2           0
Execute   1456      0.71       0.75         26       1739        425         590
Fetch     2932      0.12       2.21        337       6338          0        3061
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     4804      0.84       2.98        363       8077        427        3651

Misses in library cache during parse: 25
Misses in library cache during execute: 24

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                       343        0.08          2.09
  db file scattered read                          1        0.00          0.00

   47  user  SQL statements in session.
  888  internal SQL statements in session.
  935  SQL statements in session.
   31  statements EXPLAINed in this session.

I'm looking in particular to this relatively high activity RECURSIVE STATEMENTS, because for me, NO RECURSIFS (ie the actual submitted statements that form our code) seems harmless enough. It's my first experience to try to solve some complex looking for PL/SQL and I have no idea what might be considered more "normal", but I think I know and research on google, the results seem pretty strange to me.

Is this strong activity for RECURSIF INSTRUCTIONS a problem, and if so, what should I start looking to reduce this activity?

Kind regards

ADOS

should I concentrate my efforts on the identification of our STATES RECURSIFS

1 456 executions took 2.98 seconds. If you are concerned? It depends on if it is essential for your application.

Published by: Hemant K grapple on July 30, 2009 16:43

odd trace output 10046

How can I get 24 seconds waited sqlnet client message if the total response time is 7 seconds. This seems to be a flaw in the 10046 metric timing route.

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      4      0.01       0.00          0          0          0           2
Fetch        2      7.17       7.01     191184     198038          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9      7.18       7.01     191184     198038          0           3

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                       5        0.00          0.00
  SQL*Net message from client                     5       22.10         24.73
  db file scattered read                       8277        0.00          2.70
  db file sequential read                       780        0.00          0.01

Try an experiement:

ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';

SELECT SYSDATE FROM DUAL;

I then think about the situation, what happens if my DUAL table is slow... should I have tried this with a different version of the Oracle... anything to kill 45 seconds. Then, then run:

DISCONNECT ALL;

TKPROF output the following:

 SELECT SYSDATE
FROM
 DUAL

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0          0          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 46  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)

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

0 seconds of CPU time, elapsed time 0 seconds and 45.75 in the SQL * Net message from the expectation of the client - waiting for the next request from the client computer. Note that the maximum wait is approximately the same Total expected - I think the same is true for you.

Let's look at the raw trace file:

PARSING IN CURSOR #1 len=24 dep=0 uid=46 oct=3 lid=46 tim=360672877551 hv=124468195 ad='7cb3df00'
SELECT SYSDATE FROM DUAL
END OF STMT
PARSE #1:c=0,e=487,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=360672877548
EXEC #1:c=0,e=24,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=360672877886
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=10417 tim=360672878021
FETCH #1:c=0,e=17,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=360672878117
WAIT #1: nam='SQL*Net message from client' ela= 147 driver id=1413697536 #bytes=1 p3=0 obj#=10417 tim=360672879450
FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=360672879532
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=10417 tim=360672879606
*** 2009-07-22 20:37:47.741
WAIT #1: nam='SQL*Net message from client' ela= 45757081 driver id=1413697536 #bytes=1 p3=0 obj#=10417 tim=360718636761
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)'

Note the line: "SQL * Net client message' ela = 45757081 - that happened after the last extraction of calls."

In short, the wait is probably at the end, before writing to the trace file has been disabled.

Charles Hooper
IT Manager/Oracle DBA
K & M-making Machine, Inc.

DECODE is changing the explain plan
I have a statement with a decoding function in the where clause like this:
```
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
```
When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

Below plans to explain and tkprofs to 1 (no decode) and 2 (decode).

* explain 1 *.
{code}
SQL statement that produced these data:
Select * from table (dbms_xplan.display)

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU).
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 7080 | 2413K | 43611 (2) |
| 1. SORT ORDER BY | 7080 | 2413K | 5224K | 43611 (2) |
|* 2 | FILTER |
|* 3 | HASH JOIN | 7156. 2 438 K | 43075 (2) |
| 4. TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745. 363KO | 83 (0) |
|* 5 | OUTER HASH JOIN | 7156. 2292K | 42991 (2) |
|* 6 | HASH JOIN | 7156. 1355K | 42907 (2) |
|* 7 | HASH JOIN | 6987. 1187K | 19170 (2) |
|* 8 | HASH JOIN | 6947 | 963K | 10376 (1) |
|* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3. 144. 3 (0) |
| 10. NESTED LOOPS | 6907. 897K | 8577 (1) |
| * 11 | HASH JOIN | 2264 | 187K | 1782 (2) |
| 12. TABLE ACCESS BY INDEX ROWID | SAMPLE | 190. 4370. 17 (0) |
| 13. NESTED LOOPS | 2264 | 152K | 107 (1) |
| 14. NESTED LOOPS | 12. 552. 25 (0) |
| * 15 | TABLE ACCESS FULL | SDG_USER | 12. 288. 13 (0) |
| 16. TABLE ACCESS BY INDEX ROWID | SDG | 1. 22. 1 (0) |
| * 17. INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0) |
| * 18. INDEX RANGE SCAN | FK_SAMPLE_SDG | 597. 2 (0) |
| 19. TABLE ACCESS FULL | SAMPLE_USER | 1078K | 16 M | 1669 (1) |
| * 20. INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0) |
| 21. TABLE ACCESS FULL | ALIQUOT_USER | 3403K | 29 M | 1781 (3) |
| 22. TABLE ACCESS FULL | TEST | 3423K | 104 M | 8775 (2) |
| * 23. TABLE ACCESS FULL | RESULT | 3435K | 65 M | 23718 (2) |
| 24. VIEW | PLATE | 21787 | 2851K | 84 (2).
| * 25. FILTER |
| 26. TABLE ACCESS FULL | PLATE | 21787 | 574K | 84 (2).
| * 27. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
| * 28. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
| * 29. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
| * 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
| * 31. INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1. 7 | | 0 (0) |
---------------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

2. ((«GROUP_ID» EST NULL ou EXISTE (SELECT / * + * / 0 DE "AGIL".) filter)) "OPERATOR_GROUP"
"OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B1)) AND ('GROUP_ID' IS NULL) "'". "
OR EXISTS (SELECT / * + * / 0 "LIMS".) ' ' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE
"OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "GROUP_ID" =:B2)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * +)) "" "."
* / 0 "LIMS". "' OPERATOR_GROUP ' 'OPERATOR_GROUP' WHERE ' OPERATOR_ID"="LIMS$ OPERATOR_ID" () AND "."
(('GROUP_ID' =: B3)) AND ('GROUP_ID' IS NULL OR EXISTS (SELECT / * + * / 0 "LIMS".)) "" OPERATOR_GROUP ".
'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B4)))".
3 - access ("U_ABS_DETERMINATION" ="DETERMINATION_ASSIGNMENT")
5 - access("PLT".") PLATE_ID"(+) ="PLATE_ID")
6 - access ("TEST_ID" ="TEST_ID")
7 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
8 - access ("ALIQUOT_ID" ="ALIQUOT_ID")
9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
11 - access ("SAMPLE_ID" ="SAMPLE_ID")
15 - filter ("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE" = 'QC' AND
"U_WEEK_OF_PROCESSING"= TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY' = TO_NUMBER (:YEAR)).
17 - access ("SDG_ID" ="SDG_ID")
18 - access ("SDG_ID" ="SDG_ID")
20 - access ("SAMPLE_ID" ="SAMPLE_ID")
23 - filter ('NAME' = 'End result')
25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS".")) OPERATOR_GROUP ".
'OPERATOR_GROUP' WHERE ' OPERATOR_ID "=" LIMS$ OPERATOR_ID "() AND"GROUP_ID "=:B1))".
27 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
28 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
29 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
30 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())
31 - access ("GROUP_ID" =: B1 AND "OPERATOR_ID"="LIMS$ OPERATOR_ID" ())

Note
-----
-"PLAN_TABLE' is old version
{code}

* tkprof 1 *.
{code}

TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Sorting options: by default

********************************************************************************
Count = number of times OIC procedure has been executed
CPU = time in seconds cpu execution
elapsed = elapsed time in seconds the execution
disc = number of physical reads from disk buffers
Query = number of buffers for a consistent reading
current = number of buffers in current mode (usually for the update)
rows = number of rows processed by extracting or execute the call
********************************************************************************

SELECT sdu.u_crop_group,
SD. Name as sdg_name,
ad.variety_name,
ad.batch_number,
B.SID as aliquot_name,
Sau.u_box_code as box_code,
Sau.u_box_position as box_position,
t.Nom as test_name,
r.original_result,
PLT. Name as plate_name,
Concat (chr (a.plate_row + 64), a.plate_column) as plate_position,
au.u_replicate_number as replicate_number
OF lims_sys.sdg sd,.
lims_sys.sdg_user STO,
lims_sys. Sample his.
lims_sys.sample_user sau,
lims_sys.aliquot has,
to the lims_sys.aliquot_user,.
lims_sys.test t,
lims_sys. Result r,
PLT lims_sys.plate,
Ad lims_sys.abs_determination
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V', 'P', 'C')
AND r.name = 'result '.
AND sdu.u_client_type = "QC".
AND sdu.u_year_of_sample_delivery = (: year)
AND sdu.u_week_of_processing = (: week)
- AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Run 1 1.15 1.16 0 0 0 0
Fetch 1 8.53 16.10 227649 241266 0 500
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 3 9.68 17,27 227649 241266 0 500

Chess in the library during parsing cache: 1
Lack in the library during execution cache: 1
Optimizer mode: ALL_ROWS
The analysis of the user id: 97

Rows Row Source operation
------- ---------------------------------------------------
SORT ORDER BY 500 (cr = 241266 pr = 227649 pw = time 0 = 16104631 en)
FILTER 21311 (cr = 241266 pr = 227649 pw = time 0 = 16246749 en)
21311 HASH JOIN (cr = 241266 pr = 227649 pw = time 0 = 16225434 en)
17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr = 374 pr = 0 pw = time 0 = 69 fr)
21311 HASH JOIN RIGHT OUTER (cr = 240892 pr = 227649 pw = time 0 = 16170607 en)
21895 VIEW PLATE (cr = 316 pr = 0 pw = time 0 = 43825 US)
21895 FILTER (cr = 316 pr = 0 pw = time 0 = 43823 US)
21895 TRAY FULL ACCESS (cr = 316 pr = 0 pw = time 0 = 31 US)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
21311 HASH JOIN (cr = 240576 pr = 227649 pw = time 0 = 16106174 en)
21311 HASH JOIN (cr = 133559 pr 121596 pw = time = 0 = 9594130 en)
21311 HASH JOIN (cr = 94323 pr = 83281 pw = time 0 = 6917067 en)
21311 HASH JOIN (cr = 86383 pr 75547 pw = time = 0 = 5509672 en)
JOIN by HASH 7776 (cr = 8134 pr = 0 pw = time 0 = 285364 en)
TABLE ACCESS BY INDEX ROWID SAMPLE 7776 (cr = 572 pr = 0 pw = time 0 = 27152 US)
7876 NESTED LOOPS (cr = 377 pr = 0 pw = time 0 = 488287 en)
JOIN by HASH 99 (cr = 160 pr = 0 pw = time 0 = US 4168)
99 TABLE ACCESS FULL SDG_USER (cr = 53 pr = 0 pw = time 0 = US 1209)
5719 TABLE ACCESS FULL SDG (cr = 107 pr = 0 pw = time 0 = 17 US)
7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr = 217 pr = 0 pw = time 0 = 623 en)(object id 45990)
1079741 TABLE ACCESS FULL SAMPLE_USER (cr = 7562 pr = 0 pw = time 0 = 24 US)
3307948 TABLE ALIQUOT FULL ACCESS (cr = 78249 pr = pw 75547 time = 0 = 3331129 en)
3406836 TABLE ACCESS FULL ALIQUOT_USER (cr = 7940 pr 7734 pw = time = 0 = 556 en)
3406832 TABLE TEST FULL ACCESS (cr = 39236 pr 38315 pw = time = 0 = 3413192 en)
3406832 TABLE ACCESS FULL RESULTS (cr = 107017 pr = 106053 pw = time 0 = 6848487 en)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr = 0 pr = 0 pw = time 0 = 0 US)(object id 45769)

********************************************************************************

Select 'x '.
Of
Double

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Run 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 3 0.00 0.00 0 0 0 1

Chess in the library during parsing cache: 0
Optimizer mode: ALL_ROWS
The analysis of the user id: 97

Rows Row Source operation
------- ---------------------------------------------------
1 DOUBLE QUICK (cr = 0 pr = 0 pw = time 0 = 3 US)

********************************************************************************

Start: id: = sys.dbms_transaction.local_transaction_id; end;

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Run 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 2 0.00 0.00 0 0 0 1

Chess in the library during parsing cache: 0
Optimizer mode: ALL_ROWS
The analysis of the user id: 97

********************************************************************************

TOTALS FOR ALL NON RECURSIVE INSTRUCTIONS

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 3 0.00 0.00 0 0 0 0
Run 3 1.15 1.16 0 0 0 1
Pick 2 8.53 16.10 227649 241266 0 501
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 8 9.68 17,27 227649 241266 0 502

Chess in the library during parsing cache: 1
Lack in the library during execution cache: 1

TOTALS FOR ALL RECURSIVE INSTRUCTIONS

call the query of disc elapsed to cpu count current lines
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 30 0.00 0.00 0 0 0 0
Run 30 0.00 0.00 0 0 0 0
Get 30 0.00 0.00 0 40 0 10
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Total 90 0.00 0.00 0 40 0 10

Chess in the library during parsing cache: 0

3 the session user SQL statements.
30 internal to SQL statements in session.
33 SQL statements in session.
********************************************************************************
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Compatibility of trace files: 10.01.00
Sorting options: by default

8 sessions in the trace file.
3 SQL statements of the user in the trace file.
30 internal SQL instructions in the trace file.
33 SQL statements in the trace file.
6 unique SQL statements in the trace file.
633 lines in the trace file.
23 seconds in the trace file.
{code}
ZI wrote:
I have a statement with a decoding function in the where clause like this:
```
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
```
When I have a package-1 as parameter for cropgroup the filter would result by ' AND '-1' = '-1', and the statement is executed in less than 2 seconds.»»» When I leave this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan command is so different and why not use index scans in the statement without decoding.

I would interpret the results displayed differently.

Execution which took 17 s according to the 241 266 coherent block played tkprof output gets but in order to do so he read 227 649 the disk blocks. Note that most of the table addressed by this query blocks were read through scanning of complete table that can take advantage of multiple blocks readings, for example if you unset the db_file_multiblock_read_count 10.2 (recommended) it usually try to read 1 MB with a read request, which are 128 blocks in case of standard block size 8 k. Due to several reasons not always the full size can be requested with each read request, lets say about 200 000 blocks could have been read by about 2,000 blocks multiple readings. Each read request would turn into a physical read, could you get an estimate approximate 25 MS per read times 2,000 applications-online 50 seconds (your system is running obviously better that the average assumed by ost g 10 base optimizer without collected statistics system workload, can be that some additional file caching system is involved).

On the other hand, the execution plan that finished within 2 seconds completed 221 420 coherent block gets but did No physical reads at all. Note that most of the table blocks should be processed using one-piece random searches (ACCESS BY ROWID of the TABLE), according to the grouping of the indices factor, it could have been as many blocks that the lines have been returned to the range index scans. So you could have done with lets say more than 60,000 randomly accessed table blocks => until 60 000 monobloc required reading. So in the worst case, this may take 60 000 requests time 10ms by read-online 600 seconds, even if in reality at least some of the blocks will be stored in the buffer cache, so it should be less.

It would be interesting to know how these two declarations with a cold buffer cache, so that both had to physical reads. I suppose the first is actually faster. Of course, if the second corresponds more to your typical situation that most of the blocks is in the buffer anyway, then it could be faster, because the blocks read by random access are more likely to stay in memory blocks read by complete sweep of the table, but in a true perspective of I/O the first is expected to be higher.

Moreover, the change in the plan is probably caused by the fact that the additional predicate (DECODING) lowers the cardinality of the table of SDG_USER conduct so that LOOP IMBRIQUEE approach seems to be cheaper to the optimizer that the hash join/full scan table approach. Apparently the estimate is way off (by two orders of magnitude, in fact 100 instead of 1), then the plan is not really cheap, because it seems like the optimizer.

By the way: two actual execution plans displayed in the output from tkprof are actually different from the displayed output of EXPLAIN the PLAN, so the statement has executed a little differently provided the facility to EXPLAIN the PLAN.

Your PLAN_TABLE is old, since you are on 10g you should drop any PLAN_TABLEs that are in non - SYS diagrams, since 10 g already provides a global temporary Table as part of the default dictionary (SYS. Plan_table$ presentations via public synonym PLAN_TABLE).

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

4500 x licenses

I bought some switches of 4500 X with entservices the license, but I'm a little puzzled by the output of the see the license all. It seems to me that they come with a trial version, and not a permanent license. I'm not familiar with the activation / upgrade license, so I'd love to help in the interpretation of the output or assistance with the process to make sure of my entservices license is enabled permanently.

Switch#show license allLicense Store: Primary License StorageStoreIndex: 0 Feature: ipbase Version: 1.0 License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: MediumLicense Store: Dynamic License StorageLicense Store: Primary License StorageLicense Store: Dynamic License StorageStoreIndex: 0 Feature: entservices Version: 1.0 License Type: Evaluation Evaluation total period: 8 weeks 4 days Evaluation period left: 8 weeks 4 days License State: Active, Not in Use, EULA not accepted License Count: Non-Counted License Priority: NoneStoreIndex: 1 Feature: entservices Version: 1.0 License Type: PermanentRightToUse License State: Inactive License Count: Non-CountedStoreIndex: 2 Feature: ipbase Version: 1.0 License Type: Evaluation Evaluation total period: 8 weeks 4 days Evaluation period left: 8 weeks 4 days License State: Inactive License Count: Non-Counted License Priority: NoneStoreIndex: 3 Feature: ipbase Version: 1.0 License Type: PermanentRightToUse License State: Inactive License Count: Non-CountedStoreIndex: 4 Feature: lanbase Version: 1.0 License Type: PermanentRightToUse License State: Active, Not in Use, EULA not accepted License Count: Non-Counted

You can post the output of "sh worm?

It should show you the level of license installed.

If you do not see:

License level: entservices Type: Permanent

To try the following:

Do a 'sh bootflash"and you can see this license, if you do not run the command 'install license...". "to install it. You must restart before it takes effect.

HTH

Unlock the product key for my Genuine Windows 7 Pro

My computer has passed the real test from Windows to Windows 7 Professional. I was even offered a Security Essentials free antivirus that I installed. Yet Microsoft has blocked my product key. Please, how can Microsoft release the key. I have a few more days to activate. Please find attached the results of the diagnostic tool. Thank you.

Diagnostic report (1.9.0027.0):
-----------------------------------------
Validation of Windows data-->

Validation code: 0
Code of Validation caching online: 0x0
Windows product key: *-* - XFR46 - MMWDW-H462C
The Windows Product Key hash: xqmrPOwmyiCYtRUFwckHRuIBNL8 =
Windows product ID: 00371-841-8858794-85690
Windows product ID type: 5
Windows license type: retail
The Windows OS version: 6.1.7601.2.00010100.1.0.048
ID: {2EFE3A54-78CE-423A-ACE6-B6E639A84F89} (1)
Admin: Yes
TestCab: 0x0
LegitcheckControl ActiveX: N/a, hr = 0 x 80070002
Signed by: n/a, hr = 0 x 80070002
Product name: Windows 7 Professional
Architecture: 0x00000000
Build lab: 7601.win7sp1_gdr.140303 - 2144
TTS error:
Validation of diagnosis:
Resolution state: n/a

Given Vista WgaER-->
ThreatID (s): n/a, hr = 0 x 80070002
Version: N/a, hr = 0 x 80070002

Windows XP Notifications data-->
Cached result: n/a, hr = 0 x 80070002
File: No.
Version: N/a, hr = 0 x 80070002
WgaTray.exe signed by: n/a, hr = 0 x 80070002
WgaLogon.dll signed by: n/a, hr = 0 x 80070002

OGA Notifications data-->
Cached result: n/a, hr = 0 x 80070002
Version: N/a, hr = 0 x 80070002
OGAExec.exe signed by: n/a, hr = 0 x 80070002
OGAAddin.dll signed by: n/a, hr = 0 x 80070002

OGA data-->
Office status: 109 n/a
OGA Version: N/a, 0 x 80070002
Signed by: n/a, hr = 0 x 80070002
Office Diagnostics: 025D1FF3-364-80041010_025D1FF3-229-80041010_025D1FF3-230-1_025D1FF3-

517-80040154_025D1FF3-237-80040154_025D1FF3-238-2_025D1FF3-244-80070002_025D1FF3-258-3

Data browser-->
Proxy settings: N/A
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Default browser: C:\Program may Explorer\iexplore.exe
Download signed ActiveX controls: fast
Download unsigned ActiveX controls: disabled
Run ActiveX controls and plug-ins: allowed
Initialize and script ActiveX controls not marked as safe: disabled
Allow the Internet Explorer Webbrowser control scripts: disabled
Active scripting: allowed
Recognized ActiveX controls safe for scripting: allowed

Analysis of file data-->

Other data-->
Office details: {2EFE3A54-78CE-423A-ACE6-B6E639A84F89}

1.9.0027.0 6.1.7601.2.00010100.1.0.048 x 32

/ Architecture >*-*-*-*-H462C00371-841-8858794 -.

856905S-1-5-21-120526572-854052561-

22199328ECS

M920

American Megatrends Inc.

07.00 T

minor = "3" / >20010402000000.000000 + 000D2E23D07018400EA<>

CID > 04090409w. Central Africa time

(GMT + 01:00)

0 3

>109<>

s / >

Content Spsys.log: 0 x 80070002

License data-->
The software licensing service version: 6.1.7601.17514

Name: Windows 7 Professional edition
Description: operating system Windows - Windows (r) 7, retail channel
Activation ID: e838d943-63ed-4a0b-9fb1-47152908acc9
ID of the application: 55c92734-d682-4d71-983e-d6ec3f16059f
Extended PID: 00371-00170-841-885879-00-1033-7601.0000-1402014
Installation ID: 022262399126635441473365187890627623742186241741730054
Processor certificate URL: http://go.microsoft.com/fwlink/?LinkID=88338
The machine certificate URL: http://go.microsoft.com/fwlink/?LinkID=88339
Use license URL: http://go.microsoft.com/fwlink/?LinkID=88341
Product key certificate URL: http://go.microsoft.com/fwlink/?LinkID=88340
Partial product key: H462C
License status: initial grace period
Time remaining: 12060 minute (s) on (8 day (s))
Remaining Windows rearm count: 4
Trust time: 21/05/2014-15:22:35

Windows Activation Technologies-->
HrOffline: 0x00000000
HrOnline: 0x00000000
Beyond: 0 x 0000000000000000
Event timestamp: 5:21:2014 15:07
ActiveX: Registered, Version: 7.1.7600.16395
The admin service: recorded, Version: 7.1.7600.16395
Output beyond bitmask:

--> HWID data
Current HWID of Hash: MgAAAAMAAgABAAEAAAACAAAAAQABAAEAnJ/6FVT4OgzNUKDVIq2av87Hkoqw0fRSBGs =

Activation 1.0 data OEM-->
N/A

Activation 2.0 data OEM-->
BIOS valid for OA 2.0: Yes, but no SLIC table
Windows marker version: N/A
OEMID and OEMTableID consistent: n/a
BIOS information:
ACPI Table name OEMID value OEMTableID value
FACP AMIINT VIA_P6

I'm not an expert in the interpretation of the output of the MGADiag tool, but a Google search for the last 15 characters of your product key shows that a key by these last 15 characters has been published on the Internet... If this is the key you use, this is why Microsoft has blocked.

How to format your message here?

Try to understand, but can not.
Help, please.
I'm not after a tkprof output and you will have a hard time to read,

>
Try to understand, but can not.
Help, please.
I'm not after a tkprof output and you will have a hard time to read,
>
Add------.

 on a line before any code and again on a line by itself after any code to preserve formatting.

Use the 'Preview' tab in the reply window to see how your post will look. Correct anything before you select 'Post Message'.

Merge into the nested table

Hi all
Can I combine the records in the nested table
I have a table with 2 colum: col_1 and col_2
col_1: corresponds to the id (varchar2)
col_2: is a column nested with the type of table (sub_col_1 (number), sub_col_2 (number))

for example: I have 2 accounts table ('a', (1,2)) and ('b', (3,4)))

what I want is merged into this table with values ('a', '4.5')) + ('c', (6,7)) IN a single statement

What I should have after this operation ('a', (1,2,4,5)) + ('b', (3,4)) + ('c', (6,7)).
Can I do this?

CREATE OR REPLACE TYPE TEST_TYPE AS OBJECT(SUB_COL_1 NUMBER, SUB_COL_2 NUMBER) ;

CREATE OR REPLACE TYPE TEST_TYPE_TABLE IS TABLE OF TEST_TYPE;

CREATE TABLE TEST_MERGE_NESTED_TABLE (COL_1 VARCHAR2(1 CHAR), COL_2 TEST_TYPE_TABLE)
    NESTED TABLE COL_2 STORE AS COL_2_NESTED;
    
INSERT INTO TEST_MERGE_NESTED_TABLE VALUES('a',TEST_TYPE_TABLE(TEST_TYPE(1,2) ));
INSERT INTO TEST_MERGE_NESTED_TABLE VALUES('b',TEST_TYPE_TABLE(TEST_TYPE(3,4) ));

Oracle version: 11.2.0.3
Thank you all.

Published by: 966205 on 20:18 21/02/2013

Published by: 966205 on 20:42 21/02/2013

966205 wrote:
That means he does the same thing as what I want (adding? do not recreate this column in the physical layer).

Actually, no.
All content of the nested table is first removed (for the given FK), then the result of the MULTISET UNION is reinserted.

The evidence on:

SQL> alter session set events '10046 trace name context forever, level 12';

Session altered.

SQL> merge into test_merge_nested_table t
  2  using (
  3    select 'a' col_1, TEST_TYPE_TABLE(TEST_TYPE(4,5)) col_2 from dual union all
  4    select 'c' , TEST_TYPE_TABLE(TEST_TYPE(6,7))            from dual
  5  ) v
  6  on ( t.col_1 = v.col_1 )
  7  when matched then update
  8    set t.col_2 = t.col_2 multiset union v.col_2
  9  when not matched then insert (col_1, col_2)
 10   values (v.col_1, v.col_2) ;

2 rows merged.

SQL> alter session set events '10046 trace name context off';

Session altered.

SQL> select * from test_merge_nested_table;

C COL_2(SUB_COL_1, SUB_COL_2)
- --------------------------------------------------------------------------------
c TEST_TYPE_TABLE(TEST_TYPE(6, 7))
a TEST_TYPE_TABLE(TEST_TYPE(1, 2), TEST_TYPE(4, 5))
b TEST_TYPE_TABLE(TEST_TYPE(3, 4))

TKPROF output:

DELETE, the nested table statement objectives associated with 'a' and deletes the line after line that it contains (1,2).
The later INSERTION is performed twice (run count = 2) and target the two nested table 'a' by inserting 2 ranks: former one (1,2) + the new one (4.5) and the nested table 'c' by inserting 1 row (6,7).

SQL ID: 6bjc2z2t53csn Plan Hash: 132214516

DELETE /*+ REF_CASCADE_CURSOR */ FROM "DEV"."COL_2_NESTED"
WHERE
 "NESTED_TABLE_ID" = :1

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          3           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          1          3           1

Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  DELETE  COL_2_NESTED (cr=1 pr=0 pw=0 time=44 us)
         1          1          1   INDEX RANGE SCAN SYS_FK0000023444N00002$ (cr=1 pr=0 pw=0 time=10 us)(object id 23446)

********************************************************************************

 

********************************************************************************

SQL ID: 0fzd5yk23jyas Plan Hash: 0

INSERT /*+ NO_PARTIAL_COMMIT REF_CASCADE_CURSOR */ INTO "DEV"."COL_2_NESTED"
  ("NESTED_TABLE_ID","SYS_NC_ROWINFO$")
VALUES
(:1, :2)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.00       0.00          0          2         10           3
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0          2         10           3

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 50     (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         0          0          0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=113 us)

********************************************************************************

Interpretation of TKPROF output

Similar Questions

Maybe you are looking for