Inlist iterator
what is an inlist iterator?
From performance point of view is it better to write a query using OR , IN operator, if the column being referred has an index on to it.
http://asktom.oracle.com/pls/ask/f?p=4950:8:16232527426353483178::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:8906695863428
Similar Messages
-
Top N query with INLIST Iterator performance problem
I have a top N query that is giving me problems on Oracle 11.2.0.3.
First of all, I have a query like the following (simplified from the real query, but produces the same problem):
select /*+ gather_plan_statistics */ * from
select rowid
from payer_subscription ps
where ps.subscription_status = :i_subscription_status
and ps.merchant_id = :merchant_id2
order by transaction_date desc
) where rownum <= :i_rowcount; This query works well. It can very efficiently find me the top 10 rows for a massive data set, using an index on merchant_id, subscription_status, transaction_date.
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 0 | SELECT STATEMENT | | 1 | | 10 |00:00:00.01 | 4 |
|* 1 | COUNT STOPKEY | | 1 | | 10 |00:00:00.01 | 4 |
| 2 | VIEW | | 1 | 11 | 10 |00:00:00.01 | 4 |
|* 3 | INDEX RANGE SCAN DESCENDING| SODTEST2_IX | 1 | 100 | 10 |00:00:00.01 | 4 |
-------------------------------------------------------------------------------------------------------As you can see the estimated actual rows at each stage are 10, which is correct.
Now, I have a requirement to get the top N records for a set of merchant_Ids, so if I change the query to include two merchant_ids, the performance tanks:
select /*+ gather_plan_statistics */ * from
select rowid
from payer_subscription ps
where ps.subscription_status = :i_subscription_status
and (ps.merchant_id = :merchant_id or
ps.merchant_id = :merchant_id2 )
order by transaction_date desc
) where rownum <= :i_rowcount;
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | 10 |00:00:00.17 | 178 | | | |
|* 1 | COUNT STOPKEY | | 1 | | 10 |00:00:00.17 | 178 | | | |
| 2 | VIEW | | 1 | 200 | 10 |00:00:00.17 | 178 | | | |
|* 3 | SORT ORDER BY STOPKEY| | 1 | 200 | 10 |00:00:00.17 | 178 | 2048 | 2048 | 2048 (0)|
| 4 | INLIST ITERATOR | | 1 | | 42385 |00:00:00.10 | 178 | | | |
|* 5 | INDEX RANGE SCAN | SODTEST2_IX | 2 | 200 | 42385 |00:00:00.06 | 178 | | | |Notice now that there are 42K rows coming out of the two index range scans - Oracle is no longer aborting the index range scan when it reaches 10 rows. What I thought would happen, is that Oracle would get at most 10 rows for each merchant_id, knowing that at most 10 rows are to be returned by the query. Then it would sort that 10 + 10 rows and output the top 10 based on the transaction date, but it refuses to do that.
Does anyone know how I can get the performance of the first query, when I need to pass a list of merchants into the query? I could probably get the performance using a union all, but the list of merchants is variable, and could be anywhere between 1 or 2 to several 100, so that makes that a bit unworkable.Across the two merchants_id's there are about 42K rows (this is in test, on Prod there could be several million). In the first query example, Oracle can answer the query in about 4 logical IOs and without even doing a sort as it uses the index to scan and get the relevant rows in Oracle.
In the second case, I hoped it would pull 10 rows for each merchant_id and then sort the resulting 20 rows to find the top 10 ordered by transaction_date, but instead it is scanning far more rows than it needs to.
In my example, it takes 4 logical IOs to answer the first query, but ~ 170 to answer the second, while I think it is achievable in 8 or so. For example, this query does what I want, but it is not a feasible option due to how many merchant_id's I may have to deal with:
select /*+ gather_plan_statistics */ *
from
select *
from
select * from
select merchant_id, transaction_date
from payer_subscription ps
where ps.subscription_status = :i_subscription_status
and ps.merchant_id = :merchant_id
order by transaction_date desc
) where rownum <= :i_rowcount
union all
select * from
select merchant_id, transaction_date
from payer_subscription ps
where ps.subscription_status = :i_subscription_status
and ps.merchant_id = :merchant_id2
order by transaction_date desc
) where rownum <= :i_rowcount
) order by transaction_date desc
) where rownum <= :i_rowcount;
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | 1 | | 10 |00:00:00.01 | 6 | | | |
|* 1 | COUNT STOPKEY | | 1 | | 10 |00:00:00.01 | 6 | | | |
| 2 | VIEW | | 1 | 20 | 10 |00:00:00.01 | 6 | | | |
|* 3 | SORT ORDER BY STOPKEY | | 1 | 20 | 10 |00:00:00.01 | 6 | 2048 | 2048 | 2048 (0)|
| 4 | VIEW | | 1 | 20 | 20 |00:00:00.01 | 6 | | | |
| 5 | UNION-ALL | | 1 | | 20 |00:00:00.01 | 6 | | | |
|* 6 | COUNT STOPKEY | | 1 | | 10 |00:00:00.01 | 3 | | | |
| 7 | VIEW | | 1 | 100 | 10 |00:00:00.01 | 3 | | | |
|* 8 | INDEX RANGE SCAN DESCENDING| SODTEST2_IX | 1 | 100 | 10 |00:00:00.01 | 3 | | | |
|* 9 | COUNT STOPKEY | | 1 | | 10 |00:00:00.01 | 3 | | | |
| 10 | VIEW | | 1 | 11 | 10 |00:00:00.01 | 3 | | | |
|* 11 | INDEX RANGE SCAN DESCENDING| SODTEST2_IX | 1 | 100 | 10 |00:00:00.01 | 3 | | | |
---------------------------------------------------------------------------------------------------------------------------------------This UNION ALL query completes in 6 logical IOs - the original query I posted with 2 IDs takes 178 to return the same results. -
Performance Impact with OR concatenation / Inlist Iterator
Hello guys,
is there any performance impact with using OR concatenations or some IN-Lists?
The function of both is the "same":
1) Concatenation (OR-processing)
SELECT * FROM emp WHERE mgr# = 1 OR job = ‘YOURS’;- Similar to query rewrite into 2 seperate queries
- Which are then ‘concatenated’
2) Inlist Iterator
SELECT * FROM dept WHERE d# in (10,20,30);- Iteration over enumerated value-list
- Every value executed seperately
- Same as concatenation of 3 “OR-red” values
So i want to know if there is any performance impact if using IN-Lists instead of OR concatenations.
Thanks and Regards
StefanThe note is very misleading and far from complete; but there is one critical point of difference that you need to observe. It's talking about using a tablescan to deal with an IN-list (and that's NOT "in-list iteration"), my comments start by saying "if there is a suitable indexed access path."
The note, by the way, describes a transformation to a UNION ALL - clearly that would be inefficient if there were no indexed access path. (Given the choice between one tablescan and several consecutive tablescans, which option would you choose ?).
The note, in effect, is just about a slightly more subtle version of "why isn't oracle using my index". For "shorter" lists you might get an indexed iteration, for "longer" lists you might get a tablescan.
Remember, Metalink is not perfect; most of it is just written by ordinary people who learned about Oracle in the normal fashion.
Quick example to demonstrate the difference between concatenation and iteration:
drop table t1;
create table t1 as
select
rownum id,
rownum n1,
rpad('x',100) padding
from
all_objects
where
rownum <= 10000
create index t1_i1 on t1(id);
execute dbms_stats.gather_table_stats(user,'t1')
set autotrace traceonly explain
select
/*+ use_concat(t1) */
n1
from
t1
where
id in (10,20,30,40,50,60,70,80,90,100)
set autotrace offThe execution plan I got from 8.1.7.4 was as follows - showing the transformation to a UNION ALL - this is concatenation and required 10 query block optimisations (which were all done three times):
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=20 Card=10 Bytes=80)
1 0 CONCATENATION
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
3 2 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
4 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
5 4 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
6 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
7 6 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
8 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
9 8 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
10 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
11 10 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
12 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
13 12 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
14 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
15 14 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
16 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
17 16 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
18 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
19 18 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)
20 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=1 Bytes=8)
21 20 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=1 Card=1)This is the execution plan I got from 9.2.0.8, which doesn't transform to the UNION ALL, and only needs to optimise one query block.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=10 Bytes=80)
1 0 INLIST ITERATOR
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=3 Card=10 Bytes=80)
3 2 INDEX (RANGE SCAN) OF 'T1_I1' (NON-UNIQUE) (Cost=2 Card=10)Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk -
Inlist Iterator or Filter - Performance issue or bug?
Hi,
Case1:
SQL Statement
SELECT
/*+
FIRST_ROWS
FROM
"/BI0/PMAT_PLANT"
WHERE
"PLANT" = :A0 AND "MAT_PLANT" = :A1 AND ( "OBJVERS" = :A2 AND "CHANGED" = :A3 OR "OBJVERS" = :A4
AND "CHANGED" = :A5 ) AND ROWNUM <= :A6#
Execution Plan
SELECT STATEMENT ( Estimated Costs = 5 , Estimated #Rows = 1 )
5 COUNT STOPKEY
5 INLIST ITERATOR
5 TABLE ACCESS BY INDEX ROWID /BI0/PMAT_PLANT
INDEX RANGE SCAN /BI0/PMAT_PLANT~Z0
-> Runtime: > 1000s (!!!!!)
Case 2:
SQL Statement
SELECT
/*+
FIRST_ROWS
FROM
"/BI0/PMAT_PLANT"
WHERE
"PLANT" = :A0 AND "MAT_PLANT" = :A1 AND "OBJVERS" BETWEEN :A2 AND :A3 AND "CHANGED" BETWEEN :A4 AND :A5 <= :A6#
Execution Plan
SELECT STATEMENT ( Estimated Costs = 5 , Estimated #Rows = 1 )
5 COUNT STOPKEY
5 FILTER
5 TABLE ACCESS BY INDEX ROWID /BI0/PMAT_PLANT
INDEX RANGE SCAN /BI0/PMAT_PLANT~Z0
-> Runtime: < 1s (!!!!!)
What do I miss? Any hint?
THX in advance...
Paul
P.S. Oracle 9.2.0.3The max. number of returned rows is 2 in both cases.That's presumably because of the ROWNUM. The two queries ask different questions, so the database expects them - potentially - to return different results, and would probably do so without the STOPKEY .
Primary key: PLANT, MAT_PLANT, OBJVERS
And OBJVERS is only "A" or "M".irrelevant (applies in both cases)
And the optimizer calculates costs of 5 for each statement.Optimizer costs have no objective value, so this doesn't mean anything
So the very high runtime in one case is very interesting.No, it's obvious. Look at the queries you posted. The first query says:
return me every row where a particular value of OBVERS is matched with a particular value of CHANGED or another particular value of OBVERS is matched with another particular value of CHANGED
whereas the second query says
return me every row where OBVERS has one of a range of values and CHANGED has one of a range of values.
It's precisely because OBVERS has so few values that you have to do so much work in the first query. Basically your're checking all the orws that match on PLANT and MAT_PLANT. The second query just needs to weed out the rows where CHANGED is in a particular range of values.
Of course, the execution plans are dependent on which values you put into the variables. For instance, this query:
SELECT * FROM
"/BI0/PMAT_PLANT"
WHERE "PLANT" = 1 AND "MAT_PLANT" = 2
AND ( "OBJVERS" = 'A' AND "CHANGED" = '01/01/02'
OR "OBJVERS" = 'M' AND "CHANGED" = '02/01/02')
AND ROWNUM <= 2is not the same as
SELECT * FROM
"/BI0/PMAT_PLANT"
WHERE "PLANT" = 1 AND "MAT_PLANT" = 2
AND ( "OBJVERS" = 'M' AND "CHANGED" = '01/01/02'
OR "OBJVERS" = 'M' AND "CHANGED" = '02/01/02')
AND ROWNUM <= 2but it is the same as
SELECT * FROM
"/BI0/PMAT_PLANT"
WHERE "PLANT" = 1 AND "MAT_PLANT" = 2
AND ("CHANGED" = '01/01/02' OR "CHANGED" = '02/01/02')
AND ROWNUM <= 2Capice?
Cheers, APC -
Dear Sirs, hope question will be new in this forum.
I've found out following :
select count(*) from TEST_TAB s
where hash_key = :hk
and( R$APP in (x1, x2, ..., x10 )
or R_CALLS_LOG in ( y1, y2, ..., y756)
run time: 380 sec
select count(*) from TEST_TAB s
where hash_key = :hk
and( R$APP in (x1, x2, ..., x10 )
or R_CALLS_LOG in ( select n from BUF_TAB)
), where BUF_TAB contains list of values of 1st query
run time: 17 sec.
Description of TEST_TAB
SQL> desc TEST_TAB
Name Type Nullable Default Comments
LDN NUMBER
CID NUMBER Y
R_CALLS_LOG NUMBER Y
TRANSAC NUMBER Y
R$APP NUMBER Y
STRT DATE Y
ROW_ID ROWID Y
DEST_HASH_KEY NUMBER Y
HASH_KEY NUMBER Y
INDEXES: NO
LIST-PARTITIONED: BY "HASH_KEY"
RECORDS in tested section: ~ 1.5 mln
It seems that INLIST operator in WHERE works dramatically slowly that join with the same list stored in separate table.
Is it true for all cases or there is optimal amount of elements in filtration list when INLIST operator will be still best choice?
Thanks in advance.user618999 wrote:
Is it true for all cases when question has only 1 parameter - amount of items in list, while
TEST_TAB has no indexes ...As rgeier pointed out don't think that one query technique is better than another in all circumstances. You can over time see what usually works, but nothing is always true. You've found a situation where the inlist iterator works less efficiently but based on other circumstances the join might not work as well.
An indexed lookup for a table join or subquery is usually a good choice for faster retrieval than a full table scan - unless you need to access all of the rows in the list, in which case it will probably be slower. Without an index an in list might be faster.
I personally don't use in lists a lot, preferring joins or correlated EXISTS subqueries when the subqueries are properly lindexed. If I remember correctly a hard-coded in list has a limit of 1000 items anyway. In lists might be more efficient if they return a very small set of rows, perhaps less than 5 for fewer rows to search through, and if the underlying query (if any) can only be executed once to produce the list.
Adding to the confusion of tuning is that fact that recent versions of oracle can perform query transformations before execution. That is, the query can physically change before execution if the optimizer thinks the change will work better. Thus, in lists and table joins can sometimes be converted to the other. In some cases entire table joins can be added or eliminated.
Edited by: riedelme on Oct 1, 2009 12:55 PM -
많은 INLIST와 MULTIPLE OR 연산을 갖는 SQL의 OPTIMIZATION
제품 : ORACLE SERVER
작성날짜 : 2004-04-19
많은 Inlist와 multiple OR 연산을 갖는 SQL의 Optimization
=========================================================
PURPOSE
이 문서는 IN 연산 내의 많은 IN List와 많은 OR 연산자를 갖는
경우에 CBO가 어떻게 처리하는가에 대한 자료이다.
Explanation
많은 개발자나 DBA들은 IN 연산자와 OR 연산자를 사용하는 SQL이
과도한 Optimization time을 야기시키는 문제를 경험했을 것이다.
이 문서에서는 CBO가 어떻게 IN list와 OR 연산자를 처리하는지
설명하고자 한다.
CBO가 IN list 연산을 만나면 다음과 같은 몇 가지 option을 가지고 판단한다.
1. SQL 문장을 UNION ALL 이 들어간 문장의 연속으로 나눈다.
SELECT empno FROM emp WHERE deptno IN (10,20,30);
라는 문장을 살펴보자.
이 문장은 다음과 같이 다시 쓰여질 수 있다.
SELECT empno FROM emp WHERE deptno = 10
UNION ALL
SELECT empno FROM emp WHERE deptno = 20
UNION ALL
SELECT empno FROM emp WHERE deptno = 30
만약 deptno column이 indexed된다면 index는 각 branch 단에서 loopup하기
위해 사용될 수 있다.
만약 split이 Cost Based Optimizer로 자동으로 발생하지 않는다면
USE_CONCAT hint 를 사용함으로써 강제로 수행될 수 있다.
이 내용에 대해서는 <Note:17214.1>을 참조하도록 한다.
2. IN list를 list로 남겨 두고, filter로서 값을 사용한다.
Oracle 7에서 이 옵션은 index를 사용할 수 없다.
Oracle 8에서 이 옵션은 index를 사용할 수 있는 'inlist iterator' 라는
것을 사용하여 제공된다.
NO_EXPAND hint를 사용함으로써 expand가 일어나지 않도록 CBO 에게 지정할 수 있다.
아주 긴 inlist는 CBO 환경에서 문제를 야기시킬 수 있다. 특히 inlist가 많은 수의
UNION ALL 문장으로 expand될 때 그러하다. 왜냐하면 CBO가 expand된 문장들에
대해서 Cost를 결정해야 하기 때문이다. 이러한 expand된 문장들은 많은 수의
branch 때문에 time을 소모하는 문장들이다.
RBO(Rule Based Optimizer) 환경에서는 이것은 cost 산정을 하지 않으므로 문제가
되지 않는다.
Workaround
만약 아주 긴 inlist 때문에 parsing 문제가 있다면 workaround는 다음과 같다.
1) NO_EXPAND hint를 사용하도록 한다. 이 힌트를 쓰면 Oracle 7에서는 index를
사용하지 않고, Oracle 8에서는 index를 사용할 수 있다.
2) RBO 를 사용하도록 한다.
3) Query를 재작성한다. Inlist가 lookup table에 저장이 되도록 해서
inlist를 사용하는 대신에 그 table에 join을 한다.
주의) hint를 사용하게 되면 CBO로 동작하게 됨을 기억해야 한다.
Example
none
Reference Documents
<Note:62153.1> -
What can I do to make this query run faster
Hi All,
The below query is taking a long time. Is there any thing that I can do to shorten its time.
SELECT C.FOLIO_NO, C.CO_TRANS_NO TRANS_NO, to_char(C.CREATED_DATE, 'dd/mm/yyyy') DOC_DATE, DECODE(PP.NAME, NULL, D.EMP_NAME, PP.NAME) LODGED_BY, decode(sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID), Null, '-', sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID)) DATE_CHANGE, P.RECEIPT_NO, decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id) TRANS_ID,(case when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR20' then 1 when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR03' then 2 end) TRANS_TYPE FROM CO_TRANS_MASTER C, PAYMENT_DETAIL P, PEOPLE_PROFILE PP, SC_AGENT_EMP D, M_CAA_TRANS E where '1' <> TRIM(UPPER('S0750070Z')) and (C.CO_TRANS_ID in TRIM(UPPER('AR20')) OR C.CO_TRANS_ID in TRIM(UPPER('AR03'))OR c.co_trans_id IN TRIM (UPPER ('A020')))and C.CO_TRANS_NO = P.TRANS_NO and (C.VOID_IND = 'N' or C.VOID_IND is Null) and C.CREATED_BY = PP.PP_ID(+) and C.PROF_NO = D.PROF_NO(+) and C.CREATED_BY = D.EMP_ID (+) and TRIM(UPPER(C.CO_NO)) = TRIM(UPPER('200101586W')) and c.co_trans_id = e.trans_id (+) order by FOLIO_NO;
SQL>
SQL> show parameter user_dump_dest
NAME TYPE VALUE
user_dump_dest string /u01/app/oracle/diag/rdbms/ebi
zfile/EBIZFILE1/trace
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.2
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
SQL>
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL>
SQL> select
2 sname, pname, pval1, pval2
3 from
4 sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 09-11-2010 14:25
SYSSTATS_INFO DSTOP 09-11-2010 14:25
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 739.734748
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.
Elapsed: 00:00:00.06
SQL>
SQL> explain plan for
2 SELECT C.FOLIO_NO, C.CO_TRANS_NO TRANS_NO, to_char(C.CREATED_DATE, 'dd/mm/yyyy') DOC_DATE, DECODE(PP.NAME, NULL, D.EMP_NAME, PP.NAME) LODGED_BY, decode(sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID), Null, '-', sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID)) DATE_CHANGE, P.RECEIPT_NO, decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id) TRANS_ID,(case when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR20' then 1 when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR03' then 2 end) TRANS_TYPE FROM CO_TRANS_MASTER C, PAYMENT_DETAIL P, PEOPLE_PROFILE PP, SC_AGENT_EMP D, M_CAA_TRANS E where '1' <> TRIM(UPPER('S0750070Z')) and (C.CO_TRANS_ID in TRIM(UPPER('AR20')) OR C.CO_TRANS_ID in TRIM(UPPER('AR03'))OR c.co_trans_id IN TRIM (UPPER ('A020')))and C.CO_TRANS_NO = P.TRANS_NO and (C.VOID_IND = 'N' or C.VOID_IND is Null) and C.CREATED_BY = PP.PP_ID(+) and C.PROF_NO = D.PROF_NO(+) and C.CREATED_BY = D.EMP_ID (+) and TRIM(UPPER(C.CO_NO)) = TRIM(UPPER('200101586W')) and c.co_trans_id = e.trans_id (+) order by FOLIO_NO;
Explained.
Elapsed: 00:00:00.09
SQL>
SQL> set pagesize 1000;
SQL> set linesize 170;
SQL> @/u01/app/oracle/product/11.2.0/rdbms/admin/utlxpls.sql
SQL> Rem
SQL> Rem $Header: utlxpls.sql 26-feb-2002.19:49:37 bdagevil Exp $
SQL> Rem
SQL> Rem utlxpls.sql
SQL> Rem
SQL> Rem Copyright (c) 1998, 2002, Oracle Corporation. All rights reserved.
SQL> Rem
SQL> Rem NAME
SQL> Rem utlxpls.sql - UTiLity eXPLain Serial plans
SQL> Rem
SQL> Rem DESCRIPTION
SQL> Rem script utility to display the explain plan of the last explain plan
SQL> Rem command. Do not display information related to Parallel Query
SQL> Rem
SQL> Rem NOTES
SQL> Rem Assume that the PLAN_TABLE table has been created. The script
SQL> Rem utlxplan.sql should be used to create that table
SQL> Rem
SQL> Rem With SQL*plus, it is recomended to set linesize and pagesize before
SQL> Rem running this script. For example:
SQL> Rem set linesize 100
SQL> Rem set pagesize 0
SQL> Rem
SQL> Rem MODIFIED (MM/DD/YY)
SQL> Rem bdagevil 02/26/02 - cast arguments
SQL> Rem bdagevil 01/23/02 - rewrite with new dbms_xplan package
SQL> Rem bdagevil 04/05/01 - include CPU cost
SQL> Rem bdagevil 02/27/01 - increase Name column
SQL> Rem jihuang 06/14/00 - change order by to order siblings by.
SQL> Rem jihuang 05/10/00 - include plan info for recursive SQL in LE row source
SQL> Rem bdagevil 01/05/00 - add order-by to make it deterministic
SQL> Rem kquinn 06/28/99 - 901272: Add missing semicolon
SQL> Rem bdagevil 05/07/98 - Explain plan script for serial plans
SQL> Rem bdagevil 05/07/98 - Created
SQL> Rem
SQL>
SQL> set markup html preformat on
SQL>
SQL> Rem
SQL> Rem Use the display table function from the dbms_xplan package to display the last
SQL> Rem explain plan. Force serial option for backward compatibility
SQL> Rem
SQL> select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));
PLAN_TABLE_OUTPUT
Plan hash value: 2520189693
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 592 | 85248 | 16573 (1)| 00:03:19 |
| 1 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 7 | SORT ORDER BY | | 592 | 85248 | 16573 (1)| 00:03:19 |
| 8 | NESTED LOOPS | | | | | |
| 9 | NESTED LOOPS | | 592 | 85248 | 16572 (1)| 00:03:19 |
| 10 | NESTED LOOPS OUTER | | 477 | 54855 | 15329 (1)| 00:03:04 |
| 11 | NESTED LOOPS OUTER | | 477 | 41499 | 14374 (1)| 00:02:53 |
| 12 | INLIST ITERATOR | | | | | |
|* 13 | TABLE ACCESS BY INDEX ROWID| CO_TRANS_MASTER | 477 | 22896 | 14367 (1)| 00:02:53 |
|* 14 | INDEX RANGE SCAN | IDX_CO_TRANS_ID | 67751 | | 150 (1)| 00:00:02 |
| 15 | TABLE ACCESS BY INDEX ROWID | SC_AGENT_EMP | 1 | 39 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | PK_SC_AGENT_EMP | 1 | | 0 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 28 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | SYS_C0063100 | 1 | | 1 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | IDX_PAY_DETAIL_TRANS_NO | 1 | | 2 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | PAYMENT_DETAIL | 1 | 29 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("F"."CO_TRANS_NO"=:B1)
4 - access("F"."CO_TRANS_NO"=:B1)
6 - access("F"."CO_TRANS_NO"=:B1)
13 - filter(TRIM(UPPER("SYS_ALIAS_3"."CO_NO"))='200101586W' AND ("SYS_ALIAS_3"."VOID_IND" IS NULL
OR "SYS_ALIAS_3"."VOID_IND"='N'))
14 - access("SYS_ALIAS_3"."CO_TRANS_ID"='A020' OR "SYS_ALIAS_3"."CO_TRANS_ID"='AR03' OR
"SYS_ALIAS_3"."CO_TRANS_ID"='AR20')
16 - access("SYS_ALIAS_3"."PROF_NO"="D"."PROF_NO"(+) AND
"SYS_ALIAS_3"."CREATED_BY"="D"."EMP_ID"(+))
18 - access("SYS_ALIAS_3"."CREATED_BY"="PP"."PP_ID"(+))
19 - access("SYS_ALIAS_3"."CO_TRANS_NO"="P"."TRANS_NO")
42 rows selected.
Elapsed: 00:00:00.53
SQL>
SQL>
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.01
SQL>
SQL> rem Set the ARRAYSIZE according to your application
SQL> set autotrace traceonly arraysize 100
SQL>
SQL> alter session set tracefile_identifier = 'mytrace1';
Session altered.
Elapsed: 00:00:00.00
SQL>
SQL> rem if you're using bind variables
SQL> rem define them here
SQL>
SQL> rem variable b_var1 number
SQL> rem variable b_var2 varchar2(20)
SQL>
SQL> rem and initialize them
SQL>
SQL> rem exec :b_var1 := 1
SQL> rem exec :b_var2 := 'DIAG'
SQL> set pagesize 1000;
SQL> set linesize 170;
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
Elapsed: 00:00:00.01
SQL> SELECT C.FOLIO_NO, C.CO_TRANS_NO TRANS_NO, to_char(C.CREATED_DATE, 'dd/mm/yyyy') DOC_DATE, DECODE(PP.NAME, NULL, D.EMP_NAME, PP.NAME) LODGED_BY, decode(sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID), Null, '-', sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID)) DATE_CHANGE, P.RECEIPT_NO, decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id) TRANS_ID,(case when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR20' then 1 when decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR03' then 2 end) TRANS_TYPE FROM CO_TRANS_MASTER C, PAYMENT_DETAIL P, PEOPLE_PROFILE PP, SC_AGENT_EMP D, M_CAA_TRANS E where '1' <> TRIM(UPPER('S0750070Z')) and (C.CO_TRANS_ID in TRIM(UPPER('AR20')) OR C.CO_TRANS_ID in TRIM(UPPER('AR03'))OR c.co_trans_id IN TRIM (UPPER ('A020')))and C.CO_TRANS_NO = P.TRANS_NO and (C.VOID_IND = 'N' or C.VOID_IND is Null) and C.CREATED_BY = PP.PP_ID(+) and C.PROF_NO = D.PROF_NO(+) and C.CREATED_BY = D.EMP_ID (+) and TRIM(UPPER(C.CO_NO)) = TRIM(UPPER('200101586W')) and c.co_trans_id = e.trans_id (+) order by FOLIO_NO;
10 rows selected.
Elapsed: 00:03:42.27
Execution Plan
Plan hash value: 2520189693
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 592 | 85248 | 16573 (1)| 00:03:19 |
| 1 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | 20 | 2 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | 1 (0)| 00:00:01 |
| 7 | SORT ORDER BY | | 592 | 85248 | 16573 (1)| 00:03:19 |
| 8 | NESTED LOOPS | | | | | |
| 9 | NESTED LOOPS | | 592 | 85248 | 16572 (1)| 00:03:19 |
| 10 | NESTED LOOPS OUTER | | 477 | 54855 | 15329 (1)| 00:03:04 |
| 11 | NESTED LOOPS OUTER | | 477 | 41499 | 14374 (1)| 00:02:53 |
| 12 | INLIST ITERATOR | | | | | |
|* 13 | TABLE ACCESS BY INDEX ROWID| CO_TRANS_MASTER | 477 | 22896 | 14367 (1)| 00:02:53 |
|* 14 | INDEX RANGE SCAN | IDX_CO_TRANS_ID | 67751 | | 150 (1)| 00:00:02 |
| 15 | TABLE ACCESS BY INDEX ROWID | SC_AGENT_EMP | 1 | 39 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | PK_SC_AGENT_EMP | 1 | | 0 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 28 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | SYS_C0063100 | 1 | | 1 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | IDX_PAY_DETAIL_TRANS_NO | 1 | | 2 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | PAYMENT_DETAIL | 1 | 29 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("F"."CO_TRANS_NO"=:B1)
4 - access("F"."CO_TRANS_NO"=:B1)
6 - access("F"."CO_TRANS_NO"=:B1)
13 - filter(TRIM(UPPER("SYS_ALIAS_3"."CO_NO"))='200101586W' AND ("SYS_ALIAS_3"."VOID_IND" IS NULL
OR "SYS_ALIAS_3"."VOID_IND"='N'))
14 - access("SYS_ALIAS_3"."CO_TRANS_ID"='A020' OR "SYS_ALIAS_3"."CO_TRANS_ID"='AR03' OR
"SYS_ALIAS_3"."CO_TRANS_ID"='AR20')
16 - access("SYS_ALIAS_3"."PROF_NO"="D"."PROF_NO"(+) AND
"SYS_ALIAS_3"."CREATED_BY"="D"."EMP_ID"(+))
18 - access("SYS_ALIAS_3"."CREATED_BY"="PP"."PP_ID"(+))
19 - access("SYS_ALIAS_3"."CO_TRANS_NO"="P"."TRANS_NO")
Statistics
51 recursive calls
0 db block gets
651812 consistent gets
92202 physical reads
0 redo size
1594 bytes sent via SQL*Net to client
524 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
SQL>
SQL> disconnect
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> Thanks in advance!Hi Raj,
I have given the output below as you requested....
QL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 0taz7ckjm41yv, child number 1
SELECT C.FOLIO_NO, C.CO_TRANS_NO TRANS_NO, to_char(C.CREATED_DATE,
'dd/mm/yyyy') DOC_DATE, DECODE(PP.NAME, NULL, D.EMP_NAME, PP.NAME)
LODGED_BY, decode(sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID),
Null, '-', sf_fetch_datechange(c.co_trans_no, C.CO_TRANS_ID))
DATE_CHANGE, P.RECEIPT_NO, decode(c.co_trans_id,'A020',(select
nvl(base_trans_id,co_trans_id) from co_form5a_trans f where
f.co_trans_no=c.co_trans_no),c.co_trans_id) TRANS_ID,(case when
decode(c.co_trans_id,'A020',(select nvl(base_trans_id,co_trans_id) from
co_form5a_trans f where f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR2
0' then 1 when decode(c.co_trans_id,'A020',(select
nvl(base_trans_id,co_trans_id) from co_form5a_trans f where
f.co_trans_no=c.co_trans_no),c.co_trans_id)='AR03' then 2 end)
TRANS_TYPE FROM CO_TRANS_MASTER C, PAYMENT_DETAIL P, PEOPLE_PROFILE PP,
SC_AGENT_EMP D, M_CAA_TRANS E where '1' <> TRIM(UPPER('S0750070Z')) and
(C.CO_TRANS_ID in TRIM(UPPER('AR20')) OR C.CO_TRANS_ID in
TRIM(UPPER('AR03'))OR c.co
Plan hash value: 4175354585
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem |
| 0 | SELECT STATEMENT | | | | | |
| 1 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | | | |
|* 2 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | | |
| 3 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | | | |
|* 4 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | | |
| 5 | TABLE ACCESS BY INDEX ROWID | CO_FORM5A_TRANS | 1 | | | |
|* 6 | INDEX UNIQUE SCAN | SYS_C0059692 | 1 | | | |
| 7 | SORT ORDER BY | | 12 | 2048 | 2048 | 2048 (0)|
| 8 | NESTED LOOPS | | | | | |
| 9 | NESTED LOOPS | | 12 | | | |
| 10 | NESTED LOOPS OUTER | | 10 | | | |
| 11 | NESTED LOOPS OUTER | | 10 | | | |
|* 12 | TABLE ACCESS FULL | CO_TRANS_MASTER | 10 | | | |
| 13 | TABLE ACCESS BY INDEX ROWID| SC_AGENT_EMP | 1 | | | |
|* 14 | INDEX UNIQUE SCAN | PK_SC_AGENT_EMP | 1 | | | |
| 15 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | | | |
|* 16 | INDEX UNIQUE SCAN | SYS_C0063100 | 1 | | | |
|* 17 | INDEX RANGE SCAN | IDX_PAY_DETAIL_TRANS_NO | 1 | | | |
| 18 | TABLE ACCESS BY INDEX ROWID | PAYMENT_DETAIL | 1 | | | |
Predicate Information (identified by operation id):
2 - access("F"."CO_TRANS_NO"=:B1)
4 - access("F"."CO_TRANS_NO"=:B1)
6 - access("F"."CO_TRANS_NO"=:B1)
12 - filter((INTERNAL_FUNCTION("SYS_ALIAS_3"."CO_TRANS_ID") AND
TRIM(UPPER("SYS_ALIAS_3"."CO_NO"))='200101586W' AND ("SYS_ALIAS_3"."VOID_IND" IS NULL OR
"SYS_ALIAS_3"."VOID_IND"='N')))
14 - access("SYS_ALIAS_3"."PROF_NO"="D"."PROF_NO" AND "SYS_ALIAS_3"."CREATED_BY"="D"."EMP_ID")
16 - access("SYS_ALIAS_3"."CREATED_BY"="PP"."PP_ID")
17 - access("SYS_ALIAS_3"."CO_TRANS_NO"="P"."TRANS_NO")
Note
- cardinality feedback used for this statement
- Warning: basic plan statistics not available. These are only collected when:
* hint 'gather_plan_statistics' is used for the statement or
* parameter 'statistics_level' is set to 'ALL', at session or system level
65 rows selected. -
Convrtd to Invterval Part- ORA-03113: end-of-file on communication channel
Hi all,
I had a table as Interval Partitioned. In order to create XML- Xpath indexes on it, I converted it to Range Partitioned table.
I am able to create the XPATH indexes but I get the error: ORA-03113: end-of-file on communication channel
- When I revert the code to Interval Partitioned without the XMLIndex, it works fine(although takes time as no XML Index)
- When I convert table to non partitioned table, create the XML Index, it works fine.
But I need the partitons, so when I create the partitioned table I get the error.
CREATE TABLE INT_PART_TABLE
DB_ID VARCHAR2(10 BYTE),
xML_mESSAGE SYS.XMLTYPE,
LOAD_TIMESTAMP TIMESTAMP(6)
XMLTYPE xML_mESSAGE STORE AS BINARY XML
PARTITION BY RANGE (LOAD_TIMESTAMP)
PARTITION MAX VALUES LESS THAN (TIMESTAMP' 2013-06-01 00:00:00')
TABLESPACE CSTR_STG_DATA
NOCOMPRESS
NOCACHE
ENABLE ROW MOVEMENT;
BEGIN
DBMS_XMLINDEX.dropparameter('Indx_Par');
END;
BEGIN
DBMS_XMLINDEX.REGISTERPARAMETER(
'Indx_Par',
'PATH TABLE Table1
PATHS (INCLUDE ( /abc:field1/xyz:field2
/abc:field1/def:field2
NAMESPACE MAPPING ( xmlns:abc="ABCD"
xmlns:def="DEFG"
xmlns:xyz="XYZA"
end;
create index INDX_XPATHS on "INT_PART_TABLE" (XML_MESSAGE) indextype is xdb.xmlindex
parameters ('PARAM Indx_Par') local;
Now if I execute the following statement in
SELECT T.xML_mESSAGE
FROM INT_PART_TABLE1 T
WHERE XMLEXISTS (
declare namespace abc="ABCD";
declare namespacedef="DEFG";
declare namespace xyz="XYZA";
let $tt as xs:boolean := fn:exists($p/main/id = ("144283","9085802")])
return if ($tt) then true()
else ()'
PASSING T.xML_mESSAGE AS "p");
- Is there any other way of writing this Select statement, which may work?
- Any other thing I need to take care of when defining the table and partitions script so that I don't get this error?Hi,
I think it's time you give a clear (and working) test case so that we can safely try to reproduce the issue.
What you've given so far has syntax error and name mismatch.
So please :
- database version (SELECT * FROM v$version)
- complete sequence of DLLs
- some sample XML documents (it doesn't have to be the real ones, but at least something realistic)
Thanks in advance.
declare namespace abc="ABCD";
declare namespacedef="DEFG";
declare namespace xyz="XYZA";
let $tt as xs:boolean := fn:exists($p/main/id = ("144283","9085802")])
return if ($tt) then true()
else ()'Why all that stuff? You don't have to return a boolean.
The following works for me on 11.2.0.3 :
SQL> CREATE TABLE int_part_table (
2 db_id VARCHAR2(10)
3 , xml_message XMLTYPE
4 , load_timestamp TIMESTAMP
5 )
6 XMLTYPE xml_message STORE AS BINARY XML
7 PARTITION BY RANGE (load_timestamp) (
8 PARTITION MAX VALUES LESS THAN (timestamp '2013-06-01 00:00:00')
9 )
10 NOCOMPRESS
11 NOCACHE
12 ENABLE ROW MOVEMENT;
Table created
SQL> insert into int_part_table values (1, xmltype('<main><id>144283</id></main>'), sysdate);
1 row inserted
SQL> insert into int_part_table values (1, xmltype('<main><id>9085802</id></main>'), sysdate);
1 row inserted
SQL> insert into int_part_table values (1, xmltype('<main><id>1</id></main>'), sysdate);
1 row inserted
SQL> commit;
Commit complete
SQL> create index int_part_table_uix on int_part_table (xml_message)
2 indextype is xdb.xmlindex
3 parameters (
4 'PATH TABLE INT_PART_TABLE_PT
5 PATHS ( INCLUDE ( /main/id ) )')
6 local;
Index created
SQL> SELECT xml_message
2 FROM int_part_table
3 WHERE XMLExists(
4 '/main[id=("144283","9085802")]'
5 PASSING xml_message
6 )
7 ;
XML_MESSAGE
<main>
<id>144283</id>
</main>
<main>
<id>9085802</id>
</main>
Execution Plan
Plan hash value: 3517234298
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 155 | 34 (6)| 00:00:01 | | |
| 1 | NESTED LOOPS | | 1 | 155 | 34 (6)| 00:00:01 | | |
| 2 | VIEW | VW_SQ_1 | 1 | 25 | 32 (4)| 00:00:01 | | |
| 3 | HASH UNIQUE | | 1 | 47 | | | | |
|* 4 | HASH JOIN SEMI | | 1 | 47 | 32 (4)| 00:00:01 | | |
| 5 | PARTITION SYSTEM SINGLE | | 2 | 90 | 2 (0)| 00:00:01 | 1 | 1 |
|* 6 | TABLE ACCESS BY LOCAL INDEX ROWID| INT_PART_TABLE_PT | 2 | 90 | 2 (0)| 00:00:01 | 1 | 1 |
|* 7 | INDEX SKIP SCAN | SYS117585_INT_PART__PIKEY_IX | 3 | | 1 (0)| 00:00:01 | 1 | 1 |
| 8 | COLLECTION ITERATOR PICKLER FETCH | XQSEQUENCEFROMXMLTYPE | 8168 | 16336 | 29 (0)| 00:00:01 | | |
|* 9 | TABLE ACCESS BY USER ROWID | INT_PART_TABLE | 1 | 130 | 1 (0)| 00:00:01 | ROWID | ROWID |
Predicate Information (identified by operation id):
4 - access("SYS_P3"."VALUE"=SYS_XQ_UPKXML2SQL(VALUE(KOKBF$),2,1,0) AND
SUBSTRB("VALUE",1,1599)=SUBSTRB(SYS_XQ_UPKXML2SQL(VALUE(KOKBF$),2,1,0),1,1599))
6 - filter(SYS_XMLI_LOC_ISNODE("SYS_P3"."LOCATOR")=1)
7 - access("SYS_P3"."PATHID"=HEXTORAW('704E') )
filter("SYS_P3"."PATHID"=HEXTORAW('704E') )
9 - filter("ITEM_6"=TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE",0,7,65535,"INT_PART_TABLE".ROWID))
Note
- Unoptimized XML construct detected (enable XMLOptimizationCheck for more information)
SQL> SELECT xml_message
2 FROM int_part_table
3 WHERE XMLExists(
4 '/main[id="144283" or id="9085802"]'
5 PASSING xml_message
6 )
7 ;
XML_MESSAGE
<main>
<id>144283</id>
</main>
<main>
<id>9085802</id>
</main>
Execution Plan
Plan hash value: 3748936130
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 155 | 11 (10)| 00:00:01 | | |
| 1 | NESTED LOOPS | | 1 | 155 | 11 (10)| 00:00:01 | | |
| 2 | VIEW | VW_SQ_1 | 2 | 50 | 8 (0)| 00:00:01 | | |
| 3 | HASH UNIQUE | | 2 | 180 | | | | |
| 4 | CONCATENATION | | | | | | | |
| 5 | NESTED LOOPS | | | | | | | |
| 6 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 | | |
| 7 | PARTITION SYSTEM SINGLE | | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
|* 8 | TABLE ACCESS BY LOCAL INDEX ROWID| INT_PART_TABLE_PT | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
|* 9 | INDEX SKIP SCAN | SYS117585_INT_PART__PIKEY_IX | 3 | | 1 (0)| 00:00:01 | 1 | 1 |
| 10 | PARTITION SYSTEM SINGLE | | 1 | | 1 (0)| 00:00:01 | 1 | 1 |
|* 11 | INDEX RANGE SCAN | SYS117585_INT_PART__PIKEY_IX | 1 | | 1 (0)| 00:00:01 | 1 | 1 |
|* 12 | TABLE ACCESS BY LOCAL INDEX ROWID | INT_PART_TABLE_PT | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
| 13 | NESTED LOOPS | | | | | | | |
| 14 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 | | |
| 15 | PARTITION SYSTEM SINGLE | | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
|* 16 | TABLE ACCESS BY LOCAL INDEX ROWID| INT_PART_TABLE_PT | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
|* 17 | INDEX SKIP SCAN | SYS117585_INT_PART__PIKEY_IX | 3 | | 1 (0)| 00:00:01 | 1 | 1 |
| 18 | PARTITION SYSTEM SINGLE | | 1 | | 1 (0)| 00:00:01 | 1 | 1 |
|* 19 | INDEX RANGE SCAN | SYS117585_INT_PART__PIKEY_IX | 1 | | 1 (0)| 00:00:01 | 1 | 1 |
|* 20 | TABLE ACCESS BY LOCAL INDEX ROWID | INT_PART_TABLE_PT | 1 | 45 | 2 (0)| 00:00:01 | 1 | 1 |
|* 21 | TABLE ACCESS BY USER ROWID | INT_PART_TABLE | 1 | 130 | 1 (0)| 00:00:01 | ROWID | ROWID |
Predicate Information (identified by operation id):
8 - filter("SYS_P5"."VALUE"='9085802' AND SYS_XMLI_LOC_ISNODE("SYS_P5"."LOCATOR")=1 AND SUBSTRB("VALUE",1,1599)='9085802')
9 - access("SYS_P5"."PATHID"=HEXTORAW('704E') )
filter("SYS_P5"."PATHID"=HEXTORAW('704E') )
11 - access("SYS_P5"."RID"="SYS_P3"."RID" AND "SYS_P3"."PATHID"=HEXTORAW('0BBD') AND
"SYS_P3"."ORDER_KEY"<"SYS_P5"."ORDER_KEY")
filter(SYS_ORDERKEY_DEPTH("SYS_P3"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P5"."ORDER_KEY") AND
TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE",0,7,65535,"SYS_P3"."RID")=TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE_PT",0,7,65535,ROWI
D) AND "SYS_P5"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P3"."ORDER_KEY"))
12 - filter(SYS_XMLI_LOC_ISNODE("SYS_P3"."LOCATOR")=1)
16 - filter("SYS_P5"."VALUE"='144283' AND SYS_XMLI_LOC_ISNODE("SYS_P5"."LOCATOR")=1 AND SUBSTRB("VALUE",1,1599)='144283' AND
(LNNVL("SYS_P5"."VALUE"='9085802') OR LNNVL("SYS_P5"."PATHID"=HEXTORAW('704E') ) OR
LNNVL(SYS_XMLI_LOC_ISNODE("SYS_P5"."LOCATOR")=1) OR LNNVL(SUBSTRB("VALUE",1,1599)='9085802')))
17 - access("SYS_P5"."PATHID"=HEXTORAW('704E') )
filter("SYS_P5"."PATHID"=HEXTORAW('704E') )
19 - access("SYS_P5"."RID"="SYS_P3"."RID" AND "SYS_P3"."PATHID"=HEXTORAW('0BBD') AND
"SYS_P3"."ORDER_KEY"<"SYS_P5"."ORDER_KEY")
filter(SYS_ORDERKEY_DEPTH("SYS_P3"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P5"."ORDER_KEY") AND
TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE",0,7,65535,"SYS_P3"."RID")=TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE_PT",0,7,65535,ROWI
D) AND "SYS_P5"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P3"."ORDER_KEY"))
20 - filter(SYS_XMLI_LOC_ISNODE("SYS_P3"."LOCATOR")=1)
21 - filter("ITEM_2"=TBL$OR$IDX$PART$NUM("DEV"."INT_PART_TABLE",0,7,65535,"INT_PART_TABLE".ROWID))I asked in one of your other threads if /main/id was unique per XML document.
If so, you can use a simple function-based index instead of the XMLIndex :
SQL> drop index int_part_table_uix;
Index dropped.
SQL> create index int_part_table_ix1 on int_part_table (
2 xmlcast(
3 xmlquery('/main/id' passing XML_MESSAGE returning content)
4 as varchar2(10)
5 )
6 );
Index created.
SQL> SELECT xml_message
2 FROM int_part_table
3 WHERE XMLCast(
4 XMLQuery('/main/id' PASSING xml_message RETURNING CONTENT)
5 AS VARCHAR2(10)
6 )
7 IN ('144283', '9085802');
XML_MESSAGE
<main>
<id>144283</id>
</main>
<main>
<id>9085802</id>
</main>
Execution Plan
Plan hash value: 2864653096
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 2 | 236 | 2 (0)| 00:00:01 | | |
| 1 | INLIST ITERATOR | | | | | | | |
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID| INT_PART_TABLE | 2 | 236 | 2 (0)| 00:00:01 | 1 | 1 |
|* 3 | INDEX RANGE SCAN | INT_PART_TABLE_IX1 | 2 | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
3 - access(CAST(EXTRACTVALUE(SYS_MAKEXML(0,"SYS_NC00003$"),'/main/id',null,0,0,524293,1073874944) AS
varchar2(10) )='144283' OR CAST(EXTRACTVALUE(SYS_MAKEXML(0,"SYS_NC00003$"),'/main/id',null,0,0,524293,1073874944
) AS varchar2(10) )='9085802') -
Report takes long time in different database version
Dear Mates,
I have been in serious problem from last one month. Still i don't get any solution. Come to the problem.
I have a program where, database version is *9i R2*. Here one report are base on a database function and works perfectly. It takes 30/35 seconds to preview.
I take this schema backup by EXP command and import it to database version XE and also database version *10G R2* with IMP command. import is successful. Others report still preview as it is at 9i. But my mentioned reports didn't come as same. Now it takes 3 Hrs. :(.
I run explain plan and the out put is bellow. What should i do now ? If you want to check the query i can also post it. If any one have experience regarding this, please help me.
Plan hash value: 3745590339
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 9454 | 1874K| 207 (55)| 00:00:03 |
| 1 | SORT GROUP BY | | 9454 | 1874K| 207 (55)| 00:00:03 |
|* 2 | HASH JOIN | | 9454 | 1874K| 205 (55)| 00:00:03 |
|* 3 | INDEX FAST FULL SCAN | IND_AD_ID | 9454 | 120K| 201 (55)| 00:00:03 |
| 4 | INLIST ITERATOR | | | | | |
| 5 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | 1351 | 250K| 3 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | IND_AD_FLAG | 8 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
3 - filter("ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",:UNIT,:PROJ)<>0)
6 - access("ACC_DTL"."AD_FLAG"=6 OR "ACC_DTL"."AD_FLAG"=7 OR "ACC_DTL"."AD_FLAG"=8
OR "ACC_DTL"."AD_FLAG"=18 OR "ACC_DTL"."AD_FLAG"=19)
Note
- dynamic sampling used for this statementupper explain plan is from database 10g R2
bellow r from 9i R2
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | SORT GROUP BY | | | | |
| 2 | CONCATENATION | | | | |
| 3 | NESTED LOOPS | | | | |
| 4 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | | | |
|* 5 | INDEX RANGE SCAN | IND_AD_FLAG | | | |
|* 6 | INDEX RANGE SCAN | IND_AD_ID | | | |
| 7 | NESTED LOOPS | | | | |
| 8 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | | | |
|* 9 | INDEX RANGE SCAN | IND_AD_FLAG | | | |
|* 10 | INDEX RANGE SCAN | IND_AD_ID | | | |
| 11 | NESTED LOOPS | | | | |
| 12 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | | | |
|* 13 | INDEX RANGE SCAN | IND_AD_FLAG | | | |
|* 14 | INDEX RANGE SCAN | IND_AD_ID | | | |
| 15 | NESTED LOOPS | | | | |
| 16 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | | | |
|* 17 | INDEX RANGE SCAN | IND_AD_FLAG | | | |
|* 18 | INDEX RANGE SCAN | IND_AD_ID | | | |
| 19 | NESTED LOOPS | | | | |
| 20 | TABLE ACCESS BY INDEX ROWID| ACC_DTL | | | |
|* 21 | INDEX RANGE SCAN | IND_AD_FLAG | | | |
|* 22 | INDEX RANGE SCAN | IND_AD_ID | | | |
Predicate Information (identified by operation id):
5 - access("ACC_DTL"."AD_FLAG"=19)
6 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
filter("ERP"."ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",TO_NUMBER(:Z),TO_N
UMBER(:Z))<>0)
9 - access("ACC_DTL"."AD_FLAG"=18)
10 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
filter("ERP"."ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",TO_NUMBER(:Z),TO_N
UMBER(:Z))<>0)
13 - access("ACC_DTL"."AD_FLAG"=8)
14 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
filter("ERP"."ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",TO_NUMBER(:Z),TO_N
UMBER(:Z))<>0)
17 - access("ACC_DTL"."AD_FLAG"=7)
18 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
filter("ERP"."ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",TO_NUMBER(:Z),TO_N
UMBER(:Z))<>0)
21 - access("ACC_DTL"."AD_FLAG"=6)
22 - access("ACC_LEDGER"."LG_AD_ID"="ACC_DTL"."AD_ID")
filter("ERP"."ACC_BALANCE"("ACC_LEDGER"."LG_AD_ID",TO_NUMBER(:Z),TO_N
UMBER(:Z))<>0)
Note: rule based optimizationEdited by: HamidHelal on Oct 12, 2011 6:42 PMyes..
SELECT ALL ACC_LEDGER.LG_AD_ID, ACC_DTL.AD_NAME, abs(ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ) )BAL,
CASE WHEN ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ)>0 AND ACC_DTL.AD_FLAG IN(6 ,18) THEN
'RECEIVABLE'
WHEN ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ)<0 AND ACC_DTL.AD_FLAG IN(6,18) THEN
'PAYABLE'
WHEN ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ)>0 AND ACC_DTL.AD_FLAG IN(7,8,19) THEN
'PAYABLE'
WHEN ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ)<0 AND ACC_DTL.AD_FLAG IN(7,8,19) THEN
'RECEIVABLE'
END AS BALANCE_TYPE,
ACC_DTL.AD_CODE, ACC_DTL.AD_FLAG
FROM ACC_DTL, ACC_LEDGER
WHERE ACC_DTL.AD_FLAG IN (6, 7, 8,18,19)
AND (ACC_LEDGER.LG_AD_ID = ACC_DTL.AD_ID)
AND ACC_BALANCE(ACC_LEDGER.LG_AD_ID, :UNIT, :PROJ)<>0
GROUP BY ACC_LEDGER.LG_AD_ID, ACC_DTL.AD_NAME, ACC_DTL.AD_CODE, ACC_DTL.AD_FLAG
ORDER BY ACC_DTL.AD_FLAG , ACC_DTL.AD_NAME;here ACC_BALANCE is the database function name.. -
PERFORMANCE IMPROVEMENT for a DB view
Hi,
There is around 300000 entries with MDBS and we are having very slow access and low performance.
Following is the query.
ima61v internal table does have only single entry in a sample run.
SELECT wemng menge wepos elikz umrez
umren matnr werks lgort pstyp retpo
FROM mdbs
INTO (mdbs-wemng, mdbs-menge, mdbs-wepos, mdbs-elikz,
mdbs-umrez, mdbs-umren, mdbs-matnr, mdbs-werks,
mdbs-lgort, mdbs-pstyp, mdbs-retpo)
WHERE matnr EQ ima61v-matnr
AND werks EQ ima61v-werks
AND loekz EQ space
AND elikz EQ space
AND bstyp IN ('F', 'L').
The following is the ST05 analysis.
Executions - 1
Identical Duration - 0
Records - 0
Time/exec - 21,766,348
Rec/exec. - 0
AvgTime/R. - 21,766,348
MinTime/R. - 21,766,348
Obj. type - MDBS
The SQL explain is as follows.
SELECT STATEMENT ( Estimated Costs = 7 , Estimated #Rows = 1 )
6 TABLE ACCESS BY INDEX ROWID EKET
( Estim. Costs = 3 , Estim. #Rows = 1 )
5 NESTED LOOPS
( Estim. Costs = 7 , Estim. #Rows = 1 )
3 INLIST ITERATOR
2 TABLE ACCESS BY INDEX ROWID EKPO
( Estim. Costs = 4 , Estim. #Rows = 1 )
1 INDEX RANGE SCAN EKPO~1
( Estim. Costs = 3 , Estim. #Rows = 1 )
Search Columns: 6
4 INDEX RANGE SCAN EKET~0
( Estim. Costs = 2 , Estim. #Rows = 1 )
Search Columns: 3
1.The tables are not going for full scan.
2. DB stats are up to date.
3. All indexes show in SQL explain are available at DB
Apart from all these what else we can check to identify what is the problem? if we change the variant for multiple mateirals and if we go for b/g execution it is taking more than 30 min to execute.
and also let me know how to resolve the issue.
Thanks in Advance.
Praneeth3 simple points:
I am quite sure that you did not run the statement before you did run the trace, please repeat and show the result of the second or third execution.
I guess that is the only point, the explain is so simple that it can no take very long.
And ... there is no record coming back .... I know that there are many executions where no record comes back, but is it really a good point for a discussion of a performance problem? Is this statement never successful?
Number of records:
The view has no records, you must check the two tables EKKE and EKPO, how many records are in these tables. -
Hi,
I have a Oracle 9.2 DB with 2 cpu's,when i took a statspack report i found that CPU Time is very hight i,e more that 81%....
one of the query is taking near about 51% CPU Usage...
i.e
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESCExplain Plan for......
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT |
PLAN_TABLE_OUTPUT
| 1 | 69 | 45 | | |
| 1 | SORT UNIQUE |
| 1 | 69 | 27 | | |
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL
| 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS |
| 1 | 69 | 9 | | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS |
| 1 | 57 | 7 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD
| 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN | OT_STUDENT_FEE_COL_HEAD_UK0
1 | 1 | | 4 | | |
| 7 | INLIST ITERATOR |
| | | | | |
PLAN_TABLE_OUTPUT
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE
| 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE
| 1 | | 1 | | |
| 10 | FILTER |
| | | | | |
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD
PLAN_TABLE_OUTPUT
| 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE
| 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE
| 34600 | | 1 | | |
PLAN_TABLE_OUTPUT
Note: cpu costing is off, PLAN_TABLE' is old version
21 rows selected.
SQL>Statspack report
DB Name DB Id Instance Inst Num Release Cluster Host
ai 1372079993 ai11 1 9.2.0.6.0 YES ai1
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 175 12-Dec-08 13:21:33 ####### .0
End Snap: 176 12-Dec-08 13:56:09 ####### .0
Elapsed: 34.60 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 3,264M Std Block Size: 8K
Shared Pool Size: 608M Log Buffer: 977K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 5,727.62 21,658.54
Logical reads: 16,484.89 62,336.32
Block changes: 32.49 122.88
Physical reads: 200.46 758.03
Physical writes: 5.08 19.23
User calls: 97.43 368.44
Parses: 11.66 44.11
Hard parses: 0.39 1.48
Sorts: 3.22 12.19
Logons: 0.02 0.06
Executes: 36.70 138.77
Transactions: 0.26
% Blocks changed per Read: 0.20 Recursive Call %: 28.65
Rollback per transaction %: 20.95 Rows per Sort: 131.16
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 98.79 In-memory Sort %: 99.99
Library Hit %: 98.92 Soft Parse %: 96.65
Execute to Parse %: 68.21 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 60.50 % Non-Parse CPU: 99.48
Shared Pool Statistics Begin End
Memory Usage %: 90.06 89.79
% SQL with executions>1: 72.46 72.46
% Memory for SQL w/exec>1: 69.42 69.51
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
CPU time 3,337 81.43
db file sequential read 60,550 300 7.32
global cache cr request 130,852 177 4.33
db file scattered read 72,915 101 2.46
db file parallel read 3,384 75 1.84
Cluster Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Global Cache Service - Workload Characteristics
Ave global cache get time (ms): 1.3
Ave global cache convert time (ms): 2.1
Ave build time for CR block (ms): 0.1
Ave flush time for CR block (ms): 0.3
Ave send time for CR block (ms): 0.3
Ave time to process CR block request (ms): 0.7
Ave receive time for CR block (ms): 4.9
Ave pin time for current block (ms): 0.0
Ave flush time for current block (ms): 0.0
Ave send time for current block (ms): 0.3
Ave time to process current block request (ms): 0.3
Ave receive time for current block (ms): 2.8
Global cache hit ratio: 1.5
Ratio of current block defers: 0.0
% of messages sent for buffer gets: 1.4
% of remote buffer gets: 0.1
Ratio of I/O for coherence: 1.1
Ratio of local vs remote work: 9.7
Ratio of fusion vs physical writes: 0.1
Global Enqueue Service Statistics
Ave global lock get time (ms): 0.8
Ave global lock convert time (ms): 0.0
Ratio of global lock gets vs global lock releases: 1.1
GCS and GES Messaging statistics
Ave message sent queue time (ms): 0.4
Ave message sent queue time on ksxp (ms): 2.7
Ave message received queue time (ms): 0.2
Ave GCS message process time (ms): 0.1
Ave GES message process time (ms): 0.1
% of direct sent messages: 19.4
% of indirect sent messages: 43.5
% of flow controlled messages: 37.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
dynamically allocated gcs resourc 0 0.0 0.0
dynamically allocated gcs shadows 0 0.0 0.0
flow control messages received 0 0.0 0.0
flow control messages sent 0 0.0 0.0
gcs ast xid 0 0.0 0.0
gcs blocked converts 1,231 0.6 2.2
gcs blocked cr converts 2,432 1.2 4.4
gcs compatible basts 0 0.0 0.0
gcs compatible cr basts (global) 658 0.3 1.2
gcs compatible cr basts (local) 57,822 27.9 105.3
gcs cr basts to PIs 0 0.0 0.0
gcs cr serve without current lock 0 0.0 0.0
gcs error msgs 0 0.0 0.0
gcs flush pi msgs 821 0.4 1.5
gcs forward cr to pinged instance 0 0.0 0.0
gcs immediate (compatible) conver 448 0.2 0.8
gcs immediate (null) converts 1,114 0.5 2.0
gcs immediate cr (compatible) con 42,094 20.3 76.7
gcs immediate cr (null) converts 396,284 190.9 721.8
gcs msgs process time(ms) 42,220 20.3 76.9
gcs msgs received 545,133 262.6 993.0
gcs out-of-order msgs 5 0.0 0.0
gcs pings refused 1 0.0 0.0
gcs queued converts 0 0.0 0.0
gcs recovery claim msgs 0 0.0 0.0
gcs refuse xid 0 0.0 0.0
gcs retry convert request 0 0.0 0.0
gcs side channel msgs actual 2,397 1.2 4.4
gcs side channel msgs logical 232,024 111.8 422.6
gcs write notification msgs 15 0.0 0.0
gcs write request msgs 278 0.1 0.5
gcs writes refused 1 0.0 0.0
ges msgs process time(ms) 4,873 2.3 8.9
ges msgs received 39,769 19.2 72.4
global posts dropped 0 0.0 0.0
global posts queue time 0 0.0 0.0
global posts queued 0 0.0 0.0
global posts requested 0 0.0 0.0
global posts sent 0 0.0 0.0
implicit batch messages received 39,098 18.8 71.2
implicit batch messages sent 33,386 16.1 60.8
lmd msg send time(ms) 635 0.3 1.2
lms(s) msg send time(ms) 2 0.0 0.0
messages flow controlled 196,546 94.7 358.0
messages received actual 182,783 88.0 332.9
messages received logical 584,848 281.7 1,065.3
messages sent directly 102,657 49.4 187.0
messages sent indirectly 230,329 110.9 419.5
msgs causing lmd to send msgs 9,169 4.4 16.7
msgs causing lms(s) to send msgs 3,347 1.6 6.1
msgs received queue time (ms) 142,759 68.8 260.0
msgs received queued 584,818 281.7 1,065.2
msgs sent queue time (ms) 99,300 47.8 180.9
msgs sent queue time on ksxp (ms) 608,239 293.0 1,107.9
msgs sent queued 230,391 111.0 419.7
msgs sent queued on ksxp 229,013 110.3 417.1
GES Statistics for DB: ai Instance: ai11 Snaps: 175 -176
Statistic Total per Second per Trans
process batch messages received 65,059 31.3 118.5
process batch messages sent 50,959 24.5 92.8
Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
db file sequential read 60,550 0 300 5 110.3
global cache cr request 130,852 106 177 1 238.3
db file scattered read 72,915 0 101 1 132.8
db file parallel read 3,384 0 75 22 6.2
latch free 7,253 1,587 52 7 13.2
enqueue 44,947 0 16 0 81.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
global cache open x 1,134 3 4 4 2.1
CGS wait for IPC msg 166,993 164,390 4 0 304.2
library cache lock 3,169 0 3 1 5.8
log file sync 494 0 3 5 0.9
row cache lock 702 0 3 4 1.3
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,785 0 2 1 5.1
wait for master scn 687 0 2 2 1.3
global cache null to x 699 0 2 2 1.3
global cache s to x 778 5 1 2 1.4
direct path write 148 0 0 3 0.3
SQL*Net more data to client 3,621 0 0 0 6.6
global cache open s 149 0 0 2 0.3
library cache pin 78 0 0 2 0.1
ksxr poll remote instances 3,536 2,422 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
buffer busy waits 23 0 0 5 0.0
direct path read 9 0 0 10 0.0
buffer busy global CR 5 0 0 17 0.0
SQL*Net break/reset to clien 172 0 0 0 0.3
global cache quiesce wait 4 1 0 7 0.0
KJC: Wait for msg sends to c 86 0 0 0 0.2
BFILE get length 67 0 0 0 0.1
global cache null to s 9 0 0 1 0.0
BFILE open 6 0 0 0 0.0
BFILE read 60 0 0 0 0.1
BFILE internal seek 60 0 0 0 0.1
BFILE closure 6 0 0 0 0.0
cr request retry 4 4 0 0 0.0
SQL*Net message from client 201,907 0 180,583 894 367.8
gcs remote message 171,236 43,749 3,975 23 311.9
ges remote message 79,324 40,722 2,017 25 144.5
SQL*Net more data from clien 447 0 9 21 0.8
SQL*Net message to client 201,901 0 0 0 367.8
Background Wait Events for DB: ai Instance: ai11 Snaps: 175 -176
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
enqueue 44,666 0 16 0 81.4
latch free 4,895 108 6 1 8.9
log file parallel write 2,140 0 6 3 3.9
db file parallel write 341 0 5 14 0.6
CGS wait for IPC msg 166,969 164,366 4 0 304.1
DFS lock handle 6,900 0 2 0 12.6
control file parallel write 689 0 2 3 1.3
control file sequential read 2,733 0 2 1 5.0
wait for master scn 687 0 2 2 1.3
ksxr poll remote instances 3,528 2,419 0 0 6.4
LGWR wait for redo copy 12 6 0 9 0.0
db file sequential read 7 0 0 9 0.0
global cache null to x 26 0 0 2 0.0
global cache open x 16 0 0 1 0.0
global cache cr request 1 0 0 0 0.0
rdbms ipc message 28,636 20,600 16,937 591 52.2
gcs remote message 171,254 43,746 3,974 23 311.9
pmon timer 708 686 2,022 2856 1.3
ges remote message 79,305 40,719 2,017 25 144.5
smon timer 125 0 1,972 15776 0.2
SQL ordered by Gets for DB: ai Instance: ai11 Snaps: 175 -176
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
17,503,305 84 208,372.7 51.1 676.25 1218.80 17574787
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COU
RSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT
FEECOL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND SFCD_FE
E_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2',
'CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAuser00726 wrote:
somw of the changes that have been done....
cai11_lmd0_15771.trc.
Thu Oct 2 13:35:48 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 13:35:50 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 14:04:34 2008
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET sga_max_size='5244772679680' SCOPE=SPFILE SID='*';
Thu Oct 2 15:24:14 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:24:20 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:32:33 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 2512 MB, Target size = 3072 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 15:32:34 2008
ALTER SYSTEM SET db_cache_size='3072M' SCOPE=BOTH SID='icai11';
Thu Oct 2 15:36:46 2008
ALTER SYSTEM SET shared_pool_size='640M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:33:52 2008
CKPT: Begin resize of buffer pool 3 (DEFAULT for block size 8192)
CKPT: Current size = 3072 MB, Target size = 2512 MB
CKPT: Resize completed for buffer pool DEFAULT for blocksize 8192
Thu Oct 2 16:33:56 2008
ALTER SYSTEM SET db_cache_size='2512M' SCOPE=BOTH SID='icai11';
Thu Oct 2 16:39:30 2008
ALTER SYSTEM SET pga_aggregate_target='750M' SCOPE=BOTH SID='icai11';Just to make certain that I am not missing anything, if the above you set (all scaled to GB just for the sake of comparison):
sga_max_size=4885GB
db_cache_size=3GB
shared_pool_size=0.625GB
pga_aggregate_target=0.733GB
The SQL statement is forcing the use of a specific index, is this the best index?:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */DISTINCT CF_COURSE_CODE FROM OM_COURSE_FEE,OT_STUDENT_FEE_COL_HEAD,OT_STUDENT_FEE_COL_DETL WHERE SFCH_SYS_ID = SFCD_SFCH_SYS_ID AND
SFCD_FEE_TYPE_CODE = CF_TYPE_CODE AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' ) AND SFCH_TXN_CODE = :b1 AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' ) AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL AND SFCH_NO = :b2 AND NOT EXISTS (SELECT 'X' FROM OM_STUDENT_HEAD WHERE STUD_SRN = SFCH_STUD_SRN_TEMP_NO AND NVL(STUD_CLO_STATUS,0) != 1 AND
NVL(STUD_REG_STATUS,0) != 23 AND STUD_COURSE_CODE != 'CCT' AND CF_COURSE_CODE= STUD_COURSE_CODE ) ORDER BY 1 DESC
Unfortunately, explain plans, even with dbms_xplan.display, may not show the actual execution plan - this is more of a problem when the SQL statement includes bind variables (capturing a 10046 trace at level 8 or 12 will help). With the information provided, it looks like the problem is with the number of logical reads performed: 17,503,305 in 84 executions = 208,373 logical reads per execution. Something is causing the SQL statement to execute inefficiently, possibly a join problem between tables, possibly the forced use of an index.
From one of my previous posts related to this same SQL statement:
SELECT /*+ INDEX (OM_COURSE_FEE OCF_CFC_CODE) */ DISTINCT
CF_COURSE_CODE
FROM
OM_COURSE_FEE,
OT_STUDENT_FEE_COL_HEAD,
OT_STUDENT_FEE_COL_DETL
WHERE
SFCH_SYS_ID = SFCD_SFCH_SYS_ID
AND SFCD_FEE_TYPE_CODE = CF_TYPE_CODE
AND CF_COURSE_CODE IN ( 'PE1','PE2','CCT','CPT' )
AND SFCH_TXN_CODE = :b1
AND SFCD_SUBSCRBE_JOURNAL_YN IN ( 'T','R','1','C' )
AND SFCH_APPR_UID IS NOT NULL
AND SFCH_APPR_DT IS NOT NULL
AND SFCH_NO = :b2
AND NOT EXISTS (
SELECT
'X'
FROM
OM_STUDENT_HEAD
WHERE
STUD_SRN = SFCH_STUD_SRN_TEMP_NO
AND NVL(STUD_CLO_STATUS,0) != 1
AND NVL(STUD_REG_STATUS,0) != 23
AND STUD_COURSE_CODE != 'CCT'
AND CF_COURSE_CODE = STUD_COURSE_CODE)
ORDER BY
1 DESC
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT 1 69 34
| 1 | SORT UNIQUE 1 69 22
| 2 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_DETL | 1 | 12 | 2 | ROWID | ROW L |
| 3 | NESTED LOOPS 1 69 9
| 4 | NESTED LOOPS 1 57 7
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID | OT_STUDENT_FEE_COL_HEAD | 1 | 48 | 5 | ROWID | ROW L |
| 6 | INDEX SKIP SCAN OT_STUDENT_FEE_COL_HEAD_UK0| 1 | 1 | 4 |
| 7 | INLIST ITERATOR |
| 8 | TABLE ACCESS BY INDEX ROWID | OM_COURSE_FEE | 1 | 9 | 2 | | |
| 9 | INDEX RANGE SCAN | OCF_CFC_CODE | 1 | | 1 | | |
| 10 | FILTER
| 11 | TABLE ACCESS BY GLOBAL INDEX ROWID| OM_STUDENT_HEAD | 1 | 21 | 4 | ROWID | ROW L |
| 12 | INDEX RANGE SCAN | IDM_STUD_SRN_COURSE | 1 | | 3 | | |
| 13 | INDEX RANGE SCAN | IDM_SFCD_FEE_TYPE_CODE | 34600 | | 1 | | |It appears, based just on the SQL statement, that there is no direct relationship between OM_COURSE_FEE and OT_STUDENT_FEE_COL_HEAD, yet the plan above indicates that the two tables are being joined together, likely as a result of the index hint. There is the possibility of additional predicates being generated by Oracle which will make this possible without introducing a Cartesian join, but those predicates are not displayed with an explain plan (they will appear with a DBMS_XPLAN). I may not be remembering correctly, but if the optimizer goal is set to first rows, a Cartesian join might appear in a plan as a nested loops join - Jonathan will know for certain if that is the case.
Have you investigated the above as a possible cause? If you know that there is a problem with this one SQL statement, a 10046 trace at level 8 or 12 is much more helpful than a Statspack report.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Many-to-many Performance Problem (Using FAQ Template)
Having read "HOW TO: Post a SQL statement tuning request - template posting" I have gathered:
I have included some background information at the bottom of the post
The following SQL statement has been identified as performing poorly. It takes ~160 seconds to execute, but similar (shown below first statement) SQL statements executes in ~1 second.
SQL taking 160 seconds:
SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (7, 1);SQL taking ~1 second or less
ab.channel_fk IN (7);Or even:
ab.channel_fk IN (6, 9, 170, 89);The purpose of the SQL is to return rows from table_a that are associated with table_b (not in SQL) through the junction table table_a_b.
The version of the database is 10.2.0.4.0
These are the parameters relevant to the optimizer:
show parameter optimizer;
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
show parameter db_file_multi;
NAME TYPE VALUE
db_file_multiblock_read_count integer 16
show parameter db_block_size;
NAME TYPE VALUE
db_file_multiblock_read_count integer 16
select sname, pname, pval1, pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-18-2006 23:19
SYSSTATS_INFO DSTOP 07-25-2006 23:19
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN SREADTIM 5.918
SYSSTATS_MAIN MREADTIM 7.889
SYSSTATS_MAIN CPUSPEED 1383
SYSSTATS_MAIN MBRC 8
SYSSTATS_MAIN MAXTHR 1457152
SYSSTATS_MAIN SLAVETHR -1Here is the output of EXPLAIN PLAN:
PLAN_TABLE_OUTPUT
Plan hash value: 3781163428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1352K| 771M| | 60042 (3)| 00:05:56 |
|* 1 | HASH JOIN | | 1352K| 771M| 27M| 60042 (3)| 00:05:56 |
|* 2 | INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 | 1352K| 11M| | 1816 (4)| 00:00:11 |
| 3 | TABLE ACCESS FULL | TABLE_A | 2190K| 1230M| | 32357 (4)| 00:03:12 |
Predicate Information (identified by operation id):
1 - access(""AB"".""MEDIA_FK""=""A"".""ID"")
2 - filter(""AB"".""CHANNEL_FK""=1 OR ""AB"".""CHANNEL_FK""=7)
Note
- 'PLAN_TABLE' is old versionFor reference, the EXPLAIN PLAN when using
ab.channel_fk IN (6, 9, 170, 89);which executes in ~1 second is:
PLAN_TABLE_OUTPUT
Plan hash value: 794334170
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 143K| 81M| | 58982 (3)| 00:05:50 |
|* 1 | HASH JOIN | | 143K| 81M| 2952K| 58982 (3)| 00:05:50 |
| 2 | INLIST ITERATOR | | | | | | |
|* 3 | INDEX RANGE SCAN| C_M_INDEX | 143K| 1262K| | 1264 (1)| 00:00:08 |
| 4 | TABLE ACCESS FULL| TABLE_A | 2190K| 1230M| | 32357 (4)| 00:03:12 |
Predicate Information (identified by operation id):
1 - access(""AB"".""MEDIA_FK""=""A"".""ID"")
3 - access(""AB"".""CHANNEL_FK""=6 OR ""AB"".""CHANNEL_FK""=9 OR
""AB"".""CHANNEL_FK""=89 OR ""AB"".""CHANNEL_FK""=170)
Note
- 'PLAN_TABLE' is old versionHere is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 100;
SQL> SELECT
2 a.*
3 FROM
4 table_a a
5 INNER JOIN table_a_b ab ON a.id = ab.media_fk
6 WHERE
7 ab.channel_fk IN (7, 1);
1336148 rows selected.
Execution Plan
Plan hash value: 3781163428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1352K| 771M| | 60042 (3)| 00:05:56 |
|* 1 | HASH JOIN | | 1352K| 771M| 27M| 60042 (3)| 00:05:56 |
|* 2 | INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 | 1352K| 11M| | 1816 (4)| 00:00:11 |
| 3 | TABLE ACCESS FULL | TABLE_A | 2190K| 1230M| | 32357 (4)| 00:03:12 |
Predicate Information (identified by operation id):
1 - access("AB"."MEDIA_FK"="A"."ID")
2 - filter("AB"."CHANNEL_FK"=1 OR "AB"."CHANNEL_FK"=7)
Note
- 'PLAN_TABLE' is old version
Statistics
10586 recursive calls
0 db block gets
200457 consistent gets
408343 physical reads
0 redo size
498740848 bytes sent via SQL*Net to client
147371 bytes received via SQL*Net from client
13363 SQL*Net roundtrips to/from client
49 sorts (memory)
0 sorts (disk)
1336148 rows processedThe TKPROF output for this statement looks like the following:
TKPROF: Release 10.2.0.4.0 - Production on Mon Oct 1 12:23:21 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: ..._ora_4896.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
ALTER SYSTEM SET TIMED_STATISTICS = TRUE
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.03 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.03 0 0 0 0
Misses in library cache during parse: 0
Parsing user id: 21
SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (7, 1)
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 27.23 163.57 179906 198394 0 16
total 4 27.25 163.58 179906 198394 0 16
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 21
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.01 0.00 0 0 0 0
Execute 2 0.00 0.03 0 0 0 0
Fetch 2 27.23 163.57 179906 198394 0 16
total 6 27.25 163.62 179906 198394 0 16
Misses in library cache during parse: 1
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
2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
Trace file: ..._ora_4896.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
2 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
2 unique SQL statements in trace file.
46 lines in trace file.
187 elapsed seconds in trace file.The DBMS_XPLAN.DISPLAY_CURSOR output:
select * from table(dbms_xplan.display_cursor('474frsqbc1n4d', null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 474frsqbc1n4d, child number 0
SELECT /*+ gather_plan_statistics */ c.* FROM table_a c INNER JOIN table_a_b ab ON c.id = ab.media_fk WHERE ab.channel_fk IN (7, 1)
Plan hash value: 3781163428
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | Writes | OMem | 1Mem | Used-Mem |
|* 1 | HASH JOIN | | 1 | 1352K| 1050 |00:00:40.93 | 198K| 182K| 209K| 29M| 5266K| 3320K (1)|
|* 2 | INDEX FAST FULL SCAN| SYS_IOT_TOP_316310 | 1 | 1352K| 1336K|00:00:01.34 | 10874 | 0 | 0 | | | |
| 3 | TABLE ACCESS FULL | TABLE_A | 1 | 2190K| 2267K|00:02:45.56 | 187K| 182K| 0 | | | |
Predicate Information (identified by operation id):
1 - access(""AB"".""MEDIA_FK""=""C"".""ID"")
2 - filter((""AB"".""CHANNEL_FK""=1 OR ""AB"".""CHANNEL_FK""=7))Thank you for reading I'm looking forward for suggestions how to improve the performance of this statement.
h3. Backgroud
Many years ago my company made the decision to store many-to-many relationships in our database using pipe delimited fields. An example field value:
'|ABC|XYZ|VTR|DVD|'Each delimited value refers to a unique 'short code' in TABLE_B (There is also a true numeric foreign key in TABLE_B which is what I'm using in the junction table). We regularly search using these column with the following style SQL:
WHERE
INSTR(pipedcolumn, '|ABC|') > 0
OR INSTR(pipedcolumn, '|XYZ|' > 0
...Appropriate indexes have been created over the years to make this process as fast a possible.
We now have an opportunity to fix some of these design mistakes and implement junction tables to replace the piped field. Before this we decided to take a copy of a database from a customer with the largest record set and test. I created a new junction table:
TABLE_A_B DDL:
CREATE TABLE TABLE_A_B (
media_fk NUMBER,
channel_fk NUMBER,
PRIMARY KEY (media_fk, channel_fk),
FOREIGN KEY (media_fk) REFERENCES TABLE_A (ID),
FOREIGN KEY (channel_fk) REFERENCES TABLE_B (ID)
) ORGANIZATION INDEX COMPRESS;
CREATE INDEX C_M_INDEX ON TABLE_A_B (channel_fk, media_fk) COMPRESS;And parsing out a pipe delimited field, populated this new table.
I then compared the performance of the following SQL:
SELECT
a.*
FROM
table_a a
INNER JOIN table_a_b ab ON a.id = ab.media_fk
WHERE
ab.channel_fk IN (x, y, n); -- Can be Many Minutes
--vs.
SELECT
a.*
FROM
table_a a
WHERE
INSTR(OWNERS,'|x|') >0
OR INSTR(OWNERS,'|y|') >0
OR INSTR(OWNERS,'|n|') >0; -- About 1 second seemingly regardlessWhen x, y, n are values that occur less frequently in TABLE_A_B.CHANNEL_FK the performance is comparable. However once the frequency of x, y, n increases the performance suffers. Here is a summary of the CHANNEL_FK data in TABLE_A_B:
--SQL For Summary Data
SELECT channel_fk, count(channel_fk) FROM table_a_b GROUP BY channel_fk ORDER BY COUNT(channel_fk) DESC;
CHANNEL_FK COUNT(CHANNEL_FK)
7 780741
1 555407
2 422493
3 189493
169 144663
9 79457
6 53051
171 28401
170 19857
49 12603
...I've noticed that once I use any combination of values which occur more than about 800,000 times (i.e. IN (7, 1) = 780741 + 555407 = 1336148) then I get performance issues.
I'm finding it very difficult to accept that the old pipe delimited fields are a better solution (ignoring everything other than this search criteria!).
Thank you for reading this far. I truly look forward to suggestions on how to improve the performance of this statement.
Edited by: user1950227 on Oct 1, 2012 12:06 PM
Renamed link table in DDL.Possibly not, I followed the instructions as best as I could but may have missed things.
h5. 1. DDL for all tables and indexes?
h6. - TABLE_A_B is described above and has a total of 2,304,642 rows. TABLE_A and TABLE_B are described below.
h5. 2. row counts for all tables?
h6. - See below
h5. 3. row counts for the predicates involved?
h6. - Not sure what your asking for, I have a summary of data in TABLE_A_B above. Could you clarify please?
h5. 4. Method and command used to collect stats on the tables and indexes?
h6. - For the stats I collected above I have included the command used to collect the data. If you are asking for further data I am happy to provide it but need more information. Thanks.
TABLE_A has 2,267,980 rows. The DLL that follows has been abbriviated, only the column involved is described.
-- DDL for Table TABLE_A
CREATE TABLE "NS"."TABLE_A"
( "ID" NUMBER
--Lots more columns
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "CUSTOMNAMESPACE" ;
-- DDL for Index ID_PK
CREATE UNIQUE INDEX "NS"."MI_PK" ON "NS"."TABLE_A" ("ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 16384 NEXT 29458432 MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;
-- Constraints for Table TABLE_A
ALTER TABLE "NS"."TABLE_A" ADD CONSTRAINT "MI_PK" PRIMARY KEY ("ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 16384 NEXT 29458432 MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ENABLE;
ALTER TABLE "NS"."TABLE_A" MODIFY ("ID" NOT NULL ENABLE);TABLE_B has 22 rows. The DLL that follows has been abbriviated, only the column involved is described.
-- DDL for Table TABLE_B
CREATE TABLE "NS"."TABLE_B"
"ID" NUMBER
--Lots more columns
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "CUSTOMNAMESPACE" ;
-- DDL for Index CID_PK
CREATE UNIQUE INDEX "NS"."CID_PK" ON "NS"."TABLE_B" ("ID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 16384 NEXT 16384 MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ;
-- Constraints for Table TABLE_B
ALTER TABLE "NS"."TABLE_B" ADD CONSTRAINT "CID_PK" PRIMARY KEY ("ID")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 16384 NEXT 16384 MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM" ENABLE;
ALTER TABLE "NS"."TABLE_B" MODIFY ("ID" NOT NULL ENABLE);Edited by: davebcast on Oct 1, 2012 8:51 PM
Index name incorrect
Edited by: davebcast on Oct 1, 2012 8:52 PM -
Is there any way to tune this query? EXPLAIN PLAN included
DB version:10gR2
The below query was taking more than 3 seconds. The statistics are up to date for these tables. Is there any other way i could tune this query?
SELECT COUNT(1)
FROM
INVN_SCOPE_DTL, ship_dtl WHERE ship_dtl.WHSE = INVN_SCOPE_DTL.WHSE (+)
AND 'QC' = INVN_SCOPE_DTL.FROM_WORK_GRP (+)
AND 'MQN' = INVN_SCOPE_DTL.FROM_WORK_AREA (+)
AND ship_dtl.START_CURR_WORK_GRP = INVN_SCOPE_DTL.TO_WORK_GRP (+)
AND ship_dtl.START_CURR_WORK_AREA = INVN_SCOPE_DTL.TO_WORK_AREA (+)
AND ship_dtl.WHSE = '930' AND ship_dtl.OWNER_USER_ID = 'CTZDM'
OR ship_dtl.OWNER_USER_ID = '*'
AND ship_dtl.STAT_CODE >= '10'
AND ship_dtl.STAT_CODE <= '20'
ORDER BY ship_dtl.OWNER_USER_ID DESC,
ship_dtl.CURR_TASK_PRTY ASC, INVN_SCOPE_DTL.DISTANCE ASC, ship_dtl.RLS_DATE_TIME ASC, ship_dtl.TASK_ID ASC;
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 86 | 86 (2)|
| 1 | SORT AGGREGATE | | 1 | 86 | |
| 2 | NESTED LOOPS OUTER | | 898 | 77228 | 86 (2)|
| 3 | INLIST ITERATOR | | | | |
|* 4 | TABLE ACCESS BY INDEX ROWID| ship_dtl | 898 | 31430 | 85 (2)|
|* 5 | INDEX RANGE SCAN | ship_dtl_IND_4 | 2876 | | 1 (0)|
| 6 | TABLE ACCESS BY INDEX ROWID | INVN_SCOPE_DTL | 1 | 51 | 2 (50)|
PLAN_TABLE_OUTPUT
|* 7 | INDEX UNIQUE SCAN | PK_INVN_SCOPE_DTL | 1 | | |
Predicate Information (identified by operation id):
4 - filter("ship_dtl"."WHSE"='930' AND "ship_dtl"."STAT_CODE">=10 AND
"ship_dtl"."STAT_CODE"<=20)
5 - access("ship_dtl"."OWNER_USER_ID"='*' OR "ship_dtl"."OWNER_USER_ID"='CTZDM')
7 - access("INVN_SCOPE_DTL"."WHSE"(+)='930' AND
"INVN_SCOPE_DTL"."FROM_WORK_GRP"(+)='QC' AND "INVN_SCOPE_DTL"."FROM_WORK_AREA"(+)='MQN'
PLAN_TABLE_OUTPUT
AND "ship_dtl"."START_CURR_WORK_GRP"="INVN_SCOPE_DTL"."TO_WORK_GRP"(+) AND
"ship_dtl"."START_CURR_WORK_AREA"="INVN_SCOPE_DTL"."TO_WORK_AREA"(+))
filter("ship_dtl"."WHSE"="INVN_SCOPE_DTL"."WHSE"(+))
25 rows selected.William Robertson wrote:
I notice an OR predicate in the middle of some AND predicates without explicit bracketing. Are you sure it does what you think it does?I underline this point.
A conjuction (AND expression) has a higher priority and will be executed (logically) before the disjunction (OR expression)! So your select looks like this
SELECT COUNT(1)
FROM INVN_SCOPE_DTL, ship_dtl
WHERE
( ship_dtl.WHSE = INVN_SCOPE_DTL.WHSE (+)
AND 'QC' = INVN_SCOPE_DTL.FROM_WORK_GRP (+)
AND 'MQN' = INVN_SCOPE_DTL.FROM_WORK_AREA (+)
AND ship_dtl.START_CURR_WORK_GRP = INVN_SCOPE_DTL.TO_WORK_GRP (+)
AND ship_dtl.START_CURR_WORK_AREA = INVN_SCOPE_DTL.TO_WORK_AREA (+)
AND ship_dtl.WHSE = '930'
AND ship_dtl.OWNER_USER_ID = 'CTZDM'
OR ( ship_dtl.OWNER_USER_ID = '*'
AND ship_dtl.STAT_CODE >= '10'
AND ship_dtl.STAT_CODE <= '20'
;This might be want you want, but I doubt it very much. Please add parenthesis', to get it working the way it should be.
Edited by: Sven W. on Oct 16, 2008 3:25 PM -
Looking for your advise on this TKProf
Hello There,
I am looking for your advise on the following TKProf:
TKPROF: Release 11.1.0.7.0 - Production on Thu Apr 28 16:37:23 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: DCPRD_ora_9930_AIBRAHIM80.trc
Sort options: prsdsk exedsk fchdsk
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
The following statement encountered a error during parse:
SELECT ROWID,VENDOR_NAME,VENDOR_NUMBER,VENDOR_SITE_CODE,TERRITORY_SHORT_NAME,CONCATENATED_ADDRESS,LANGUAGE_DESCRIPTION,AREA_CODE,PHONE,COUNTRY,LANGUAGE,INVOICE_CURRENCY_CODE,VENDOR_ID,VENDOR_SITE_ID FROM AP_VENDOR_DISP_V WHERE (VENDOR_ID=:1) and (VENDOR_SITE_ID=:2)
Error encountered: ORA-01445
SQL ID: 5uz1ugat7bn9k
Plan Hash: 1624111731
SELECT COUNT( DECODE( POD.PREVENT_ENCUMBRANCE_FLAG , 'Y', NULL , DECODE(
POD.ENCUMBERED_FLAG , 'Y', 'Y' , NULL ) ) ) , COUNT( DECODE(
POD.PREVENT_ENCUMBRANCE_FLAG , 'Y', NULL , DECODE( POD.ENCUMBERED_FLAG ,
'Y', NULL , 'N' ) ) ) , COUNT( DECODE( POD.PREVENT_ENCUMBRANCE_FLAG , 'Y',
'Y' , NULL ) )
FROM
PO_DISTRIBUTIONS_ALL POD , PO_LINE_LOCATIONS_ALL POLL , PO_HEADERS_ALL POH
WHERE POLL.LINE_LOCATION_ID(+) = POD.LINE_LOCATION_ID AND POH.PO_HEADER_ID =
POD.PO_HEADER_ID AND ( (:B2 <> :B11 AND NVL(POLL.CANCEL_FLAG,'N') <> 'Y')
OR (:B2 = :B11 AND NVL(POH.CANCEL_FLAG,'N') <> 'Y') ) AND ( ( :B2 <> :B11
AND NVL(POLL.CLOSED_CODE,:B10 ) <> :B9 ) OR ( :B2 = :B11 AND
NVL(POH.CLOSED_CODE,:B10 ) <> :B9 ) ) AND ( ( :B5 = :B8 AND
POD.PO_DISTRIBUTION_ID = :B3 ) OR ( :B5 = :B7 AND POD.LINE_LOCATION_ID =
:B3 ) OR ( :B5 = :B6 AND POD.PO_LINE_ID = :B3 ) OR ( :B5 = :B4 AND :B2 =
:B1 AND POD.PO_RELEASE_ID = :B3 ) OR ( :B5 = :B4 AND :B2 <> :B1 AND
POD.PO_HEADER_ID = :B3 ) ) AND ( ( :B2 <> :B1 AND POD.PO_RELEASE_ID IS NULL
) OR ( :B2 = :B1 AND POD.PO_RELEASE_ID IS NOT NULL ) )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 114604 414.24 434.04 0 0 0 0
Fetch 114604 45.91 750.41 46028 2831063 0 114604
total 229209 460.15 1184.46 46028 2831063 0 114604
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 183 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 SORT AGGREGATE (cr=12 pr=9 pw=0 time=0 us)
1 1 1 CONCATENATION (cr=12 pr=9 pw=0 time=0 us)
1 1 1 FILTER (cr=12 pr=9 pw=0 time=0 us)
1 1 1 FILTER (cr=12 pr=9 pw=0 time=0 us)
1 1 1 NESTED LOOPS OUTER (cr=12 pr=9 pw=0 time=0 us cost=7 size=57 card=1)
1 1 1 NESTED LOOPS (cr=7 pr=4 pw=0 time=0 us cost=5 size=42 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID PO_DISTRIBUTIONS_ALL (cr=4 pr=4 pw=0 time=0 us cost=4 size=29 card=1)
1 1 1 INDEX RANGE SCAN PO_DISTRIBUTIONS_N11 (cr=3 pr=3 pw=0 time=0 us cost=3 size=0 card=5)(object id 45031)
1 1 1 TABLE ACCESS BY INDEX ROWID PO_HEADERS_ALL (cr=3 pr=0 pw=0 time=0 us cost=1 size=13 card=1)
1 1 1 INDEX UNIQUE SCAN PO_HEADERS_U1 (cr=2 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 45109)
1 1 1 TABLE ACCESS BY INDEX ROWID PO_LINE_LOCATIONS_ALL (cr=5 pr=5 pw=0 time=0 us cost=2 size=15 card=1)
1 1 1 INDEX UNIQUE SCAN PO_LINE_LOCATIONS_U1 (cr=3 pr=3 pw=0 time=0 us cost=1 size=0 card=1)(object id 45204)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=6 size=57 card=1)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=42 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_DISTRIBUTIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=3 size=29 card=1)
0 0 0 INDEX UNIQUE SCAN PO_DISTRIBUTIONS_U1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 45078)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_HEADERS_ALL (cr=0 pr=0 pw=0 time=0 us cost=1 size=477061 card=36697)
0 0 0 INDEX UNIQUE SCAN PO_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 45109)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_LINE_LOCATIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=2 size=11849205 card=789947)
0 0 0 INDEX UNIQUE SCAN PO_LINE_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 45204)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=7 size=57 card=1)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=5 size=42 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_DISTRIBUTIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=4 size=29 card=1)
0 0 0 INDEX RANGE SCAN PO_DISTRIBUTIONS_N1 (cr=0 pr=0 pw=0 time=0 us cost=3 size=0 card=1)(object id 45023)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_HEADERS_ALL (cr=0 pr=0 pw=0 time=0 us cost=1 size=13 card=1)
0 0 0 INDEX UNIQUE SCAN PO_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 45109)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_LINE_LOCATIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=2 size=15 card=1)
0 0 0 INDEX UNIQUE SCAN PO_LINE_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 45204)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=10 size=57 card=1)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=8 size=42 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_DISTRIBUTIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=7 size=29 card=1)
0 0 0 INDEX RANGE SCAN PO_DISTRIBUTIONS_N3 (cr=0 pr=0 pw=0 time=0 us cost=3 size=0 card=21)(object id 45049)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_HEADERS_ALL (cr=0 pr=0 pw=0 time=0 us cost=1 size=13 card=1)
0 0 0 INDEX UNIQUE SCAN PO_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 45109)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_LINE_LOCATIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=2 size=15 card=1)
0 0 0 INDEX UNIQUE SCAN PO_LINE_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 45204)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 0 0 NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=8 size=57 card=1)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=6 size=42 card=1)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_DISTRIBUTIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=5 size=29 card=1)
0 0 0 INDEX RANGE SCAN PO_DISTRIBUTIONS_N4 (cr=0 pr=0 pw=0 time=0 us cost=3 size=0 card=3)(object id 45054)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_HEADERS_ALL (cr=0 pr=0 pw=0 time=0 us cost=1 size=13 card=1)
0 0 0 INDEX UNIQUE SCAN PO_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 45109)
0 0 0 TABLE ACCESS BY INDEX ROWID PO_LINE_LOCATIONS_ALL (cr=0 pr=0 pw=0 time=0 us cost=2 size=15 card=1)
0 0 0 INDEX UNIQUE SCAN PO_LINE_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 45204)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 46028 1.12 712.45
SELECT ROW_ID,ORG_ID,PO_RELEASE_ID,PO_HEADER_ID,RELEASE_TYPE,AGENT_ID,VENDOR_ID,SHIP_TO_LOCATION_ID,SHIP_TO_LOCATION,SHIP_TO_ORGANIZATION_ID,VENDOR_SITE_ID,APPROVED_DATE,APPROVED_FLAG,AUTHORIZATION_STATUS,CANCEL_DATE,CANCEL_REASON,CANCELLED_BY,CANCEL_FLAG,HOLD_BY,HOLD_DATE,HOLD_REASON,HOLD_FLAG,CLOSED_CODE,FROZEN_FLAG,PRINT_COUNT,PRINTED_DATE,CREATED_BY,CREATION_DATE,LAST_UPDATED_BY,LAST_UPDATE_DATE,LAST_UPDATE_LOGIN,PROGRAM_APPLICATION_ID,PROGRAM_ID,PROGRAM_UPDATE_DATE,REQUEST_ID,ATTRIBUTE2,ATTRIBUTE3,ATTRIBUTE4,ATTRIBUTE1,ATTRIBUTE5,ATTRIBUTE6,ATTRIBUTE7,ATTRIBUTE8,ATTRIBUTE9,ATTRIBUTE10,ATTRIBUTE11,ATTRIBUTE12,ATTRIBUTE13,ATTRIBUTE15,ATTRIBUTE14,ATTRIBUTE_CATEGORY,PO_NUM,RELEASE_NUM,REVISION_NUM,RELEASE_REVISION_NUM,REVISED_DATE,RELEASE_DATE,VENDOR_NAME,VENDOR_SITE_CODE,CURRENCY_CODE,AGENT_NAME,STATUS,FIRM_STATUS_LOOKUP_CODE,ACCEPTANCE_REQUIRED_FLAG,ACCEPTANCE_DUE_DATE,PCARD_ID,GOVERNMENT_CONTEXT,AGREEMENT_TYPE,AMOUNT_LIMIT,MIN_RELEASE_AMOUNT,PRICE_UPDATE_TOLERANCE,AGREEMENT_BUYER,AGREEMENT_CONTACT,AGREEMENT_DESCRIPTION,NOTE_TO_SUPPLIER,NOTE_TO_RECEIVER,START_DATE,END_DATE,PAYMENT_TERMS,PAY_ON_CODE,SHIPPING_CONTROL,GLOBAL_ATTRIBUTE_CATEGORY,GLOBAL_ATTRIBUTE1,GLOBAL_ATTRIBUTE2,GLOBAL_ATTRIBUTE3,GLOBAL_ATTRIBUTE4,GLOBAL_ATTRIBUTE5,GLOBAL_ATTRIBUTE6,GLOBAL_ATTRIBUTE7,GLOBAL_ATTRIBUTE8,GLOBAL_ATTRIBUTE9,GLOBAL_ATTRIBUTE10,GLOBAL_ATTRIBUTE11,GLOBAL_ATTRIBUTE12,GLOBAL_ATTRIBUTE13,GLOBAL_ATTRIBUTE14,GLOBAL_ATTRIBUTE15,GLOBAL_ATTRIBUTE16,GLOBAL_ATTRIBUTE17,GLOBAL_ATTRIBUTE18,GLOBAL_ATTRIBUTE19,GLOBAL_ATTRIBUTE20,TYPE_LOOKUP_CODE,PO_AUTHORIZATION_STATUS,FOB_LOOKUP_CODE,FREIGHT_TERMS_LOOKUP_CODE FROM PO_RELEASES_V WHERE NVL(consigned_consumption_flag, 'N') <> 'Y' and ((authorization_status is null or authorization_status not in ('IN PROCESS', 'PRE-APPROVED' ))) and ((NOT(RELEASE_TYPE IN ('BLANKET', 'SCHEDULED')) OR (((PO_RELEASES_V.security_level_code = 'PUBLIC' ) OR (PO_RELEASES_V.security_level_code = 'PRIVATE' AND 183739=AGENT_ID) OR (PO_RELEASES_V.security_level_code = 'HIERARCHY' AND ((183739=AGENT_ID) OR (EXISTS (SELECT 'Y' FROM PO_ACTION_HISTORY POAH2 WHERE POAH2.employee_id =183739 AND POAH2.object_type_code = (DECODE(PO_RELEASES_V.DOCUMENT_TYPE, 'BLANKET', 'PA', 'STANDARD', 'PO' , 'PLANNED' , 'PO' , 'CONTRACT' , 'PA', 'RELEASE' , 'RELEASE' ) ) AND POAH2.object_id = PO_RELEASES_V.PO_RELEASE_ID)) OR (183739 IN (SELECT H.superior_id FROM PO_EMPLOYEE_HIERARCHIES H, PO_SYSTEM_PARAMETERS PSP WHERE H.employee_id = PO_RELEASES_V.AGENT_ID AND H.position_structure_id = NVL(PSP.SECURITY_POSITION_STRUCTURE_ID,-1) AND PSP.ORG_ID = PO_RELEASES_V.ORG_ID )))) OR (PO_RELEASES_V.security_level_code = 'PURCHASING' AND ((183739=AGENT_ID) OR (EXISTS (SELECT 'Y' FROM PO_ACTION_HISTORY POAH2 WHERE POAH2.employee_id =183739 AND POAH2.object_type_code = (DECODE(PO_RELEASES_V.DOCUMENT_TYPE, 'BLANKET', 'PA', 'STANDARD', 'PO' , 'PLANNED' , 'PO' , 'CONTRACT' , 'PA', 'RELEASE' , 'RELEASE' ) ) AND POAH2.object_id = PO_RELEASES_V.PO_RELEASE_ID)) OR (EXISTS(SELECT NULL FROM PO_AGENTS WHERE agent_id= 183739 AND SYSDATE BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE+1))))))AND (('MODIFY' = 'VIEW_ONLY' ) OR ( 'MODIFY' = 'MODIFY' AND PO_RELEASES_V.access_level_code IN ('MODIFY','FULL') ) OR ( 'MODIFY' = 'FULL' AND PO_RELEASES_V.access_level_code = 'FULL' ) OR ( 183739 = AGENT_ID))))) and (LAST_UPDATED_BY = last_updated_by
AND nvl(cancel_flag,'N') ='N'
AND nvl(closed_code,'OPEN') !='FINALLY CLOSED'
AND nvl(frozen_flag,'N') !='Y'
AND release_type IN ('BLANKET','SCHEDULED')
AND EXISTS (SELECT 'Header is not frozen'
FROM po_headers ph
WHERE ph.po_header_id = po_releases_v.po_header_id
AND NVL(ph.frozen_flag,'N') ='N'
AND nvl(ph.closed_code,'OPEN') !='FINALLY CLOSED')
AND ('' IS NULL
OR po_releases_v.authorization_status IN
(SELECT plc.lookup_code
FROM po_lookup_codes plc
WHERE plc.lookup_type = 'AUTHORIZATION STATUS'
AND plc.displayed_field LIKE ''))) order by po_num desc, release_num desc
call count cpu elapsed disk query current rows
Parse 1 168.61 160.43 288 4291 14 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 1 166.81 580.89 18452 2628283 0 2
total 3 335.43 741.33 18740 2632574 14 2
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 183
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 more data to client 3 0.00 0.00
db file sequential read 18452 0.88 417.79
SQL*Net message from client 1 0.00 0.00
SQL ID: 3ktacv9r56b51
Plan Hash: 458693102
select owner#,name,namespace,remoteowner,linkname,p_timestamp,p_obj#,
nvl(property,0),subname,type#,d_attrs
from
dependency$ d, obj$ o where d_obj#=:1 and p_obj#=obj#(+) order by order#
call count cpu elapsed disk query current rows
Parse 131 0.00 0.01 0 0 8 0
Execute 131 0.01 0.03 0 0 0 0
Fetch 1125 0.25 9.06 386 3632 0 994
total 1387 0.26 9.10 386 3632 8 994
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 3
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 7 20 SORT ORDER BY (cr=27 pr=4 pw=0 time=0 us cost=20 size=375 card=5)
1 7 20 NESTED LOOPS OUTER (cr=27 pr=4 pw=0 time=18 us cost=19 size=375 card=5)
1 7 20 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=4 pr=1 pw=0 time=2 us cost=4 size=155 card=5)
1 7 20 INDEX RANGE SCAN I_DEPENDENCY1 (cr=3 pr=0 pw=0 time=0 us cost=3 size=0 card=5)(object id 116)
1 7 20 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=23 pr=3 pw=0 time=0 us cost=3 size=44 card=1)
1 7 20 INDEX RANGE SCAN I_OBJ1 (cr=16 pr=2 pw=0 time=0 us cost=2 size=0 card=1)(object id 1288242)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 386 0.20 8.95
SQL ID: cvn54b7yz0s8u
Plan Hash: 2991757387
select /*+ index(idl_ub1$ i_idl_ub11) +*/ piece#,length,piece
from
idl_ub1$ where obj#=:1 and part=:2 and version=:3 order by piece#
call count cpu elapsed disk query current rows
Parse 165 0.00 0.00 0 0 8 0
Execute 165 0.08 0.06 0 0 0 0
Fetch 449 0.09 10.49 379 1740 0 410
total 779 0.17 10.56 379 1740 8 410
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 3
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 2 TABLE ACCESS BY INDEX ROWID IDL_UB1$ (cr=5 pr=1 pw=0 time=0 us cost=4 size=21 card=1)
1 1 2 INDEX RANGE SCAN I_IDL_UB11 (cr=4 pr=0 pw=0 time=3 us cost=3 size=0 card=1)(object id 110)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 379 0.22 10.44
********************************************************************************SQL ID: 8r75sj1fpjn1k
Plan Hash: 1052563856
SELECT PLC_STA.DISPLAYED_FIELD, DECODE(POR.CANCEL_FLAG, 'Y',
PLC_CAN.DISPLAYED_FIELD, NULL), DECODE(NVL(POR.CLOSED_CODE, 'OPEN'), 'OPEN',
NULL, PLC_CLO.DISPLAYED_FIELD), DECODE(POR.FROZEN_FLAG, 'Y',
PLC_FRO.DISPLAYED_FIELD, NULL), DECODE(POR.HOLD_FLAG, 'Y',
PLC_HLD.DISPLAYED_FIELD, NULL), POR.AUTHORIZATION_STATUS,
NVL(POR.CANCEL_FLAG, 'N'), NVL(POR.CLOSED_CODE, 'OPEN'),
NVL(POR.FROZEN_FLAG, 'N'), NVL(POR.HOLD_FLAG, 'N')
FROM
PO_RELEASES POR, PO_LOOKUP_CODES PLC_STA, PO_LOOKUP_CODES PLC_CAN,
PO_LOOKUP_CODES PLC_CLO, PO_LOOKUP_CODES PLC_FRO, PO_LOOKUP_CODES PLC_HLD
WHERE PLC_STA.LOOKUP_CODE = DECODE(POR.APPROVED_FLAG, 'R',
POR.APPROVED_FLAG, NVL(POR.AUTHORIZATION_STATUS,'INCOMPLETE')) AND
PLC_STA.LOOKUP_TYPE IN ('PO APPROVAL', 'DOCUMENT STATE') AND
PLC_CAN.LOOKUP_CODE = 'CANCELLED' AND PLC_CAN.LOOKUP_TYPE = 'DOCUMENT
STATE' AND PLC_CLO.LOOKUP_CODE = NVL(POR.CLOSED_CODE, 'OPEN') AND
PLC_CLO.LOOKUP_TYPE = 'DOCUMENT STATE' AND PLC_FRO.LOOKUP_CODE = 'FROZEN'
AND PLC_FRO.LOOKUP_TYPE = 'DOCUMENT STATE' AND PLC_HLD.LOOKUP_CODE = 'ON
HOLD' AND PLC_HLD.LOOKUP_TYPE = 'DOCUMENT STATE' AND POR.PO_RELEASE_ID =
:B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 114597 37.02 40.60 0 0 0 0
Fetch 114597 64.11 68.70 239 2988322 0 114597
total 229195 101.13 109.30 239 2988322 0 114597
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 183 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 NESTED LOOPS (cr=27 pr=6 pw=0 time=0 us)
1 1 1 NESTED LOOPS (cr=26 pr=5 pw=0 time=0 us cost=18 size=323 card=1)
1 1 1 MERGE JOIN CARTESIAN (cr=20 pr=4 pw=0 time=0 us cost=14 size=265 card=1)
1 1 1 MERGE JOIN CARTESIAN (cr=16 pr=4 pw=0 time=0 us cost=11 size=207 card=1)
1 1 1 MERGE JOIN CARTESIAN (cr=12 pr=4 pw=0 time=0 us cost=8 size=149 card=1)
1 1 1 NESTED LOOPS (cr=8 pr=4 pw=0 time=0 us cost=5 size=91 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID PO_RELEASES_ALL (cr=4 pr=2 pw=0 time=0 us cost=2 size=33 card=1)
1 1 1 INDEX UNIQUE SCAN PO_RELEASES_U1 (cr=2 pr=2 pw=0 time=0 us cost=1 size=0 card=1)(object id 45219)
1 1 1 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=4 pr=2 pw=0 time=0 us cost=3 size=58 card=1)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=0 us cost=2 size=0 card=1)(object id 33540)
1 1 1 BUFFER SORT (cr=4 pr=0 pw=0 time=0 us cost=5 size=58 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=4 pr=0 pw=0 time=0 us cost=3 size=58 card=1)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 33540)
1 1 1 BUFFER SORT (cr=4 pr=0 pw=0 time=0 us cost=8 size=58 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=4 pr=0 pw=0 time=0 us cost=3 size=58 card=1)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 33540)
1 1 1 BUFFER SORT (cr=4 pr=0 pw=0 time=0 us cost=11 size=58 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=4 pr=0 pw=0 time=0 us cost=3 size=58 card=1)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 33540)
1 1 1 INLIST ITERATOR (cr=6 pr=1 pw=0 time=0 us)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=6 pr=1 pw=0 time=0 us cost=3 size=0 card=1)(object id 33540)
1 1 1 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=1 pr=1 pw=0 time=0 us cost=4 size=58 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 239 0.23 4.54
SQL ID: 7ng34ruy5awxq
Plan Hash: 3984801583
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags,i.property,
i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey,i.lblkkey,
i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#,
nvl(i.degree,1),nvl(i.instances,1),i.rowcnt,mod(i.pctthres$,256),
i.indmethod#,i.trunccnt,nvl(c.unicols,0),nvl(c.deferrable#+c.valid#,0),
nvl(i.spare1,i.intcols),i.spare4,i.spare2,i.spare6,decode(i.pctthres$,null,
null,mod(trunc(i.pctthres$/256),256)),ist.cachedblk,ist.cachehit,
ist.logicalread
from
ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols,
min(to_number(bitand(defer,1))) deferrable#,min(to_number(bitand(defer,4)))
valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where
i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#
call count cpu elapsed disk query current rows
Parse 24 0.01 0.00 0 0 4 0
Execute 80 0.03 0.04 0 0 0 0
Fetch 470 0.27 6.55 197 882 0 390
total 574 0.31 6.60 197 882 4 390
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 24
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 5 18 SORT ORDER BY (cr=11 pr=3 pw=0 time=0 us cost=8 size=376 card=2)
1 5 18 HASH JOIN OUTER (cr=11 pr=3 pw=0 time=2 us cost=7 size=376 card=2)
1 5 18 NESTED LOOPS OUTER (cr=7 pr=2 pw=0 time=7560 us cost=3 size=290 card=2)
1 5 18 TABLE ACCESS CLUSTER IND$ (cr=6 pr=2 pw=0 time=7555 us cost=3 size=186 card=2)
1 1 1 INDEX UNIQUE SCAN I_OBJ# (cr=2 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 3)
0 0 0 TABLE ACCESS BY INDEX ROWID IND_STATS$ (cr=1 pr=0 pw=0 time=0 us cost=0 size=52 card=1)
0 0 0 INDEX UNIQUE SCAN I_IND_STATS$_OBJ# (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 647660)
0 0 0 VIEW (cr=4 pr=1 pw=0 time=0 us cost=3 size=43 card=1)
0 0 0 SORT GROUP BY (cr=4 pr=1 pw=0 time=0 us cost=3 size=16 card=1)
0 0 0 TABLE ACCESS CLUSTER CDEF$ (cr=4 pr=1 pw=0 time=0 us cost=2 size=16 card=1)
1 1 1 INDEX UNIQUE SCAN I_COBJ# (cr=2 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 27)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 197 0.35 6.34
SQL ID: 96g93hntrzjtr
Plan Hash: 841937906
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
call count cpu elapsed disk query current rows
Parse 38 0.01 0.00 0 0 2 0
Execute 663 0.28 0.24 0 0 0 0
Fetch 663 0.05 4.84 150 2731 0 656
total 1364 0.34 5.09 150 2731 2 656
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 38
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=4 pr=1 pw=0 time=0 us)
1 1 1 INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=3 pr=0 pw=0 time=0 us)(object id 194)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 150 0.28 4.80
SQL ID: ga9j9xk5cy9s0
Plan Hash: 467424113
select /*+ index(idl_sb4$ i_idl_sb41) +*/ piece#,length,piece
from
idl_sb4$ where obj#=:1 and part=:2 and version=:3 order by piece#
call count cpu elapsed disk query current rows
Parse 165 0.00 0.01 0 0 8 0
Execute 165 0.05 0.07 0 0 0 0
Fetch 369 0.11 3.79 141 1107 0 204
total 699 0.16 3.88 141 1107 8 204
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 3
Rows (1st) Rows (avg) Rows (max) Row Source Operation
2 2 2 TABLE ACCESS BY INDEX ROWID IDL_SB4$ (cr=6 pr=0 pw=0 time=0 us cost=4 size=19 card=1)
2 2 2 INDEX RANGE SCAN I_IDL_SB41 (cr=5 pr=0 pw=0 time=9 us cost=3 size=0 card=1)(object id 113)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 141 0.20 3.75
SQL ID: 39m4sx9k63ba2
Plan Hash: 2769382227
select /*+ index(idl_ub2$ i_idl_ub21) +*/ piece#,length,piece
from
idl_ub2$ where obj#=:1 and part=:2 and version=:3 order by piece#
call count cpu elapsed disk query current rows
Parse 165 0.03 0.01 0 0 8 0
Execute 165 0.05 0.06 0 0 0 0
Fetch 219 0.03 3.08 114 759 0 93
total 549 0.11 3.16 114 759 8 93
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Number of plan statistics captured: 3
Rows (1st) Rows (avg) Rows (max) Row Source Operation
2 1 2 TABLE ACCESS BY INDEX ROWID IDL_UB2$ (cr=5 pr=1 pw=0 time=0 us cost=4 size=20 card=1)
2 1 2 INDEX RANGE SCAN I_IDL_UB21 (cr=4 pr=0 pw=0 time=9 us cost=3 size=0 card=1)(object id 112)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 114 0.13 3.06
SQL ID: 8swypbbr0m372
Plan Hash: 872636971
select order#,columns,types
from
access$ where d_obj#=:1
call count cpu elapsed disk query current rows
Parse 131 0.00 0.01 0 0 8 0
Execute 131 0.02 0.02 0 0 0 0
Fetch 1017 0.05 2.77 113 2170 0 886
total 1279 0.07 2.81 113 2170 8 886
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 2)
Number of plan statistics captured: 3
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0 4 12 TABLE ACCESS BY INDEX ROWID ACCESS$ (cr=11 pr=1 pw=0 time=0 us cost=4 size=200 card=8)
0 4 12 INDEX RANGE SCAN I_ACCESS1 (cr=7 pr=0 pw=0 time=3 us cost=3 size=0 card=8)(object id 118)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 113 0.14 2.74
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 100 168.74 160.81 295 4538 40 0
Execute 119 3.39 3.38 2 43 0 12
Fetch 107 166.95 583.44 18545 2628759 0 364
total 326 339.08 747.64 18842 2633340 40 376
Misses in library cache during parse: 30
Misses in library cache during execute: 11
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 221 0.00 0.00
SQL*Net message from client 221 100.05 191.50
db file sequential read 18558 0.88 420.50
log file sync 2 0.01 0.01
SQL*Net more data to client 52 0.00 0.00
SQL*Net more data from client 9 0.03 0.03
SQL*Net break/reset to client 2 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2161 0.50 0.48 0 0 282 0
Execute 349226 639.57 671.70 7 86 74 9
Fetch 365281 113.87 886.34 48788 5852890 0 362441
total 716668 753.94 1558.53 48795 5852976 356 362450
Misses in library cache during parse: 119
Misses in library cache during execute: 136
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 48795 1.12 781.12
latch: row cache objects 1 0.00 0.00
344378 user SQL statements in session.
4837 internal SQL statements in session.
349215 SQL statements in session.
Trace file: DCPRD_ora_9930_AIBRAHIM80.trc
Trace file compatibility: 11.1.0.7
Sort options: prsdsk exedsk fchdsk
1 session in tracefile.
344378 user SQL statements in trace file.
4837 internal SQL statements in trace file.
349215 SQL statements in trace file.
196 unique SQL statements in trace file.
32265404 lines in trace file.
2505 elapsed seconds in trace file.
Regards,
Tareq -
Query Performance Tuning - Help
Hello Experts,
Good Day to all...
TEST@ora10g>select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE 10.2.0.4.0 Production"
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
SELECT fa.user_id,
fa.notation_type,
MAX(fa.created_date) maxDate,
COUNT(*) bk_count
FROM book_notations fa
WHERE fa.user_id IN
( SELECT user_id
FROM
( SELECT /*+ INDEX(f2,FBK_AN_ID_IDX) */ f2.user_id,
MAX(f2.notatn_id) f2_annotation_id
FROM book_notations f2,
title_relation tdpr
WHERE f2.user_id IN ('100002616221644',
'100002616221645',
'100002616221646',
'100002616221647',
'100002616221648')
AND f2.pack_id=tdpr.pack_id
AND tdpr.title_id =93402
GROUP BY f2.user_id
ORDER BY 2 DESC)
WHERE ROWNUM <= 10)
GROUP BY fa.user_id,
fa.notation_type
ORDER BY 3 DESC;Cost of the Query is too much...
Below is the explain plan of the query
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 29 | 1305 | 52 (10)| 00:00:01 |
| 1 | SORT ORDER BY | | 29 | 1305 | 52 (10)| 00:00:01 |
| 2 | HASH GROUP BY | | 29 | 1305 | 52 (10)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | book_notations | 11 | 319 | 4 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 53 | 2385 | 50 (6)| 00:00:01 |
| 5 | VIEW | VW_NSO_1 | 5 | 80 | 29 (7)| 00:00:01 |
| 6 | HASH UNIQUE | | 5 | 80 | | |
|* 7 | COUNT STOPKEY | | | | | |
| 8 | VIEW | | 5 | 80 | 29 (7)| 00:00:01 |
|* 9 | SORT ORDER BY STOPKEY | | 5 | 180 | 29 (7)| 00:00:01 |
| 10 | HASH GROUP BY | | 5 | 180 | 29 (7)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | book_notations | 5356 | 135K| 26 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 6917 | 243K| 27 (0)| 00:00:01 |
| 13 | MAT_VIEW ACCESS BY INDEX ROWID| title_relation | 1 | 10 | 1 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IDX_TITLE_ID | 1 | | 1 (0)| 00:00:01 |
| 15 | INLIST ITERATOR | | | | | |
|* 16 | INDEX RANGE SCAN | FBK_AN_ID_IDX | 5356 | | 4 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | FBK_AN_ID_IDX | 746 | | 1 (0)| 00:00:01 |
Table Details
SELECT COUNT(*) FROM book_notations; --111367
Columns
user_id -- nullable field - VARCHAR2(50 BYTE)
pack_id -- NOT NULL --NUMBER
notation_type-- VARCHAR2(50 BYTE) -- nullable field
CREATED_DATE - DATE -- nullable field
notatn_id - VARCHAR2(50 BYTE) -- nullable field
Index
FBK_AN_ID_IDX - Non unique - Composite columns --> (user_id and pack_id)
SELECT COUNT(*) FROM title_relation; --12678
Columns
pack_id - not null - number(38) - PK
title_id - not null - number(38)
Index
IDX_TITLE_ID - Non Unique - TITLE_ID
Please help...
Thanks...Linus wrote:
Thanks Bravid for your reply; highly appreciate that.
So as you say; index creation on the NULL column doesnt have any impact. OK fine.
What happens to the execution plan, performance and the stats when you remove the index hint?
Find below the Execution Plan and Predicate information
"PLAN_TABLE_OUTPUT"
"Plan hash value: 126058086"
"| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |"
"| 0 | SELECT STATEMENT | | 25 | 1125 | 55 (11)| 00:00:01 |"
"| 1 | SORT ORDER BY | | 25 | 1125 | 55 (11)| 00:00:01 |"
"| 2 | HASH GROUP BY | | 25 | 1125 | 55 (11)| 00:00:01 |"
"| 3 | TABLE ACCESS BY INDEX ROWID | book_notations | 10 | 290 | 4 (0)| 00:00:01 |"
"| 4 | NESTED LOOPS | | 50 | 2250 | 53 (8)| 00:00:01 |"
"| 5 | VIEW | VW_NSO_1 | 5 | 80 | 32 (10)| 00:00:01 |"
"| 6 | HASH UNIQUE | | 5 | 80 | | |"
"|* 7 | COUNT STOPKEY | | | | | |"
"| 8 | VIEW | | 5 | 80 | 32 (10)| 00:00:01 |"
"|* 9 | SORT ORDER BY STOPKEY | | 5 | 180 | 32 (10)| 00:00:01 |"
"| 10 | HASH GROUP BY | | 5 | 180 | 32 (10)| 00:00:01 |"
"| 11 | TABLE ACCESS BY INDEX ROWID | book_notations | 5875 | 149K| 28 (0)| 00:00:01 |"
"| 12 | NESTED LOOPS | | 7587 | 266K| 29 (0)| 00:00:01 |"
"| 13 | MAT_VIEW ACCESS BY INDEX ROWID| title_relation | 1 | 10 | 1 (0)| 00:00:01 |"
"|* 14 | INDEX RANGE SCAN | IDX_TITLE_ID | 1 | | 1 (0)| 00:00:01 |"
"| 15 | INLIST ITERATOR | | | | | |"
"|* 16 | INDEX RANGE SCAN | FBK_AN_ID_IDX | 5875 | | 4 (0)| 00:00:01 |"
"|* 17 | INDEX RANGE SCAN | FBK_AN_ID_IDX | 775 | | 1 (0)| 00:00:01 |"
"Predicate Information (identified by operation id):"
" 7 - filter(ROWNUM<=10)"
" 9 - filter(ROWNUM<=10)"
" 14 - access(""TDPR"".""TITLE_ID""=93402)"
" 16 - access((""F2"".""USER_ID""='100002616221644' OR ""F2"".""USER_ID""='100002616221645' OR "
" ""F2"".""USER_ID""='100002616221646' OR ""F2"".""USER_ID""='100002616221647' OR "
" ""F2"".""USER_ID""='100002616221648') AND ""F2"".""PACK_ID""=""TDPR"".""PACK_ID"")"
" 17 - access(""FA"".""USER_ID""=""$nso_col_1"")"
The cost is the same because the plan is the same. The optimiser chose to use that index anyway. The point is, now that you have removed it, the optimiser is free to choose other indexes or a full table scan if it wants to.
>
Statistics
BEGIN
DBMS_STATS.GATHER_TABLE_STATS ('TEST', 'BOOK_NOTATIONS');
END;
"COLUMN_NAME" "NUM_DISTINCT" "NUM_BUCKETS" "HISTOGRAM"
"NOTATION_ID" 110269 1 "NONE"
"USER_ID" 213 212 "FREQUENCY"
"PACK_ID" 20 20 "FREQUENCY"
"NOTATION_TYPE" 8 8 "FREQUENCY"
"CREATED_DATE" 87 87 "FREQUENCY"
"CREATED_BY" 1 1 "NONE"
"UPDATED_DATE" 2 1 "NONE"
"UPDATED_BY" 2 1 "NONE"
After removing the hint ; the query still shows the same "COST"
Autotrace
recursive calls 1
db block gets 0
consistent gets 34706
physical reads 0
redo size 0
bytes sent via SQL*Net to client 964
bytes received via SQL*Net from client 1638
SQL*Net roundtrips to/from client 2
sorts (memory) 3
sorts (disk) 0
Output of query
"USER_ID" "NOTATION_TYPE" "MAXDATE" "COUNT"
"100002616221647" "WTF" 08-SEP-11 20000
"100002616221645" "LOL" 08-SEP-11 20000
"100002616221644" "OMG" 08-SEP-11 20000
"100002616221648" "ABC" 08-SEP-11 20000
"100002616221646" "MEH" 08-SEP-11 20000Thanks...I still don't know what we're working towards at the moment. WHat is the current run time? What is the expected run time?
I can't tell you if there's a better way to write this query or if indeed there is another way to write this query because I don't know what it is attempting to achieve.
I can see that you're accessing 100k rows from a 110k row table and it's using an index to look those rows up. That seems like a job for a full table scan rather than index lookups.
David
Maybe you are looking for
-
Hi., The scenario is 1) Material subjected to Quality is received from Vendor 2) Out of 10 quantity, 5 rejected in Quality Usage Decision. 3) In our company daily hundreds of UD's are done. 4)Is there any report in which we get the information about
-
Problem writing to Port A, B, C on PCI-2025E
I have a VI written to control some 5V devices (solenoid valves) using port write. I am using a PCI-2025E card. This worked fine on DI0 (the digital I/O port available on positions 1-50), but when I switch to digital port A (on position 51-100 of the
-
How can I change the name of our podcasts
In the podcst directory ours is listed as: liberty-baptist-church-sermons/id719265104 How can I chnage that to read the real name of the program: The Liberty Pulpit Frank Chyz Media Director Liberty Baptist Church Ellenboro, NC
-
Hi All, Can we add HTML content in the workflow? We have workflows on lead and Opportunity. These workflows used to send mail based on certain condition. Is it possible to add HTML content to the message body of the workflow? We would like to make fe
-
Colleague can't open my Logic Pro 8 files
Hello out there I hope you will understand my english. I got a huge problem - I'm a musician, recording selfwritten songs at home and taking them on an external hard drive to the studio, where a producer does the last changes to it. I'm working with