Query tuning to force pratition range scan
Hi All,
I am working on a query that fetches data from a partitioned table, but does not use partitions. Below is the query and its explain plan.
SELECT L1_ABBREVIATION "CHARGE_LEVEL_1",
L2_ABBREVIATION "CHARGE_LEVEL_2",
L4_ABBREVIATION "CHARGE_LEVEL_4",
CUSTOMER_TYPE,
INVOICE_TEXT,
DECODE(B_PARTY_NAME, 'SSG/Default/5', 'PTW', 'NON-PTW') B_PARTY_NAME,
SUM(NUM_OF_CHARGES) "NUMBER_OF_CHARGES",
SUM(CHARGE_AMOUNT) "CHARGE_AMOUNT",
COUNT(DISTINCT PRIME_ACCOUNT_ID) "NUM_ACTIVE_USERS"
FROM TACT_PC24
WHERE START_DATE >= TRUNC(SYSDATE) + -16
AND START_DATE <= TRUNC(SYSDATE) + -10
AND 1 = 1
And ((source_system_id =
(select source_system_id
from tact_source_system
where ACCOUNT_NUMBER_PREFIX = '92')) OR ('%' = '92'))
GROUP BY L1_ABBREVIATION,
L2_ABBREVIATION,
L4_ABBREVIATION,
CUSTOMER_TYPE,
INVOICE_TEXT,
DECODE(B_PARTY_NAME, 'SSG/Default/5', 'PTW', 'NON-PTW')
Operation Object Cost Mbytes Partition end
SELECT STATEMENT CHOOSE Cost=3448222 3448222
SORT GROUP BY 3448222 2193
FILTER
PARTITION RANGE ITERATOR (KEY:KEY)
PARTITION LIST ALL (1:2)
TABLE ACCESS FULL TACT_PC24_NEW 3267962 2193 (KEY:KEY)
TABLE ACCESS FULL TACT_SOURCE_SYSTEM 2 0
However when i tried below query (just hot-coded the date range values)
SELECT L1_ABBREVIATION "CHARGE_LEVEL_1",
L2_ABBREVIATION "CHARGE_LEVEL_2",
L4_ABBREVIATION "CHARGE_LEVEL_4",
CUSTOMER_TYPE,
INVOICE_TEXT,
DECODE(B_PARTY_NAME, 'SSG/Default/5', 'PTW', 'NON-PTW') B_PARTY_NAME,
SUM(NUM_OF_CHARGES) "NUMBER_OF_CHARGES",
SUM(CHARGE_AMOUNT) "CHARGE_AMOUNT",
COUNT(DISTINCT PRIME_ACCOUNT_ID) "NUM_ACTIVE_USERS"
FROM TACT_PC24
WHERE START_DATE >= to_date('20120214' ,'YYYYMMDD')
AND START_DATE <= to_date('20120220' ,'YYYYMMDD')
AND 1 = 1
And ((source_system_id =
(select source_system_id
from tact_source_system
where ACCOUNT_NUMBER_PREFIX = '92')) OR ('%' = '92'))
GROUP BY L1_ABBREVIATION,
L2_ABBREVIATION,
L4_ABBREVIATION,
CUSTOMER_TYPE,
INVOICE_TEXT,
DECODE(B_PARTY_NAME, 'SSG/Default/5', 'PTW', 'NON-PTW')
Operation Object Cost Mbytes Partition end
SELECT STATEMENT CHOOSE Cost=3448222 124347
SORT GROUP BY 124347 2193
FILTER
PARTITION RANGE ITERATOR (KEY:KEY)
PARTITION LIST ALL (1:2)
TABLE ACCESS FULL TACT_PC24_NEW 66151 2193 (KEY:KEY)
TABLE ACCESS FULL TACT_SOURCE_SYSTEM 2 1
Can you help me understand why explain plan varied between these queries. I would appropriate if some one can give me an approach to tune this query.
WHERE START_DATE >= TRUNC(SYSDATE) + -16
AND START_DATE <= TRUNC(SYSDATE) + -10
and
WHERE START_DATE >= to_date('20120214' ,'YYYYMMDD')
AND START_DATE <= to_date('20120220' ,'YYYYMMDD')
Is the same...
You got some strange conditions:
1 = 1 --> always TRUE
OR ('%' = '92') --> always FALSE
source_system_id =
SELECT source_system_id
FROM tact_source_system
WHERE ACCOUNT_NUMBER_PREFIX = '92'
OR ('%' = '92')
-- try left join insted...
Similar Messages
-
Is index range scan the reason for query running long time
I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
Operation Object COST CARDINALITY BYTES
SELECT STATEMENT () 413 1000 265000
COUNT (STOPKEY)
FILTER ()
TABLE ACCESS (BY INDEX ROWID) ORDERS 413 58720 15560800
INDEX (RANGE SCAN) IDX_SERV_PROV_ID 13 411709
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
John Seaman
http://www.asktheoracle.net -
hello all
my one of query is returning result in 1-2 mins only for 1 lakh record but i am not sure if it showed me complete rows or not because when I an trying to get count of result ..its taking lot of time .when I am using this query on plsql code ..code is running slow so just wanted to confirm on query tuning point of view if its fine or not ..please look onto it and let me know if query is fine or not by explain plan .my oracle version is 11g
this is my query
SELECT ROWNUM , TRUNC(rownum/5000) + 20000 ,'FOR_UPDATE', sku_org.NAME ,
acct_promo_sku.src_num , acct_promo_sku.sub_type ,
promo_actual.sku_actual_pos
FROM siebel.s_src acct_promo_hdr,
siebel.s_src acct_title_format,
siebel.s_src acct_promo_sku,
siebel.s_src_x acct_promo_hdrx,
siebel.s_src_x acct_promo_skux,
siebel.s_prod_int prod,
siebel.s_bu promo_hdr_org,
siebel.s_bu sku_org,
siebelwb.stg_sbl_acct_promo_actuals2 promo_actual
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = acct_title_format.par_src_id
AND acct_title_format.sub_type = 'PLAN_ACCT_PROMOTION_CATEGORY'
AND acct_title_format.row_id = acct_promo_sku.par_src_id
AND acct_promo_sku.sub_type = 'PLAN_ACCOUNT_PROMOTION_PRODUCT'
AND acct_promo_hdr.row_id = acct_promo_hdrx.par_row_id
AND acct_promo_sku.row_id = acct_promo_skux.par_row_id(+)
AND acct_promo_sku.prod_id = prod.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
AND acct_promo_sku.bu_id = sku_org.row_id
AND prod.x_prod_material_num = promo_actual.material_number
and prod.X_PROD_SALES_ORG=promo_actual.sales_org
AND acct_promo_hdr.row_id = promo_actual.acct_promo_id
and nvl(acct_promo_hdr.pr_accnt_id,0)=nvl(promo_actual.acct_siebel_rowid,0)
and nvl(acct_promo_hdr.x_indirect_id,0)=nvl(promo_actual.indirect_acct_siebel_rowid,0)
AND promo_actual.load_date >= TRUNC(SYSDATE)
AND promo_actual.load_date < TRUNC(SYSDATE + 1)
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 3864590768
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 298 | 2300 (1)| 00:00:28 |
| 1 | COUNT | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 298 | 2300 (1)| 00:00:28 |
| 5 | NESTED LOOPS OUTER | | 1 | 273 | 2298 (1)| 00:00:28 |
| 6 | NESTED LOOPS | | 1 | 263 | 2296 (1)| 00:00:28 |
| 7 | NESTED LOOPS | | 1 | 236 | 2295 (1)| 00:00:28 |
| 8 | NESTED LOOPS | | 1 | 165 | 2292 (1)| 00:00:28 |
| 9 | NESTED LOOPS | | 1 | 117 | 2289 (1)| 00:00:28 |
| 10 | NESTED LOOPS | | 1 | 109 | 2289 (1)| 00:00:28 |
| 11 | NESTED LOOPS | | 1 | 99 | 2287 (1)| 00:00:28 |
|* 12 | TABLE ACCESS FULL | STG_SBL_ACCT_PROMO_ACTUALS2 | 1 | 49 | 2285 (1)| 00:0
|* 13 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 50 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | 8 | 0 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 48 | 3 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 71 | 3 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | S_BU | 1 | 27 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 25 | 2 (0)| 00:00:
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<TRUNC(SYSDATE@!+1))
12 - filter("PROMO_ACTUAL"."LOAD_DATE">=TRUNC(SYSDATE@!) AND "PROMO_ACTUAL"."LOAD_DATE"<TRUNC(SYSD
13 - filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
NVL("ACCT_PROMO_HDR"."PR_ACCNT_ID",'0')=NVL("PROMO_ACTUAL"."ACCT_SIEBEL_ROWID",'0') AND
NVL("ACCT_PROMO_HDR"."X_INDIRECT_ID",'0')=NVL("PROMO_ACTUAL"."INDIRECT_ACCT_SIEBEL_ROWID",'0'
14 - access("ACCT_PROMO_HDR"."ROW_ID"="PROMO_ACTUAL"."ACCT_PROMO_ID")
15 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_PROMO_HDRX"."PAR_ROW_ID")
16 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID")
17 - filter("ACCT_TITLE_FORMAT"."SUB_TYPE"='PLAN_ACCT_PROMOTION_CATEGORY')
18 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_TITLE_FORMAT"."PAR_SRC_ID")
19 - filter("ACCT_PROMO_SKU"."PROD_ID" IS NOT NULL AND
"ACCT_PROMO_SKU"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION_PRODUCT')
20 - access("ACCT_TITLE_FORMAT"."ROW_ID"="ACCT_PROMO_SKU"."PAR_SRC_ID")
22 - access("ACCT_PROMO_SKU"."BU_ID"="SKU_ORG"."ROW_ID")
23 - access("ACCT_PROMO_SKU"."ROW_ID"="ACCT_PROMO_SKUX"."PAR_ROW_ID"(+))
24 - access("ACCT_PROMO_SKU"."PROD_ID"="PROD"."ROW_ID")
25 - filter("PROD"."X_PROD_MATERIAL_NUM" IS NOT NULL AND
"PROD"."X_PROD_MATERIAL_NUM"="PROMO_ACTUAL"."MATERIAL_NUMBER" AND
"PROD"."X_PROD_SALES_ORG"="PROMO_ACTUAL"."SALES_ORG")
55 rows selected.
thanksHi,
the plan you posted has the cost of 2300, i.e. 2300 single-block reads or equivalent number f multi-block reads. Even if none of the blocks is found in cache, 2300 reas shouldn't take more than a couple of minutes, beacause for most of the hard drives available today a disk read is typically within 5-10 ms.
This means that if there is a problem, we will never find out about it by looking in the plan. And it's quite likely that there is, in fact, a problem, because the plan contains a bunch of nested joins, and the cost of each nested join is directly proportional to the cardinality of the previous nested loop. I.e. it suffices to make one bad mistake in estimating the number of rows coming fom one of the nested rows to screw up the entire plan and get all remaining estimates (including the total cost of the query) completely wrong.
In order for us to be able to tell more, we need to see the plan with rowsource statistics, and please don't forget to use tags to preserve formatting (use the preview tab to make sure the posted plan is actually readable).
Best regards,
Nikolay -
What is mean by index range scan and fast full scan
What is mean by the following execution plans
1)Table access by index rowid
2) Index range scan
3) Index fast full scan
4) global index by rowid
..etc
where i can get this information.In what situation CBO take these paths.Can you pls give me a link where i can find all these.I read these long time ago but not able to recollect
Thanks
AnandOracle® Database Performance Tuning Guide
10g Release 2 (10.2)
Part Number B14211-01
13.5 Understanding Access Paths for the Query Optimizer
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#sthref1281 -
This is my first post in this forum regarding query tuning, so my sincere apologies in advance if I have:
1) not included sufficient information,
2) included too much information,
3) not posted to the correct forum
I read through Randolf Geist's web page on instructions to post a query tuning request
and attempted to follow it as closely as possible.
I am attempting to figure out where a view I have constructed can be optimized.
It takes approx. 45 seconds to 1 minute to run; I would like to cut that down to 10 seconds if possible.
The view itself is somewhat complex; I will post the actual code if it will help you help me. Please advise.
I was under the impression that posting the code was not necessary, but if it is, let me know and I will post it.
I have been doing SQL development for a few years, but only recently in Oracle.
I have no experience in looking through the following output and being able to tell where I can improve performance,
so this will be a learning experience for me. Thanks in advance for your help - I appreciate it.
Some additional information - my view is based on tables over which I have no control - it is a third-party application
which I do reporting from. I do have the freedom to create indexes on columns within the tables if necessary.
The statement is simply
SELECT * FROM LLU_V_PRODUCTION_DETAIL_03
which is the name of my view.
here's all the information I've been able to retrieve by following Randolf's instructions:
Oracle version is 10.2.0.1.0 - 64bit
Here are optimizer parameters:
NAME TYPE VALUE
user_dump_dest string C:\ORACLE\PRODUCT\10.2.0\ADMIN
\AXIUMPRODUCTION\UDUMP
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.1
optimizer_index_caching integer 90
optimizer_index_cost_adj integer 20
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
NAME TYPE VALUE
db_file_multiblock_read_count integer 16
NAME TYPE VALUE
db_block_size integer 8192
NAME TYPE VALUE
cursor_sharing string EXACT
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 10-29-2005 01:36
SYSSTATS_INFO DSTOP 10-29-2005 01:36
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1298.56584
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.Here is the output of EXPLAIN PLAN:
PLAN_TABLE_OUTPUT
Plan hash value: 662813077
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 23M| 53G| | 62330 (2)| 00:12:28 |
| 1 | VIEW | LLU_V_PRODUCTION_DETAIL_03 | 23M| 53G| | 62330 (2)| 00:12:28 |
| 2 | UNION-ALL | | | | | | |
|* 3 | HASH JOIN | | 18M| 5062M| | 1525 (10)| 00:00:19 |
| 4 | VIEW | index$_join$_007 | 1725 | 25875 | | 4 (25)| 00:00:01 |
|* 5 | HASH JOIN | | | | | | |
| 6 | INDEX FAST FULL SCAN | USERS_PRIMARY | 1725 | 25875 | | 1 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | USERS_PRODUCER | 1725 | 25875 | | 2 (0)| 00:00:01 |
|* 8 | HASH JOIN | | 416K| 105M| | 1399 (2)| 00:00:17 |
| 9 | TABLE ACCESS FULL | PRODUCER | 1396 | 118K| | 24 (0)| 00:00:01 |
|* 10 | HASH JOIN | | 29819 | 5183K| | 1372 (2)| 00:00:17 |
| 11 | TABLE ACCESS FULL | CLASS | 20 | 1660 | | 3 (0)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | QR_PRODUCTION | 149K| 13M| | 1367 (2)| 00:00:17 |
|* 13 | FILTER | | | | | | |
|* 14 | HASH JOIN | | 16M| 5651M| | 32983 (2)| 00:06:36 |
| 15 | VIEW | index$_join$_014 | 1725 | 25875 | | 4 (25)| 00:00:01 |
|* 16 | HASH JOIN | | | | | | |
| 17 | INDEX FAST FULL SCAN | USERS_PRIMARY | 1725 | 25875 | | 1 (0)| 00:00:01 |
| 18 | INDEX FAST FULL SCAN | USERS_PRODUCER | 1725 | 25875 | | 2 (0)| 00:00:01 |
|* 19 | HASH JOIN | | 149K| 49M| | 32874 (1)| 00:06:35 |
| 20 | TABLE ACCESS FULL | CLASS | 20 | 1660 | | 3 (0)| 00:00:01 |
|* 21 | HASH JOIN | | 149K| 37M| | 32870 (1)| 00:06:35 |
| 22 | TABLE ACCESS FULL | PRODUCER | 1396 | 118K| | 24 (0)| 00:00:01 |
|* 23 | HASH JOIN | | 222K| 37M| 12M| 32844 (1)| 00:06:35 |
| 24 | TABLE ACCESS FULL | PATIENT | 188K| 10M| | 6979 (1)| 00:01:24 |
|* 25 | HASH JOIN | | 222K| 24M| | 23860 (2)| 00:04:47 |
|* 26 | TABLE ACCESS FULL | PROCEDUR | 888 | 44400 | | 11 (0)| 00:00:01 |
|* 27 | TABLE ACCESS FULL | TRX | 442K| 28M| | 23845 (2)| 00:04:47 |
|* 28 | TABLE ACCESS FULL | USERS | 1 | 11 | | 55 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 473 | | 25798 (1)| 00:05:10 |
| 30 | NESTED LOOPS | | 1 | 413 | | 25797 (1)| 00:05:10 |
| 31 | NESTED LOOPS | | 1 | 398 | | 25796 (1)| 00:05:10 |
| 32 | NESTED LOOPS | | 1 | 390 | | 25795 (1)| 00:05:10 |
|* 33 | HASH JOIN | | 1 | 303 | | 25794 (1)| 00:05:10 |
| 34 | TABLE ACCESS FULL | LLU_EVALUATION_DESCRIPTIONS | 95 | 6175 | | 3 (0)| 00:00:01 |
|* 35 | HASH JOIN | | 4630 | 1076K| | 25791 (1)| 00:05:10 |
|* 36 | HASH JOIN | | 9607 | 1623K| | 23834 (1)| 00:04:47 |
| 37 | MERGE JOIN | | 888 | 91464 | | 13 (8)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | CLASS | 20 | 1660 | | 1 (0)| 00:00:01 |
| 39 | INDEX FULL SCAN | CLASS_PRIMARY | 20 | | | 1 (0)| 00:00:01 |
|* 40 | SORT JOIN | | 888 | 17760 | | 12 (9)| 00:00:01 |
|* 41 | TABLE ACCESS FULL | PROCEDUR | 888 | 17760 | | 11 (0)| 00:00:01 |
|* 42 | TABLE ACCESS FULL | TRX | 19125 | 1307K| | 23820 (1)| 00:04:46 |
|* 43 | TABLE ACCESS FULL | GRADITEM | 655K| 40M| | 1952 (1)| 00:00:24 |
| 44 | TABLE ACCESS BY INDEX ROWID | PRODUCER | 1 | 87 | | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | PRODUCER_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 46 | TABLE ACCESS BY INDEX ROWID | GRADING | 1 | 8 | | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | GRADING_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 48 | TABLE ACCESS BY INDEX ROWID | USERS | 221 | 3315 | | 1 (0)| 00:00:01 |
|* 49 | INDEX RANGE SCAN | USERS_PRODUCER | 1 | | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | PATIENT | 1 | 60 | | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | PATIENT_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | USERS | 109 | 1635 | | 1 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 438 | | 2023 (1)| 00:00:25 |
| 54 | NESTED LOOPS | | 1 | 423 | | 2022 (1)| 00:00:25 |
| 55 | NESTED LOOPS | | 1 | 363 | | 2021 (1)| 00:00:25 |
| 56 | NESTED LOOPS | | 1 | 276 | | 2020 (1)| 00:00:25 |
| 57 | NESTED LOOPS | | 1 | 193 | | 2019 (1)| 00:00:25 |
| 58 | NESTED LOOPS | | 1 | 185 | | 2018 (1)| 00:00:25 |
| 59 | NESTED LOOPS | | 1 | 173 | | 2017 (1)| 00:00:25 |
| 60 | NESTED LOOPS | | 1 | 140 | | 2016 (1)| 00:00:25 |
|* 61 | TABLE ACCESS FULL | GRADITEM | 317 | 23141 | | 1953 (2)| 00:00:24 |
|* 62 | TABLE ACCESS BY INDEX ROWID| TRX | 1 | 67 | | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | TRX_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 64 | TABLE ACCESS BY INDEX ROWID | TRX | 1 | 33 | | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TRX_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 66 | TABLE ACCESS BY INDEX ROWID | GRADITEM | 1 | 12 | | 1 (0)| 00:00:01 |
|* 67 | INDEX RANGE SCAN | GRADITEM_ID | 19 | | | 1 (0)| 00:00:01 |
|* 68 | TABLE ACCESS BY INDEX ROWID | GRADING | 1 | 8 | | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | GRADING_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | CLASS | 1 | 83 | | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | CLASS_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 72 | TABLE ACCESS BY INDEX ROWID | PRODUCER | 1 | 87 | | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | PRODUCER_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 74 | TABLE ACCESS BY INDEX ROWID | PATIENT | 1 | 60 | | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | PATIENT_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 76 | INDEX RANGE SCAN | USERS_PRODUCER | 1 | | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("QRP"."ProviderID"="U1"."Producer")
5 - access(ROWID=ROWID)
8 - access(TRIM("QRP"."ProviderID")=TRIM("P"."Producer"))
10 - access(TRIM("QRP"."axiUm_Discipline")=TRIM("CLASS"."Class"))
12 - filter("QRP"."ProviderID" IS NOT NULL AND "QRP"."Location"<'9990' AND "QRP"."ProcedureID"<>185 AND
"QRP"."PatientFirstName"<>'NON-PATIENT' AND ("QRP"."PatientFirstName"<>'TED' OR "QRP"."PatientLastName" NOT LIKE
'CAVENDER%'))
13 - filter( NOT EXISTS (SELECT 0 FROM AXIUM."USERS" "USERS" WHERE "Custom3"='YES' AND LNNVL("User"<>:B1)) OR
TO_CHAR(INTERNAL_FUNCTION("P"."EndDate"),'YYYY')<'2011' OR TRIM(TO_CHAR(INTERNAL_FUNCTION("P"."EndDate"),'YYYY')) IS
NULL OR "TRX"."Procedure"='A0021' OR "TRX"."Procedure"='A0022')
14 - access("TRX"."Producer"="U1"."Producer")
16 - access(ROWID=ROWID)
19 - access("PROC"."Discipline"="CLASS"."Class")
21 - access("TRX"."Producer"="P"."Producer")
23 - access("TRX"."Patient"="PAT"."Patient")
25 - access("TRX"."Procedure"="PROC"."Procedure")
26 - filter("PROC"."Discipline" IS NOT NULL)
27 - filter("TRX"."Deleted"=0 AND "TRX"."Status"='C' AND "TRX"."Procedure" NOT LIKE 'D0149%' AND
"TRX"."Procedure"<>'D5001C')
28 - filter("Custom3"='YES' AND LNNVL("User"<>:B1))
33 - access(TRIM(UPPER("GI"."QuestionText"))=TRIM(UPPER("LLU"."GRADITEM_QuestionText")) AND
TRIM(UPPER("GI"."Text"))=TRIM(UPPER("LLU"."GRADITEM_Text")) AND TRIM("TRX"."Procedure")=TRIM("LLU"."ProcedureCode"))
35 - access("TRX"."Type"="GI"."Type" AND "TRX"."Id"="GI"."Id" AND "TRX"."Treatment"="GI"."Treatment")
36 - access("TRX"."Procedure"="PROC"."Procedure")
40 - access("PROC"."Discipline"="CLASS"."Class")
filter("PROC"."Discipline"="CLASS"."Class")
41 - filter("PROC"."Discipline" IS NOT NULL)
42 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C')
43 - filter("GI"."Grading"<>0)
45 - access("TRX"."Producer"="P"."Producer")
46 - filter("G"."Deleted"=0)
47 - access("TRX"."Grading"="G"."Grading")
filter("G"."Grading"<>0 AND "G"."Grading"="GI"."Grading")
49 - access("TRX"."Producer"="U1"."Producer")
51 - access("TRX"."Patient"="PAT"."Patient")
61 - filter("GI"."IsHeading"=3 AND TRIM("GI"."QuestionText")='Comments' AND "GI"."Grading"<>0)
62 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C' AND ("TRX"."Procedure"='G1002' OR
"TRX"."Procedure"='G1003'))
63 - access("GI"."Type"="TRX"."Type" AND "GI"."Id"="TRX"."Id" AND "GI"."Treatment"="TRX"."Treatment")
64 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C' AND ("TRX"."Procedure"='G1002' OR
"TRX"."Procedure"='G1003') AND "TRX"."Grading"="TRX"."Grading")
65 - access("TRX"."Type"="TRX"."Type" AND "TRX"."Id"="TRX"."Id" AND "TRX"."Treatment"="TRX"."Treatment")
66 - filter("GI"."RelValue"<>0 AND "TRX"."Type"="GI"."Type" AND "TRX"."Treatment"="GI"."Treatment")
67 - access("TRX"."Id"="GI"."Id")
68 - filter("G"."Deleted"=0)
69 - access("TRX"."Grading"="G"."Grading")
filter("G"."Grading"<>0 AND "GI"."Grading"="G"."Grading")
71 - access("TRX"."Discipline"="CLASS"."Class")
73 - access("TRX"."Producer"="P"."Producer")
75 - access("TRX"."Patient"="PAT"."Patient")
76 - access("TRX"."Producer"="U1"."Producer")
138 rows selected.
Elapsed: 00:00:00.62
631015 rows selected.
Elapsed: 00:01:49.13Output from AUTOTRACE (I think)
NOTE: this post was too long for the forum, so I have removed a number of lines in the following output which appeared to be duplicating the above section (EXPLAIN PLAN).
Statistics
2657 recursive calls
0 db block gets
12734113 consistent gets
13499 physical reads
0 redo size
103697740 bytes sent via SQL*Net to client
69744 bytes received via SQL*Net from client
6312 SQL*Net roundtrips to/from client
76 sorts (memory)
0 sorts (disk)
631015 rows processedThe TKPROF output
select * from llu_v_production_detail_03
call count cpu elapsed disk query current rows
Parse 1 0.51 0.51 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 6312 88.09 98.01 13490 12733584 0 631015
total 6314 88.60 98.52 13490 12733584 0 631015
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 57
Rows Row Source Operation
631015 VIEW LLU_V_PRODUCTION_DETAIL_03 (cr=12733584 pr=13490 pw=0 time=92145592 us)
631015 UNION-ALL (cr=12733584 pr=13490 pw=0 time=91514573 us)
125485 HASH JOIN (cr=8099 pr=6396 pw=0 time=1523326 us)
1725 VIEW index$_join$_007 (cr=24 pr=0 pw=0 time=4777 us)
1725 HASH JOIN (cr=24 pr=0 pw=0 time=3051 us)
1725 INDEX FAST FULL SCAN USERS_PRIMARY (cr=7 pr=0 pw=0 time=50 us)(object id 55023)
1725 INDEX FAST FULL SCAN USERS_PRODUCER (cr=17 pr=0 pw=0 time=16 us)(object id 55024)
144513 HASH JOIN (cr=8075 pr=6396 pw=0 time=2326445 us)
1396 TABLE ACCESS FULL PRODUCER (cr=107 pr=0 pw=0 time=29 us)
144513 HASH JOIN (cr=7968 pr=6396 pw=0 time=2035684 us)
20 TABLE ACCESS FULL CLASS (cr=7 pr=0 pw=0 time=71 us)
151043 TABLE ACCESS FULL QR_PRODUCTION (cr=7961 pr=6396 pw=0 time=313553 us)
462685 FILTER (cr=10755862 pr=7094 pw=0 time=58570941 us)
466790 HASH JOIN (cr=145247 pr=7094 pw=0 time=11007301 us)
1725 VIEW index$_join$_014 (cr=24 pr=0 pw=0 time=6817 us)
1725 HASH JOIN (cr=24 pr=0 pw=0 time=5091 us)
1725 INDEX FAST FULL SCAN USERS_PRIMARY (cr=7 pr=0 pw=0 time=35 us)(object id 55023)
1725 INDEX FAST FULL SCAN USERS_PRODUCER (cr=17 pr=0 pw=0 time=19 us)(object id 55024)
485205 HASH JOIN (cr=145223 pr=7094 pw=0 time=10945107 us)
20 TABLE ACCESS FULL CLASS (cr=7 pr=0 pw=0 time=105 us)
507772 HASH JOIN (cr=145216 pr=7094 pw=0 time=11947534 us)
1396 TABLE ACCESS FULL PRODUCER (cr=107 pr=0 pw=0 time=18 us)
507772 HASH JOIN (cr=145109 pr=7094 pw=0 time=10924473 us)
188967 TABLE ACCESS FULL PATIENT (cr=31792 pr=0 pw=0 time=188998 us)
507772 HASH JOIN (cr=113317 pr=7094 pw=0 time=9652037 us)
895 TABLE ACCESS FULL PROCEDUR (cr=46 pr=0 pw=0 time=65 us)
509321 TABLE ACCESS FULL TRX (cr=113271 pr=7094 pw=0 time=5604567 us)
8548 TABLE ACCESS FULL USERS (cr=10610615 pr=0 pw=0 time=39053120 us)
42669 NESTED LOOPS (cr=507317 pr=0 pw=0 time=3686506 us)
42669 NESTED LOOPS (cr=421535 pr=0 pw=0 time=3217140 us)
45269 NESTED LOOPS (cr=301155 pr=0 pw=0 time=2449542 us)
45323 NESTED LOOPS (cr=210131 pr=0 pw=0 time=2134056 us)
45323 HASH JOIN (cr=119056 pr=0 pw=0 time=1635472 us)
95 TABLE ACCESS FULL LLU_EVALUATION_DESCRIPTIONS (cr=7 pr=0 pw=0 time=118 us)
98272 HASH JOIN (cr=119049 pr=0 pw=0 time=1446703 us)
46996 HASH JOIN (cr=109018 pr=0 pw=0 time=944857 us)
786 MERGE JOIN (cr=50 pr=0 pw=0 time=1528 us)
20 TABLE ACCESS BY INDEX ROWID CLASS (cr=4 pr=0 pw=0 time=99 us)
20 INDEX FULL SCAN CLASS_PRIMARY (cr=1 pr=0 pw=0 time=10 us)(object id 53850)
786 SORT JOIN (cr=46 pr=0 pw=0 time=750 us)
895 TABLE ACCESS FULL PROCEDUR (cr=46 pr=0 pw=0 time=18 us)
47196 TABLE ACCESS FULL TRX (cr=108968 pr=0 pw=0 time=805137 us)
696300 TABLE ACCESS FULL GRADITEM (cr=10031 pr=0 pw=0 time=277 us)
45323 TABLE ACCESS BY INDEX ROWID PRODUCER (cr=91075 pr=0 pw=0 time=414937 us)
45323 INDEX UNIQUE SCAN PRODUCER_PRIMARY (cr=45752 pr=0 pw=0 time=198709 us)(object id 54581)
45269 TABLE ACCESS BY INDEX ROWID GRADING (cr=91024 pr=0 pw=0 time=353081 us)
45270 INDEX UNIQUE SCAN GRADING_PRIMARY (cr=45753 pr=0 pw=0 time=173185 us)(object id 54088)
42669 TABLE ACCESS BY INDEX ROWID USERS (cr=120380 pr=0 pw=0 time=703786 us)
42669 INDEX RANGE SCAN USERS_PRODUCER (cr=46127 pr=0 pw=0 time=249186 us)(object id 55024)
42669 TABLE ACCESS BY INDEX ROWID PATIENT (cr=85782 pr=0 pw=0 time=407452 us)
42669 INDEX UNIQUE SCAN PATIENT_PRIMARY (cr=43098 pr=0 pw=0 time=198477 us)(object id 54370)
176 TABLE ACCESS BY INDEX ROWID USERS (cr=49426 pr=0 pw=0 time=1783886 us)
367 NESTED LOOPS (cr=49149 pr=0 pw=0 time=6159428 us)
190 NESTED LOOPS (cr=48953 pr=0 pw=0 time=409391 us)
190 NESTED LOOPS (cr=48569 pr=0 pw=0 time=407105 us)
190 NESTED LOOPS (cr=48185 pr=0 pw=0 time=404820 us)
191 NESTED LOOPS (cr=47991 pr=0 pw=0 time=410291 us)
193 NESTED LOOPS (cr=47603 pr=0 pw=0 time=422507 us)
193 NESTED LOOPS (cr=46979 pr=0 pw=0 time=416890 us)
193 NESTED LOOPS (cr=46396 pr=0 pw=0 time=414374 us)
14285 TABLE ACCESS FULL GRADITEM (cr=9602 pr=0 pw=0 time=85793 us)
193 TABLE ACCESS BY INDEX ROWID TRX (cr=36794 pr=0 pw=0 time=128427 us)
8218 INDEX UNIQUE SCAN TRX_PRIMARY (cr=28576 pr=0 pw=0 time=64353 us)(object id 54930)
193 TABLE ACCESS BY INDEX ROWID TRX (cr=583 pr=0 pw=0 time=2169 us)
193 INDEX UNIQUE SCAN TRX_PRIMARY (cr=390 pr=0 pw=0 time=918 us)(object id 54930)
193 TABLE ACCESS BY INDEX ROWID GRADITEM (cr=624 pr=0 pw=0 time=4840 us)
1547 INDEX RANGE SCAN GRADITEM_ID (cr=395 pr=0 pw=0 time=2910 us)(object id 54093)
191 TABLE ACCESS BY INDEX ROWID GRADING (cr=388 pr=0 pw=0 time=1887 us)
191 INDEX UNIQUE SCAN GRADING_PRIMARY (cr=197 pr=0 pw=0 time=943 us)(object id 54088)
190 TABLE ACCESS BY INDEX ROWID CLASS (cr=194 pr=0 pw=0 time=1306 us)
190 INDEX UNIQUE SCAN CLASS_PRIMARY (cr=4 pr=0 pw=0 time=551 us)(object id 53850)
190 TABLE ACCESS BY INDEX ROWID PRODUCER (cr=384 pr=0 pw=0 time=1617 us)
190 INDEX UNIQUE SCAN PRODUCER_PRIMARY (cr=194 pr=0 pw=0 time=715 us)(object id 54581)
190 TABLE ACCESS BY INDEX ROWID PATIENT (cr=384 pr=0 pw=0 time=1941 us)
190 INDEX UNIQUE SCAN PATIENT_PRIMARY (cr=194 pr=0 pw=0 time=939 us)(object id 54370)
176 INDEX RANGE SCAN USERS_PRODUCER (cr=196 pr=0 pw=0 time=1389 us)(object id 55024)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 6312 0.00 0.00
db file scattered read 1614 0.02 2.08
SQL*Net message from client 6312 0.00 10.11
SQL*Net more data to client 48662 0.00 0.70
db file sequential read 4645 0.02 7.11
latch: shared pool 7 0.00 0.00
latch: cache buffers chains 1 0.00 0.00
********************************************************************************Again, I apologize if this is way more information than is necessary.
All advice/suggestions/assistance will be gratefully accepted.
CarlHi Rob,
Thank you for replying. Here is the view definition . . . it looks pretty convoluted, I know.
I am reporting from a database which I have no control over other than to add indexes where needed.
For reporting purposes, I am needing to create the dataset from a number of different tables; hence all the UNION clauses.
-- CODE FOLLOWS
CREATE OR REPLACE VIEW LLU_V_PRODUCTION_DETAIL_03
AS
SELECT
'QR' AS "Source",
U1."User" AS "UserID",
QRP."ProviderID" AS "ProviderID",
P."LastName" AS "ProviderLastName",
P."FirstName" AS "ProviderFirstName",
TO_CHAR(P."EndDate",'YYYY') AS "GraduationYear",
P."PGroup",
QRP."PatientID",
QRP."ChartNumber",
QRP."PatientLastName",
QRP."PatientFirstName",
QRP."ProcedureID" || '-' || QRP."ProcedureSuffix" AS "Procedure",
QRP."ProcedureDescription",
QRP."Tooth" AS "Site",
QRP."Surface",
QRP."axiUm_Discipline" AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name" AS "DisciplineName",
QRP."Points",
0 AS "Hours",
QRP."ServiceDate",
0 AS "Id",
QRP."UniqueID" AS "Grading",
0 AS "LastSort",
QRP."CategoryID",
'' AS "CPAR comments"
FROM QR_PRODUCTION QRP
INNER JOIN PRODUCER P
ON TRIM(QRP."ProviderID") = TRIM(P."Producer")
INNER JOIN CLASS
ON TRIM(QRP."axiUm_Discipline") = TRIM(CLASS."Class")
INNER JOIN USERS U1
ON QRP."ProviderID" = U1."Producer"
WHERE (QRP."Location" < '9990')
AND (QRP."ProviderID" IS NOT NULL)
AND (QRP."ProcedureID" <> 185)
-- skip the Cavender family - training patients
AND NOT (QRP."PatientLastName" LIKE 'CAVENDER%' AND QRP."PatientFirstName" = 'TED')
AND QRP."PatientFirstName" <> 'NON-PATIENT'
--ORDER BY QRP."ProcedureID"
UNION ALL
SELECT
'axiUm TRX' AS "Source",
U1."User" AS "UserID",
TRX."Producer" AS "ProviderID",
P."LastName",
P."FirstName",
TO_CHAR(P."EndDate",'YYYY') AS "GraduationYear",
P."PGroup",
PAT."Patient",
PAT."Chart",
PAT."Last" AS "PatientLastName",
PAT."First" AS "PatientFirstName",
TRX."Procedure",
PROC."Description",
TRX."Site",
TRX."Surface",
TRIM(PROC."Discipline") AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name",
CASE WHEN
((TRX."Procedure" IN ('A0013','A0019','A0020','A0021','A0023','A0024','A0025','A0026','A0027','A0028','A0029','A0030','O179'))
OR
-- no points are to be awarded for any procedures performed on typodonts
(EXISTS (SELECT 1 FROM PTTYPES PTT WHERE PTT."Patient" = PAT."Patient" and PTT."PatType" = 'TYPO' and PTT."Deleted" = 0)))
AND -- except for the following procedures
(TRX."Procedure" NOT IN ('A0015','A0016','A0018','D0210'))
THEN 0 ELSE PROC."RelValue" END AS "Points",
CASE WHEN TRX."Procedure" IN ('A0013','A0019','A0020','A0021','A0023','A0024','A0025','A0026','A0027','A0028','A0029','A0030','O179')
THEN PROC."RelValue" ELSE 0 END AS "Hours",
TRX."TreatmentDate",
TRX."Id",
TRX."Grading",
-1 AS "LastSort",
-- additional link conditions added and table name changed on 1 July 2009 - cji
SELECT "CategoryID" FROM LLU_CATEGORIES_X_PROCEDURES_03 LLU
WHERE TRX."Procedure" = LLU."ProcedureID"
AND TO_CHAR(P."EndDate",'YYYY') = LLU."GraduationYear"
AND SUBSTR(TRX."Producer",1,1) = LLU."ProviderType"
AND LLU."CategoryID" NOT IN (82)
) AS "CategoryID",
'' AS "CPAR comments"
FROM TRX
INNER JOIN PATIENT PAT
ON TRX."Patient" = PAT."Patient"
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
INNER JOIN PROCEDUR PROC
ON TRX."Procedure" = PROC."Procedure"
INNER JOIN CLASS
ON PROC."Discipline" = CLASS."Class"
INNER JOIN PRODUCER P
ON TRX."Producer" = P."Producer"
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
--AND (TRX."Grading" = 0)
AND (TRX."Procedure" NOT LIKE 'D0149%')
AND (TRX."Procedure" <> 'D5001C')
-- exclude all procedures approved by Peds faculty ONLY FOR CLASS OF 2011 AND LATER
-- EXCEPT FOR the Peds Block code (A0021 and A0022) - always include those
AND NOT
TRX."AppUser" IN (SELECT "User" FROM USERS WHERE "Custom3" = 'YES') -- Peds faculty
AND
TO_CHAR(P."EndDate",'YYYY') >= '2011'
AND
TRIM(TO_CHAR(P."EndDate",'YYYY')) IS NOT NULL
AND
TRX."Procedure" NOT IN ('A0021','A0022')
UNION ALL
SELECT
'axiUm GRADING' AS "Source",
U1."User" AS "UserID",
TRX."Producer" AS "ProviderID",
P."LastName",
P."FirstName",
TO_CHAR(P."EndDate",'YYYY'), -- Graduation year
P."PGroup",
PAT."Patient",
PAT."Chart",
PAT."Last" AS "PatientLastName",
PAT."First" AS "PatientFirstName",
TRX."Procedure",
LLU."Description",
TRX."Site",
TRX."Surface",
TRIM(PROC."Discipline") AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name",
LLU."Points", --LLU_POINTS_FROM_EVALUATIONS(TRX."Procedure", nvl(GI."Text",0)),
0 AS "Hours",
TRX."TreatmentDate",
GI."Id",
GI."Grading",
GI."Row" AS "LastSort",
LLU."CategoryID",
'' AS "CPAR comments"
FROM TRX
INNER JOIN PATIENT PAT
ON TRX."Patient" = PAT."Patient"
INNER JOIN PRODUCER P
ON TRX."Producer" = P."Producer"
INNER JOIN GRADING G
ON TRX."Grading" = G."Grading"
INNER JOIN GRADITEM GI
ON G."Grading" = GI."Grading"
AND TRX."Type" = GI."Type"
AND TRX."Id" = GI."Id"
AND TRX."Treatment" = GI."Treatment"
INNER JOIN PROCEDUR PROC
ON TRX."Procedure" = PROC."Procedure"
INNER JOIN CLASS
ON PROC."Discipline" = CLASS."Class"
INNER JOIN LLU_EVALUATION_DESCRIPTIONS LLU
ON (TRIM(UPPER(GI."QuestionText")) = TRIM(UPPER(LLU."GRADITEM_QuestionText")))
AND (TRIM(UPPER(GI."Text")) = TRIM(UPPER(LLU."GRADITEM_Text")))
AND (TRIM(TRX."Procedure") = TRIM(LLU."ProcedureCode"))
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (G."Deleted" = 0)
UNION ALL
SELECT 'ClinPtsAdj',
U1."User" AS "UserID",
TRX."Producer",
P."LastName", P."FirstName",
TO_CHAR(P."EndDate",'YYYY'), -- Graduation year
P."PGroup", PAT."Patient", PAT."Chart", PAT."Last", PAT."First",
TRX."Procedure",
'Clinic points adjustment',
'' AS "Site",
'' AS "Surface",
TRIM(TRX."Discipline"),
"CLASS"."Rank",
"CLASS"."Name",
DERIVED."Points",
0 AS "Hours",
GI."Date",
GI."Id",
GI."Grading",
GI."Row",
NULL AS "CategoryID",
TRIM(REPLACE(GI."Note", CHR(13) || CHR(10), ' '))
FROM TRX
INNER JOIN PATIENT PAT
ON (TRX."Patient" = PAT."Patient")
INNER JOIN PRODUCER P
ON (TRX."Producer" = P."Producer")
INNER JOIN CLASS
ON (TRX."Discipline" = CLASS."Class")
INNER JOIN GRADING G
ON (TRX."Grading" = G."Grading")
INNER JOIN GRADITEM GI
ON (GI."Grading" = G."Grading")
AND (GI."Type" = TRX."Type")
AND (GI."Id" = TRX."Id")
AND (GI."Treatment" = TRX."Treatment")
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
INNER JOIN
SELECT TRX."Type", TRX."Id", TRX."Treatment", TRX."Grading",
CASE WHEN TRX."Procedure" = 'G1003' THEN GI."RelValue" * -1 ELSE "RelValue" END AS "Points"
FROM TRX, GRADITEM GI
WHERE (TRX."Type" = GI."Type")
AND (TRX."Id" = GI."Id")
AND (TRX."Treatment" = GI."Treatment")
AND (TRX."Procedure" IN ('G1002','G1003'))
AND (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (GI."RelValue" <> 0)
) DERIVED
ON (TRX."Type" = DERIVED."Type")
AND (TRX."Id" = DERIVED."Id")
AND (TRX."Treatment" = DERIVED."Treatment")
AND (TRX."Grading" = DERIVED."Grading")
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (G."Deleted" = 0)
AND (TRX."Procedure" IN ('G1002','G1003'))
AND (GI."IsHeading" = 3)
AND (TRIM(GI."QuestionText") = 'Comments')
--ORDER BY "ProviderID", "DisciplineSorter", "Id", "Grading", "Site", "LastSort";A couple of additional points:
The table USERS already had an index on column "Producer"; I added an index on column "Custom3" but it did not seem to make any difference.
Table USERS has 1,725 rows
Table PRODUCER (aliased as P) has 1,396 rows
Table TRX has 1,443,764 rows.
Any additional information you need I will be glad to provide.
Thanks a bunch; it may not be too late to teach an old dog new tricks.
And thank you all for the kind words about the posting; about the only thing I can do well is follow directions.
Carl -
Hi Fellas,
I am new to query tuning. I have a big query with a TKPROF details. It is just fetching 34 records and taking approx 30 mins.
The TKPROF detail will follow after the query.
SELECT /*+ NO_INDEX(A, RA_CUSTOMER_TRX_N11 ) USE_NL(TYPES,A) */ a.customer_trx_id CUSTOMER_TRX_ID ,
a.trx_number TRX_NUMBER ,
A . INTERFACE_HEADER_ATTRIBUTE5 BILLING_STAGE ,
A . INTERFACE_HEADER_CONTEXT PBRR_TYPE ,
A . INTERFACE_HEADER_ATTRIBUTE11 BILLING_TERM ,
NVL ( TL . SEQUENCE_NUM , 1 ) TERM_SEQUENCE_NUMBER ,
types.type TRX_TYPE ,
l_types.meaning TRX_TYPE_NAME ,
TYPES . ACCOUNTING_AFFECT_FLAG OPEN_RECEIVABLE_FLAG ,
a.trx_date TRX_DATE , SHIP_TO_CUSTOMER_ID SHIP_TO_CUSTOMER_ID ,
SHIP_TO_CONTACT_ID SHIP_TO_CONTACT_ID ,
REMIT_TO_ADDRESS_ID REMIT_TO_ADDRESS_ID ,
A . PRIMARY_SALESREP_ID PRIMARY_SALESREP_ID ,
B . ACCOUNT_NUMBER CUSTOMER_NUMBER ,
A . INTERNAL_NOTES INTERNAL_NOTES ,
A . COMMENTS TRX_COMMENTS ,
PREVIOUS_CUSTOMER_TRX_ID PREVIOUS_CUSTOMER_TRX_ID ,
SHIP_TO_SITE_USE_ID SHIP_TO_SITE_USE_ID ,
NVL ( PRINTING_COUNT , 0 ) PRINTING_COUNT ,
PRINTING_ORIGINAL_DATE PRINTING_ORIGINAL_DATE ,
PRINTING_LAST_PRINTED PRINTING_LAST_PRINTED ,
PRINTING_PENDING PRINTING_PENDING ,
LAST_PRINTED_SEQUENCE_NUM LAST_PRINTED_SEQUENCE_NUMBER ,
START_DATE_COMMITMENT START_DATE_COMMITMENT ,
END_DATE_COMMITMENT END_DATE_COMMITMENT ,
INITIAL_CUSTOMER_TRX_ID INITIAL_CUSTOMER_TRX_ID ,
A . INVOICE_CURRENCY_CODE INVOICE_CURRENCY_CODE ,
A . REASON_CODE CREDIT_HEADER_REASON_CODE_CSTM ,
A . TERM_ID TERM_ID ,
A . SHIP_DATE_ACTUAL SHIP_DATE_ACTUAL ,
A . SHIP_VIA SHIP_VIA ,
A . WAYBILL_NUMBER WAYBILL_NUMBER ,
A . PURCHASE_ORDER PURCHASE_ORDER_NUMBER ,
A . PURCHASE_ORDER_REVISION PURCHASE_ORDER_REVISION ,
A . PURCHASE_ORDER_DATE PURCHASE_ORDER_DATE ,
A . CREATED_BY ORDER_CREATED_BY_CSTM ,
P . DUE_DATE TERM_DUE_DATE_FROM_PS ,
NVL ( TL . RELATIVE_AMOUNT , 100 ) * ( 100 / NVL ( T . BASE_AMOUNT , 100 ) ) TERM_RELATIVE_AMOUNT ,
T . NAME TERM_NAME ,
A . BILL_TO_CUSTOMER_ID BILL_TO_CUSTOMER_ID ,
A . BILL_TO_CONTACT_ID BILL_TO_CONTACT_ID ,
A . BILL_TO_SITE_USE_ID BILL_TO_SITE_USE_ID ,
U_BILL . LOCATION BILL_TO_LOCATION ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) BILL_CUST_NAME ,
RTRIM ( RPAD ( LOC . ADDRESS1 , 40 ) ) BILL_ADDRESS1 ,
RTRIM ( RPAD ( LOC . ADDRESS2 , 40 ) ) BILL_ADDRESS2 ,
RTRIM ( RPAD ( LOC . ADDRESS3 , 40 ) ) BILL_ADDRESS3 ,
RTRIM ( RPAD ( LOC . ADDRESS4 , 40 ) ) BILL_ADDRESS4 ,
LOC . CITY BILL_CITY , NVL ( LOC . STATE ,
LOC . PROVINCE ) BILL_STATE ,
LOC . POSTAL_CODE BILL_POSTAL_CODE ,
LOC . COUNTRY BILL_COUNTRY ,
U_BILL . TAX_REFERENCE BILL_SITE_TAX_REFERENCE ,
PARTY . TAX_REFERENCE BILL_CUST_TAX_REFERENCE ,
nvl(amount_line_items_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)), to_number(null)) TRX_LINE_AMOUNT ,
nvl(tax_original, to_number(null)) TRX_TAX_AMOUNT ,
nvl(freight_original, to_number(null)) TRX_FREIGHT_AMOUNT ,
p.amount_due_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)) TRX_ALL_AMOUNT ,
DECODE ( : P_ORDER_BY , 'TRX_NUMBER' , A . TRX_NUMBER , 'ADJUSTMENT_NUMBER' , A.TRX_NUMBER , 'CUSTOMER' , SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) , 'POSTAL_CODE' , LOC . POSTAL_CODE , A . TRX_NUMBER ) ORDER_BY ,
LOC . ADDRESS1 BILL_TO_ADDRESS1 ,
LOC . ADDRESS2 BILL_TO_ADDRESS2 ,
LOC . ADDRESS3 BILL_TO_ADDRESS3 ,
LOC . ADDRESS4 BILL_TO_ADDRESS4 ,
LOC . STATE BILL_TO_STATE ,
LOC . PROVINCE BILL_TO_PROVINCE ,
T . description Term_Description ,
a . org_id ,
a . created_from
FROM
AR_ADJUSTMENTS COM_ADJ,
AR_PAYMENT_SCHEDULES P,
RA_CUST_TRX_LINE_GL_DIST REC,
RA_CUSTOMER_TRX A,
HZ_CUST_ACCOUNTS B,
RA_TERMS T,
RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
HZ_PARTIES PARTY,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
HZ_CUST_SITE_USES U_BILL
WHERE
A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID AND
REC.CUSTOMER_TRX_ID = A.CUSTOMER_TRX_ID AND
REC.LATEST_REC_FLAG = 'Y' AND
REC.ACCOUNT_CLASS = 'REC' AND
P.PAYMENT_SCHEDULE_ID + DECODE ( P.CLASS , 'INV' , 0 , '' ) = COM_ADJ.PAYMENT_SCHEDULE_ID (+) AND
COM_ADJ.SUBSEQUENT_TRX_ID IS NULL AND 'C' = COM_ADJ.ADJUSTMENT_TYPE (+) AND
A.COMPLETE_FLAG = 'Y' AND
A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID AND
L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ' AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
L_TYPES.LOOKUP_CODE = DECODE ( TYPES.TYPE , 'DEP' , 'INV' , TYPES.TYPE ) AND
NVL ( P.TERMS_SEQUENCE_NUMBER , nvl ( TL.SEQUENCE_NUM , 0 ) ) = nvl ( TL.SEQUENCE_NUM , nvl ( p.terms_sequence_number , 0 ) ) AND
DECODE ( P.PAYMENT_SCHEDULE_ID , '' , 0 , NVL ( T.PRINTING_LEAD_DAYS , 0 ) ) = 0 AND
A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID AND
U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID AND
A_BILL.party_site_id = party_site.party_site_id AND
B.PARTY_ID = PARTY.PARTY_ID AND
loc.location_id = party_site.location_id AND
NVL ( P.AMOUNT_DUE_REMAINING , 0 ) <> 0 AND
A.CUST_TRX_TYPE_ID = 2526 AND
TYPES.TYPE = 'INV' AND
A.TERM_ID = TL.TERM_ID (+) AND
A.TERM_ID = T.TERM_ID (+) AND
A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID (+) AND
A.PRINTING_PENDING = 'Y' AND
NVL ( TL.SEQUENCE_NUM , 1 ) > NVL ( A.LAST_PRINTED_SEQUENCE_NUM , 0 ) and 1 = 1 AND
NOT EXISTS ( SELECT 'X' from ECE_TP_DETAILS ETD ,
ECE_TP_HEADERS ETH
WHERE
ETH.TP_HEADER_ID = A_BILL.TP_HEADER_ID AND
ETD.TP_HEADER_ID = ETH.TP_HEADER_ID AND
ETD.EDI_FLAG = 'Y' AND
ETD.DOCUMENT_ID = 'INO' AND
ETD.DOCUMENT_TYPE = DECODE ( TYPES.TYPE , 'CM' , DECODE ( A.PREVIOUS_CUSTOMER_TRX_ID , NULL , 'OACM' , 'CM' ) , TYPES.TYPE ) ) AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
T.NAME not like 'PB%' AND
1 = 1 AND
MIT_AR.GE_AR_COAKLEY_ELIGIBLE ( 'NEW' , P.CUSTOMER_TRX_ID , A.ORG_ID ) = 0 AND
A.org_id = TYPES.org_id UNION SELECT /*+ NO_INDEX(A, RA_CUSTOMER_TRX_N11 ) USE_NL(TYPES,A) */
a.customer_trx_id , a.trx_number ,
A . INTERFACE_HEADER_ATTRIBUTE5 ,
A . INTERFACE_HEADER_CONTEXT ,
A . INTERFACE_HEADER_ATTRIBUTE11 ,
NVL ( P . TERMS_SEQUENCE_NUMBER , 1 ) ,
types.type , l_types.meaning ,
TYPES . ACCOUNTING_AFFECT_FLAG ,
a.trx_date ,
A . SHIP_TO_CUSTOMER_ID ,
A . SHIP_TO_CONTACT_ID ,
A . REMIT_TO_ADDRESS_ID ,
A . PRIMARY_SALESREP_ID ,
B . ACCOUNT_NUMBER ,
A . INTERNAL_NOTES ,
A . COMMENTS ,
PREVIOUS_CUSTOMER_TRX_ID ,
SHIP_TO_SITE_USE_ID ,
NVL ( PRINTING_COUNT , 0 ) ,
PRINTING_ORIGINAL_DATE ,
PRINTING_LAST_PRINTED ,
PRINTING_PENDING ,
LAST_PRINTED_SEQUENCE_NUM ,
START_DATE_COMMITMENT ,
END_DATE_COMMITMENT ,
INITIAL_CUSTOMER_TRX_ID ,
A . INVOICE_CURRENCY_CODE ,
A . REASON_CODE ,
A . TERM_ID ,
A . SHIP_DATE_ACTUAL ,
A . SHIP_VIA ,
A . WAYBILL_NUMBER ,
A . PURCHASE_ORDER ,
A . PURCHASE_ORDER_REVISION ,
A . PURCHASE_ORDER_DATE ,
A . CREATED_BY ,
P . DUE_DATE ,
NVL ( TL . RELATIVE_AMOUNT , 100 ) * ( 100 / NVL ( T . BASE_AMOUNT , 100 ) ) ,
T . NAME , A . BILL_TO_CUSTOMER_ID ,
A . BILL_TO_CONTACT_ID ,
A . BILL_TO_SITE_USE_ID ,
U_BILL . LOCATION BILL_TO_LOCATION ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) BILL_CUST_NAME ,
RTRIM ( RPAD ( LOC . ADDRESS1 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS2 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS3 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS4 , 40 ) ) ,
LOC . CITY ,
NVL ( LOC . STATE , LOC . PROVINCE ) ,
LOC . POSTAL_CODE ,
LOC . COUNTRY ,
U_BILL . TAX_REFERENCE ,
PARTY . TAX_REFERENCE ,
nvl(amount_line_items_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)), to_number(null)) ,
nvl(tax_original, to_number(null)) ,
nvl(freight_original, to_number(null)) ,
p.amount_due_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)) ,
DECODE ( : P_ORDER_BY , 'TRX_NUMBER' ,
A . TRX_NUMBER , 'ADJUSTMENT_NUMBER' ,
A.TRX_NUMBER , 'CUSTOMER' ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) , 'POSTAL_CODE' ,
LOC . POSTAL_CODE , A . TRX_NUMBER ) ORDER_BY ,
LOC . ADDRESS1 ,
LOC . ADDRESS2 ,
LOC . ADDRESS3 ,
LOC . ADDRESS4 ,
LOC . STATE ,
LOC . PROVINCE ,
T . description ,
a . org_id ,
a . created_from
FROM
RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
HZ_CUST_ACCOUNTS B,
HZ_PARTIES PARTY,
HZ_CUST_SITE_USES U_BILL,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
AR_ADJUSTMENTS COM_ADJ,
RA_CUSTOMER_TRX A,
AR_PAYMENT_SCHEDULES P,
RA_TERMS T
WHERE
A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID
AND P.PAYMENT_SCHEDULE_ID + DECODE ( P.CLASS , 'INV' , 0 , '' ) = COM_ADJ.PAYMENT_SCHEDULE_ID (+) AND
COM_ADJ.SUBSEQUENT_TRX_ID IS NULL AND
'C' = COM_ADJ.ADJUSTMENT_TYPE (+) AND
A.COMPLETE_FLAG = 'Y' AND
A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID AND
A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID AND
L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ' AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
L_TYPES.LOOKUP_CODE = DECODE ( TYPES.TYPE , 'DEP' , 'INV' , TYPES.TYPE ) AND
NVL ( T.PRINTING_LEAD_DAYS , 0 ) > 0 AND
A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID AND
U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID AND
A_BILL.PARTY_SITE_ID = PARTY_SITE.PARTY_SITE_ID AND
B.PARTY_ID = PARTY.PARTY_ID AND
LOC.LOCATION_ID = PARTY_SITE.LOCATION_ID AND
NVL ( P.TERMS_SEQUENCE_NUMBER , TL.SEQUENCE_NUM ) = TL.SEQUENCE_NUM AND
NVL ( P.AMOUNT_DUE_REMAINING , 0 ) <> 0 AND
A.CUST_TRX_TYPE_ID = 2526 AND
TYPES.TYPE = 'INV' AND
T.TERM_ID = P.TERM_ID AND
TL.TERM_ID (+) = T.TERM_ID AND
A.PRINTING_PENDING = 'Y' AND
P.TERMS_SEQUENCE_NUMBER > NVL ( A.LAST_PRINTED_SEQUENCE_NUM , 0 ) and 1 = 1 AND
NOT EXISTS ( SELECT 'X' from
ECE_TP_DETAILS ETD ,
ECE_TP_HEADERS ETH
WHERE
ETH.TP_HEADER_ID = A_BILL.TP_HEADER_ID AND
ETD.TP_HEADER_ID = ETH.TP_HEADER_ID AND
ETD.EDI_FLAG = 'Y' AND
ETD.DOCUMENT_ID = 'INO' AND
ETD.DOCUMENT_TYPE = DECODE ( TYPES.TYPE , 'CM' , DECODE ( A.PREVIOUS_CUSTOMER_TRX_ID , NULL , 'OACM' , 'CM' ) , TYPES.TYPE ) ) AND
NVL ( A.PRINTING_OPTION , 'REP' ) IN ( 'PRI' , 'REP' ) AND
T.NAME not like 'PB%' AND 1 = 1 AND
MIT_AR.GE_AR_COAKLEY_ELIGIBLE ( 'NEW' , P.CUSTOMER_TRX_ID , A.ORG_ID ) = 0 AND
A.org_id = TYPES.org_id
ORDER BY 60 ASC,68 ASC,2 ASC,3 ASC,4 ASC,5 ASC,44 ASC
call count cpu elapsed disk query current rows
Parse 1 0.06 0.08 0 364 0 0
Execute 1 5.11 4.98 0 0 0 0
Fetch 18 81.35 1375.73 203636 357435 0 34
total 20 86.52 1380.80 203636 357799 0 34
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 25
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
34 34 34 SORT UNIQUE (cr=569992 pr=227554 pw=0 time=1658548772 us)
34 34 34 UNION-ALL (cr=569992 pr=227554 pw=0 time=773822949 us)
34 34 34 FILTER (cr=228022 pr=107808 pw=0 time=773820837 us)
34 34 34 FILTER (cr=228022 pr=107808 pw=0 time=773820394 us)
34 34 34 NESTED LOOPS OUTER (cr=228022 pr=107808 pw=0 time=771070499 us)
34 34 34 NESTED LOOPS (cr=227986 pr=107806 pw=0 time=773799735 us)
34 34 34 NESTED LOOPS (cr=227882 pr=107806 pw=0 time=773742298 us)
34 34 34 NESTED LOOPS (cr=227812 pr=107806 pw=0 time=773688021 us)
34 34 34 NESTED LOOPS (cr=227708 pr=107806 pw=0 time=773636699 us)
34 34 34 FILTER (cr=227638 pr=107806 pw=0 time=773566978 us)
4616 4616 4616 NESTED LOOPS OUTER (cr=220679 pr=106836 pw=0 time=823009777 us)
4610 4610 4610 NESTED LOOPS (cr=206836 pr=102712 pw=0 time=623651066 us)
4610 4610 4610 NESTED LOOPS (cr=188367 pr=96450 pw=0 time=531982352 us)
4610 4610 4610 NESTED LOOPS (cr=179145 pr=96449 pw=0 time=530980660 us)
4610 4610 4610 FILTER (cr=165290 pr=96448 pw=0 time=529149297 us)
4610 4610 4610 NESTED LOOPS OUTER (cr=165290 pr=96448 pw=0 time=530066499 us)
4607 4607 4607 NESTED LOOPS (cr=156074 pr=96442 pw=0 time=762671095 us)
4615 4615 4615 NESTED LOOPS (cr=146842 pr=96441 pw=0 time=751255741 us)
4615 4615 4615 NESTED LOOPS (cr=137610 pr=96435 pw=0 time=751144978 us)
4615 4615 4615 NESTED LOOPS (cr=123763 pr=96435 pw=0 time=750949543 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=96435 pw=0 time=750675597 us)
*329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6046 pw=0 time=31982795 us)(object id 4788)* 4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=239450 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=160139 us)(object id 55731)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=13847 pr=0 pw=0 time=180337 us)
4615 4615 4615 INDEX UNIQUE SCAN FND_LOOKUP_VALUES_U1 (cr=9232 pr=0 pw=0 time=135717 us)(object id 491822)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_TERMS_B (cr=9232 pr=6 pw=0 time=155074 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_TERMS_B_U1 (cr=4617 pr=0 pw=0 time=60566 us)(object id 55734)
4607 4607 4607 TABLE ACCESS BY INDEX ROWID RA_TERMS_TL (cr=9232 pr=1 pw=0 time=181115 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_TERMS_TL_U1 (cr=4617 pr=1 pw=0 time=82153 us)(object id 55755)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID RA_TERMS_LINES (cr=9216 pr=6 pw=0 time=259864 us)
4610 4610 4610 INDEX RANGE SCAN RA_TERMS_LINES_U1 (cr=4609 pr=1 pw=0 time=104110 us)(object id 6703)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=13855 pr=1 pw=0 time=1350357 us)
4610 4610 4610 INDEX UNIQUE SCAN HZ_CUST_SITE_USES_U1 (cr=9222 pr=1 pw=0 time=434079 us)(object id 44870)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=9222 pr=1 pw=0 time=1024466 us)
4610 4610 4610 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U1 (cr=4612 pr=1 pw=0 time=337477 us)(object id 46883)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_LINE_GL_DIST_ALL (cr=18469 pr=6262 pw=0 time=86754686 us)
4610 4610 4610 INDEX RANGE SCAN RA_CUST_TRX_LINE_GL_DIST_N6 (cr=13836 pr=4061 pw=0 time=55844483 us)(object id 1510967)
4616 4616 4616 TABLE ACCESS BY INDEX ROWID AR_PAYMENT_SCHEDULES_ALL (cr=13843 pr=4124 pw=0 time=50689789 us)
4616 4616 4616 INDEX RANGE SCAN AR_PAYMENT_SCHEDULES_N2 (cr=9233 pr=1494 pw=0 time=15169412 us)(object id 4877)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=70 pr=0 pw=0 time=24450 us)
34 34 34 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (cr=36 pr=0 pw=0 time=5962 us)(object id 85278)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES (cr=104 pr=0 pw=0 time=58609 us)
34 34 34 INDEX UNIQUE SCAN HZ_PARTY_SITES_U1 (cr=70 pr=0 pw=0 time=31189 us)(object id 45527)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS (cr=70 pr=0 pw=0 time=52502 us)
34 34 34 INDEX UNIQUE SCAN HZ_LOCATIONS_U1 (cr=36 pr=0 pw=0 time=23883 us)(object id 45692)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=104 pr=0 pw=0 time=49042 us)
34 34 34 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=70 pr=0 pw=0 time=22106 us)(object id 757879)
0 0 0 TABLE ACCESS BY INDEX ROWID AR_ADJUSTMENTS_ALL (cr=36 pr=2 pw=0 time=19638 us)
0 0 0 INDEX RANGE SCAN AR_ADJUSTMENTS_N3 (cr=36 pr=2 pw=0 time=19271 us)(object id 5473)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=9 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_HEADERS_U1 (cr=0 pr=0 pw=0 time=7 us)(object id 46119)
0 0 0 TABLE ACCESS BY INDEX ROWID ECE_TP_DETAILS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_DETAILS_U2 (cr=0 pr=0 pw=0 time=0 us)(object id 6271)
0 0 0 FILTER (cr=341970 pr=119746 pw=0 time=883424760 us)
0 0 0 FILTER (cr=341970 pr=119746 pw=0 time=883424758 us)
0 0 0 NESTED LOOPS OUTER (cr=341970 pr=119746 pw=0 time=883424757 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424752 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424749 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424742 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424740 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424735 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424731 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424726 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424724 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424721 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424715 us)
34 34 34 NESTED LOOPS (cr=341900 pr=119746 pw=0 time=882400482 us)
4615 4615 4615 NESTED LOOPS (cr=123763 pr=93484 pw=0 time=674293279 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=93484 pw=0 time=674030164 us)
329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6130 pw=0 time=36621510 us)(object id 4788)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=249893 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=169485 us)(object id 55731)
34 34 34 TABLE ACCESS BY INDEX ROWID AR_PAYMENT_SCHEDULES_ALL (cr=218137 pr=26262 pw=0 time=310068873 us)
3304 3304 3304 INDEX RANGE SCAN AR_PAYMENT_SCHEDULES_N2 (cr=214841 pr=24355 pw=0 time=283359418 us)(object id 4877)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_B (cr=70 pr=0 pw=0 time=829 us)
34 34 34 INDEX UNIQUE SCAN RA_TERMS_B_U1 (cr=36 pr=0 pw=0 time=527 us)(object id 55734)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_SITE_USES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 44870)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 46883)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 85278)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 757879)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_PARTY_SITES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 45527)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 45692)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_TL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN RA_TERMS_TL_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 55755)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_LINES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX RANGE SCAN RA_TERMS_LINES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 6703)
0 0 0 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 491822)
0 0 0 TABLE ACCESS BY INDEX ROWID AR_ADJUSTMENTS_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX RANGE SCAN AR_ADJUSTMENTS_N3 (cr=0 pr=0 pw=0 time=0 us)(object id 5473)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 46119)
0 0 0 TABLE ACCESS BY INDEX ROWID ECE_TP_DETAILS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_DETAILS_U2 (cr=0 pr=0 pw=0 time=0 us)(object id 6271)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 6 0.00 0.00
SQL*Net message to client 18 0.00 0.00
SQL*Net more data to client 2 0.00 0.00
gc current block 2-way 5375 0.02 3.76
gc cr grant 2-way 49175 0.05 24.09
db file sequential read 203636 0.51 1289.70
gcs drm freeze in enter server mode 7 0.28 1.30
latch: KCL gc element parent latch 4 0.00 0.00
gc remaster 2 0.07 0.12
latch: gcs resource hash 26 0.00 0.00
latch free 1 0.00 0.00
gc cr block 2-way 9 0.00 0.00
latch: cache buffers chains 1 0.00 0.00
SQL*Net message from client 18 0.00 0.00
Thanks in Advance..Hi,
it looks like your problem stems from the wrong choice of the driving table:
4615 4615 4615 NESTED LOOPS (cr=123763 pr=96435 pw=0 time=750949543 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=96435 pw=0 time=750675597 us)
329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6046 pw=0 time=31982795 us)(object id 4788) 4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=239450 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=160139 us)(object id 55731)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=13847 pr=0 pw=0 time=180337 us)Here, you are spending 750 seconds retriveing 329k rows, 98% of which are rejected on the next step. And the reason this is happening is because the optimizer underestimates the cardinatlity of this step by a factor of x50 (6.2k estimated, 329k actual value). Find out why this is happening or post relevant diagnostic information here (predicates, columns stats etc.), and fix this -- this should make your query twice as fast.
The second half is coming from the SORT UNIQUE step. This looks weird: why on Earth it would take over 800 seconds to sort 34 rows?! Maybe there is something in the plan that I'm missing -- it's really hard to read because it's not formatted. Please obtain a plan with rowsource stats using dbms_xplan.display_cursor and post it here (google dbms_xplan.display_cursor allstats last if not sure how to do that).
Best regards,
Nikolay -
Please reply for the query tuning
Hi, i am a beginner in oracle dba, I have to know if i have studied little bit about query tuning in ORACLE.
I wanna know if i have the following query and its plan then how it can be tuned:
QUERY:
SELECT z.emplid ,h.first_name || ' ' || h.last_name ,z.grade ,z.DEPTID ,z.LOCATION
FROM sysadm.ps_lnt_latestbu_vw z, sysadm.ps_personal_data h
WHERE z.empl_status ='A' --index access
AND z.emplid = h.emplid --join
and z.emplid not in (select g.emplid from sysadm.ps_lnt_asn_skl_tbl g) --join
and z.Business_unit=
( select l.lnt_subunit from sysadm.ps_position_data l where l.position_nbr in
( select b.position_nbr from sysadm.ps_job b,sysadm.psoprdefn y
where b.effdt=( select max(g.effdt) from sysadm.ps_job g
where g.emplid=b.emplid --join costs high
and g.effdt<=SYSDATE) --filter/index
and b.effseq=
(select max(h.effseq) from sysadm.ps_job h
where h.emplid=b.emplid --join costs high
and h.effdt=b.effdt) --join costs high
and b.empl_rcd=0 --filter/index access
and y.EMPLID=b.EMPLID --join
and y.OPRID='1112' -- filter/index access
order by z.emplid
/AND its plan is:
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1 Bytes=64)
1 0 SORT (ORDER BY) (Cost=6 Card=1 Bytes=64)
2 1 NESTED LOOPS (ANTI) (Cost=4 Card=1 Bytes=64)
3 2 NESTED LOOPS (Cost=3 Card=1 Bytes=56)
4 3 VIEW OF 'PS_LNT_LATESTBU_VW' (Cost=2 Card=1 Bytes=31)
5 4 UNION-ALL
6 5 CONCATENATION
7 6 TABLE ACCESS (BY INDEX ROWID) OF 'PS_POSITION_DATA' (Cost=5 Card=90 Bytes=1890)
8 7 NESTED LOOPS
9 8 NESTED LOOPS (Cost=275 Card=1 Bytes=90)
10 9 NESTED LOOPS (Cost=275 Card=1 Bytes=82)
11 10 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=50)
12 11 INDEX (RANGE SCAN) OF 'PS2JOB' (NON-UNIQUE) (Cost=2 Card=1)
13 12 SORT (AGGREGATE)
14 13 FIRST ROW (Cost=3 Card=1 Bytes=19)
15 14 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
16 12 SORT (AGGREGATE)
17 16 FIRST ROW (Cost=3 Card=1 Bytes=22)
18 17 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
19 10 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT'(UNIQUE)
20 9 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
21 8 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=5 Card=90)
22 6 FILTER
23 22 NESTED LOOPS (Cost=275 Card=1 Bytes=90)
24 23 NESTED LOOPS (Cost=275 Card=1 Bytes=82)
25 24 NESTED LOOPS (Cost=275 Card=1 Bytes=71)
26 25 INDEX (FAST FULL SCAN) OF 'PS8POSITION_DATA' (NON-UNIQUE) (Cost=5 Card=90 Bytes=1890)
27 25 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=50)
28 27 INDEX (RANGE SCAN) OF 'PS2JOB' (NON-UNIQUE) (Cost=2 Card=1)
29 28 SORT (AGGREGATE)
30 29 FIRST ROW (Cost=3 Card=1 Bytes=22)
31 30 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
32 28 SORT (AGGREGATE)
33 32 FIRST ROW (Cost=3 Card=1 Bytes=19)
34 33 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
35 24 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT' (UNIQUE)
36 23 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA'(UNIQUE)
37 22 SORT (AGGREGATE)
38 37 FIRST ROW (Cost=2 Card=1 Bytes=17)
39 38 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
40 5 FILTER
41 40 NESTED LOOPS (Cost=751 Card=1 Bytes=191)
42 41 NESTED LOOPS (OUTER) (Cost=750 Card=1 Bytes=167)
43 42 NESTED LOOPS (OUTER) (Cost=749 Card=1 Bytes=143)
44 43 NESTED LOOPS (Cost=748 Card=1 Bytes=134)
45 44 NESTED LOOPS (Cost=748 Card=1 Bytes=123)
46 45 NESTED LOOPS (Cost=748 Card=1 Bytes=119)
47 46 NESTED LOOPS (Cost=747 Card=1 Bytes=98)
48 47 NESTED LOOPS (Cost=744 Card=1 Bytes=62)
49 48 NESTED LOOPS (Cost=744 Card=1Bytes=54)
50 49 VIEW OF 'PS_LNTPRJOBSYSJRVW'(Cost=741 Card=1 Bytes=9)
51 50 FILTER
52 51 NESTED LOOPS (OUTER) (Cost=735 Card=1 Bytes=68)
53 52 NESTED LOOPS (Cost=734Card=1 Bytes=51)
54 53 NESTED LOOPS (Cost=734 Card=1 Bytes=43)
55 54 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=734 Card=1 Bytes=32)
56 55 INDEX (RANGE SCAN) OF 'PSCJOB' (NON-UNIQUE) (Cost=206 Card=1013)
57 54 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT' (UNIQUE)
58 53 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
59 52 INDEX (RANGE SCAN) OF'PS_POSITION_DATA' (UNIQUE) (Cost=1 Card=1 Bytes=17)
60 51 SORT (AGGREGATE)
61 60 FIRST ROW (Cost=3 Card=1 Bytes=19)
62 61 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
63 51 SORT (AGGREGATE)
64 63 FIRST ROW (Cost=3 Card=1 Bytes=22)
65 64 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
66 51 SORT (AGGREGATE)
67 66 FIRST ROW (Cost=2 Card=1 Bytes=17)
68 67 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
69 49 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=45)
70 69 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=2 Card=1)
71 70 SORT (AGGREGATE)
72 71 INDEX (RANGE SCAN) OF'PSAJOB' (NON-UNIQUE) (Cost=3 Card=1 Bytes=19)
73 72 SORT (AGGREGATE)
74 73 FIRST ROW (Cost=3Card=8 Bytes=88)
75 74 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=25963)
76 70 SORT (AGGREGATE)
77 76 FIRST ROW (Cost=3 Card=8 Bytes=88)
78 77 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=25963)
79 48 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
80 47 TABLE ACCESS (BY INDEX ROWID) OF'PS_JOB' (Cost=3 Card=1 Bytes=36)
81 80 INDEX (RANGE SCAN) OF 'PSAJOB'(NON-UNIQUE) (Cost=2 Card=1)
82 81 SORT (AGGREGATE)
83 82 FIRST ROW (Cost=3 Card=1 Bytes=19)
84 83 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
85 81 SORT (AGGREGATE)
86 85 FIRST ROW (Cost=3 Card=1 Bytes=22)
87 86 INDEX (RANGE SCAN (MIN/MAX)) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=207700)
88 46 INDEX (RANGE SCAN) OF 'PS8POSITION_DATA' (NON-UNIQUE) (Cost=1 Card=1 Bytes=21)
89 45 INDEX (UNIQUE SCAN) OF 'PS_BUS_UNIT_TBL_HR' (UNIQUE)
90 44 INDEX (UNIQUE SCAN) OF 'PS_EMPLOYMENT'(UNIQUE)
91 43 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA'(UNIQUE) (Cost=1 Card=1 Bytes=9)
92 42 INDEX (FULL SCAN) OF 'PS0LOCATION_TBL' (NON-UNIQUE) (Cost=1 Card=1 Bytes=24)
93 41 INDEX (RANGE SCAN) OF 'PS0LOCATION_TBL' (NON-UNIQUE) (Cost=1 Card=1 Bytes=24)
94 40 SORT (AGGREGATE)
95 94 FIRST ROW (Cost=2 Card=1 Bytes=17)
96 95 INDEX (RANGE SCAN (MIN/MAX)) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=2 Card=9000)
97 4 TABLE ACCESS (BY INDEX ROWID) OF 'PS_POSITION_DATA' (Cost=2 Card=1 Bytes=13)
98 97 NESTED LOOPS (Cost=9 Card=1 Bytes=19)
99 98 VIEW OF 'VW_NSO_1' (Cost=5 Card=1 Bytes=6)
100 99 SORT (UNIQUE)
101 100 NESTED LOOPS (Cost=5 Card=1 Bytes=44)
102 101 TABLE ACCESS (BY INDEX ROWID) OF 'PSOPRDEFN' (Cost=2 Card=1 Bytes=14)
103 102 INDEX (UNIQUE SCAN) OF 'PS_PSOPRDEFN'(UNIQUE) (Cost=1 Card=1)
104 101 TABLE ACCESS (BY INDEX ROWID) OF 'PS_JOB' (Cost=3 Card=1 Bytes=30)
105 104 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=2 Card=1)
106 105 SORT (AGGREGATE)
107 106 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=8 Bytes=128)
108 105 SORT (AGGREGATE)
109 108 INDEX (RANGE SCAN) OF 'PSAJOB' (NON-UNIQUE) (Cost=3 Card=1 Bytes=19)
110 98 INDEX (RANGE SCAN) OF 'PS_POSITION_DATA' (UNIQUE) (Cost=1 Card=1)
111 3 TABLE ACCESS (BY INDEX ROWID) OF 'PS_PERSONAL_DATA'(Cost=1 Card=1 Bytes=25)
112 111 INDEX (UNIQUE SCAN) OF 'PS_PERSONAL_DATA' (UNIQUE)
113 2 INDEX (RANGE SCAN) OF 'PS_LNT_ASN_SKL_TBL' (UNIQUE) (Cost=1 Card=10076 Bytes=80608)
Statistics
70 recursive calls
0 db block gets
1186931 consistent gets
5660 physical reads
60 redo size
462 bytes sent via SQL*Net to client
373 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
0 rows processedMy thoughts for this is:
1. NLJ high cost -- rewrite inner sub-query
2. sort is done for each join for max function every time so, therefore try use use sort merge hint
3. h alias has been referenced twice for table name.
PLEASE TELL ME WHAT TO DO IF I AM ORACLE DBA.
Thanks in advance.
Edited by: user2060331 on Mar 25, 2010 9:17 AM
Edited by: user2060331 on Mar 25, 2010 9:21 AM
Edited by: user2060331 on Mar 25, 2010 9:32 AM
Edited by: user2060331 on Mar 25, 2010 9:47 AMNo it's not. You should see indentations for each level of the explain plan. You've lost all of it. It should look like this (not your query):
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 16116 | 2911K| 712 | | |
| 1 | FILTER | | | | | | |
| 2 | CONNECT BY WITH FILTERING | | | | | | |
| 3 | FILTER | | | | | | |
| 4 | COUNT | | | | | | |
| 5 | HASH JOIN RIGHT OUTER | | 16116 | 2911K| 712 | | |
| 6 | REMOTE | LSW_USR_GRP_XREF | 518 | 13986 | 4 | MYPROJ~ | R->S |
| 7 | HASH JOIN RIGHT OUTER | | 16116 | 2486K| 707 | | |
| 8 | REMOTE | LSW_USR_XREF | 222 | 2886 | 4 | MYPROJ~ | R->S |
| 9 | HASH JOIN RIGHT OUTER| | 16116 | 2282K| 702 | | |
| 10 | TABLE ACCESS FULL | MYPROJ_PROCESS_MAP | 176 | 4752 | 4 | | |
| 11 | HASH JOIN OUTER | | 16116 | 1857K| 698 | | |
| 12 | TABLE ACCESS FULL | MYPROJ_MPPA | 16116 | 1243K| 71 | | |
| 13 | REMOTE | LSW_TASK | 80730 | 3074K| 625 | MYPROJ~ | R->S |
| 14 | HASH JOIN | | | | | | |
| 15 | CONNECT BY PUMP | | | | | | |
| 16 | COUNT | | | | | | |
| 17 | HASH JOIN RIGHT OUTER | | 16116 | 2911K| 712 | | |
| 18 | REMOTE | LSW_USR_GRP_XREF | 518 | 13986 | 4 | MYPROJ~ | R->S |
| 19 | HASH JOIN RIGHT OUTER | | 16116 | 2486K| 707 | | |
| 20 | REMOTE | LSW_USR_XREF | 222 | 2886 | 4 | MYPROJ~ | R->S |
| 21 | HASH JOIN RIGHT OUTER| | 16116 | 2282K| 702 | | |
| 22 | TABLE ACCESS FULL | MYPROJ_PROCESS_MAP | 176 | 4752 | 4 | | |
| 23 | HASH JOIN OUTER | | 16116 | 1857K| 698 | | |
| 24 | TABLE ACCESS FULL | MYPROJ_MPPA | 16116 | 1243K| 71 | | |
| 25 | REMOTE | LSW_TASK | 80730 | 3074K| 625 | MYPROJ~ | R->S |
--------------------------------------------------------------------------------------------------- -
Query Tuning (sequential read + direct path read/write temp)
Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
Below is the tkprof:
SELECT
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
ELSE 0
END) BILL
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END) PAY
, SUM(FT.CUR_AMT) DUE
, SUM(CASE
WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END
ELSE 0
END) PAY_02JUN
FROM
CI_FT FT
, CI_SA SA
, CI_ACCT_CHAR AC
, CI_CUST_CL_L CL
, CI_ACCT A
, CI_ACCT_PER AP
SELECT
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
, MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB ', PP.PHONE)) MOB
, MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN ', PP.PHONE)) BUS
, MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME ', PP.PHONE)) HOME
, MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX ', PP.PHONE)) FAX
, MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
, MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
, MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION ', PC.CHAR_VAL)) NATION
FROM
CI_PER P
, CI_PER_PHONE PP
, CI_PER_NAME PN
, CI_PER_CHAR PC
WHERE
P.PER_ID = PP.PER_ID (+)
AND P.PER_ID = PN.PER_ID (+)
AND P.PER_ID = PC.PER_ID (+)
GROUP BY
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
) P
WHERE
P.PER_ID = AP.PER_ID
AND AP.ACCT_ID = AC.ACCT_ID
AND AP.ACCT_ID = SA.ACCT_ID
AND AP.MAIN_CUST_SW = 'Y'
AND A.ACCT_ID = SA.ACCT_ID
AND A.ACCT_ID = AP.ACCT_ID
AND AC.CHAR_TYPE_CD = 'ACCTYPE'
AND AC.CHAR_VAL IN ('UOS', 'DEFAULT')
AND AC.ACCT_ID = SA.ACCT_ID
AND CL.LANGUAGE_CD = 'ENG'
AND A.ACCT_ID = AC.ACCT_ID
AND A.CUST_CL_CD = CL.CUST_CL_CD
AND SA.SA_ID = FT.SA_ID
AND FT.FREEZE_DTTM IS NOT NULL
GROUP BY
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
HAVING
SUM(FT.CUR_AMT) > 0
call count cpu elapsed disk query current rows
Parse 1 0.64 0.64 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 304 353.09 430.04 21720 52997832 0 4543
total 306 353.73 430.69 21720 52997832 0 4543
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 79 (CISADM)
Rows Row Source Operation
4543 FILTER (cr=52997832 pr=21720 pw=10311 time=430019418 us)
5412 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
199471 VIEW (cr=52997832 pr=21720 pw=10311 time=423392346 us)
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655 pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
571492 NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
286061 NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
123411 NESTED LOOPS (cr=1989056 pr=2642 pw=0 time=22711194 us)
123411 NESTED LOOPS (cr=1864959 pr=2642 pw=0 time=20860026 us)
123411 NESTED LOOPS (cr=1494040 pr=1754 pw=0 time=15553373 us)
243088 NESTED LOOPS (cr=29540 pr=1754 pw=0 time=10213331 us)
13227 TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
243088 INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
123411 INLIST ITERATOR (cr=1464500 pr=0 pw=0 time=7220251 us)
123411 INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
123411 TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
123411 INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
123411 TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
123411 INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
283749 TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
283749 INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
571492 INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
2777066 TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 304 0.00 0.00
db file sequential read 11366 0.34 65.63
direct path write temp 1473 0.06 2.91
latch: cache buffers chains 17 0.00 0.00
db file scattered read 7 0.01 0.03
read by other session 2 0.00 0.00
direct path read temp 1473 0.03 6.85
SQL*Net message from client 304 0.02 2.74
SQL*Net more data to client 292 0.00 0.00
********************************************************************************Luckys
I've just realised that I mis-read part of your plan:
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
I shall be using the Hints as advised, when we say we
have to "rewrite the query"
given the current context excluding the HINTS, what
exactly should I be
considering in terms of query rewrite, what
additional intelligence I can add to the
query in question so that CBO produces a different
plan.
The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
When are talking about high intermediate rows
processing are we referring to this
section of the plan?;
4013304 TABLE ACCESS BY INDEX ROWID CI_FT
(cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987
pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655
pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432
pr=2950 pw=0 time=38953485 us)
2777066 TABLE ACCESS BY INDEX ROWID
CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156
pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA
(cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1
(cr=5688247 pr=104 pw=0 time=51063061 us)(object id
98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335
pr=1332 pw=0 time=124063022 us)(object id 116797)
Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
Moreover tables have been analyzed:
CI_ACCT 243068
CI_ACCT_CHAR 222320
CI_ACCT_PER 242971
CI_FT 794510
CI_PER 13227
CI_PER_CHAR 42555
CI_PER_PHONE 18488
CI_SA 1082301
Parameters:
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking. -
Query tuning : you can do it yourself
Hello,
This thread is not a question.
How tune my query ?
My query didn't use indexes why ?
I have indexes on table, stats are up-to-date why Oracle does a full scan on table ?
What are the hint which I can use ?
etc...
I would like try to answer to many such questions posted in this forum about query tuning.
And explain that tuning is not always complicated, is not always reserved to some consultants, is not always solved by hints usage, and not require to buy some books which would give some magic solutions.
By this thread, I would explain to people which have some query performance issues, that the solution is maybe here, in front of their eyes, inside the query itself. The solution may come from their own side, and that they can be happy to solve such question themself.
I'll develop here below a case from a real word situation encountered some time ago.At this point, remove this huge and nightmarish hint. We'll use it only if no other ways may found.
First, a look into the data model to see if the joins may be rewrite differently.
Original joins :
dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID and
dw.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID and
dw.REGION_ROUTING_ID = rr.REGION_ROUTING_ID and
dw.CITY_ROUTING_ID = cr.CITY_ROUTING_ID andAnd indeed, the join may be rewrite as below :
and dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID
and ar.CITY_ROUTING_ID = cr.CITY_ROUTING_ID
and cr.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID
and cor.REGION_ROUTING_ID = rr.REGION_ROUTING_IDNote the aliases were change here. Is it complicated to try to rewrite query like that ?
Secondly, we will try to see how avoid or, at least, workaround the all OR conditions. It would be well if we could merge all the FROM (bind variable :a) in one column, same for all TO (bind variable :b), unfortunately, the data model cannot be change (of course). Ok, we will try to work with a temporary table by combining all the possiblities between the two conditions.
create global temporary table REGION_ROUTING_TMP
on commit preserve rows
as
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP1 as REGION_TO
from REGION_ROUTING
where 1=2;And an index based on the two mains criteria of the query may help :
create index IDX_REGION_ROUTING_TMP on REGION_ROUTING_TMP(REGION_FROM,REGION_TO);Then we'll populate table :
insert into REGION_ROUTING_TMP
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP1 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP2 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_FROM as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_STOP2 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP1 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP2 as REGION_FROM, REGION_STOP3 as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP2 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING
union
select REGION_ROUTING_NAMES, REGION_ROUTING_ID, REGION_STOP3 as REGION_FROM, REGION_TO as REGION_TO
from REGION_ROUTING;The insert take near 9 seconds, which is a reasonnable elapse time.
At this point, the query become :
Select
ap.AIRPORT_PAIR,
dw.DELIVERY_PERIOD,
dw.TOTAL_PAX As Demand,
od.GLOBAL_TOTAL_PAX as Total_OD_Demand,
dw.REPORTED_PAX As ReportedPax,
ap.AIRPORT_FROM,
ap.AIRPORT_TO,
ap.CITY_FROM,
ap.CITY_TO,
ap.COUNTRY_FROM_NAME,
ap.COUNTRY_TO_NAME,
ap.REGION_FROM_NAME,
ap.REGION_TO_NAME,
ar.AIRPORT_ROUTING,
cr.CITY_ROUTING,
cor.COUNTRY_ROUTING_NAMES,
rr.REGION_ROUTING_NAMES,
ar.NUMBER_OF_STOP,
dw.PERCENT_OF_TOTAL_PAX_VS_OD,
dw.AIRLINE1,
dw.AIRLINE2,
dw.AIRLINE3,
dw.AIRLINE4,
dw.NUMBER_OF_AIRLINE,
dw.AIRCRAFTCLASS_NAME,
dw.FARE
From
REGION_ROUTING_TMP rr, -- here we use now the temporary table instead of REGION_ROUTING table
DETAILED_FLIGHTS dw,
AIRPORT_PAIR ap,
AIRPORT_ROUTING ar,
CITY_ROUTING cr,
COUNTRY_ROUTING cor,
OD od
where
dw.DELIVERY_PERIOD in ('2006-09','2006-08','2006-07')
and dw.AIRPORT_PAIR_ID = ap.AIRPORT_PAIR_ID
and dw.OD_ID = od.OD_ID
and dw.AIRPORT_ROUTING_ID = ar.AIRPORT_ROUTING_ID
and ar.CITY_ROUTING_ID = cr.CITY_ROUTING_ID
and cr.COUNTRY_ROUTING_ID = cor.COUNTRY_ROUTING_ID
and cor.REGION_ROUTING_ID = rr.REGION_ROUTING_ID
and rr.REGION_FROM = '7' |
and rr.REGION_TO = '8' |-> these two lines replace all the OR conditions;And explain plan :
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 469 | 174K| 3462 | | |
| 1 | NESTED LOOPS | | 469 | 174K| 3462 | | |
| 2 | NESTED LOOPS | | 458 | 166K| 3004 | | |
| 3 | NESTED LOOPS | | 454 | 127K| 2096 | | |
| 4 | NESTED LOOPS | | 258 | 58308 | 548 | | |
| 5 | NESTED LOOPS | | 246 | 48216 | 56 | | |
| 6 | NESTED LOOPS | | 26 | 4420 | 4 | | |
| 7 | TABLE ACCESS BY INDEX ROWID | REGION_ROUTING_TMP | 1 | 123 |
|* 8 | INDEX RANGE SCAN | IDX_REGION_ROUTING_TMP | 1 | | 1 | |
| 9 | TABLE ACCESS BY INDEX ROWID | COUNTRY_ROUTING | 32 | 1504 | 2
|* 10 | INDEX RANGE SCAN | IX9_COUNTRY_ROUTING | 32 | | 1 | |
| 11 | TABLE ACCESS BY INDEX ROWID | CITY_ROUTING | 9 | 234 | 2 |
|* 12 | INDEX RANGE SCAN | IX9_CITY_ROUTING | 12 | | 1 |
| 13 | TABLE ACCESS BY INDEX ROWID | AIRPORT_ROUTING | 1 | 30 | 2
|* 14 | INDEX RANGE SCAN | IX10_AIRPORT_ROUTING | 1 | | 1 |
|* 15 | TABLE ACCESS BY GLOBAL INDEX ROWID| DETAILED_FLIGHTS | 2 | 122 |
|* 16 | INDEX RANGE SCAN | IX3_DETAILED_FLIGHTS | 9 | | 2 |
| 17 | TABLE ACCESS BY INDEX ROWID | AIRPORT_PAIR | 1 | 85 | 2 |
|* 18 | INDEX RANGE SCAN | IX1_AIRPORT_PAIR | 1 | | 1 | |
| 19 | TABLE ACCESS BY INDEX ROWID | OD | 1 | 10 | 1 | |
|* 20 | INDEX UNIQUE SCAN | PK_OD | 1 | | | | |
----------------------------------------------------------------------------------------------------Ouf, this sound like better, isn't it ? Was it complicated to arrive as such result ?
Ok, now launch the query and see the elapse time :
104103 rows selected.
Elapsed: 00:09:00.12
Statistics
0 recursive calls
0 db block gets
1214845 consistent gets
272481 physical reads
0 redo size
11164355 bytes sent via SQL*Net to client
257032 bytes received via SQL*Net from client
6942 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
104103 rows processedWoaw, developer is now very happy, less than 10 minutes instead of one hour... and without modify anything else in database and server settings, without add indexes, without add any hints...
Ok, now the problem is in the number of returned lines. Have you see the number of return client/server ? We'll now to try to reduce this one. Increasing the number of line returned by fetch :
set arraysize 5000
--run the query
104103 rows selected.
Elapsed: 00:02:25.49
Statistics
0 recursive calls
0 db block gets
1150893 consistent gets
271432 physical reads
0 redo size
11018641 bytes sent via SQL*Net to client
1013 bytes received via SQL*Net from client
22 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
104103 rows processedOk, the number of retunr client/server is now low, and elapse time is ok user. -
Wrong cardinality estimate for range scan
select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - ProductionSQL : select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=:b1 and GC_FULFILLMENT_STATUS_ID=:b2;
Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 474K| 99M| 102 (85)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 474K| 99M| 102 (85)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 474K| | 91 (95)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=TO_NUMBER(:B2) AND "MARKETPLACE_ID"=TO_NUMBER(:B1))
filter("MARKETPLACE_ID"=TO_NUMBER(:B1))If i use literals than CBO uses cardinality =1 (I believe this is due it fix control :5483301 which i set to off In my environment)
select * from GC_FULFILLMENT_ITEMS where MARKETPLACE_ID=5 and GC_FULFILLMENT_STATUS_ID=2;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 220 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| GC_FULFILLMENT_ITEMS | 1 | 220 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | I_GCFI_GCFS_ID_SDOC_MKTPLID | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("GC_FULFILLMENT_STATUS_ID"=2 AND "MARKETPLACE_ID"=5)
filter("MARKETPLACE_ID"=5)Here is column distribution and histogram information
Enter value for column_name: MARKETPLACE_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
MARKETPLACE_ID 1 1 1
MARKETPLACE_ID 3 8548 8547
MARKETPLACE_ID 4 15608 7060
MARKETPLACE_ID 5 16385 777 --->
MARKETPLACE_ID 35691 16398 13
MARKETPLACE_ID 44551 16407 9
6 rows selected.
Enter value for column_name: GC_FULFILLMENT_STATUS_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
GC_FULFILLMENT_STATUS_ID 5 19602 19602
GC_FULFILLMENT_STATUS_ID 6 19612 10
GC_FULFILLMENT_STATUS_ID 8 19802 190
3 rows selected.
Actual distribution
select MARKETPLACE_ID,count(*) from GC_FULFILLMENT_ITEMS group by MARKETPLACE_ID order by 1;
MARKETPLACE_ID COUNT(*)
1 2099
3 16339936
4 13358682
5 1471839 --->
35691 33623
44551 19881
78931 40273
101611 1
6309408
9 rows selected.
BHAVIK_DBA: GC1EU> select GC_FULFILLMENT_STATUS_ID,count(*) from GC_FULFILLMENT_ITEMS group by GC_FULFILLMENT_STATUS_ID order by 1;
GC_FULFILLMENT_STATUS_ID COUNT(*)
1 880
2 63 --->
3 24
5 37226908
6 22099
7 18
8 325409
9 343
8 rows selected.10053 trace
SINGLE TABLE ACCESS PATH
Table: GC_FULFILLMENT_ITEMS Alias: GC_FULFILLMENT_ITEMS
Card: Original: 36703588.000000 Rounded: 474909 Computed: 474909.06 Non Adjusted: 474909.06
Best:: AccessPath: IndexRange
Index: I_GCFI_GCFS_ID_SDOC_MKTPLID
Cost: 102.05 Degree: 1 Resp: 102.05 Card: 474909.06 Bytes: 0
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('_b_tree_bitmap_plans' 'false')
OPT_PARAM('_optim_peek_user_binds' 'false')
OPT_PARAM('_fix_control' '5483301:0')
ALL_ROWS
OUTLINE_LEAF(@"SEL$F5BB74E1")
MERGE(@"SEL$2")
OUTLINE(@"SEL$1")
OUTLINE(@"SEL$2")
INDEX_RS_ASC(@"SEL$F5BB74E1" "GC_FULFILLMENT_ITEMS"@"SEL$2" ("GC_FULFILLMENT_ITEMS"."GC_FULFILLMENT_STATUS_ID" "GC_FULFILLMENT_ITEMS"."SHIP_DELIVERY_OPTION_CODE" "GC_FULFILLMENT_ITEMS"."MARKETPLACE_ID"))
END_OUTLINE_DATA
*/Is there any reason why CBO is using card=474909.06 ? Having fix control () in place, it should have set card=1 if it is considering GC_FULFILLMENT_STATUS_ID= 2 as "rare" value..isn't it ?OraDBA02 wrote:
You are right Charles.
I was reading one of your blog and saw that.
As you said, it is an issue with SQLPLUS.
However, plan for the sql which is comming from application still shows the same (wrong cardinality) plan. It does not have TO_NUMBER function because of the reason that it does not experience data-type conversion that SQLPLUS has.
But YES...Plan is exactly the same with/without NO_NUMBER.OraDBA02,
I believe that some of the other people responding to this thread might have already described why the execution plan in the library cache is the same plan that you are seeing. One of the goals of using bind variables in SQL statements is to reduce the number of time consuming (and resource intensive) hard parses. That also means that a second goal is to share the same execution plan for future executions of the same SQL statement, even through bind variable values have changed. The catch here is that bind variable peeking, introduced with Oracle Database 9.0.1 (may be disabled by modifying a hidden parameter), helps the optimizer select the "best" (lowest calculated cost) execution plan for those specific bind variable values - the same plan may not be the "best" execution plan for other sets of bind variable values on future executions.
Histograms on one or more of the columns in the WHERE clause could either help or hinder the situation further. It might further help the first execution, but might further hinder future executions with different bind variable values. Oracle Database 11.1 introduced something called adaptive cursor sharing (and 11.2 introduced cardinality feedback) that in theory addresses issues where the execution plan should change for later executions with different bind variable values (but the SQL statement must execute poorly at least once).
There might be multiple child cursors in the library cache for the same SQL statement, each potentially with a different execution plan. I suggest finding the SQL_ID of the SQL statement that the application is submitting (you can do this by checking V$SQL or V$SQLAREA). Once you have the SQL_ID, go back to the SQL statement that I suggested for displaying the execution plan:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'TYPICAL'));The first NULL in the above SQL statement is where you would specify the SQL_ID. If you leave the second NULL in place, the above SQL statement will retrieve the execution plan for all child cursors with that SQL_ID.
For instance, if the SQL_ID was 75chksrfa5fbt, you would execute the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL'));Usually, you can take it a step further to see the bind variables that were used during the optimization phase. To do that, you would add the +PEEKED_BINDS format parameter:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS'));Note that there are various optimizer parameters that affect the optimizer's decisions, for instance, maybe the optimizer mode is set to FIRST_ROWS. Also possibly helpful is the +OUTLINE format parameter that might provide a clue regarding the value of some of the parameters affecting the optimizer. The SQL statement that you would then enter is similar to the following:
SELECT * FROM TABLE (DBMS_XPLAN.DISPLAY_CURSOR('75chksrfa5fbt',NULL,'TYPICAL +PEEKED_BINDS +OUTLINE'));Additional information might be helpful. Please see the following two forum threads to see what kind of information you should gather:
When your query takes too long… : When your query takes too long ...
How to post a SQL statement tuning request: HOW TO: Post a SQL statement tuning request - template posting
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Query tuning help required:
I have a query which is taking long time. Is there any way I can improve the query to shorten its time of execution.
I have given below the details of it.
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.25
SQL> SELECT pa.regn_no,
2 (SELECT mst.status_desc
3 FROM m_status mst
4 WHERE mst.trans_id = 'PA01'
5 AND mst.status_code = pa.regn_status) AS regn_status,
6 (SELECT pp.NAME
7 FROM people_profile pp
8 WHERE pp.pp_id = pa.ident_no) AS NAME, pa.ident_no,
9 TO_CHAR (pa.approval_date, 'dd/mm/yyyy') AS approval_date,
10 TO_CHAR (pa.de_reg_date, 'dd/mm/yyyy') AS de_regist_date,
11 TO_CHAR (pa.cert_reg_exp_date, 'dd/mm/yyyy') AS cert_expiry_date,
12 pa.gender, pa.fax_no,
13 (SELECT nationality_desc
14 FROM people_profile pp, m_nationality
15 WHERE pp.pp_id = pa.ident_no
16 AND pp.nationality = nationality_code) AS nationality,
17 (SELECT pp.email_add
18 FROM people_profile pp
19 WHERE pp.pp_id = pa.ident_no) AS email_add,
20 (SELECT pp.mobile_no
21 FROM people_profile pp
22 WHERE pp.pp_id = pa.ident_no) AS mobile_no,
23 TO_CHAR ((SELECT pp.birth_date
24 FROM people_profile pp
25 WHERE pp.pp_id = pa.ident_no),
26 'dd/mm/yyyy'
27 ) AS birth_date,
28 REPLACE (sf_get_address_people (pa.ident_no, '2', 'C'),
29 '<br>',
30 CHR (10)
31 ) AS address,
32 sf_get_pa_firm_info (pa.ident_no) AS firm_profile,
33 sf_get_pa_firm_partner (pa.ident_no) AS firm_partner,
34 sf_get_pa_pmp_code (pa.ident_no) AS pmp_code, ppv.pae_name,
35 ppv.pmp_code AS pmp_code_1, ppv.cycle_no, ppv.seq_no,
36 DECODE (ppv.visit_type,
37 'I', 'INITIAL',
38 'R', 'REVISIT',
39 ''
40 ) AS visit_type,
41 TO_CHAR (ppv.initial_ltr_date, 'dd/mm/yyyy') AS initial_ltr_date,
42 TO_CHAR (ppv.sec_ltr_date, 'dd/mm/yyyy') AS sec_ltr_date,
43 TO_CHAR (ppv.review_from, 'dd/mm/yyyy') AS review_from,
44 TO_CHAR (ppv.review_to, 'dd/mm/yyyy') AS review_to,
45 TO_CHAR (ppv.finding_date, 'dd/mm/yyyy') AS finding_date,
46 TO_CHAR (ppv.finding_due_date, 'dd/mm/yyyy') AS finding_due_date,
47 TO_CHAR (ppv.finding_reply_date,
48 'dd/mm/yyyy'
49 ) AS finding_reply_date,
50 ppv.pmsc,
51 TO_CHAR (ppv.clarif_ltr_date, 'dd/mm/yyyy') AS clarif_ltr_date,
52 ppv.paoc_date,
53 TO_CHAR (ppv.final_paoc_date, 'dd/mm/yyyy') AS final_paoc_date,
54 (SELECT result_desc
55 FROM m_pmp_result ms
56 WHERE result_id = ppv.pmp_status) AS pmp_status,
57 TO_CHAR (ppv.suspension_end_date,
58 'dd/mm/yyyy'
59 ) AS suspension_end_date,
60 TO_CHAR (ppv.final_ltr_date, 'dd/mm/yyyy') AS final_ltr_date,
61 ppv.findings_summary,
62 TO_CHAR (ppv.invoice_date, 'dd/mm/yyyy') AS invoice_date,
63 ppv.amount_billed,
64 TO_CHAR (ppv.payment_date, 'dd/mm/yyyy') AS payment_date,
65 DECODE (ppv.pay_icpas,
66 'Y', 'YES',
67 'N', 'NO',
68 'V', 'NA',
69 ''
70 ) AS pay_icpas,
71 ppv.updated_date, ppv.updated_by, ppv.remarks,
72 DECODE ((SELECT ppr.review_status
73 FROM pa_pmp_reviews ppr
74 WHERE ppr.regn_no = ppv.regn_no
75 AND ppr.cycle_no = ppv.cycle_no),
76 'P', 'In Progress',
77 'C', 'Closed',
78 ''
79 ) AS review_status,
80 pcl.complaint_no,
81 DECODE (pcl.complaint_status,
82 'P', 'Pending',
83 'C', 'Closed',
84 ''
85 ) AS complaint_status,
86 pcl.remarks AS remarks_1,
87 DECODE (pcl.complaint_outcome,
88 'C', 'Cancelled',
89 'R', 'Restriction of Practice',
90 'P', 'Penalty (Fine) - Disciplinary',
91 'E', 'Censure - Disciplinary',
92 'S', 'Suspended - Disciplinary',
93 ''
94 ) AS complaint_outcome,
95 TO_CHAR (pcl.complaint_date, 'dd/mm/yyyy') AS complaint_date,
96 pcl.complainant_nric, pcl.complainant_name, pcl.complaint_details,
97 TO_CHAR (pcl.effective_date, 'dd/mm/yyyy') AS effective_date,
98 TO_CHAR (pcl.effective_date_to,
99 'dd/mm/yyyy') AS effective_date_to,
100 sf_get_pa_exam_info (pa.regn_no, 'L') AS local_exam_detail,
101 sf_get_pa_exam_info (pa.regn_no, 'F') AS foreign_exam_detail,
102 sf_get_pa_exempt_info (pa.regn_no) AS exempt_detail
103 FROM pa_profile pa, pa_pmp_visits ppv, pa_complaint pcl
104 WHERE pa.regn_no = ppv.regn_no(+) AND pa.regn_no = pcl.regn_no(+)
105 ORDER BY pa.regn_no DESC;
1163 rows selected.
Elapsed: 00:02:08.87
Execution Plan
Plan hash value: 2912197266
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1109 | 330K| 17 (12)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | M_STATUS | 1 | 23 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | PK_M_STATUS | 1 | | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 25 | 3 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 26 | 4 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| PEOPLE_PROFILE | 1 | 12 | 3 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_M_NATIONALITY | 1 | 14 | 1 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 20 | 3 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 11 | 3 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | PEOPLE_PROFILE | 1 | 10 | 3 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | SYS_C00103408 | 1 | | 2 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | M_PMP_RESULT | 1 | 37 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | XPK_M_PMP_RESULT | 1 | | 0 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | PA_PMP_REVIEWS | 1 | 8 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | SYS_C00103321 | 1 | | 0 (0)| 00:00:01 |
| 19 | SORT ORDER BY | | 1109 | 330K| 17 (12)| 00:00:01 |
|* 20 | HASH JOIN RIGHT OUTER | | 1109 | 330K| 16 (7)| 00:00:01 |
| 21 | TABLE ACCESS FULL | PA_COMPLAINT | 146 | 20294 | 3 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 1109 | 179K| 13 (8)| 00:00:01 |
| 23 | TABLE ACCESS FULL | PA_PMP_VISITS | 90 | 11340 | 3 (0)| 00:00:01 |
| 24 | TABLE ACCESS FULL | PA_PROFILE | 1109 | 44360 | 9 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("MST"."TRANS_ID"='PA01' AND "MST"."STATUS_CODE"=:B1)
filter("MST"."STATUS_CODE"=:B1)
4 - access("PP"."PP_ID"=:B1)
7 - access("PP"."PP_ID"=:B1)
8 - access("PP"."NATIONALITY"="NATIONALITY_CODE")
10 - access("PP"."PP_ID"=:B1)
12 - access("PP"."PP_ID"=:B1)
14 - access("PP"."PP_ID"=:B1)
16 - access("RESULT_ID"=:B1)
18 - access("PPR"."REGN_NO"=:B1 AND "PPR"."CYCLE_NO"=:B2)
20 - access("PA"."REGN_NO"="PCL"."REGN_NO"(+))
22 - access("PA"."REGN_NO"="PPV"."REGN_NO"(+))
Statistics
17577 recursive calls
0 db block gets
8703644 consistent gets
6138 physical reads
0 redo size
424453 bytes sent via SQL*Net to client
3641 bytes received via SQL*Net from client
13 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1163 rows processed
NAME TYPE VALUE
user_dump_dest string /opt/app/oracle/diag/rdbms/ebi
zfile/EBIZFILE/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.1
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 11-20-2009 09:46
SYSSTATS_INFO DSTOP 11-20-2009 09:46
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1676.76768
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 SLAVETHRHi,
obviously the problem you are having is described by the following lines of your execution plan
SORT ORDER BY | | 1109 | 330K| 17 (12)| 00:00:01 |
|* 20 | HASH JOIN RIGHT OUTER | | 1109 | 330K| 16 (7)| 00:00:01 |
| 21 | TABLE ACCESS FULL | PA_COMPLAINT | 146 | 20294 | 3 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 1109 | 179K| 13 (8)| 00:00:01 |
| 23 | TABLE ACCESS FULL | PA_PMP_VISITS | 90 | 11340 | 3 (0)| 00:00:01 |
| 24 | TABLE ACCESS FULL | PA_PROFILE | 1109 | 44360 | 9
You don't have a "real" "WHERE" condition in the query that could lead the Oracle CBO to consider using an index.
This leads to a full scan of PA_PMP_VISITS and PA_PROFILE and subsequently -in order to process the join condition between these two tables-
to this "HASH JOIN RIGHT OUTER". You cannot avoid this, with the current WHERE condition ...
Following thoughts :
1) Try narrowing down your result set by specifying a "real" WHERE Condition on one of the two tables, specifying an indexed column
2) If this cannot be done, try using query parallelism (parallel hint). This will give you acceptable SQL-execution times.
3) If this is not possible, there would be a third approach : You could consider the definition of an index on "pa.regn" and use a hint on your query in order to use it. Due to your order condition there is a possibility that CBO is going to use it, especially if you specify WHERE ROWNUM < ...
Regards,
Michalis -
Hi ,
11.2.0.1
AIX 6.1
I have following query which is executed from Application,the query comes back within 2 secs for not so common last_name combined with gender but it is taking longer time for common last_names like 'BROWN' or 'JONES' or 'SMITH' with gender_id .
select customerin0_.ROW_NUMBER as ROW1_22596_, customerin0_.ADDRESS_ID as
ADDRESS2_22596_, customerin0_.addressTypeId as addressT3_22596_,
customerin0_.city as city22596_, customerin0_.CONTACT_DETAILS_CODE_ID as
CONTACT5_22596_, customerin0_.county as county22596_, customerin0_.countyID
as countyID22596_, customerin0_.dob as dob22596_, customerin0_.eyecolor as
eyecolor22596_, customerin0_.eyecolorid as eyecolorid22596_,
customerin0_.FIRST_NAME as FIRST11_22596_, customerin0_.gender as
gender22596_, customerin0_.genderid as genderid22596_,
customerin0_.ID_NUMBER as ID14_22596_, customerin0_.JURISDICTION_CODE as
JURISDI15_22596_, customerin0_.LAST_NAME as LAST16_22596_,
customerin0_.LEGAL_ENTITY_ID as LEGAL17_22596_,
customerin0_.LEGAL_ENTITY_NUMBER as LEGAL18_22596_,
customerin0_.LEGAL_ENTITY_TYPE as LEGAL19_22596_, customerin0_.MIDDLE_NAME
as MIDDLE20_22596_, customerin0_.STREET_ADDRESS_1 as STREET21_22596_,
customerin0_.suffix_value as suffix22_22596_, customerin0_.ZIP_CODE as
ZIP23_22596_, customerin0_.ZIP_PLUS_4 as ZIP24_22596_
from
CUSTOMER_IND_SEARCH_VIEW customerin0_ where (customerin0_.LAST_NAME like :1)
and customerin0_.genderid=:2 and rownum<=200
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 18 1.88 123.53 8245 12403 0 179
total 18 1.88 123.53 8245 12403 0 179
Misses in library cache during parse: 0
Parsing user id: 135 (???)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
ges message buffer allocation 259 0.00 0.00
gc cr grant 2-way 259 0.00 0.08
db file sequential read 10126 1.40 148.07
SQL*Net message from client 19 0.02 0.10
SQL*Net message to client 18 0.00 0.00
********************************************************************************Was not able to generate plan out of tkrprof ,captured it from OEM.
10 | NESTED LOOPS | | 805 | 73255 | 3477 (1)| 00:00:42 |
| 11 | NESTED LOOPS | | 805 | 51520 | 1866 (1)| 00:00:23 |
| 12 | NESTED LOOPS | | 805 | 33005 | 254 (0)| 00:00:04 |
|* 13 | TABLE ACCESS BY INDEX ROWID| REF_CONTACT_DETAILS | 1 | 10 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | XAK1_REF_CD_VALUE | 1 | | 0 (0)| |
| 15 | TABLE ACCESS BY INDEX ROWID| PERSON_PROFILE_NAMES | 805 | 24955 | 253 (0)| 00:00:04 |
|* 16 | INDEX RANGE SCAN | IDX$$_D7D50001 | 805 | | 4 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | PERSON_PROFILE | 1 | 23 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | XPK_PERSON_PROFILE | 1 | | 1 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | LEGAL_ENTITY | 1 | 27 | 2 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | XPK_LEGAL_ENTITY | 1 | | 1 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID | LEGAL_ENTITY_ADDRESSES | 1 | 81 | 3 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | LENUM_CODE_ID | 1 | | 2 (0)| 00:00:01 |
|* 23 | TABLE ACCESS BY INDEX ROWID | LEGAL_ENTITY_IDENTIFICATIONS | 1 | 36 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | XIF1_LEGAL_ENTITY_ID | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("REFCOUNTIES"."ID"=:B1)
4 - access("REFEYECOLORS"."ID"=:B1)
6 - access("REFGENDER"."ID"=:B1)
7 - filter(ROWNUM<=200)
13 - filter("REFCONTACTDETAILS"."MODE_TYPE"=4)
14 - access("REFCONTACTDETAILS"."VALUE"='PRA')
16 - access("PERSONPROFILENAMES"."LAST_NAME" LIKE :1 AND "PERSONPROFILENAMES"."IS_DELETED"=0)
filter(("PERSONPROFILENAMES"."LAST_NAME" LIKE :1 AND "PERSONPROFILENAMES"."IS_DELETED"=0))
17 - filter("SYS_ALIAS_2"."GENDER_ID"=:2)
18 - access("SYS_ALIAS_2"."PP_LEGALENTITY_NUMBER"="PERSONPROFILENAMES"."PP_LEGALENTITY_NUMBER")
19 - filter(("LEGALENTITY"."IS_DELETED"=0 OR "LEGALENTITY"."IS_DELETED"=NULL))
20 - access("LEGALENTITY"."LEGAL_ENTITY_NUMBER"="SYS_ALIAS_2"."PP_LEGALENTITY_NUMBER")
21 - filter("LEGALENTITYADDRESSES"."IS_DELETED"=0)
22 - access("LEGALENTITY"."LEGAL_ENTITY_NUMBER"="LEGALENTITYADDRESSES"."LEGAL_ENTITY_NUMBER" AND
"REFCONTACTDETAILS"."ID"="LEGALENTITYADDRESSES"."CONTACT_DETAILS_CODE_ID")
23 - filter(("LEGAL_ENTITY_ID"."END_DATE">=SYSDATE@! AND "LEGAL_ENTITY_ID"."EFFECTIVE_DATE"<=SYSDATE@!))
24 - access("LEGAL_ENTITY_ID"."LEGAL_ENTITY_NUMBER"="LEGALENTITY"."LEGAL_ENTITY_NUMBER")
Please advice ....
Thanks
Edited by: Monto on Aug 22, 2012 4:22 AMExplain Plan with common name.
SELECT customerin0_.ROW_NUMBER AS ROW1_22596_,
customerin0_.ADDRESS_ID AS ADDRESS2_22596_,
customerin0_.addressTypeId AS addressT3_22596_,
customerin0_.city AS city22596_,
customerin0_.CONTACT_DETAILS_CODE_ID AS CONTACT5_22596_,
customerin0_.county AS county22596_,
customerin0_.countyID AS countyID22596_,
customerin0_.dob AS dob22596_,
customerin0_.eyecolor AS eyecolor22596_,
customerin0_.eyecolorid AS eyecolorid22596_,
customerin0_.FIRST_NAME AS FIRST11_22596_,
customerin0_.gender AS gender22596_,
customerin0_.genderid AS genderid22596_,
customerin0_.ID_NUMBER AS ID14_22596_,
customerin0_.JURISDICTION_CODE AS JURISDI15_22596_,
customerin0_.LAST_NAME AS LAST16_22596_,
customerin0_.LEGAL_ENTITY_ID AS LEGAL17_22596_,
customerin0_.LEGAL_ENTITY_NUMBER AS LEGAL18_22596_,
customerin0_.LEGAL_ENTITY_TYPE AS LEGAL19_22596_,
customerin0_.MIDDLE_NAME AS MIDDLE20_22596_,
customerin0_.STREET_ADDRESS_1 AS STREET21_22596_,
customerin0_.suffix_value AS suffix22_22596_,
customerin0_.ZIP_CODE AS ZIP23_22596_,
customerin0_.ZIP_PLUS_4 AS ZIP24_22596_
FROM xmatapp.CUSTOMER_IND_SEARCH_VIEW customerin0_
WHERE (customerin0_.LAST_NAME LIKE 'SMITH%')
AND customerin0_.genderid = 2
AND ROWNUM <= 200
call count cpu elapsed disk query current rows
Parse 1 0.04 0.05 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 15 5.05 167.51 14050 20246 0 200
total 17 5.09 167.56 14050 20246 0 200
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
41 TABLE ACCESS BY INDEX ROWID REF_COUNTIES (cr=58 pr=0 pw=0 time=0 us cost=1 size=12 card=1)
41 INDEX UNIQUE SCAN XPK_REF_COUNTIES (cr=17 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308432)
7 TABLE ACCESS BY INDEX ROWID REF_EYE_COLORS (cr=11 pr=0 pw=0 time=0 us cost=1 size=10 card=1)
7 INDEX UNIQUE SCAN XPK_REF_EYE_COLORS (cr=4 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308404)
1 TABLE ACCESS BY INDEX ROWID REF_GENDER (cr=2 pr=0 pw=0 time=0 us cost=1 size=9 card=1)
1 INDEX UNIQUE SCAN XPK_REF_GENDER (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308759)
200 COUNT STOPKEY (cr=20175 pr=14050 pw=0 time=2540633 us)
200 NESTED LOOPS OUTER (cr=20175 pr=14050 pw=0 time=2540633 us cost=103 size=1248 card=6)
200 NESTED LOOPS (cr=19756 pr=13775 pw=0 time=17003952 us cost=80 size=1032 card=6)
200 NESTED LOOPS (cr=19304 pr=13586 pw=0 time=14271285 us cost=55 size=1092 card=12)
200 NESTED LOOPS (cr=19017 pr=13453 pw=0 time=13593988 us cost=31 size=768 card=12)
4923 NESTED LOOPS (cr=4640 pr=4614 pw=0 time=63281900 us cost=7 size=492 card=12)
1 TABLE ACCESS BY INDEX ROWID REF_CONTACT_DETAILS (cr=2 pr=0 pw=0 time=0 us cost=1 size=10 card=1)
1 INDEX UNIQUE SCAN XAK1_REF_CD_VALUE (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308425)
4923 TABLE ACCESS BY INDEX ROWID PERSON_PROFILE_NAMES (cr=4638 pr=4614 pw=0 time=63269280 us cost=6 size=372 card=12)
4923 INDEX RANGE SCAN IDX$$_D7D50001 (cr=30 pr=16 pw=0 time=60326 us cost=2 size=0 card=12)(object id 311149)
200 TABLE ACCESS BY INDEX ROWID PERSON_PROFILE (cr=14377 pr=8839 pw=0 time=0 us cost=2 size=23 card=1)
4923 INDEX UNIQUE SCAN XPK_PERSON_PROFILE (cr=9454 pr=4288 pw=0 time=0 us cost=1 size=0 card=1)(object id 308484)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY (cr=287 pr=133 pw=0 time=0 us cost=2 size=27 card=1)
200 INDEX UNIQUE SCAN XPK_LEGAL_ENTITY (cr=225 pr=80 pw=0 time=0 us cost=1 size=0 card=1)(object id 308494)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY_ADDRESSES (cr=452 pr=189 pw=0 time=0 us cost=3 size=81 card=1)
200 INDEX RANGE SCAN LENUM_CODE_ID (cr=281 pr=94 pw=0 time=0 us cost=2 size=0 card=1)(object id 307952)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY_IDENTIFICATIONS (cr=419 pr=275 pw=0 time=0 us cost=4 size=36 card=1)
200 INDEX RANGE SCAN XIF1_LEGAL_ENTITY_ID (cr=219 pr=77 pw=0 time=0 us cost=2 size=0 card=1)(object id 308082)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
ges message buffer allocation 8576 0.00 0.02
library cache lock 7 0.00 0.00
library cache pin 7 0.00 0.00
SQL*Net message to client 15 0.00 0.00
Disk file operations I/O 19 0.01 0.03
gc cr grant 2-way 8554 0.01 3.09
db file sequential read 14050 0.91 158.32
SQL*Net message from client 15 32.28 35.97
gc cr grant congested 8 0.00 0.01
********************************************************************************Plan with rare names.
SELECT customerin0_.ROW_NUMBER AS ROW1_22596_,
customerin0_.ADDRESS_ID AS ADDRESS2_22596_,
customerin0_.addressTypeId AS addressT3_22596_,
customerin0_.city AS city22596_,
customerin0_.CONTACT_DETAILS_CODE_ID AS CONTACT5_22596_,
customerin0_.county AS county22596_,
customerin0_.countyID AS countyID22596_,
customerin0_.dob AS dob22596_,
customerin0_.eyecolor AS eyecolor22596_,
customerin0_.eyecolorid AS eyecolorid22596_,
customerin0_.FIRST_NAME AS FIRST11_22596_,
customerin0_.gender AS gender22596_,
customerin0_.genderid AS genderid22596_,
customerin0_.ID_NUMBER AS ID14_22596_,
customerin0_.JURISDICTION_CODE AS JURISDI15_22596_,
customerin0_.LAST_NAME AS LAST16_22596_,
customerin0_.LEGAL_ENTITY_ID AS LEGAL17_22596_,
customerin0_.LEGAL_ENTITY_NUMBER AS LEGAL18_22596_,
customerin0_.LEGAL_ENTITY_TYPE AS LEGAL19_22596_,
customerin0_.MIDDLE_NAME AS MIDDLE20_22596_,
customerin0_.STREET_ADDRESS_1 AS STREET21_22596_,
customerin0_.suffix_value AS suffix22_22596_,
customerin0_.ZIP_CODE AS ZIP23_22596_,
customerin0_.ZIP_PLUS_4 AS ZIP24_22596_
FROM xmatapp.CUSTOMER_IND_SEARCH_VIEW customerin0_
WHERE (customerin0_.LAST_NAME LIKE 'KUMAR%')
AND customerin0_.genderid = '2'
AND ROWNUM <= 200
call count cpu elapsed disk query current rows
Parse 1 0.05 0.07 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 15 0.02 0.03 0 1829 0 200
total 17 0.07 0.10 0 1829 0 200
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
Rows Row Source Operation
23 TABLE ACCESS BY INDEX ROWID REF_COUNTIES (cr=37 pr=0 pw=0 time=0 us cost=1 size=12 card=1)
23 INDEX UNIQUE SCAN XPK_REF_COUNTIES (cr=14 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308432)
5 TABLE ACCESS BY INDEX ROWID REF_EYE_COLORS (cr=9 pr=0 pw=0 time=0 us cost=1 size=10 card=1)
5 INDEX UNIQUE SCAN XPK_REF_EYE_COLORS (cr=4 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308404)
1 TABLE ACCESS BY INDEX ROWID REF_GENDER (cr=2 pr=0 pw=0 time=0 us cost=1 size=9 card=1)
1 INDEX UNIQUE SCAN XPK_REF_GENDER (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308759)
200 COUNT STOPKEY (cr=1781 pr=0 pw=0 time=15124 us)
200 NESTED LOOPS OUTER (cr=1781 pr=0 pw=0 time=14726 us cost=103 size=1248 card=6)
200 NESTED LOOPS (cr=1383 pr=0 pw=0 time=35422 us cost=80 size=1032 card=6)
200 NESTED LOOPS (cr=980 pr=0 pw=0 time=20198 us cost=55 size=1092 card=12)
200 NESTED LOOPS (cr=741 pr=0 pw=0 time=15422 us cost=31 size=768 card=12)
289 NESTED LOOPS (cr=129 pr=0 pw=0 time=3648 us cost=7 size=492 card=12)
1 TABLE ACCESS BY INDEX ROWID REF_CONTACT_DETAILS (cr=2 pr=0 pw=0 time=0 us cost=1 size=10 card=1)
1 INDEX UNIQUE SCAN XAK1_REF_CD_VALUE (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 308425)
289 TABLE ACCESS BY INDEX ROWID PERSON_PROFILE_NAMES (cr=127 pr=0 pw=0 time=3360 us cost=6 size=372 card=12)
289 INDEX RANGE SCAN IDX$$_D7D50001 (cr=18 pr=0 pw=0 time=672 us cost=2 size=0 card=12)(object id 311149)
200 TABLE ACCESS BY INDEX ROWID PERSON_PROFILE (cr=612 pr=0 pw=0 time=0 us cost=2 size=23 card=1)
289 INDEX UNIQUE SCAN XPK_PERSON_PROFILE (cr=323 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 308484)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY (cr=239 pr=0 pw=0 time=0 us cost=2 size=27 card=1)
200 INDEX UNIQUE SCAN XPK_LEGAL_ENTITY (cr=194 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 308494)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY_ADDRESSES (cr=403 pr=0 pw=0 time=0 us cost=3 size=81 card=1)
200 INDEX RANGE SCAN LENUM_CODE_ID (cr=230 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 307952)
200 TABLE ACCESS BY INDEX ROWID LEGAL_ENTITY_IDENTIFICATIONS (cr=398 pr=0 pw=0 time=0 us cost=4 size=36 card=1)
200 INDEX RANGE SCAN XIF1_LEGAL_ENTITY_ID (cr=198 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 308082)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
ges message buffer allocation 14 0.00 0.00
library cache lock 7 0.00 0.00
library cache pin 7 0.00 0.00
KJC: Wait for msg sends to complete 2 0.00 0.00
SQL*Net message to client 15 0.00 0.00
SQL*Net message from client 15 18.88 21.81
********************************************************************************PERSONPROFILENAMES-16 Milion rows
LEGALENTITYADDRESSES-34 Milion rows
PERSONPROFILE-16 Milion rows
LEGALENTITY 17 Milion rows
refcontactdetails 45 rows
Thanks -
Sql Query Tuning. Please help me to tune this query
Hi All ,
I have this problematic Sql . It is taking huge time to execute. It contains a view CIDV, which i think is the bottleneck.
I have pasted the query below. I will be pasting TKPROF and explain plan for the same. Please advice me to tune this query.
SELECT GCC.SEGMENT1 || '.' || GCC.SEGMENT2 || '.' || GCC.SEGMENT3 || '.' ||
GCC.SEGMENT4 || '.' || GCC.SEGMENT5 || '.' || GCC.SEGMENT6 || '.' ||
GCC.SEGMENT7 || '.' || GCC.SEGMENT8 || '.' || GCC.SEGMENT9 OFFSET_ACCOUNT,
OOD.ORGANIZATION_CODE,
CIDV.SUBINVENTORY_CODE OFFSET_SUBINV,
MIL.SEGMENT1 || '.' || MIL.SEGMENT2 || '.' || MIL.SEGMENT3 || '.' ||
MIL.SEGMENT4 || '.' || MIL.SEGMENT5 OFFSET_LOCATOR,
CIDV.LAST_UPDATE_LOGIN
FROM APPS.CST_INV_DISTRIBUTION_V CIDV,
APPS.GL_CODE_COMBINATIONS GCC,
APPS.MTL_ITEM_LOCATIONS MIL,
APPS.ORG_ORGANIZATION_DEFINITIONS OOD
WHERE CIDV.TRANSACTION_ID = :B2
AND CIDV.PRIMARY_QUANTITY = (-1) * :B1
AND CIDV.REFERENCE_ACCOUNT = GCC.CODE_COMBINATION_ID
AND OOD.ORGANIZATION_ID = CIDV.ORGANIZATION_ID
AND MIL.INVENTORY_LOCATION_ID = CIDV.LOCATOR_ID
AND GCC.ACCOUNT_TYPE = 'A'****************
TKPROF
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 68337 10.32 10.32 0 0 0 0
Fetch 68337 229.75 936.36 58819 6743323 1121 68232
total 136675 240.07 946.69 58819 6743323 1121 68232
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 203 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 MERGE JOIN CARTESIAN (cr=102 pr=15 pw=0 time=193608 us cost=56 size=219 card=1)
1 1 1 NESTED LOOPS (cr=100 pr=15 pw=0 time=193483 us cost=53 size=219 card=1)
1 1 1 NESTED LOOPS (cr=99 pr=15 pw=0 time=193407 us cost=52 size=215 card=1)
1 1 1 NESTED LOOPS (cr=96 pr=15 pw=0 time=193378 us cost=51 size=190 card=1)
1 1 1 NESTED LOOPS (cr=93 pr=15 pw=0 time=193284 us cost=49 size=162 card=1)
1 1 1 NESTED LOOPS (cr=89 pr=14 pw=0 time=185515 us cost=46 size=138 card=1)
1 1 1 NESTED LOOPS (cr=85 pr=12 pw=0 time=157975 us cost=44 size=81 card=1)
1 1 1 NESTED LOOPS (cr=83 pr=12 pw=0 time=157925 us cost=43 size=73 card=1)
1 1 1 NESTED LOOPS (cr=81 pr=12 pw=0 time=157641 us cost=43 size=132 card=2)
1 1 1 VIEW CST_INV_DISTRIBUTION_V (cr=78 pr=12 pw=0 time=156386 us cost=41 size=118 card=2)
1 1 1 UNION-ALL (cr=78 pr=12 pw=0 time=156378 us)
0 0 0 NESTED LOOPS OUTER (cr=44 pr=9 pw=0 time=124997 us cost=20 size=291 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124993 us cost=18 size=255 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124990 us cost=18 size=251 card=1)
33 33 33 MERGE JOIN CARTESIAN (cr=25 pr=6 pw=0 time=98544 us cost=14 size=192 card=1)
1 1 1 NESTED LOOPS OUTER (cr=22 pr=5 pw=0 time=85754 us cost=12 size=156 card=1)
1 1 1 NESTED LOOPS (cr=19 pr=4 pw=0 time=79830 us cost=10 size=120 card=1)
1 1 1 NESTED LOOPS OUTER (cr=17 pr=4 pw=0 time=79813 us cost=9 size=113 card=1)
1 1 1 NESTED LOOPS (cr=15 pr=4 pw=0 time=79752 us cost=8 size=106 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=2 pw=0 time=43120 us cost=6 size=93 card=1)
1 1 1 NESTED LOOPS (cr=7 pr=2 pw=0 time=43087 us cost=4 size=83 card=1)
1 1 1 NESTED LOOPS (cr=6 pr=2 pw=0 time=43072 us cost=4 size=80 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=2 pw=0 time=43042 us cost=4 size=76 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_MATERIAL_TRANSACTIONS_U1 (cr=4 pr=2 pw=0 time=43011 us cost=3 size=0 card=1)(object id 12484094)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=20 us cost=0 size=764 card=191)(object id 9983)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=54 card=18)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=27 us cost=2 size=736324450 card=73632445)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=2 pw=0 time=36626 us cost=2 size=957481070 card=73652390)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=42 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=28 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=12 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=0 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=5915 us cost=2 size=36 card=1)(object id 705891)
33 33 33 BUFFER SORT (cr=3 pr=1 pw=0 time=12713 us cost=12 size=36 card=1)
33 33 33 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=12582 us cost=2 size=36 card=1)(object id 705891)
0 0 0 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=19 pr=3 pw=0 time=26591 us cost=4 size=59 card=1)
66 66 66 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=18 pr=2 pw=0 time=13607 us cost=3 size=0 card=3)(object id 12484127)
0 0 0 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=4 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=36 card=1)(object id 705891)
1 1 1 NESTED LOOPS (cr=34 pr=3 pw=0 time=31269 us cost=21 size=288 card=1)
1 1 1 NESTED LOOPS (cr=30 pr=3 pw=0 time=31161 us cost=19 size=275 card=1)
1 1 1 NESTED LOOPS (cr=26 pr=3 pw=0 time=31105 us cost=17 size=265 card=1)
1 1 1 NESTED LOOPS (cr=25 pr=3 pw=0 time=31082 us cost=17 size=261 card=1)
1 1 1 NESTED LOOPS OUTER (cr=23 pr=3 pw=0 time=31027 us cost=16 size=254 card=1)
1 1 1 NESTED LOOPS (cr=21 pr=3 pw=0 time=30980 us cost=15 size=247 card=1)
1 1 1 NESTED LOOPS (cr=20 pr=3 pw=0 time=30957 us cost=15 size=243 card=1)
1 1 1 NESTED LOOPS OUTER (cr=19 pr=3 pw=0 time=30926 us cost=15 size=240 card=1)
1 1 1 NESTED LOOPS (cr=16 pr=3 pw=0 time=30389 us cost=13 size=204 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=0 pw=0 time=665 us cost=9 size=131 card=1)
1 1 1 NESTED LOOPS OUTER (cr=8 pr=0 pw=0 time=306 us cost=7 size=95 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=5 pr=0 pw=0 time=37 us cost=5 size=59 card=1)
2 2 2 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=4 pr=0 pw=0 time=17 us cost=4 size=0 card=3)(object id 12484127)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=216 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=352 us cost=2 size=36 card=1)(object id 705891)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=3 pw=0 time=29716 us cost=4 size=73 card=1)
1 1 1 INDEX RANGE SCAN MTL_MATERIAL_TRANSACTIONS_N23 (cr=4 pr=3 pw=0 time=29588 us cost=3 size=0 card=1)(object id 12484133)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=520 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=22 us cost=0 size=3 card=1)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=16 us cost=0 size=4 card=1)(object id 9983)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=34 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=19 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=44 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=14 us cost=0 size=0 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=13 us cost=0 size=4 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=49 us cost=2 size=10 card=1)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=0 pw=0 time=96 us cost=2 size=13 card=1)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ALL_ORGANIZATION_UNITS (cr=3 pr=0 pw=0 time=1246 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK (cr=2 pr=0 pw=0 time=24 us cost=0 size=0 card=1)(object id 250158)
1 1 1 INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK (cr=2 pr=0 pw=0 time=275 us cost=0 size=7 card=1)(object id 689101)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=38 us cost=1 size=8 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=15 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS (cr=4 pr=2 pw=0 time=27531 us cost=2 size=57 card=1)
1 1 1 INDEX UNIQUE SCAN GL_CODE_COMBINATIONS_U1 (cr=3 pr=1 pw=0 time=19925 us cost=1 size=0 card=1)(object id 51426)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_ITEM_LOCATIONS (cr=4 pr=1 pw=0 time=7758 us cost=3 size=24 card=1)
1 1 1 INDEX RANGE SCAN MTL_ITEM_LOCATIONS_U1 (cr=3 pr=0 pw=0 time=51 us cost=2 size=0 card=1)(object id 9761)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=85 us cost=2 size=28 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=29 us cost=1 size=0 card=2)(object id 5379798)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=25 us cost=1 size=25 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=11 us cost=1 size=0 card=1)(object id 5379798)
1 1 1 INDEX FULL SCAN GL_SETS_OF_BOOKS_U2 (cr=1 pr=0 pw=0 time=69 us cost=1 size=4 card=1)(object id 1380842)
1 1 1 BUFFER SORT (cr=2 pr=0 pw=0 time=110 us cost=55 size=0 card=1)
1 1 1 TABLE ACCESS FULL FND_PRODUCT_GROUPS (cr=2 pr=0 pw=0 time=59 us cost=3 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 2 0.00 0.00
library cache pin 2 0.00 0.00
Disk file operations I/O 249 0.00 0.00
db file sequential read 58819 2.61 714.28
gc cr grant 2-way 5198 0.16 4.52
gc current grant busy 1 0.00 0.00
KJC: Wait for msg sends to complete 517 0.00 0.05
library cache: mutex X 433 0.01 0.04
gc cr grant congested 28 0.08 0.18
latch: ges resource hash list 5 0.00 0.00
gc current block 2-way 513 0.11 0.61
gc current block congested 2 0.00 0.00
latch: gc element 16 0.00 0.01
latch: cache buffers chains 4 0.00 0.00
latch: object queue header operation 3 0.00 0.00
********************************************************************************Explain Plan for the query
SELECT STATEMENT, GOAL = ALL_ROWS Cost=56 Cardinality=1 Bytes=219
MERGE JOIN CARTESIAN Cost=56 Cardinality=1 Bytes=219
NESTED LOOPS Cost=53 Cardinality=1 Bytes=219
NESTED LOOPS Cost=52 Cardinality=1 Bytes=215
NESTED LOOPS Cost=51 Cardinality=1 Bytes=190
NESTED LOOPS Cost=49 Cardinality=1 Bytes=162
NESTED LOOPS Cost=46 Cardinality=1 Bytes=138
NESTED LOOPS Cost=44 Cardinality=1 Bytes=81
NESTED LOOPS Cost=43 Cardinality=1 Bytes=73
NESTED LOOPS Cost=43 Cardinality=2 Bytes=132
VIEW Object owner=APPS Object name=CST_INV_DISTRIBUTION_V Cost=41 Cardinality=2 Bytes=118
UNION-ALL
NESTED LOOPS OUTER Cost=20 Cardinality=1 Bytes=291
NESTED LOOPS Cost=18 Cardinality=1 Bytes=255
NESTED LOOPS Cost=18 Cardinality=1 Bytes=251
MERGE JOIN CARTESIAN Cost=14 Cardinality=1 Bytes=192
NESTED LOOPS OUTER Cost=12 Cardinality=1 Bytes=156
NESTED LOOPS Cost=10 Cardinality=1 Bytes=120
NESTED LOOPS OUTER Cost=9 Cardinality=1 Bytes=113
NESTED LOOPS Cost=8 Cardinality=1 Bytes=106
NESTED LOOPS Cost=6 Cardinality=1 Bytes=93
NESTED LOOPS Cost=4 Cardinality=1 Bytes=83
NESTED LOOPS Cost=4 Cardinality=1 Bytes=80
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=76
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_U1 Cost=3 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=191 Bytes=764
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=18 Bytes=54
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=73632445 Bytes=736324450
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=73652390 Bytes=957481070
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
BUFFER SORT Cost=12 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=4 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=3 Cardinality=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
NESTED LOOPS Cost=21 Cardinality=1 Bytes=288
NESTED LOOPS Cost=19 Cardinality=1 Bytes=275
NESTED LOOPS Cost=17 Cardinality=1 Bytes=265
NESTED LOOPS Cost=17 Cardinality=1 Bytes=261
NESTED LOOPS OUTER Cost=16 Cardinality=1 Bytes=254
NESTED LOOPS Cost=15 Cardinality=1 Bytes=247
NESTED LOOPS Cost=15 Cardinality=1 Bytes=243
NESTED LOOPS OUTER Cost=15 Cardinality=1 Bytes=240
NESTED LOOPS Cost=13 Cardinality=1 Bytes=204
NESTED LOOPS Cost=9 Cardinality=1 Bytes=131
NESTED LOOPS OUTER Cost=7 Cardinality=1 Bytes=95
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=5 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=4 Cardinality=3
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=73
INDEX RANGE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_N23 Cost=3 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=1 Bytes=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=1 Bytes=4
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=1 Bytes=10
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=1 Bytes=13
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ALL_ORGANIZATION_UNITS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ORGANIZATION_UNITS_PK Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ALL_ORGANIZATION_UNTS_TL_PK Cost=0 Cardinality=1 Bytes=7
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=8
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=GL Object name=GL_CODE_COMBINATIONS Cost=2 Cardinality=1 Bytes=57
INDEX UNIQUE SCAN Object owner=GL Object name=GL_CODE_COMBINATIONS_U1 Cost=1 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_ITEM_LOCATIONS Cost=3 Cardinality=1 Bytes=24
INDEX RANGE SCAN Object owner=INV Object name=MTL_ITEM_LOCATIONS_U1 Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=2 Cardinality=1 Bytes=28
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=2
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=1 Cardinality=1 Bytes=25
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=1
INDEX FULL SCAN Object owner=GL Object name=GL_SETS_OF_BOOKS_U2 Cost=1 Cardinality=1 Bytes=4
BUFFER SORT Cost=55 Cardinality=1
TABLE ACCESS FULL Object owner=APPLSYS Object name=FND_PRODUCT_GROUPS Cost=3 Cardinality=1 -
Hi all,
We are using Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production on
Linux 2.6.5-7.282-bigsmp #1 SMP box.
The following query is taking aproximately 1 hr to execute.
SELECT item.ap_id, item.ap_version_id, oa.customer_id,CI.CAPTION OFFER_ID, ITEM.BILL_START_DATE , ITEM.CTDB_CRE_DATETIME , oa.order_unit_id
FROM tbap_item item,
tbprice_plan pp,
tborder_action oa,
tborder_action_impl oaimpl,
TBCATALOG_ITEM CI
WHERE item.entity_type = 'amdocs.oms.sbcproduct.ApPricePlanImpl'
AND item.item_def_id = pp.cid
AND item.item_def_ver = pp.pcversion_id
AND pp.is_promote = '1'
AND item.order_action_id = oa.order_unit_id
AND oa.order_unit_id = oaimpl.order_unit_id
AND oaimpl.bypass_reason_id = 'MI'
AND oa.xml_id IS NOT NULL
AND item.state IN ('AS', 'OR')
AND item.status = 'AC'
AND CI.CID = ITEM.ITEM_DEF_ID
AND CI.PCVERSION_ID = ITEM.ITEM_DEF_VER
AND item.ap_version_id = '0'
AND EXISTS (SELECT 1 FROM TBAP_ITEM TEMP WHERE TEMP.AP_ID = ITEM.AP_ID AND TEMP.END_DATE > SYSDATE AND TEMP.STATE IN ('AS' , 'OR') AND TEMP.STATUS ='AC');
the execution plan before collecting the stats is:
Query Plan
SELECT STATEMENT [CHOOSE] Cost=120002
NESTED LOOPS SEMI Cost=120002 Card=98407 Bytes=18402109
MERGE JOIN Cost=80639 Card=98407 Bytes=16040341
SORT JOIN Cost=80607 Card=98407 Bytes=13481759
MERGE JOIN Cost=78626 Card=98407 Bytes=13481759
SORT JOIN Cost=76699 Card=119937 Bytes=14992125
MERGE JOIN Cost=76699 Card=119937 Bytes=14992125
SORT JOIN Cost=76682 Card=171602 Bytes=19219424
MERGE JOIN Cost=76682 Card=171602 Bytes=19219424
SORT JOIN Cost=74698 Card=990661 Bytes=82224863
TABLE ACCESS FULL TBAP_ITEM [ANALYZED] Cost=62069 Card=990661 Bytes=82224863
SORT JOIN Cost=1985 Card=89365 Bytes=2591585
TABLE ACCESS FULL TBORDER_ACTION [ANALYZED] Cost=1511 Card=89365 Bytes=2591585
SORT JOIN Cost=17 Card=195 Bytes=2535
TABLE ACCESS FULL TBPRICE_PLAN [ANALYZED] Cost=2 Card=195 Bytes=2535
SORT JOIN Cost=1928 Card=73323 Bytes=879876
TABLE ACCESS FULL TBORDER_ACTION_IMPL [ANALYZED] Cost=1698 Card=73323 Bytes=879876
SORT JOIN Cost=33 Card=3017 Bytes=78442
TABLE ACCESS FULL TBCATALOG_ITEM [ANALYZED] Cost=4 Card=3017 Bytes=78442
TABLE ACCESS BY INDEX ROWID TBAP_ITEM [ANALYZED] Cost=1 Card=2037512 Bytes=48900288
INDEX RANGE SCAN TBAP_ITEM_PK [ANALYZED] Cost=2 Card=2 Bytes=
after collecting the stats:
SELECT STATEMENT [CHOOSE] Cost=64972
NESTED LOOPS SEMI Cost=64972 Card=333 Bytes=62937
NESTED LOOPS Cost=64839 Card=333 Bytes=54945
MERGE JOIN Cost=64446 Card=1965 Bytes=300645
SORT JOIN Cost=64414 Card=1965 Bytes=249555
MERGE JOIN Cost=64414 Card=1965 Bytes=249555
SORT JOIN Cost=62429 Card=13393 Bytes=1312514
MERGE JOIN Cost=62429 Card=13393 Bytes=1312514
SORT JOIN Cost=2 Card=140 Bytes=1820
TABLE ACCESS FULL TBPRICE_PLAN [ANALYZED] Cost=2 Card=140 Bytes=1820
SORT JOIN Cost=62428 Card=26785 Bytes=2276725
TABLE ACCESS FULL TBAP_ITEM [ANALYZED] Cost=62072 Card=26785 Bytes=2276725
SORT JOIN Cost=1985 Card=89365 Bytes=2591585
TABLE ACCESS FULL TBORDER_ACTION [ANALYZED] Cost=1511 Card=89365 Bytes=2591585
SORT JOIN Cost=33 Card=3017 Bytes=78442
TABLE ACCESS FULL TBCATALOG_ITEM [ANALYZED] Cost=4 Card=3017 Bytes=78442
TABLE ACCESS BY INDEX ROWID TBORDER_ACTION_IMPL [ANALYZED] Cost=1 Card=1 Bytes=12
INDEX UNIQUE SCAN TBORDER_ACTION_IMPL_PK [ANALYZED] Cost=1 Card=1 Bytes=
TABLE ACCESS BY INDEX ROWID TBAP_ITEM [ANALYZED] Cost=1 Card=2972308 Bytes=71335392
INDEX RANGE SCAN TBAP_ITEM_PK [ANALYZED] Cost=2 Card=2 Bytes=
I am now taking the level 4 trace now.will post it once Its done. I found some "latchfree" timeouts while running it now...
I also find that few cols refered in where clause doesn't have indexes...So I am going to discuss this with the developers. also I want modify the query too..as below.
ELECT item.ap_id, item.ap_version_id, oa.customer_id,CI.CAPTION OFFER_ID, ITEM.BILL_START_DATE , ITEM.CTDB_CRE_DATETIME , oa.order_unit_id
FROM tbap_item item,
tbprice_plan pp,
tborder_action oa,
tborder_action_impl oaimpl,
TBCATALOG_ITEM CI
WHERE
item.entity_type = 'amdocs.oms.sbcproduct.ApPricePlanImpl'
AND item.status = 'AC'
AND item.state IN ('AS', 'OR')
AND item.ap_version_id = '0'
AND pp.is_promote = '1'
AND oaimpl.bypass_reason_id = 'MI'
AND oa.xml_id IS NOT NULL
AND item.item_def_id = pp.cid
AND item.item_def_ver = pp.pcversion_id
AND item.order_action_id = oa.order_unit_id
AND oa.order_unit_id = oaimpl.order_unit_id
AND CI.CID = ITEM.ITEM_DEF_ID
AND CI.PCVERSION_ID = ITEM.ITEM_DEF_VER
AND EXISTS (SELECT 1 FROM TBAP_ITEM TEMP WHERE
TEMP.STATE IN ('AS' , 'OR') AND TEMP.STATUS ='AC' AND TEMP.AP_ID = ITEM.AP_ID AND TEMP.END_DATE > SYSDATE );
Please suggest. what else I need to check to imporve the performace .
Thanks in advace for your help and suggestions.here is formatted one:
call count cpu elapsed disk query current rows
Parse 1 0.14 0.19 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 8 58.21 4169.28 1663901 1699503 10 103
total 10 58.36 4169.47 1663901 1699503 10 103
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 139
Rows Row Source Operation
103 NESTED LOOPS SEMI
158 NESTED LOOPS
3613 MERGE JOIN
3613 SORT JOIN
3613 MERGE JOIN
110996 SORT JOIN
110996 MERGE JOIN
195 SORT JOIN
195 TABLE ACCESS FULL OBJ#(33959)
110996 SORT JOIN
820046 TABLE ACCESS FULL OBJ#(33563)
3613 SORT JOIN
89365 TABLE ACCESS FULL OBJ#(33538)
3613 SORT JOIN
3017 TABLE ACCESS FULL OBJ#(33889)
158 TABLE ACCESS BY INDEX ROWID OBJ#(33534)
3613 INDEX UNIQUE SCAN OBJ#(33645) (object id 33645)
103 TABLE ACCESS BY INDEX ROWID OBJ#(33563)
275 INDEX RANGE SCAN OBJ#(48320) (object id 48320)
******************************************************************************** -
Query Tuning - using CASE statement in the WHERE clause
Hi All,
My query has been modified to use a CASE statement in the WHERE clause to consider data from certain columns based on a parameter value. This modified query is doing a full table scan and running endlessly. Please suggest what may be done to improve its performance:
Query:
SELECT LAST_DAY(TRUNC(TO_TIMESTAMP(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS summary_date,
os.acctnum,
os.avieworigin_refid,
COUNT(1) cnt_articleview,
SUM(NVL(autocompletedterm,0)) cnt_autocompletedterm
FROM TABLE1 os
WHERE os.acctnum IS NOT NULL
AND os.avieworigin_refid IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
AND CASE WHEN
Param_ValueToCheck = 'FULL' AND get_date_timestamp(os.requestdatetime) BETWEEN
TO_DATE('01-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND
TO_DATE('31-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
THEN 1
WHEN
Param_ValueToCheck = 'INCR' AND os.entry_createddate BETWEEN
TO_DATE('01-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND
TO_DATE('31-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
THEN 1
END = 1
AND CASE WHEN
Param_ValueToCheck = 'FULL' AND os.entry_CreatedDate BETWEEN
TO_DATE('01-APR-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND
TO_DATE('07-JUN-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
THEN 1
WHEN
Param_ValueToCheck = 'INCR' THEN 1
END = 1
GROUP BY LAST_DAY(TRUNC(TO_TIMESTAMP(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))), os.acctnum,os.avieworigin_refid;Table Description:
(Number of rows : approx > 600,000,000)
Name Null Type
ARTICLEID NOT NULL NUMBER(20)
USERKEY NUMBER(10)
AVIEWORIGIN_REFID VARCHAR2(10)
SUCCESS_IND VARCHAR2(2)
ENTRY_CREATEDDATE DATE
CREATED_BY VARCHAR2(10)
FILENUMBER NUMBER(10)
LINENUMBER NUMBER(10)
ACCTNUM VARCHAR2(10)
AUTOCOMPLETEDTERM NUMBER(2)
REQUESTDATETIME VARCHAR2(19)Explain Plan
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2224314832
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 590 | 33040 | 2501K (1)| 08:20:15 | | |
| 1 | HASH GROUP BY | | 590 | 33040 | 2501K (1)| 08:20:15 | | |
| 2 | PARTITION RANGE ALL| | 590 | 33040 | 2501K (1)| 08:20:15 | 1 |1048575|
|* 3 | TABLE ACCESS FULL | TABLE1 | 590 | 33040 | 2501K (1)| 08:20:15 | 1 |1048575|
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter(UPPER("OS"."SUCCESS_IND")='S' AND CASE WHEN ('FULL'='FULL' AND
"OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-04-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-06-07 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) THEN 1 WHEN
'FULL'='INCR' THEN 1 END =1 AND "OS"."REQUESTDATETIME" IS NOT NULL AND CASE WHEN ('FULL'='FULL'
AND "ODS"."GET_DATE_TIMESTAMP"("REQUESTDATETIME")>=TO_DATE(' 2011-05-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "ODS"."GET_DATE_TIMESTAMP"("REQUESTDATETIME")<=TO_DATE(' 2011-05-31 00:00:00',
'syyyy-mm-dd hh24:mi:ss')) THEN 1 WHEN ('FULL'='INCR' AND "OS"."ENTRY_CREATEDDATE">=TO_DATE('
2011-05-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE('
PLAN_TABLE_OUTPUT
2011-05-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) THEN 1 END =1 AND "OS"."ACCTNUM" IS NOT NULL AND
"OS"."AVIEWORIGIN_REFID" IS NOT NULL)Edited by: Chaitanya on Jun 9, 2011 2:44 AM
Edited by: Chaitanya on Jun 9, 2011 2:47 AMHi Dom,
Modified Query:
SELECT LAST_DAY(TRUNC(TO_TIMESTAMP(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS summary_date,
os.acctnum,
os.avieworigin_refid,
COUNT(1) cnt_articleview,
SUM(NVL(autocompletedterm,0)) cnt_autocompletedterm
FROM TABLE1 os
WHERE os.acctnum IS NOT NULL
AND os.avieworigin_refid IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
AND (('FULL' = 'FULL'
AND (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('01-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
AND TO_DATE('31-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
AND os.entry_CreatedDate BETWEEN TO_DATE('01-APR-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
AND TO_DATE('07-JUN-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
OR ('FULL' = 'INCR'
AND os.entry_createddate BETWEEN TO_DATE('01-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
AND TO_DATE('31-MAY-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') ))
GROUP BY LAST_DAY(TRUNC(TO_TIMESTAMP(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))), os.acctnum,os.avieworigin_refid;Execute Plan:
PLAN_TABLE_OUTPUT
Plan hash value: 3615447714
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 25125 | 1374K| | 407K (1)| 01:21:36 | | |
| 1 | HASH GROUP BY | | 25125 | 1374K| 3768K| 407K (1)| 01:21:36 | | |
| 2 | PARTITION RANGE ITERATOR| | 25125 | 1374K| | 407K (1)| 01:21:32 | 29 | 31 |
|* 3 | TABLE ACCESS FULL | TABLE1 | 25125 | 1374K| | 407K (1)| 01:21:32 | 29 | 31 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter("OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-04-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
UPPER("OS"."SUCCESS_IND")='S' AND "OS"."REQUESTDATETIME" IS NOT NULL AND
"ODS"."GET_DATE_TIMESTAMP"("REQUESTDATETIME")>=TO_DATE(' 2011-05-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"ODS"."GET_DATE_TIMESTAMP"("REQUESTDATETIME")<=TO_DATE(' 2011-05-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"OS"."ACCTNUM" IS NOT NULL AND "OS"."AVIEWORIGIN_REFID" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE('
2011-06-07 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))Edited by: Chaitanya on Jun 9, 2011 4:51 AM
Maybe you are looking for
-
BAPI_PO_GETDETAIL
Hello All, I want to use the above BAPI to retrive purchase order details remotely. PO details available in the logistic system X . My client requirement is that want to store this information in system Y(this is also SAP system). But my question is
-
Data deletion on primary index and secondary index
Hello, I have a question regarding data deletion in BDB-JE. Suppose I have an Entity class which has a primary index and a secondary index, the secondary key does not have outer related entity. So when I want to delete this entity, is it correct we o
-
Excise Invoice Reversal Procedure
Hello Experts, Please let me know the exact procedure for the reversal of an Incoming Excise Invoice. Which docs. to prepare and what effect does it makes on the JE's. ? Thanx & Regards, PAPIL
-
Can the menu/forward/backward/pause be scratched/peeled off?
to prevent scratches i usually put some packing tape on wherever need be (cell phone screens, etc) I was thinking of doing the same as it has done a great job for me in the past, but i don't want to be peeling off any of the clickwheel as well. can s
-
How to Install deskjet3510 on iPad
How do I install hp desk jet 3511 all-in-one on my iPad