Ideas for tuning query
Oracle 10.2.0.4
Windows Server 2003 32-bit
Problem query in monthly report. Query is based on a very complex view, too complex to cleanse of proprietary info and post, so I'm not asking for a specific analysis of the view, just some ideas based on the following:
query came to my attention because it often blows up, running out of space on the TEMP ts. Continuing to add space is really not a tenable solution.
Running a 10046 trace on the query, then producing a tkprof report indicates one step of the plan is producing over 138 million rows. This for a final report of only 120 rows, and the largest table in the entire view is right at 1 million rows. At first I suspected a Cartesian join, but we were unable to find at least the classic case of it .. two tables in a SELECT with no joining criteria. Still, those numbers suggest what I would call a 'Cartesian-like' join.
These numbers are being produced at these steps:
5 VIEW X_EDSTEST_X_VW (cr=1259106 pr=9218935 pw=6275357 time=653383732 us)
5 HASH UNIQUE (cr=1259106 pr=9218935 pw=6275357 time=653383725 us)
10 HASH JOIN RIGHT ANTI (cr=1259097 pr=9218932 pw=6275357 time=653350593 us)
137025904 VIEW VW_WIF_1 (cr=629938 pr=8789891 pw=6046202 time=2728542480 us)
138866830 WINDOW SORT (cr=629938 pr=8789891 pw=6046202 time=4552220507 us)
138866830 HASH JOIN (cr=629938 pr=5943 pw=3030 time=66116252 us)
726058 NESTED LOOPS (cr=629013 pr=1991 pw=0 time=29460324 us)
2063 NESTED LOOPS (cr=629013 pr=1991 pw=0 time=8439492 us)
2063 HASH JOIN (cr=624885 pr=1991 pw=0 time=8416797 us)I googled the 'vw_wif_1' and didn't get a lot out of it. It seems to be an internal view created by oracle, and is tied to the 'window sort'. Most of the discussion I could get from there was pointing toward analytic functions, but we don't use any in this query/view.
So, in general, does anyone have any ideas on what kinds of things I should be looking for here.
Nikolay - thanks for taking the time to look at this. Of course the plan I previously posted was a 'live' plan taken from the trace. Below is generated by utlxpls. I'm a bit puzzeled by the results in that while the plan itself is the same, the row counts a wildly different, especially at the critical point of the VW_WIF_1 view. Nevertheless ...
Table truncated.
SQL> set linesize 256
SQL> set trimspool on
SQL> set pagesize 0
SQL> explain plan for
2 SELECT * FROM APP_SCHEMA.X_EDSTEST_X_VW;
Explained.
SQL> set echo off
Plan hash value: 3099799268
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 306 | 87516 | | 2588 (1)| 00:00:32 | | |
| 1 | SORT AGGREGATE | | 1 | 13 | | | | | |
| 2 | FIRST ROW | | 1463K| 18M| | 1 (0)| 00:00:01 | | |
|* 3 | INDEX FULL SCAN (MIN/MAX) | IDX_RAC_DELIM_PMT_EFFD_MANDGOC | 1463K| 18M| | 1 (0)| 00:00:01 | | |
| 4 | SORT AGGREGATE | | 1 | 13 | | | | | |
| 5 | FIRST ROW | | 1463K| 18M| | 1 (0)| 00:00:01 | | |
|* 6 | INDEX FULL SCAN (MIN/MAX) | IDX_RAC_DELIM_PMT_EFFD_MANDGOC | 1463K| 18M| | 1 (0)| 00:00:01 | | |
| 7 | SORT AGGREGATE | | 1 | 13 | | | | | |
| 8 | FIRST ROW | | 1463K| 18M| | 1 (0)| 00:00:01 | | |
|* 9 | INDEX FULL SCAN (MIN/MAX) | IDX_RAC_DELIM_PMT_EFFD_MANDGOC | 1463K| 18M| | 1 (0)| 00:00:01 | | |
| 10 | SORT AGGREGATE | | 1 | 13 | | | | | |
| 11 | FIRST ROW | | 1463K| 18M| | 1 (0)| 00:00:01 | | |
|* 12 | INDEX FULL SCAN (MIN/MAX) | IDX_RAC_DELIM_PMT_EFFD_MANDGOC | 1463K| 18M| | 1 (0)| 00:00:01 | | |
| 13 | VIEW | X_EDSTEST_X_VW | 306 | 87516 | | 2588 (1)| 00:00:32 | | |
| 14 | HASH UNIQUE | | 306 | 88128 | | 2588 (1)| 00:00:32 | | |
|* 15 | HASH JOIN RIGHT ANTI | | 306 | 88128 | | 2587 (1)| 00:00:32 | | |
|* 16 | VIEW | VW_WIF_1 | 850 | 14450 | | 1398 (1)| 00:00:17 | | |
| 17 | WINDOW SORT | | 850 | 121K| | 1398 (1)| 00:00:17 | | |
|* 18 | HASH JOIN | | 850 | 121K| | 1397 (1)| 00:00:17 | | |
| 19 | NESTED LOOPS | | 306 | 29988 | | 1188 (1)| 00:00:15 | | |
| 20 | NESTED LOOPS | | 10 | 650 | | 1108 (1)| 00:00:14 | | |
|* 21 | HASH JOIN | | 10 | 560 | | 1105 (1)| 00:00:14 | | |
| 22 | NESTED LOOPS | | 4 | 120 | | 3 (0)| 00:00:01 | | |
| 23 | NESTED LOOPS | | 4 | 100 | | 2 (0)| 00:00:01 | | |
| 24 | TABLE ACCESS BY INDEX ROWID | RAC_ACCOUNT | 1 | 11 | | 1 (0)| 00:00:01 | | |
|* 25 | INDEX RANGE SCAN | RAC_ACCOUNT_NUMBER_IX | 1 | | | 1 (0)| 00:00:01 | | |
| 26 | TABLE ACCESS BY INDEX ROWID | USE_PURP | 3 | 42 | | 1 (0)| 00:00:01 | | |
|* 27 | INDEX RANGE SCAN | USE_OF_PURPOSE_IDX5 | 3 | | | 1 (0)| 00:00:01 | | |
|* 28 | INDEX UNIQUE SCAN | PK_CTR_CONTRACT | 1 | 5 | | 1 (0)| 00:00:01 | | |
| 29 | VIEW | VIEW_PARTDESCVERSION | 20346 | 516K| | 1101 (1)| 00:00:14 | | |
| 30 | SORT UNIQUE | | 20346 | 2841K| 6280K| 1101 (2)| 00:00:14 | | |
| 31 | UNION-ALL | | | | | | | | |
|* 32 | HASH JOIN | | 20345 | 2841K| | 446 (2)| 00:00:06 | | |
|* 33 | INDEX FAST FULL SCAN | USE_PURP_IN1 | 13268 | 246K| | 17 (0)| 00:00:01 | | |
|* 34 | HASH JOIN RIGHT OUTER | | 12185 | 1475K| | 428 (1)| 00:00:06 | | |
| 35 | VIEW | MAP_DATA_TYPES | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 36 | TABLE ACCESS BY INDEX ROWID| MAP_DATA_TYPES_TABLE | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 37 | INDEX RANGE SCAN | MDT_TYPE | 11 | | | 1 (0)| 00:00:01 | | |
|* 38 | HASH JOIN | | 12185 | 940K| | 426 (1)| 00:00:06 | | |
| 39 | TABLE ACCESS FULL | CTR_REF_PARTDESC_CONTRACT | 12185 | 309K| | 21 (0)| 00:00:01 | | |
| 40 | TABLE ACCESS FULL | PRD_PARTVERSION | 37835 | 1958K| | 404 (1)| 00:00:05 | | |
|* 41 | HASH JOIN OUTER | | 1 | 142 | | 5 (20)| 00:00:01 | | |
| 42 | NESTED LOOPS | | 1 | 97 | | 3 (0)| 00:00:01 | | |
| 43 | NESTED LOOPS | | 1 | 44 | | 2 (0)| 00:00:01 | | |
| 44 | TABLE ACCESS BY INDEX ROWID| RAC_ACCOUNT | 1 | 18 | | 1 (0)| 00:00:01 | | |
|* 45 | INDEX FULL SCAN | IDX_RAC_CONTRACT_ID | 1 | | | 1 (0)| 00:00:01 | | |
| 46 | TABLE ACCESS BY INDEX ROWID| CTR_REF_PARTDESC_CONTRACT | 1 | 26 | | 1 (0)| 00:00:01 | | |
|* 47 | INDEX RANGE SCAN | CTR_REF_TC_CONTRACT_FK | 2 | | | 1 (0)| 00:00:01 | | |
| 48 | TABLE ACCESS BY INDEX ROWID | PRD_PARTVERSION | 1 | 53 | | 1 (0)| 00:00:01 | | |
|* 49 | INDEX UNIQUE SCAN | PRD_PARTVERSION_PK | 1 | | | 1 (0)| 00:00:01 | | |
| 50 | VIEW | MAP_DATA_TYPES | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 51 | TABLE ACCESS BY INDEX ROWID | MAP_DATA_TYPES_TABLE | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 52 | INDEX RANGE SCAN | MDT_TYPE | 11 | | | 1 (0)| 00:00:01 | | |
| 53 | TABLE ACCESS BY INDEX ROWID | PRD_PARTVERSION | 1 | 9 | | 1 (0)| 00:00:01 | | |
|* 54 | INDEX UNIQUE SCAN | PRD_PARTVERSION_PK | 1 | | | 1 (0)| 00:00:01 | | |
| 55 | REMOTE | STAT_POSITION | 29 | 957 | | 8 (0)| 00:00:01 | STAT_~ | R->S |
|* 56 | INDEX RANGE SCAN | RWO_RAC_ENTRY_IDX_CTR_ED | 98148 | 4600K| | 208 (1)| 00:00:03 | | |
| 57 | NESTED LOOPS | | 306 | 82926 | | 1191 (2)| 00:00:15 | | |
| 58 | NESTED LOOPS | | 10 | 1730 | | 1109 (1)| 00:00:14 | | |
|* 59 | HASH JOIN | | 10 | 1200 | | 1106 (1)| 00:00:14 | | |
| 60 | NESTED LOOPS | | 4 | 376 | | 4 (0)| 00:00:01 | | |
| 61 | NESTED LOOPS | | 4 | 296 | | 3 (0)| 00:00:01 | | |
| 62 | NESTED LOOPS | | 4 | 276 | | 2 (0)| 00:00:01 | | |
| 63 | TABLE ACCESS BY INDEX ROWID | RAC_ACCOUNT | 1 | 50 | | 1 (0)| 00:00:01 | | |
|* 64 | INDEX RANGE SCAN | RAC_ACCOUNT_NUMBER_IX | 1 | | | 1 (0)| 00:00:01 | | |
| 65 | TABLE ACCESS BY INDEX ROWID | USE_PURP | 3 | 57 | | 1 (0)| 00:00:01 | | |
|* 66 | INDEX RANGE SCAN | USE_OF_PURPOSE_IDX5 | 3 | | | 1 (0)| 00:00:01 | | |
|* 67 | INDEX UNIQUE SCAN | PK_CTR_CONTRACT | 1 | 5 | | 1 (0)| 00:00:01 | | |
| 68 | TABLE ACCESS BY INDEX ROWID | AP_ASSIGNEE | 1 | 20 | | 1 (0)| 00:00:01 | | |
|* 69 | INDEX UNIQUE SCAN | AP_ASSIGNEE_PK | 1 | | | 1 (0)| 00:00:01 | | |
| 70 | VIEW | VIEW_PARTDESCVERSION | 20346 | 516K| | 1101 (1)| 00:00:14 | | |
| 71 | SORT UNIQUE | | 20346 | 2841K| 6280K| 1101 (2)| 00:00:14 | | |
| 72 | UNION-ALL | | | | | | | | |
|* 73 | HASH JOIN | | 20345 | 2841K| | 446 (2)| 00:00:06 | | |
|* 74 | INDEX FAST FULL SCAN | USE_PURP_IN1 | 13268 | 246K| | 17 (0)| 00:00:01 | | |
|* 75 | HASH JOIN RIGHT OUTER | | 12185 | 1475K| | 428 (1)| 00:00:06 | | |
| 76 | VIEW | MAP_DATA_TYPES | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 77 | TABLE ACCESS BY INDEX ROWID | MAP_DATA_TYPES_TABLE | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 78 | INDEX RANGE SCAN | MDT_TYPE | 11 | | | 1 (0)| 00:00:01 | | |
|* 79 | HASH JOIN | | 12185 | 940K| | 426 (1)| 00:00:06 | | |
| 80 | TABLE ACCESS FULL | CTR_REF_PARTDESC_CONTRACT | 12185 | 309K| | 21 (0)| 00:00:01 | | |
| 81 | TABLE ACCESS FULL | PRD_PARTVERSION | 37835 | 1958K| | 404 (1)| 00:00:05 | | |
|* 82 | HASH JOIN OUTER | | 1 | 142 | | 5 (20)| 00:00:01 | | |
| 83 | NESTED LOOPS | | 1 | 97 | | 3 (0)| 00:00:01 | | |
| 84 | NESTED LOOPS | | 1 | 44 | | 2 (0)| 00:00:01 | | |
| 85 | TABLE ACCESS BY INDEX ROWID | RAC_ACCOUNT | 1 | 18 | | 1 (0)| 00:00:01 | | |
|* 86 | INDEX FULL SCAN | IDX_RAC_CONTRACT_ID | 1 | | | 1 (0)| 00:00:01 | | |
| 87 | TABLE ACCESS BY INDEX ROWID | CTR_REF_PARTDESC_CONTRACT | 1 | 26 | | 1 (0)| 00:00:01 | | |
|* 88 | INDEX RANGE SCAN | CTR_REF_TC_CONTRACT_FK | 2 | | | 1 (0)| 00:00:01 | | |
| 89 | TABLE ACCESS BY INDEX ROWID | PRD_PARTVERSION | 1 | 53 | | 1 (0)| 00:00:01 | | |
|* 90 | INDEX UNIQUE SCAN | PRD_PARTVERSION_PK | 1 | | | 1 (0)| 00:00:01 | | |
| 91 | VIEW | MAP_DATA_TYPES | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 92 | TABLE ACCESS BY INDEX ROWID | MAP_DATA_TYPES_TABLE | 11 | 495 | | 1 (0)| 00:00:01 | | |
|* 93 | INDEX RANGE SCAN | MDT_TYPE | 11 | | | 1 (0)| 00:00:01 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | PRD_PARTVERSION | 1 | 53 | | 1 (0)| 00:00:01 | | |
|* 95 | INDEX UNIQUE SCAN | PRD_PARTVERSION_PK | 1 | | | 1 (0)| 00:00:01 | | |
| 96 | REMOTE | STAT_POSITION | 29 | 2842 | | 8 (0)| 00:00:01 | STAT_~ | R->S |
Predicate Information (identified by operation id):
3 - filter("ENTRY_TYPE"='AAAA')
6 - filter("ENTRY_TYPE"='AAAA')
9 - filter("ENTRY_TYPE"='AAAA')
12 - filter("ENTRY_TYPE"='AAAA')
15 - access("STAT_POS"."PARTVERSION_ID"="PARTVERSION_ID")
16 - filter("VW_COL_2" IS NOT NULL)
18 - access("PRD_PRT"."PARTVERSION_ID"="RAC_ENT"."PARTVERSION_ID")
21 - access("VWPRTDSC"."CONTRACT_ID"="CTR_CON"."CONTRACT_ID")
25 - access("RAC_ACC"."ACCOUNT_NUMBER"=1003046)
27 - access("UP"."ID_OBJ_3"="RAC_ACC"."ACCOUNT_ID")
28 - access("CTR_CON"."CONTRACT_ID"="UP"."ID_OBJ_1")
32 - access("CTR_REF_PARTDESC_CONTRACT"."CONTRACT_ID"="USE_PURP"."ID_OBJ_1")
33 - filter("USE_PURP"."OBJ_TYPE"='CTR' AND ("USE_PURP"."PURPOSE"='AGEN' OR "USE_PURP"."PURPOSE"='CTRP' OR
"USE_PURP"."PURPOSE"='CTRPH'))
34 - access("MAP_DATA_TYPES"."CODE"(+)="PRD_PARTVERSION"."TYPE")
36 - filter("M"."VISIBLE_YN"='Y')
37 - access("M"."TYPE"='EDIT')
38 - access("CTR_REF_PARTDESC_CONTRACT"."PARTVERSION_ID"="PRD_PARTVERSION"."PARTVERSION_ID")
41 - access("MAP_DATA_TYPES"."CODE"(+)="PRD_PARTVERSION"."TYPE")
45 - filter("RAC_ACCOUNT"."ACQUISITION_CONTRACT_ID" IS NOT NULL)
47 - access("CTR_REF_PARTDESC_CONTRACT"."CONTRACT_ID"="RAC_ACCOUNT"."ACQUISITION_CONTRACT_ID")
49 - access("CTR_REF_PARTDESC_CONTRACT"."PARTVERSION_ID"="PRD_PARTVERSION"."PARTVERSION_ID")
51 - filter("M"."VISIBLE_YN"='Y')
52 - access("M"."TYPE"='EDIT')
54 - access("PRD_PRT"."PARTVERSION_ID"="VWPRTDSC"."PARTVERSION_ID")
56 - access("RAC_ENT"."ENTRY_TYPE"='AAAA')
59 - access("VWPRTDSC"."CONTRACT_ID"="CTR_CON"."CONTRACT_ID")
64 - access("RAC_ACC"."ACCOUNT_NUMBER"=1003046)
66 - access("UP"."ID_OBJ_3"="RAC_ACC"."ACCOUNT_ID")
67 - access("CTR_CON"."CONTRACT_ID"="UP"."ID_OBJ_1")
69 - access("UP"."ID_JURISTIC_PERSON"="APA"."ID_JURISTIC_PERSON")
73 - access("CTR_REF_PARTDESC_CONTRACT"."CONTRACT_ID"="USE_PURP"."ID_OBJ_1")
74 - filter("USE_PURP"."OBJ_TYPE"='CTR' AND ("USE_PURP"."PURPOSE"='AGEN' OR "USE_PURP"."PURPOSE"='CTRP' OR
"USE_PURP"."PURPOSE"='CTRPH'))
75 - access("MAP_DATA_TYPES"."CODE"(+)="PRD_PARTVERSION"."TYPE")
77 - filter("M"."VISIBLE_YN"='Y')
78 - access("M"."TYPE"='EDIT')
79 - access("CTR_REF_PARTDESC_CONTRACT"."PARTVERSION_ID"="PRD_PARTVERSION"."PARTVERSION_ID")
82 - access("MAP_DATA_TYPES"."CODE"(+)="PRD_PARTVERSION"."TYPE")
86 - filter("RAC_ACCOUNT"."ACQUISITION_CONTRACT_ID" IS NOT NULL)
88 - access("CTR_REF_PARTDESC_CONTRACT"."CONTRACT_ID"="RAC_ACCOUNT"."ACQUISITION_CONTRACT_ID")
90 - access("CTR_REF_PARTDESC_CONTRACT"."PARTVERSION_ID"="PRD_PARTVERSION"."PARTVERSION_ID")
92 - filter("M"."VISIBLE_YN"='Y')
93 - access("M"."TYPE"='EDIT')
95 - access("PRD_PRT"."PARTVERSION_ID"="VWPRTDSC"."PARTVERSION_ID")
Remote SQL Information (identified by operation id):
55 - SELECT "PARTVERSION_ID","PARTVERSION_TYPE","DISCOUNT" FROM "APP_SCHEMA_2"."STAT_POSITION" "STAT_POS" WHERE "DISCOUNT"<100 AND
"PARTVERSION_TYPE"=:1 AND "PARTVERSION_ID"=:2 (accessing 'STAT_DB.WORLD' )
96 - SELECT "ID_STATPOS","ORDER_NO","PARTVERSION_ID","PARTVERSION_TYPE","DISCOUNT","SALES","RETURNS","VALIDATION_DATE" FROM
"APP_SCHEMA_2"."STAT_POSITION" "STAT_POS" WHERE "DISCOUNT"<100 AND "PARTVERSION_ID"=:1 AND "PARTVERSION_TYPE"=:2 (accessing 'STAT_DB.WORLD' )
Note
- dynamic sampling used for this statement
166 rows selected.
Similar Messages
-
Hi All,
I'm trying to write a query and I'm not sure how to do it. Basically, a user will select "current month - 9" or "previous month - 9" from a drop down list. With that information I need to write a query that will pull data from 12 columns named VAL2-VAL13. The output will return the current month and the previous 9. The problem is that I can't dynamically set aliases for each column so I'm forced to use static aliases (Jan to Dec). The query is going to be written in a proprietary application so I have limited capabilities (standard SQL or call a procedure). I've been told I could create and call a procedure that can calculate the current and 9 previous months and dynamically set the month headers. First, is this true and second how would I do it?
ThanksYour first step will be to normalize your data.
select year, 1 AS month, val2 AS data from your_table union all
select year, 2 AS month, val3 AS data from your_table union all
select year, 3 AS month, val4 AS data from your_table union all
select year, 4 AS month, val5 AS data from your_table union all
select year, 5 AS month, val6 AS data from your_table union all
select year, 6 AS month, val7 AS data from your_table union all
select year, 7 AS month, val8 AS data from your_table union all
select year, 8 AS month, val9 AS data from your_table union all
select year, 9 AS month, val10 AS data from your_table union all
select year, 10 AS month, val11 AS data from your_table union all
select year, 11 AS month, val12 AS data from your_table union all
select year, 12 AS month, val13 AS data from your_table
From there you can use lag() to determine which months you're interested in. -
Hello people,
I have a complex question.
Imagine a supermarket where all sold products are written in a database. The sources are three cash registers. The database will continue filled with new data. I will:
- From a certain product (for example, "JAM", this product is part of a table 'products' in which these specific products are named) the data request which is received in a 30 second after the insertime product 'JAM'.
- The above action I break per cash register (cash_1, Cash_2, Cash_3).
- I want to select all products in all three subqueries occur.
As far as I have:
Select *
From db
Where product in (Select * from db where insertdate between (Select insertdate from db where product = ‘JAM’ and source = ‘Cash_1’) and ((Select insertdate from db where product = ‘JAM’ and source = ‘Cash_1’)-(sysdate-0.000347)))
and product in (Select * from db where insertdate between (Select insertdate from db where product = ‘JAM’ and source = ‘Cash_2’) and ((Select insertdate from db where product = ‘JAM’ and source = ‘Cash_2’)-(sysdate-0.000347)))
And product in (Select * from db where insertdate between (Select insertdate from db where product = ‘JAM’ and source = ‘Cash_3’) and ((Select insertdate from db where product = ‘JAM’ and source = ‘Cash_3’)-(sysdate-0.000347)))
Who can help me? I suppose that this query will very tuff for the server. Are there any ways to tune this query up? I like to hear from you.
Aldert
Edited by: user11315153 on 30-jun-2009 0:51As far as I can see the query is
SELECT *
FROM db
WHERE product IN
(SELECT *
FROM db
WHERE insertdate BETWEEN (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_1')
AND ( (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_1')
- (SYSDATE
- 0.000347)))
AND product IN
(SELECT *
FROM db
WHERE insertdate BETWEEN (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_2')
AND ( (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_2')
- (SYSDATE
- 0.000347)))
AND product IN
(SELECT *
FROM db
WHERE insertdate BETWEEN (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_3')
AND ( (SELECT insertdate
FROM db
WHERE product = 'JAM'
AND source = 'Cash_3')
- (SYSDATE
- 0.000347)))which would probably suffer from a »ORA-00913: too many values«, because you can't do »..where product in (select * from ....)« (if db has more than one column).
It would be better to provide table structures - db version - and to formulate what you actually want to achieve. -
Tuning query with inline views
Hi!
I have a performance problem with the following query. I try to combine v1 and v2 into one inline view but because of the recursive design of the tables workflow and workflow_node it didn't work.
Does anybody has an idea for tuning this query?
SELECT distinct v1.u_protocol_id
FROM ( SELECT workflow_node.workflow_id,u_protocol.u_protocol_id
FROM workflow_node,workflow,U_protocol
WHERE workflow.workflow_id=workflow_node.workflow_id
AND u_protocol.u_protocol_id = workflow_node.parameter_2
AND workflow_node.workflow_node_type_id=17
AND workflow.workflow_node_type_id=42
) v1,
( SELECT workflow_node.workflow_id,test_template.test_template_id
FROM workflow_node,test_template
WHERE test_template.test_template_id = workflow_node.template
AND workflow_node.order_number = 1
AND workflow_node.workflow_node_type_id=42
) v2,
( SELECT aliquot.aliquot_id,test_template.test_template_id
FROM aliquot,test,test_template
WHERE aliquot.aliquot_id = test.aliquot_id
AND test.test_template_id = test_template.test_template_id
) v3
WHERE v1.workflow_id = v2.workflow_id
AND v2.test_template_id= v3.test_template_idI have found a script (utlxplan.sql) for creating the plan_table so here it is
SQL> @c:\utlxplan.sql;
Table created.
SQL> EXPLAIN PLAN FOR SELECT distinct v1.u_protocol_id
2 FROM ( SELECT workflow_node.workflow_id,u_protocol.u_protocol_id
3 FROM lims_sys.workflow_node,lims_sys.workflow,lims_sys.U_protocol
4 WHERE workflow.workflow_id=workflow_node.workflow_id
5 AND u_protocol.u_protocol_id = workflow_node.parameter_2
6 AND workflow_node.workflow_node_type_id=17
7 AND workflow.workflow_node_type_id=42
8 ) v1,
9 ( SELECT workflow_node.workflow_id,test_template.test_template_id
10 FROM lims_sys.aliquot,lims_sys.test,lims_sys.workflow_node,lims_sys.test_template
11 WHERE aliquot.aliquot_id = test.aliquot_id
12 AND test.test_template_id = test_template.test_template_id
13 AND test_template.test_template_id = workflow_node.template
14 ) v2
15 WHERE v1.workflow_id = v2.workflow_id
16 /
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name |
Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | |
PLAN_TABLE_OUTPUT
| | |
| 1 | SORT UNIQUE | |
| | |
| 2 | FILTER | |
| | |
| 3 | NESTED LOOPS | |
| | |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | |
| | |
| 5 | NESTED LOOPS | |
| | |
| 6 | NESTED LOOPS | |
| | |
| 7 | NESTED LOOPS | |
| | |
PLAN_TABLE_OUTPUT
| 8 | NESTED LOOPS | |
| | |
| 9 | TABLE ACCESS BY INDEX ROWID| WORKFLOW |
| | |
|* 10 | INDEX RANGE SCAN | FK_WORKFLOW_WORKFLOW_NODE_TYPE |
| | |
| 11 | TABLE ACCESS BY INDEX ROWID| WORKFLOW_NODE |
PLAN_TABLE_OUTPUT
| | |
| 12 | AND-EQUAL | |
| | |
|* 13 | INDEX RANGE SCAN | FK_WORKFLOW_NODE_WORKFLOW |
| | |
|* 14 | INDEX RANGE SCAN | FK_WORKFLOW_NODE_NODE_TYPE |
| | |
PLAN_TABLE_OUTPUT
| 15 | TABLE ACCESS BY INDEX ROWID | U_PROTOCOL |
| | |
|* 16 | INDEX UNIQUE SCAN | PK_U_PROTOCOL |
| | |
| 17 | TABLE ACCESS BY INDEX ROWID | WORKFLOW_NODE |
| | |
|* 18 | INDEX RANGE SCAN | FK_WORKFLOW_NODE_WORKFLOW |
| | |
PLAN_TABLE_OUTPUT
| 19 | TABLE ACCESS BY INDEX ROWID | TEST_TEMPLATE |
| | |
|* 20 | INDEX UNIQUE SCAN | PK_TEST_TEMPLATE |
| | |
| 21 | TABLE ACCESS BY INDEX ROWID | TEST |
| | |
|* 22 | INDEX RANGE SCAN | FK_TEST_TEST_TEMPLATE |
PLAN_TABLE_OUTPUT
| | |
| 23 | TABLE ACCESS BY INDEX ROWID | ALIQUOT |
| | |
|* 24 | INDEX UNIQUE SCAN | PK_ALIQUOT |
| | |
| 25 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP |
| | |
PLAN_TABLE_OUTPUT
| 26 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP |
| | |
| 27 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP |
| | |
| 28 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP |
| | |
| 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP |
| | |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
10 - access("SYS_ALIAS_5"."WORKFLOW_NODE_TYPE_ID"=42)
13 - access("SYS_ALIAS_5"."WORKFLOW_ID"="WORKFLOW_NODE"."WORKFLOW_ID")
14 - access("WORKFLOW_NODE"."WORKFLOW_NODE_TYPE_ID"=17)
PLAN_TABLE_OUTPUT
16 - access("SYS_ALIAS_4"."U_PROTOCOL_ID"=TO_NUMBER("WORKFLOW_NODE"."PARAMETER
_2"))
18 - access("WORKFLOW_NODE"."WORKFLOW_ID"="WORKFLOW_NODE"."WORKFLOW_ID")
20 - access("SYS_ALIAS_1"."TEST_TEMPLATE_ID"="WORKFLOW_NODE"."TEMPLATE")
22 - access("SYS_ALIAS_2"."TEST_TEMPLATE_ID"="SYS_ALIAS_1"."TEST_TEMPLATE_ID")
24 - access("SYS_ALIAS_3"."ALIQUOT_ID"="SYS_ALIAS_2"."ALIQUOT_ID")
Note: rule based optimization -
Parameters to be considered for tuning the QUERY Performance.
Hi Guys
I wanted to identify the Query which is taking more resources through the Dynamic performance views and not through OEM.I wanter to tune the Query.
Please suggest me on this. Also i wanted to know what are all the parameters to be considered for tuning a query like Query execution time, I/O Hits, Library cache hits, etc and from which performance view these paramaters can be taken. I also wanted to know how to find the size of library cache and how much queries can be holded in a library cache and what will be the retention of queries in library cache and how to retrive the queries from Library cache.
Thanks a lot
Edited by: user448837 on Sep 23, 2008 9:24 PMHmm there is a parameter called makemyquery=super_fast, check that ;-).
Ok jokes apart, your question is like asking a doctor that when a person is sick than how to troubleshoot his sickeness? So does a doctor start giving medicine immediately? No right? He has to check some symptoms of the patient. The same is applicable to the query also. There is no view as such which would tell you the performance of the query ie it is good or bad. Tell me if a query is taking up 5 minutes and I come and tell you this, what would you say its good or bad or the query took this much CPU time what would you say, its too much or too less? I am sure your answers would be "it depends". That's the key point.
The supermost point in the performance check is two things, one the plan of the query. What kind of plan optimizer took for the query and whether it was really good or not? There are millions os ways to do som ething but the idea is to do it in the best way. That's what the idea of reading explain plan. I would suggest get your self familiar with explain plan's various paths and their pros and cons. Also about the query's charectristics, you can check V$sql, v$sqlarea , V$sql_text views.
Your other question that you want to check the size of the library cache , its contents and the retention, I would say that its all internally managed. You never size library cache but shared pool only. Similary the best bet for a dba/developer is to check the queries are mostly shareable and there wont be any duplicate sqls. So the cursor_sharing parameter can be used for this. The control is not given to us to manage the rentention or the flushing of the queries from the cache.
HTH
Aman.... -
Performance tuning in 11g for said query
Hello,
I have the below query which needs to be tuned:
SELECT DISTINCT a.emplid
, a.upa_fiscal_year
, b.balance_period
, 0
, a.descr
, a.UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.balance_period = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period )
UNION
SELECT emplid
, upa_fiscal_year
, balance_period
, 1
, 'Total'
, SUM ( UPA_CURRENT_AMT )
, SUM ( UPA_CURRENT_AMT2 )
, SUM ( UPA_CURRENT_AMT3 )
, SUM ( UPA_CURRENT_AMT4 )
FROM (
SELECT DISTINCT a.emplid emplid
, a.upa_fiscal_year upa_fiscal_year
, b.balance_period balance_period
, a.descr
, a.UPA_CURRENT_AMT UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2 UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3 UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4 UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.BALANCE_PERIOD = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period ) )
GROUP BY emplid , upa_fiscal_year , balance_period;The EXPLAIN plan for this query is as under:
Plan hash value: 3550380953
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 24 | 2784 | | 429M (53)|999:59:59 |
| 1 | SORT UNIQUE | | 24 | 2784 | | 429M (53)|999:59:59 |
| 2 | UNION-ALL | | | | | | |
|* 3 | FILTER | | | | | | |
| 4 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 5 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 6 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 7 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 8 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 10 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 11 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 12 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 13 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 16 | FILTER | | | | | | |
| 17 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 18 | FILTER | | | | | | |
|* 19 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 21 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 91 | | | |
| 23 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 24 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | | | | | |
| 26 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 30 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
| 31 | HASH GROUP BY | | 12 | 852 | | 214M (5)|715:46:12 |
| 32 | VIEW | | 12 | 852 | | 214M (5)|715:46:12 |
| 33 | HASH UNIQUE | | 12 | 1932 | | 214M (5)|715:46:12 |
|* 34 | FILTER | | | | | | |
| 35 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 36 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 37 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 38 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 39 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 41 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 42 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 43 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 44 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 46 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 47 | FILTER | | | | | | |
| 48 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 49 | FILTER | | | | | | |
|* 50 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 52 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 53 | SORT AGGREGATE | | 1 | 91 | | | |
| 54 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 55 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 56 | NESTED LOOPS | | | | | | |
| 57 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID| PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 59 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
7 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
12 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
13 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
15 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
16 - filter("V"."DESCR"=:B1)
18 - filter(:B1>:B2)
19 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
20 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
21 - filter("V"."UPA_FISCAL_YEAR"=:B1)
28 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
29 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
30 - filter("V"."DESCR"=:B1)
34 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
38 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
43 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
44 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
46 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
47 - filter("V"."DESCR"=:B1)
49 - filter(:B1>:B2)
50 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
51 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
52 - filter("V"."UPA_FISCAL_YEAR"=:B1)
59 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
60 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
61 - filter("V"."DESCR"=:B1)Any directions as to how to tune this query would be greatly appreciated!
Thanks,
Suddhasatwalooks like these two steps hurts the most (causing the NL join take forever - because of the 4,5M rows)
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')do you have an index on PS_UPA_EQ_DC_BAL.UPA_INC_TYPE column?
reducing the number of rows returned in this step would be critical to speed up the NL join -
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 |
--------------------------------------------------------------------------------------------------- -
Suggetion For below query tuning...
Can any one suggest what to tune for following query...
Query:
SQL> SELECT count(1)
2 FROM SCOTT.IVR_CALL_MASTER
3 WHERE STARTDATETIME BETWEEN '01-Dec-2007' AND '31-Dec-2007'
4 AND SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1),LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1)
5 LIKE ';2%'
6 AND CALLENDREASON < '6'
7 AND ACCOUNTNUMBER IS NOT NULL
8 AND SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1), LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1)
9 NOT IN (';2',';21',';113')
10 /
COUNT(1)
687156
Elapsed: 00:10:02.06
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=91867 Card=1 Bytes=2
6)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'IVR_CALL_MASTER' (Cost
=91867 Card=1 Bytes=26)
3 2 INDEX (RANGE SCAN) OF 'IND_MAS_DAT' (NON-UNIQUE) (Cost
=311 Card=116534)
Statistics
0 recursive calls
0 db block gets
8392293 consistent gets
216218 physical reads
0 redo size
381 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Table_statistics:
♀OWNER EMPTY_BLOCKS BLOCKS NUM_ROWS LAST_ANAL INI_TRANS FREELISTS PCT_FREE AVG_SPACE
SCOTT 0 605599 32713980 01-JUL-07 1 1 10 0
Column_Stats:
♀COLUMN_NAME NUM_DISTINCT
ACCOUNTNUMBER 1932852
AUTHFAILREASON 3
AUTHFLAG 3
CALLENDREASON 7
CALLID 0
CLI 2672332
CRN 1130007
DESTVDN 64
DURATIONOFCALL 1063
ENDDATETIME 6518689
ENDTIME 85257
FIRSTTIMEFLAG 7
LANGUAGE 2
LINENO 240
ORIGINVDN 320
PRU_AGENTMENU 1
PRU_FOLIO 1
PRU_VM 1
STARTDATETIME 6447794
STARTTIME 85277
TRANVERSEPATH1 22338
TRANVERSEPATH2 15138
VPS_NO 7
Index_columns:
♀INDEX_NAME COLUMN_NAME COLUMN_POSITION
INDX3 CRN 1
IND_MAS_ACCNO ACCOUNTNUMBER 1
IND_MAS_CLI CLI 1
IND_MAS_DAT STARTDATETIME 1
[post]
Thanks in Advance.I'm not sure if that will help, you'll need to test it out.
When I mean is that
SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1),
LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1) LIKE ';2%'
includes everything that being with ";2", but then you exclude three cases with this:
SUBSTR(TRANVERSEPATH1,INSTR(TRANVERSEPATH1,';',-1,1), LENGTH(TRANVERSEPATH1)-INSTR(TRANVERSEPATH1,';',-1,1)+1) NOT IN (';2',';21',';113')
';113' isn't like ';2%' so it isn't included to begin with.
depending on how many "like ';2%'" values you have, it may be quicker to use an "IN" clause with just the ones you want, for example:
substr(tranversepath1,instr(tranversepath1,';',-1,1), length(tranversepath1)-instr(tranversepath1,';',-1,1)+1) in (';22',';20',';213') -
Tuning query with sdo_join in it
Hello all. I'm new to the forum, but I hope someone can help me tuning a spatial query. I have no DBA experience or education, but I'm writing SQL queries for a few years now, first in Oracle 9i (with Locator), now in Oracle 10g (10.2) and Oracle XE.
I’ve posted this in the Spatial forum as I suspect it’s mostly a spatial issue.
I have a table like:
CREATE TABLE CYCLORAMA (
DATASETID VARCHAR2(9 BYTE),
IMAGEID VARCHAR2(9 BYTE),
OPNAMEDATUM CHAR(20 BYTE),
GEOMETRIE MDSYS.SDO_GEOMETRY
)with only a standard spatial index on GEOMETRIE, and containing about 180000 records. IMAGEID is unique, but not defined as such. Geometry is SDO_POINT_TYPE for all records, like: MDSYS.SDO_GEOMETRY(2001,90112,MDSYS.SDO_POINT_TYPE(86039.572,439541.158,'null'),'null','null'). USER_SDO_GEOM_METADATA is filled with values used for all my geometries: SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X',0,300000,,001), SDO_DIM_ELEMENT('Y',300000,600000,,001)) and SRID = 90112.
What I need to do is to find (and ultimately delete) all records that have another record with a different value for DATASETID, a higher value for OPNAMEDATUM and fall within 3 meters distance. What I came up with so far is:
select /*+ all_rows */ s.imageid
, sdo_geom.sdo_distance(s.geometrie,t.geometrie,0.1) dist
from cyclorama s, cyclorama t
, table(sdo_join('CYCLORAMA','GEOMETRIE','CYCLORAMA','GEOMETRIE','distance=3')) x
-- create a crosstable with records that may be within 3 meters distance
where s.rowid = x.rowid1 and x.rowid2 = t.rowid and not x.rowid1 = x.rowid2
-- filter 'duplicate matches' sdo_join generates for a self join, and select:
and s.datasetid != t.datasetid -- if in different dataset
and s.opnamedatum < t.opnamedatum -- from a later date
and sdo_geom.sdo_distance(s.geometrie,t.geometrie,0.1) < 3 -- within 3 meters
;This is surprisingly fast (7 seconds for first 50 records), but still takes about 7 minutes (Oracle XE on a 768MB, 2.7GHz VM) for the whole query. This is acceptable, but:
* Is this solution the best approach?
* Can this be done faster or more efficient? Clever indexes, hints, smarter query, ...?
* Is it worth optimizing the SDO_DIM_ARRAY for this table, e.g. narrowing the range of coordinate values)?
* How to delete the found records most efficiently?
* Can this be done using an anti-join, to select the records to keep?
Thank you for reading this, and any answers you may have,
J-----.
Jeroen MurisJack,
Thank you for your response. It helped me to clean up the query. All the changes did not give a much better explain plan - at least not to my inexperienced eyes - but the total execution time for the query is now reduced to under two minutes. The query as it is now:
select /*+ ordered all_rows */ x.rowid1
from table(sdo_join('CYCLORAMA','GEOMETRIE','CYCLORAMA','GEOMETRIE','distance=3 mask=ANYINTERACT')) x
, cyclorama s, cyclorama t
where not x.rowid1 = x.rowid2
and s.rowid = x.rowid1 and x.rowid2 = t.rowid
and s.datasetid != t.datasetid
and s.opnamedatum < t.opnamedatum;Because the docs state that mask=FILTER is the default, I added an explicit mask=ANYINTERACT to the sdo_join parameters when I removed the sdo_distance from the query. Still, the query returns 205035 records with the sdo_distance, and 205125 without. But this may be the result of the extra 0.001 from sdo_dim. I did not investigate as the 3 meter is not crucial.
I believe I already had a mechanism in place to reduce the number of self-joins with "not x.rowid1 = x.rowid2" and "s.opnamedatum < t.opnamedatum". I can not guarantee that for all records s.opnamedatum < t.opnamedatum equals x.rowid1 < x.rowid2.
Based on the [url http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_operat.htm#BGEDJIBF]docs, I finally added an 'ordered' hint and reshuffled the tables in the from clause.
I'm happy with performance now, and creating a new table with the records to keep should not be a problem. Still I'm curious about the following:
<li>Is it worth optimizing the SDO_DIM_ARRAY for the original table, e.g. narrowing the range of coordinate values?
<li>How can sdo_join best be used for an anti-join, to select the records to keep?
Thank you,
J-----. -
How to clear Local-Cache Entries for a Query in BW?
Hi There,
i`m student und i need please your help for my Thesis!!
I execute the same Query many times in BEx Web Analyzer und note a Query Response Time under ST03N using each time a different READ Mode and Cache Mode is inactiv (Query Monitor RSRT).
First time i exectue the Query, it reads also from database, second time it uses the local Cache and that `s okay!
My problem is:
When i change the Read mode and execute the Query again, it uses for the first run also the old entries from the Cache so i get wrong response time for the first run!!
I know that while the mode cache inactiv , the local cache will still be used, so how can i delete the local cache entries each
time i change the read mode and execute the Query? In Cache monitor (rsrcache) i find only entries for Global cache etc..
I've already tried to close the session and login in to the System again but it doesn`t solve the Problem!!
i don't have a permission (access rights) to switch off the complete Cache (local and global ).
Any idea please??
Thanks und Best Regards,
Rachidoo
P.S: sorry for my bad english!! i have to refresh it soon:)Hi Praba,
the entries stored in RSRCACHE are for global cache, there is no entry for my query in Cache monitor!
i execute the query in RSRT using java web button and cache mode inactiv so, the results will be stored in local cache.
this is as below what i want to do for my performance tests in my Thesis:
1. run a query for the first time with cache inactiv and note runtime of it
2. run the query again with cache inactiv and note runtime of it
3. clear the local cache (i don't know how to do it??)
4. change the read mode of query in RSRT then run the same query for the first time and note runtime of it
5. run the query again and note runtime of it.
i'm doing the same procedure for each Read mode.
the problem is in step 4 , The olap Processor gets the old results form the cache so i get wrong runtime for my tests.
Generate the report doesn't help, any idea please? -
No method found for XML query element
Hi,
I have an EJB module which contains some entity beans.
If I try to deploy it or verify it using the Sun One Verifier Tool I get the following exception...
Error: ** Error trying to process file: java.lang.RuntimeException: No method found for XML query element: Ambiguous or invalid <query-method>
java.lang.RuntimeException: No method found for XML query element: Ambiguous or invalid <query-method>
at com.sun.enterprise.deployment.xml.EjbNode.parseQueries(EjbNode.java:700)
at com.sun.enterprise.deployment.xml.EjbNode.completeLoadingDescriptor(EjbNode.java:671)
at com.sun.enterprise.deployment.xml.EjbBundleNode.completeLoadingDescriptor(EjbBundleNode.java:524)
at com.iplanet.ias.deployment.EjbBundleXmlReader.load(EjbBundleXmlReader.java:249)
at com.iplanet.ias.deployment.EjbBundleXmlReader.loadStdAloneModule(EjbBundleXmlReader.java:162)
at com.sun.enterprise.tools.verifier.Verifier.openEjbJar(Verifier.java:2421)
at com.sun.enterprise.tools.verifier.Verifier.loadEjbJar(Verifier.java:1318)
at com.sun.enterprise.tools.verifier.Verifier.loadJar(Verifier.java:866)
at com.sun.enterprise.tools.verifier.gui.MainPanel.run(MainPanel.java:187)
at java.lang.Thread.run(Thread.java:536)
Look in file "EntityBeans.jar_verified.xml" for detailed results on test assertions.
This problem can be resolved by un-installing the IDE, removing my user directory, and re-installing the IDE (I am using SunOne Studio 5 SE Update 1). The problem is that it returns with alarming regularity.
Anyone else experiencing this? Any help would be much appreciated.Sometimes, but not always, this exception appears in the ide.log before the error first occurs.
com.sun.forte4j.j2ee.packaging.PackagingIOException: package/EntityBeans.ejbjar
at com.sun.forte4j.j2ee.packaging.PackagingUtil.writeJarFile(PackagingUtil.java:403)
at com.sun.forte4j.j2ee.packaging.PackagingUtil.writeJarFile(PackagingUtil.java:67)
at com.sun.forte4j.j2ee.ejbmodule.EJBModuleDataObject.writeEJBJar(EJBModuleDataObject.java:2673)
at com.iplanet.ias.tools.forte.verifier.VerifierAction.performAction(VerifierAction.java:63)
at org.openide.util.actions.NodeAction$DelegateAction.actionPerformed(NodeAction.java:431)
at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:97)
at org.openide.util.Task.run(Task.java:136)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:328)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:670) -
Hello BI guys,
This is Calvin from Korea. We are implementing BI 7.0 and have some severe performance problem. For some queries they don't use cache mode, even though the global cache are used.
When I checked these kind of queries by performance information in RSRT, I got following message,
===================================================
InfoProvider Definition |
===================================================
ZCOAG0101 | At Least One InfoProvider Not InfoCube
ZCOAG0101 | Not All InfoProviders Can Use Aggregates
===================================================
===================================================
Query Definition |
===================================================
Read Mode | Do Not Read upon Drilling Navigation/ Hierarchy
Query Cannot | Use the Cache Reason
Cache Mode | Cache Not Used By Query
Cache Update | Query Does Not Use Delta Process
Type of SP Grouping for Delta Cache Process | No Provider Partitioning
===================================================
And after run of technical information,
===================================================
Cache-Relevant Data |
===================================================
Query Can Use the Cache | No
Query Generation Time | 2007.09.17 15:05:31
InfoProvider - Last Data Change | 2007.09.16 21:43:11
Last Load of Exchange Rates | 2007.07.13 15:01:48
===================================================
Does anybody have ideas for this problem?
Your help will be highly appreciated and get points!
Thanks in advance
Regards,
Worried Calvinhi Dong Suk Choi ,
the technical information which u have furnished clearly says that the settings
that u have made does not enable the query to use cache.
u can enhance cache by customizing the inforovider or in the transaction rsrt
even if the concerned query does not have required settings u can make them in rsrt tcode.
goto rsrt set the read mode and cache mode as u wish, however default settings would give optimum performance.
and run the query.
in the rsrt screen a push button execute + debug enter that and unmark the check box do not use cache.
hope this helps.
reward points if helpful.
bye.
under properties tab u can give the query settingMessage was edited by:
Rakesh Elangovan -
Any idea what this query is trying to do?
Do you guys have any idea what this query(used for report generation) is used for? I don't understand the WHERE clause of this query especially what the Pipe operators(|| ' 21:00:00') are used for?
SELECT c.course_id,
mph.subject
from courses c, main_pgm_hdr mph
where
c.classid=mph.classid
AND
TO_CHAR(MPH.CLOSE_DATE, 'mm/dd/yyyy hh24:mi:ss') >= TO_CHAR(TRUNC(SYSDATE, 'MM') - 1, 'mm/dd/yyyy')
|| ' 21:00:00'
AND TO_CHAR(MPH.CLOSE_DATE, 'mm/dd/yyyy hh24:mi:ss') <= TO_CHAR(SYSDATE, 'mm/dd/yyyy')
|| ' 20:59:59'Edited by: user10450365 on Jan 13, 2009 7:11 PMThey are trying to get the data having CLOSE_DATE between 20:59:59 and 21:00:00 for the present day. But the way its done is wrong. They have converted the date into Char and they are comparing. Its absolutely incorrect.
One way to do it would be
SELECT DISTINCT (PS.CARR_ID) AS CARRIER ,
MPH.SHPMT_NBR AS TRAILER ,
MPH.SHPMT_NBR AS SHPMT_NBR,
TO_CHAR(MPH.CREATE_DATE_TIME, 'mm/dd/yyyy hh24:mi:ss') AS LOADED ,
TO_CHAR(MPH.CLOSE_DATE, 'mm/dd/yyyy hh24:mi:ss') AS FINALIZED
FROM PARCL_SERV PS,
MANIF_PARCL_HDR MPH
WHERE PS.MANIF_TYPE = MPH.MANIF_TYPE
AND MPH.CLOSE_DATE >= TRUNC(sysdate)+(21/24)
AND MPH.CLOSE_DATE <= TRUNC(sysdate)+((20/24)+(59/1440)+(59/86400))Edited by: Karthick_Arp on Jan 13, 2009 1:27 AM -
Free tool for tuning and generating alternative quwry
Can anyone pls guide me as to which FREE software is available for tuning the complex sql queries. Also it will be helpful if it provides alternate ways to design the query in different ways.
It seems obvious to say so, but the best tool is a well-informed prefessional.
http://tahiti.oracle.com
http://asktom.oracle.com
Concepts Guide, Performance and Tuning Guide, SQL Reference etc -
Cannot find result area for a query
I have 4 queries in a workbook, all on separate sheets. I usually refresh all queries at once from a fifth worksheet. I started getting this error when the first query is refreshed that says "Cannot find the result area for a query - probably all its cells were deleted. Please define a new location for the result area!"
If I refresh each query individually, I do not get this error. But I want to refresh all at once, which had always worked in the past. If I play along with the error and try to select a cell to put the results, it still does not solve the issue. Any ideas why suddenlt started receiving this error?
Thanks.Try going through all the tabs on the workbook and ensure that you place the cursor within one of the cells of the query, then resave, close and open. See if the message still occurs.
I know it sounds silly but we have had this issue in the past with multi tabbed workbooks and this, simple as it sounds has been the cause.
Maybe you are looking for
-
Safari 6.0.5 thinks my mac is a mobile device, what to do?
Hello, I am running OS X 10.8.4 (Mountain Lion) with Safari 6.0.5. Half a week ago when I opened up Safari, I was redirected to a mobile version of Google and other pages I use. The rest of the week I was looking for a solution to fix this, but I hav
-
Can I buy an iTunes voucher and get the code sent straight to my email?
Can I buy an iTunes voucher and get the code sent straight to my email?
-
How to insert more than 4000 bytes in BLOB column
Hi all, My oracle version is Oracle Database 11g Enterprise Edition Release 11.2.0.3.0. I have checked in google and in this forum also, but did not find the answer. When inserting into less than 4000 bytes, it is inserting without any issues. If i a
-
Form Guide - Web Service for Drop down
Running LC ES 1 8.2 with JBoss I have a form that I created in Designer and everything works fine in Workspace. I decided to make the form into a Guide and have changed my web service so that it executes on the initialize event for the drop down. I
-
Hi guys I have configured my process B1PO2B1SO based on the documentation available but when creating the Purchase Order on the Subsidiary the document is created in SAP but If I try to see the log I have this Message on the failure section. com.sap.