Performance problem, same range scan different execution time
Oracle 11 GR 1 material, execute queries within seconds of each other.I have 2 questions that are logically the same. Even the explain command plans are very similar, except the other indicates a range index scan doing much more work than the first. The table is an IOT with deal_bucket_id and datetime as PK (in that order).
TKPROF output below:
select count(*) from deal_bucket_detail where deal_bucket_idHow can I work on why the second query is much more work than the first?
in
(815
, 816
, 817
, 818
...
, 997)
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
-----------------------------------------------------------------------------------------------------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.79 2.24 2936 3551 0 1
-----------------------------------------------------------------------------------------------------
total 4 0.79 2.24 2936 3551 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=3551 pr=2936 pw=2936 time=0 us)
1430928 FILTER (cr=3551 pr=2936 pw=2936 time=380920 us)
1430928 INLIST ITERATOR (cr=3551 pr=2936 pw=2936 time=372057 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=3551 pr=2936 pw=2936 time=8782 us cost=1203 size=4069596 card=339133)(object id 14199)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 2936 0.02 1.49
SQL*Net message from client 2 0.00 0.00
********************************************************************************
select count(*) from deal_bucket_detail where deal_bucket_id
between 815 and 997
and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')
call count cpu elapsed disk query current rows
-----------------------------------------------------------------------------------------------------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 3.70 8.86 29199 26986 0 1
-----------------------------------------------------------------------------------------------------
total 4 3.70 8.86 29199 26986 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 43
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=26986 pr=29199 pw=29199 time=0 us)
1430928 FILTER (cr=26986 pr=29199 pw=29199 time=6986078 us)
1430928 INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=26986 pr=29199 pw=29199 time=6977063 us cost=45208 size=5195748 card=432979)(object id 14199)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
db file sequential read 219 0.04 0.08
db file parallel read 35 0.04 0.32
db file scattered read 211 0.10 5.02
SQL*Net message from client 2 0.00 0.00
********************************************************************************
Published by: SamB on August 5, 2009 18:09
The two make an index range scan, but another index range scan.
-------------
Query 1: inlist iterator with
Query 2: analysis of range of index for all values, starting at the bottom, thanks to between.
Sybrand Bakker
Senior Oracle DBA
Tags: Database
Similar Questions
-
Can you change text of reversal in the same range for different triggers?
Hi, I have not used Fireworks since version 3, which was about 6 years ago when I dabbled in web development. My past has turn against me, and I need to make a pretty simple site quickly enough for my boss. I myself have CS4, and now that I understand that you can only use the buttons for disjoint bearings, I begin to make progress...
What I want to achieve, is that there are 6 "buttons" on my page, which, when they you flipping them will display the text in a box on the side. I would use separate boxes for each button, but there is not enough space on the page, because there is a lot of text, so I would use a box at the same place to display all 6 texts, according to which the button is reversed. Is this possible?
I have no doubt entirely my head layers round and this may be very simple, but could someone please point me in the right direction, even if it is a link to the right drill bit using the product?
Because the reversal disjoint button does not work, I created 6 slices for triggers. I first tried the hot spots, but could not use them as I want as a direct substitution trigger the filter effect.
Yes, you can trigger the different content on the postponement of several other sections.
It is easier to show the describe statement, so here is a sample file that does what I think you are looking for:
(1) six buttons
(2) each button a unique text
(3) each button corresponds to a rollover State
(4) single text appears in the same place for each button on turnover
I hope this helps!
Dave
Right-click and save the image below - it's a Fireworks source file:
-
Same SQL different execution Plans in two different database instances.
Hi all
I run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.
OS: Redhat Linux 5
Database version: 11.2.02 (on two instances)
Plan on 1 Instance that takes 30 minutes.
On the Instance 2SELECT X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, X_REPLEN_RQST_INV_STG.INV_ITEM_ID, X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, X_REPLEN_RQST_INV_STG.REPLEN_STATUS, X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, X_REPLEN_RQST_INV_STG.REQ_ID, X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, P.FIRST_PO_DISP_DT, W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID FROM X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_PURCH_COST_F ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID INNER join W_PURCH_SCHEDULE_LINE_F ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_STATUS_D S1 ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS LEFT OUTER JOIN W_STATUS_D S2 ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT FROM X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = P.PO_ID LEFT OUTER JOIN W_PRODUCT_D ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID LEFT OUTER JOIN X_ITEM_ATTRIB_D ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID WHERE TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL AND X_REPLEN_RQST_INV_STG.replenish_type = '1' AND X_REPLEN_RQST_INV_STG.replen_status = '4' AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' AND S1.STATUS_CODE != 'X' AND S2.STATUS_CODE != 'X' AND P.FIRST_PO_DISP_DT IS NOT NULL Execution Plan ---------------------------------------------------------- Plan hash value: 1674299164 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 461 | 13942 (1)| 00:04:11 | |* 1 | HASH JOIN | | 1 | 461 | 13942 (1)| 00:04:11 | | 2 | NESTED LOOPS | | | | | | | 3 | NESTED LOOPS | | 1 | 441 | 10409 (1)| 00:03:08 | | 4 | NESTED LOOPS | | 1 | 421 | 10407 (1)| 00:03:08 | | 5 | NESTED LOOPS | | 1 | 388 | 10406 (1)| 00:03:08 | | 6 | NESTED LOOPS | | 1 | 319 | 10405 (1)| 00:03:08 | | 7 | NESTED LOOPS | | 1 | 280 | 10404 (1)| 00:03:08 | |* 8 | HASH JOIN | | 1 | 220 | 10401 (1)| 00:03:08 | | 9 | NESTED LOOPS | | | | | | | 10 | NESTED LOOPS | | 16 | 2896 | 10392 (1)| 00:03:08 | |* 11 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 16 | 2432 | 10375 (1)| 00:03:07 | |* 12 | INDEX UNIQUE SCAN | W_RQST_LN_CS_F_U1 | 1 | | 1 (0)| 00:00:01 | | 13 | TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F | 1 | 29 | 2 (0)| 00:00:01 | |* 14 | TABLE ACCESS FULL | W_STATUS_D | 1 | 39 | 8 (0)| 00:00:01 | | 15 | TABLE ACCESS BY INDEX ROWID | W_PURCH_COST_F | 1 | 60 | 3 (0)| 00:00:01 | |* 16 | INDEX RANGE SCAN | W_PURCH_COST_F_M1 | 1 | | 2 (0)| 00:00:01 | |* 17 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 39 | 1 (0)| 00:00:01 | |* 18 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | | 19 | TABLE ACCESS BY INDEX ROWID | W_PURCH_SCHEDULE_LINE_F | 1 | 69 | 1 (0)| 00:00:01 | |* 20 | INDEX UNIQUE SCAN | W_PRCH_SC_LN_F_U1 | 1 | | 1 (0)| 00:00:01 | | 21 | TABLE ACCESS BY INDEX ROWID | W_PRODUCT_D | 1 | 33 | 1 (0)| 00:00:01 | |* 22 | INDEX UNIQUE SCAN | W_PRODUCT_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 23 | INDEX RANGE SCAN | X_ITEM_ATTRIB_U01 | 1 | | 1 (0)| 00:00:01 | |* 24 | TABLE ACCESS BY INDEX ROWID | X_ITEM_ATTRIB_D | 1 | 20 | 2 (0)| 00:00:01 | | 25 | VIEW | | 1428K| 27M| 3529 (2)| 00:01:04 | |* 26 | FILTER | | | | | | | 27 | HASH GROUP BY | | 1428K| 27M| 3529 (2)| 00:01:04 | | 28 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 3493 (1)| 00:01:03 | ----------------------------------------------------------------------------------------------------------------
In the second execution plan, we can see that it uses a Cartesian product.SELECT X_REPLEN_RQST_INV_STG.BUSINESS_UNIT, NVL(SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)),'N/A') AS DOC_ID, W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_ITEM, W_PURCH_SCHEDULE_LINE_F.PURCH_SCHEDULE_NUM, X_REPLEN_RQST_INV_STG.INV_ITEM_ID, X_REPLEN_RQST_INV_STG.PROCESS_DATE AS REPLEN_PROCESS_DT, X_REPLEN_RQST_INV_STG.EXPECTED_DATE AS REPLEN_EXPECTED_DT, X_REPLEN_RQST_INV_STG.REORDER_QTY AS REPLEN_REORDER_QTY, X_ITEM_ATTRIB_D.REPLENISH_CLASS AS REPLEN_CLASS, X_REPLEN_RQST_INV_STG.REPLEN_STATUS, X_REPLEN_RQST_INV_STG.REPLENISH_TYPE AS REPLEN_TYPE, X_REPLEN_RQST_INV_STG.REQ_ID, X_REPLEN_RQST_INV_STG.REQ_LINE_NBR, X_REPLEN_RQST_INV_STG.REQ_SCHED_NBR, X_REPLEN_RQST_INV_STG.REQ_DISTRIB_NBR, P.FIRST_PO_DISP_DT, W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID FROM X_REPLEN_RQST_INV_STG LEFT OUTER JOIN W_RQSTN_LINE_COST_F ON X_REPLEN_RQST_INV_STG.RQSTN_LN_COST_INTG_ID = W_RQSTN_LINE_COST_F.INTEGRATION_ID AND X_REPLEN_RQST_INV_STG.DATASOURCE_NUM_ID = W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_PURCH_COST_F ON W_RQSTN_LINE_COST_F.INTEGRATION_ID = W_PURCH_COST_F.REQ_DISTR_INTG_ID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = W_PURCH_COST_F.DATASOURCE_NUM_ID INNER join W_PURCH_SCHEDULE_LINE_F ON W_PURCH_COST_F.PURCH_SCHEDULE_INTG_ID = W_PURCH_SCHEDULE_LINE_F.INTEGRATION_ID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = W_PURCH_SCHEDULE_LINE_F.DATASOURCE_NUM_ID LEFT OUTER JOIN W_STATUS_D S1 ON W_RQSTN_LINE_COST_F.APPROVAL_STATUS_WID = S1.ROW_WID AND W_RQSTN_LINE_COST_F.DATASOURCE_NUM_ID = S1.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S1.W_STATUS_CLASS LEFT OUTER JOIN W_STATUS_D S2 ON W_PURCH_COST_F.APPROVAL_STATUS_WID = S2.ROW_WID AND W_PURCH_COST_F.DATASOURCE_NUM_ID = S2.DATASOURCE_NUM_ID AND 'PURCH_APPROVE' = S2.W_STATUS_CLASS LEFT OUTER JOIN (SELECT p1.BUSINESS_UNIT, p1.PO_ID, MIN(p1.DATETIME_DISP) AS FIRST_PO_DISP_DT FROM X_PS_PO_DISPATCHED p1 GROUP BY p1.BUSINESS_UNIT, p1.PO_ID) P ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = P.BUSINESS_UNIT AND SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', -1, 1) - LENGTH(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM)) = P.PO_ID LEFT OUTER JOIN W_PRODUCT_D ON W_PURCH_SCHEDULE_LINE_F.PRODUCT_WID = W_PRODUCT_D.ROW_WID LEFT OUTER JOIN X_ITEM_ATTRIB_D ON SUBSTR (W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, 1, INSTR(W_PURCH_SCHEDULE_LINE_F.PURCH_ORDER_NUM, '~', 1, 1)-1) = X_ITEM_ATTRIB_D.BUSINESS_UNIT AND W_PRODUCT_D.PART_NUM = X_ITEM_ATTRIB_D.INV_ITEM_ID WHERE TRIM(X_REPLEN_RQST_INV_STG.req_id) IS NOT NULL AND X_REPLEN_RQST_INV_STG.replenish_type = '1' AND X_REPLEN_RQST_INV_STG.replen_status = '4' AND X_ITEM_ATTRIB_D.REPLENISH_CLASS = 'A' AND S1.STATUS_CODE != 'X' AND S2.STATUS_CODE != 'X' AND P.FIRST_PO_DISP_DT IS NOT NULL --------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 420 | 19630 (1)| 00:04:35 | | 1 | NESTED LOOPS | | | | | | | 2 | NESTED LOOPS | | 1 | 420 | 19630 (1)| 00:04:35 | | 3 | NESTED LOOPS | | 1 | 400 | 19627 (1)| 00:04:35 | | 4 | NESTED LOOPS | | 1 | 386 | 19626 (1)| 00:04:35 | | 5 | NESTED LOOPS | | 1 | 317 | 19625 (1)| 00:04:35 | | 6 | NESTED LOOPS | | 1 | 289 | 19624 (1)| 00:04:35 | | 7 | NESTED LOOPS | | 1 | 229 | 19621 (1)| 00:04:35 | | 8 | NESTED LOOPS | | 1 | 201 | 19620 (1)| 00:04:35 | | 9 | MERGE JOIN CARTESIAN | | 1 | 172 | 19619 (1)| 00:04:35 | | 10 | VIEW | | 1 | 20 | 4942 (2)| 00:01:10 | |* 11 | FILTER | | | | | | | 12 | HASH GROUP BY | | 1 | 20 | 4942 (2)| 00:01:10 | | 13 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 4902 (1)| 00:01:09 | | 14 | BUFFER SORT | | 1 | 152 | 19619 (1)| 00:04:35 | |* 15 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 1 | 152 | 14676 (1)| 00:03:26 | | 16 | TABLE ACCESS BY INDEX ROWID| W_RQSTN_LINE_COST_F | 1 | 29 | 1 (0)| 00:00:01 | |* 17 | INDEX UNIQUE SCAN | W_RQST_LN_CS_F_U1 | 1 | | 1 (0)| 00:00:01 | |* 18 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 28 | 1 (0)| 00:00:01 | |* 19 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | | 20 | TABLE ACCESS BY INDEX ROWID | W_PURCH_COST_F | 3 | 180 | 3 (0)| 00:00:01 | |* 21 | INDEX RANGE SCAN | W_PURCH_COST_F_M1 | 1 | | 2 (0)| 00:00:01 | |* 22 | TABLE ACCESS BY INDEX ROWID | W_STATUS_D | 1 | 28 | 1 (0)| 00:00:01 | |* 23 | INDEX UNIQUE SCAN | W_STATUS_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 24 | TABLE ACCESS BY INDEX ROWID | W_PURCH_SCHEDULE_LINE_F | 1 | 69 | 1 (0)| 00:00:01 | |* 25 | INDEX UNIQUE SCAN | W_PRCH_SC_LN_F_U1 | 1 | | 1 (0)| 00:00:01 | |* 26 | TABLE ACCESS BY INDEX ROWID | W_PRODUCT_D | 1 | 14 | 1 (0)| 00:00:01 | |* 27 | INDEX UNIQUE SCAN | W_PRODUCT_D_P1 | 1 | | 0 (0)| 00:00:01 | |* 28 | INDEX RANGE SCAN | X_ITEM_ATTRIB_U01 | 1 | | 2 (0)| 00:00:01 | |* 29 | TABLE ACCESS BY INDEX ROWID | X_ITEM_ATTRIB_D | 1 | 20 | 3 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------------
Thank you.Oceaner wrote:
Hi allI run a different query on two instances of database. On one instance, the query takes 30 minutes and the other it takes 10 hours to complete. Data on the two instances are the same. When I generated the execution plan, on the two cases, it was different.
The most obvious difference is the subquery total inline:
Quick plan:
---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------- |* 1 | HASH JOIN | | 1 | 461 | 13942 (1)| 00:04:11 | | 2 | NESTED LOOPS | | | | | | ... | 25 | VIEW | | 1428K| 27M| 3529 (2)| 00:01:04 | |* 26 | FILTER | | | | | | | 27 | HASH GROUP BY | | 1428K| 27M| 3529 (2)| 00:01:04 | | 28 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 3493 (1)| 00:01:03 | ----------------------------------------------------------------------------------------------------------------Plan of slow
--------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------------------- ... | 9 | MERGE JOIN CARTESIAN | | 1 | 172 | 19619 (1)| 00:04:35 | | 10 | VIEW | | 1 | 20 | 4942 (2)| 00:01:10 | |* 11 | FILTER | | | | | | | 12 | HASH GROUP BY | | 1 | 20 | 4942 (2)| 00:01:10 | | 13 | TABLE ACCESS FULL | X_PS_PO_DISPATCHED | 1428K| 27M| 4902 (1)| 00:01:09 | | 14 | BUFFER SORT | | 1 | 152 | 19619 (1)| 00:04:35 | |* 15 | TABLE ACCESS FULL | X_REPLEN_RQST_INV_STG | 1 | 152 | 14676 (1)| 00:03:26 | ... ---------------------------------------------------------------------------------------------------------------Note the value of lines given to the operation - VIEW
One for the slow plan - that of why Oracle chose display online as a starting point for the query and used a Cartesian merge join to join to the table nearby.1.4Million for the fast plan - this is why Oracle has decided to visit the table set and use it as the table of the probe in a hash join.
I think we can assume that the estimation of the single line is a big mistake. We can also assume that the two series of statistics (or possibly index definitions) on the tables two versions do not match.
It would be useful, of course, see the comprehensive implementation plan, and preferably one from memory: (http://jonathanlewis.wordpress.com/2006/12/22/dbms_xplan-again/).
You might notice that you outer joins are not relevant - maybe this SQL is a framework for a more general query - given that the plan shows that they have all been turned away.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle -
ViewObject range Paging performance problem
Hi all
I am facing a performance problem with the implementation of an obligation to programmatically add a number of extra where the parameters of the clause (using bind) variable in combination with range paging.
My code looks like this
... ApplicationModule am = Configuration.createRootApplicationModule("services.DossierAM", "DossierAMLocal"); ViewObject vo = am.findViewObject("DossierListView"); // apply programmatic view criteria ViewCriteria vc = vo.createViewCriteria(); ViewCriteriaRow vcr = vc.createViewCriteriaRow(); vcr.setAttribute("Reference", "15/%"); vc.addElement(vcr); vo.applyViewCriteria(vc, true); // enable range paging vo.setAccessMode(RowSet.RANGE_PAGING); vo.setIterMode(RowIterator.ITER_MODE_LAST_PAGE_PARTIAL); vo.setRangeSize(50); vo.scrollToRangePage(5); // Cause a java.sql.SQLException: Parameter IN or OUT missing for index.....debugging learned that the :vc_temp_1 bind variable is not filled // vo.scrollToRange(250); // Cause a java.sql.SQLException: Parameter IN or OUT missing for index.....debugging learned that the :vc_temp_1 bind variable is not filled ... ...I found 2 solutions, but they both require an application of additional database that is, performance wise, is not acceptable.
The first solution is to slip into an additional call to exectueQuery() before the call to function scrollToRangePage (int) or scrollToRange (int).
The second solution is to use the method (int) setRangeStart instead of variants scrollToRange (Page). This method performs also 2 database calls.
My question to you:
Is there another way to satisfy the requirement of programming add a certain number of parameters of the additional where clause (using the variable binding) in combination with the pagination of the range without the need to perform queries of database 2?
The code is tested with JDeveloper, 11.1.2.4.0, and 12.1.3.0.0 and behaves the same on both versions.
Kind regards
Steven.
Have you tried to create truly VC with bind variable (rather than use binding implied var created by frame)?
Something like: http://www.jobinesh.com/2010/10/creating-view-criteria-having-bind.html
Dario
-
Why I have two different execution plans for the same query on two different servers
Hello everyone.
I need your help to solve the problem quickly.
In a nutshell, we have two servers that have the same version of Oracle RDBMS (11.2.0.4 EE). One of them for purposes of development and another is a production one.
We have therefore two different execution plans for the same query executed on both servers. The only case of execution is OK and another is too slow.
So I have to slow down the work of query using the same scheme to explain that young.
Fence wire.
-
Version 12: Same SQL, another scheme == > different execution plan?
I'm testing a huge application with a database middleware sophisticated against the Oracle 12 database. So far, it works well with Pervasive SQL, MSSQL and Oracle 8 database... 11.
There are many questions about execution plans changed from Version 11 to 12. Oracle will tell what all of the improvements are (or at least have to improvements), and I can't really denied him. It's not the subject.
But I met some SQLs with horrible execution time, especially connected to Crystal Reports. Whenever I tried to check them, the queries have been executed quickly. As far as I can see, this has to do with the schema/user who executes the SQL statement in a first time. Here are the details:
• = ADMIN, DML = GUI DDL: all data are stored in a scheme of the ADMIN. The ADMIN user creates the tables, views and so on. It grants access to and creates synonyms for users, but it cannot modify the data using DML, given that triggers prevent him. End users, named 'GUI' users, are allowed to use the DML, but they have no privileges DDL.
• Database of reports (on paper) are generally quite complex. They have only a limited data set (must fit on sheets of paper!), and the Oracle optimizer optimizes often against this goal. Because Crystal Reports generates no advice, most of the reports are based on a view ADMIN. < xyz > (with the necessary information) and are accessible via a GUI. < xyz > synonym of user GUI.
• Crystal Reports running slowly (~ 5 minutes) connected as a GUI. I export it, get the SQL export, log in as an ADMINISTRATORand run the query, it works quickly (~ 2 seconds). Well, I've probably changed some white space, the line endings and others then copy / paste, I don't?
• I tried many things, connecting both GUI and ADMIN, simplifying the application, execution and so on. Then I got confused version of who this query: when the ADMIN has added an additional space character it was fast, removed again and it was slow again. Whitespace have an influence on the execution plan? Probably not, and if yes, my vision of the world would collapse.
• Later, I found out: in Version 12, depends on the user executing this query. Nail down us the source of the query for the synonym GUI. < xyz >. Let us make a new version of it (coded by white space - smile), and if run you it like GUI first, it's slow. Even if you re - log on as ADMINISTRATOR, the same version of this query is still slow. (This is a bug!)
Question 1: When I prepend the SQL with 'EXPLAIN PLAN FOR', I seem to be changing. As GUI has no plan_table and no privilege to explain a plan, I can't spy on the implementation plan of 'bad '. I don't want to give too much GUI, and I fear it could alter the execution plan. Is there a trick to get the plan of execution of a SQL statement in v$ sql or v$ sqlarea? (Means: execute the query: GUI and explain it as an ADMINISTRATOR)
Question 2: Is this on the privileges of the GUI? What you think, what direction will further investigate?
Oracle database generates an execution plan based on SQL, the dictionary, the statistics, the privileges of the user of the analysis and database and session settings. One of the privileges is GRANT MERGE [ALL] DISPLAY, which was responsible for the difference in this particular example and in this particular version.
When you log on as another user and run the same code in SQL, Oracle database verifies all required components before she reuses the old execution plan. This is a minor bug, but it is.
In the example, the privilege GRANT MERGE ANY NOTICE was given implicitly by the DBA privilege. Because MERGE ANY VIEW disables security controls, the privilege of s/n, default, also disables security controls. This is not a desired behavior from the DBA privilege.
-
Need help to open two images with the same file with different exposures on the screen at the same time in the Photoshop creative cloud (in previous versions we could open two images of the same nef (raw) file and then combine them on the screen with the move tool. They have become a composite of two layers which could be developed further with the mask tool.
Hello
Please go to the preferences > workspace and uncheck the option 'open the document in the tabs '.
Now you can click on file and choose file > open and open the two images in two different windows which can be arranged side by side.
Thank you
-
Hi Experts,
I am new to Oracle. Ask for your help to fix the performance of a query of insertion problem.
I have an insert query that is go search for records of the partitioned table.
Background: the user indicates that the query was running in 30 minutes to 10 G. The database is upgraded to 12 by one of my colleague. Now the query works continuously for hours, but no result. Check the settings and SGA is 9 GB, Windows - 4 GB. DB block size is 8192, DB Multiblock read file Count is 128. Overall target of PGA is 2457M.
The parameters are given below
VALUE OF TYPE NAME
------------------------------------ ----------- ----------
DBFIPS_140 boolean FALSE
O7_DICTIONARY_ACCESSIBILITY boolean FALSE
whole active_instance_count
aq_tm_processes integer 1
ARCHIVE_LAG_TARGET integer 0
asm_diskgroups chain
asm_diskstring chain
asm_power_limit integer 1
asm_preferred_read_failure_groups string
audit_file_dest string C:\APP\ADM
audit_sys_operations Boolean TRUEAUDIT_TRAIL DB string
awr_snapshot_time_offset integer 0
background_core_dump partial string
background_dump_dest string C:\APP\PRO
\RDBMS\TRA
BACKUP_TAPE_IO_SLAVES boolean FALSE
bitmap_merge_area_size integer 1048576
blank_trimming boolean FALSE
buffer_pool_keep string
buffer_pool_recycle string
cell_offload_compaction ADAPTIVE channel
cell_offload_decryption Boolean TRUE
cell_offload_parameters string
cell_offload_plan_display string AUTO
cell_offload_processing Boolean TRUE
cell_offloadgroup_name string
whole circuits
whole big client_result_cache_lag 3000
client_result_cache_size big integer 0
clonedb boolean FALSE
cluster_database boolean FALSE
cluster_database_instances integer 1
cluster_interconnects chain
commit_logging string
commit_point_strength integer 1
commit_wait string
string commit_write
common_user_prefix string C#.
compatible string 12.1.0.2.0
connection_brokers string ((TYPE = DED
((TYPE = EM
control_file_record_keep_time integer 7
control_files string G:\ORACLE\TROL01. CTL
FAST_RECOV
NTROL02. CT
control_management_pack_access string diagnostic
core_dump_dest string C:\app\dia
bal12\cdum
cpu_count integer 4
create_bitmap_area_size integer 8388608
create_stored_outlines string
cursor_bind_capture_destination memory of the string + tell
CURSOR_SHARING EXACT stringcursor_space_for_time boolean FALSE
db_16k_cache_size big integer 0
db_2k_cache_size big integer 0
db_32k_cache_size big integer 0
db_4k_cache_size big integer 0
db_8k_cache_size big integer 0
db_big_table_cache_percent_target string 0
db_block_buffers integer 0
db_block_checking FALSE string
db_block_checksum string TYPICAL
Whole DB_BLOCK_SIZE 8192db_cache_advice string WE
db_cache_size large integer 0
db_create_file_dest chain
db_create_online_log_dest_1 string
db_create_online_log_dest_2 string
db_create_online_log_dest_3 string
db_create_online_log_dest_4 string
db_create_online_log_dest_5 string
db_domain chain
db_file_multiblock_read_count integer 128
db_file_name_convert chainDB_FILES integer 200
db_flash_cache_file string
db_flash_cache_size big integer 0
db_flashback_retention_target around 1440
chain of db_index_compression_inheritance NONE
DB_KEEP_CACHE_SIZE big integer 0
chain of db_lost_write_protect NONE
db_name string ORCL
db_performance_profile string
db_recovery_file_dest string G:\Oracle\
y_Area
whole large db_recovery_file_dest_size 12840M
db_recycle_cache_size large integer 0
db_securefile string PREFERRED
channel db_ultra_safe
db_unique_name string ORCL
db_unrecoverable_scn_tracking Boolean TRUE
db_writer_processes integer 1
dbwr_io_slaves integer 0
DDL_LOCK_TIMEOUT integer 0
deferred_segment_creation Boolean TRUE
dg_broker_config_file1 string C:\APP\PRO
\DATABASE\
dg_broker_config_file2 string C:\APP\PRO
\DATABASE\
dg_broker_start boolean FALSE
diagnostic_dest channel directory
disk_asynch_io Boolean TRUE
dispatchers (PROTOCOL = string
12XDB)
distributed_lock_timeout integer 60
dml_locks whole 2076
whole dnfs_batch_size 4096dst_upgrade_insert_conv Boolean TRUE
enable_ddl_logging boolean FALSE
enable_goldengate_replication boolean FALSE
enable_pluggable_database boolean FALSE
event string
exclude_seed_cdb_view Boolean TRUE
fal_client chain
fal_server chain
FAST_START_IO_TARGET integer 0
fast_start_mttr_target integer 0
fast_start_parallel_rollback string LOW
file_mapping boolean FALSE
fileio_network_adapters string
filesystemio_options chain
fixed_date chain
gcs_server_processes integer 0
global_context_pool_size string
global_names boolean FALSE
global_txn_processes integer 1
hash_area_size integer 131072
channel heat_map
hi_shared_memory_address integer 0hs_autoregister Boolean TRUE
iFile file
inmemory_clause_default string
inmemory_force string by DEFAULT
inmemory_max_populate_servers integer 0
inmemory_query string ENABLE
inmemory_size big integer 0
inmemory_trickle_repopulate_servers_ integer 1
percent
instance_groups string
instance_name string ORCL
instance_number integer 0
instance_type string RDBMS
instant_restore boolean FALSE
java_jit_enabled Boolean TRUE
java_max_sessionspace_size integer 0
JAVA_POOL_SIZE large integer 0
java_restrict string no
java_soft_sessionspace_limit integer 0
JOB_QUEUE_PROCESSES around 1000
LARGE_POOL_SIZE large integer 0
ldap_directory_access string NONE
ldap_directory_sysauth string no.
license_max_sessions integer 0
license_max_users integer 0
license_sessions_warning integer 0
listener_networks string
LOCAL_LISTENER (ADDRESS = string
= i184borac
(NET) (PORT =
lock_name_space string
lock_sga boolean FALSE
log_archive_config string
Log_archive_dest chain
Log_archive_dest_1 chain
LOG_ARCHIVE_DEST_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
log_archive_dest_19 string
LOG_ARCHIVE_DEST_2 string
log_archive_dest_20 string
log_archive_dest_21 string
log_archive_dest_22 string
log_archive_dest_23 string
log_archive_dest_24 string
log_archive_dest_25 string
log_archive_dest_26 string
log_archive_dest_27 string
log_archive_dest_28 string
log_archive_dest_29 string
log_archive_dest_3 string
log_archive_dest_30 string
log_archive_dest_31 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string
allow the chain of log_archive_dest_state_1
allow the chain of log_archive_dest_state_10
allow the chain of log_archive_dest_state_11
allow the chain of log_archive_dest_state_12
allow the chain of log_archive_dest_state_13
allow the chain of log_archive_dest_state_14
allow the chain of log_archive_dest_state_15
allow the chain of log_archive_dest_state_16
allow the chain of log_archive_dest_state_17
allow the chain of log_archive_dest_state_18
allow the chain of log_archive_dest_state_19
allow the chain of LOG_ARCHIVE_DEST_STATE_2allow the chain of log_archive_dest_state_20
allow the chain of log_archive_dest_state_21
allow the chain of log_archive_dest_state_22
allow the chain of log_archive_dest_state_23
allow the chain of log_archive_dest_state_24
allow the chain of log_archive_dest_state_25
allow the chain of log_archive_dest_state_26
allow the chain of log_archive_dest_state_27
allow the chain of log_archive_dest_state_28
allow the chain of log_archive_dest_state_29
allow the chain of log_archive_dest_state_3allow the chain of log_archive_dest_state_30
allow the chain of log_archive_dest_state_31
allow the chain of log_archive_dest_state_4
allow the chain of log_archive_dest_state_5
allow the chain of log_archive_dest_state_6
allow the chain of log_archive_dest_state_7
allow the chain of log_archive_dest_state_8
allow the chain of log_archive_dest_state_9
log_archive_duplex_dest string
log_archive_format string ARC%S_%R.%
log_archive_max_processes integer 4log_archive_min_succeed_dest integer 1
log_archive_start Boolean TRUE
log_archive_trace integer 0
whole very large log_buffer 28784K
log_checkpoint_interval integer 0
log_checkpoint_timeout around 1800
log_checkpoints_to_alert boolean FALSE
log_file_name_convert chain
whole MAX_DISPATCHERS
max_dump_file_size unlimited string
max_enabled_roles integer 150
whole max_shared_servers
max_string_size string STANDARD
memory_max_target big integer 0
memory_target large integer 0
NLS_CALENDAR string GREGORIAN
nls_comp BINARY string
nls_currency channel u
string of NLS_DATE_FORMAT DD-MON-RR
nls_date_language channel ENGLISH
string nls_dual_currency C
nls_iso_currency string UNITED KINnls_language channel ENGLISH
nls_length_semantics string OCTET
string nls_nchar_conv_excp FALSE
nls_numeric_characters chain.,.
nls_sort BINARY string
nls_territory string UNITED KIN
nls_time_format HH24.MI string. SS
nls_time_tz_format HH24.MI string. SS
chain of NLS_TIMESTAMP_FORMAT DD-MON-RR
NLS_TIMESTAMP_TZ_FORMAT string DD-MON-RR
noncdb_compatible boolean FALSE
object_cache_max_size_percent integer 10
object_cache_optimal_size integer 102400
olap_page_pool_size big integer 0
open_cursors integer 300
Open_links integer 4
open_links_per_instance integer 4
optimizer_adaptive_features Boolean TRUE
optimizer_adaptive_reporting_only boolean FALSE
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 12.1.0.2optimizer_index_caching integer 0
OPTIMIZER_INDEX_COST_ADJ integer 100
optimizer_inmemory_aware Boolean TRUE
the string ALL_ROWS optimizer_mode
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
OPS os_authent_prefix string $
OS_ROLES boolean FALSE
parallel_adaptive_multi_user Boolean TRUE
parallel_automatic_tuning boolean FALSE
parallel_degree_level integer 100
parallel_degree_limit string CPU
parallel_degree_policy chain MANUAL
parallel_execution_message_size integer 16384
parallel_force_local boolean FALSE
parallel_instance_group string
parallel_io_cap_enabled boolean FALSE
PARALLEL_MAX_SERVERS integer 160
parallel_min_percent integer 0
parallel_min_servers integer 16parallel_min_time_threshold string AUTO
parallel_server boolean FALSE
parallel_server_instances integer 1
parallel_servers_target integer 64
parallel_threads_per_cpu integer 2
pdb_file_name_convert string
pdb_lockdown string
pdb_os_credential string
permit_92_wrap_format Boolean TRUE
pga_aggregate_limit great whole 4914M
whole large pga_aggregate_target 2457M-
Plscope_settings string IDENTIFIER
plsql_ccflags string
plsql_code_type chain INTERPRETER
plsql_debug boolean FALSE
plsql_optimize_level integer 2
plsql_v2_compatibility boolean FALSE
plsql_warnings DISABLE channel: AL
PRE_PAGE_SGA Boolean TRUE
whole process 300
processor_group_name string
query_rewrite_enabled string TRUE
applied query_rewrite_integrity chain
rdbms_server_dn chain
read_only_open_delayed boolean FALSE
recovery_parallelism integer 0
Recyclebin string on
redo_transport_user string
remote_dependencies_mode string TIMESTAMP
remote_listener chain
Remote_login_passwordfile string EXCLUSIVE
REMOTE_OS_AUTHENT boolean FALSE
remote_os_roles boolean FALSEreplication_dependency_tracking Boolean TRUE
resource_limit Boolean TRUE
resource_manager_cpu_allocation integer 4
resource_manager_plan chain
result_cache_max_result integer 5
whole big result_cache_max_size K 46208
result_cache_mode chain MANUAL
result_cache_remote_expiration integer 0
resumable_timeout integer 0
rollback_segments chain
SEC_CASE_SENSITIVE_LOGON Boolean TRUEsec_max_failed_login_attempts integer 3
string sec_protocol_error_further_action (DROP, 3)
sec_protocol_error_trace_action string PATH
sec_return_server_release_banner boolean FALSE
disable the serial_reuse chain
service name string ORCL
session_cached_cursors integer 50
session_max_open_files integer 10
entire sessions 472
Whole large SGA_MAX_SIZE M 9024
Whole large SGA_TARGET M 9024
shadow_core_dump string no
shared_memory_address integer 0
SHARED_POOL_RESERVED_SIZE large integer 70464307
shared_pool_size large integer 0
whole shared_server_sessions
SHARED_SERVERS integer 1
skip_unusable_indexes Boolean TRUE
smtp_out_server chain
sort_area_retained_size integer 0
sort_area_size integer 65536
spatial_vector_acceleration boolean FALSE
SPFile string C:\APP\PRO
\DATABASE\
sql92_security boolean FALSE
SQL_Trace boolean FALSE
sqltune_category string by DEFAULT
standby_archive_dest channel % ORACLE_HO
standby_file_management string MANUAL
star_transformation_enabled string TRUE
statistics_level string TYPICAL
STREAMS_POOL_SIZE big integer 0
tape_asynch_io Boolean TRUEtemp_undo_enabled boolean FALSE
entire thread 0
threaded_execution boolean FALSE
timed_os_statistics integer 0
TIMED_STATISTICS Boolean TRUE
trace_enabled Boolean TRUE
tracefile_identifier chain
whole of transactions 519
transactions_per_rollback_segment integer 5
UNDO_MANAGEMENT string AUTO
UNDO_RETENTION integer 900undo_tablespace string UNDOTBS1
unified_audit_sga_queue_size integer 1048576
use_dedicated_broker boolean FALSE
use_indirect_data_buffers boolean FALSE
use_large_pages string TRUE
user_dump_dest string C:\APP\PRO
\RDBMS\TRA
UTL_FILE_DIR chain
workarea_size_policy string AUTO
xml_db_events string enableThanks in advance
Firstly, thank you for posting the 10g implementation plan, which was one of the key things that we were missing.
Second, you realize that you have completely different execution plans, so you can expect different behavior on each system.
Your package of 10g has a total cost of 23 959 while your plan of 12 c has a cost of 95 373 which is almost 4 times more. All things being equal, cost is supposed to relate directly to the time spent, so I expect the 12 c plan to take much more time to run.
From what I can see the 10g plan begins with a scan of full table on DEALERS, and then a full scan on SCARF_VEHICLE_EXCLUSIONS table, and then a full scan on CBX_tlemsani_2000tje table, and then a full scan on CLAIM_FACTS table. The first three of these analyses tables have a very low cost (2 each), while the last has a huge cost of 172K. Yet once again, the first three scans produce very few lines in 10g, less than 1,000 lines each, while the last product table scan 454 K lines.
It also looks that something has gone wrong in the 10g optimizer plan - maybe a bug, which I consider that Jonathan Lewis commented. Despite the full table scan with a cost of 172 K, NESTED LOOPS it is part of the only has a cost of 23 949 or 24 K. If the math is not in terms of 10g. In other words, maybe it's not really optimal plan because 10g optimizer may have got its sums wrong and 12 c might make his right to the money. But luckily this 'imperfect' 10g plan happens to run fairly fast for one reason or another.
The plan of 12 starts with similar table scans but in a different order. The main difference is that instead of a full table on CLAIM_FACTS scan, it did an analysis of index on CLAIM_FACTS_AK9 beach at the price of 95 366. It is the only main component of the final total cost of 95 373.
Suggestions for what to do? It is difficult, because there is clearly an anomaly in the system of 10g to have produced the particular execution plan that he uses. And there is other information that you have not provided - see later.
You can try and force a scan of full table on CLAIM_FACTS by adding a suitable example suspicion "select / * + full (CF) * / cf.vehicle_chass_no...". "However, the tips are very difficult to use and does not, guarantee that you will get the desired end result. So be careful. For the essay on 12 c, it may be worth trying just to see what happens and what produces the execution plan looks like. But I would not use such a simple, unique tip in a production system for a variety of reasons. For testing only it might help to see if you can force the full table on CLAIM_FACTS scan as in 10g, and if the performance that results is the same.
The two plans are parallel ones, which means that the query is broken down into separate, independent steps and several steps that are executed at the same time, i.e. several CPUS will be used, and there will be several readings of the disc at the same time. (It is a mischaracterization of the works of parallel query how). If 10g and 12 c systems do not have the SAME hardware configuration, then you would naturally expect different time elapsed to run the same parallel queries. See the end of this answer for the additional information that you may provide.
But I would be very suspicious of the hardware configuration of the two systems. Maybe 10 g system has 16-core processors or more and 100's of discs in a matrix of big drives and maybe the 12 c system has only 4 cores of the processor and 4 disks. That would explain a lot about why the 12 c takes hours to run when the 10 g takes only 30 minutes.
Remember what I said in my last reply:
"Without any contrary information I guess the filter conditions are very low, the optimizer believes he needs of most of the data in the table and that a table scan or even a limited index scan complete is the"best"way to run this SQL. In other words, your query takes just time because your tables are big and your application has most of the data in these tables. "
When dealing with very large tables and to do a full table parallel analysis on them, the most important factor is the amount of raw hardware, you throw the ball to her. A system with twice the number of CPUS and twice the number of disks will run the same parallel query in half of the time, at least. It could be that the main reason for the 12 c system is much slower than the system of 10g, rather than on the implementation plan itself.
You may also provide us with the following information which would allow a better analysis:
- Row counts in each tables referenced in the query, and if one of them are partitioned.
- Hardware configurations for both systems - the 10g and the 12 a. Number of processors, the model number and speed, physical memory, CPU of discs.
- The discs are very important - 10g and 12 c have similar disk subsystems? You use simple old records, or you have a San, or some sort of disk array? Are the bays of identical drives in both systems? How are they connected? Fast Fibre Channel, or something else? Maybe even network storage?
- What is the size of the SGA in both systems? of values for MEMORY_TARGET and SGA_TARGET.
- The fact of the CLAIM_FACTS_AK9 index exist on the system of 10g. I guess he does, but I would like that it confirmed to be safe.
John Brady
-
Performance problem on the SQL query that does not use the primary key index
Hello!
I have some performance issues on a single SQL query (Oracle 10 g).
I could solve the problem by using the INDEX indicator, but I would like to know WHY this is happening.
* Tables *.
create table jobs)
ID number (5) not null,
name varchar2 (100),
primary key constraint Job_PK (id)
)
/
-Record count: 298
create table Comp)
integer ID not null,
name varchar2 (100),
primary key constraint Comp_PK (id)
)
/
-Record count: 193
-Relation m: n
create table JobComp)
integer ID not null,
id_job integer not null,
id_comp integer not null,
primary key constraint JobComp_PK (id),
unique key constraint JobComp_UK (id_job, id_comp),
Constraint JobComp_FK_Job foreign key (id_job) refers to Job (id),
Constraint JobComp_FK_Comp foreign key (id_comp) makes reference Comp (id)
)
/
create index JobComp_IX_Comp on JobComp (Cod_Comp)
/
create index JobComp_IX_Job on JobComp (Cod_Job)
/
-Record count: 6431
* Ask *.
When I run this query, the execution plan shows the index using (JobComp_PK and JobComp_IX_Comp).
No problem.
Select JobComp.*
of JobComp
Join jobs
on Job.id = JobComp.id_job
where JobComp.id_comp = 134
/
-runs in 0.20 sec
But when I add the field 'name' of the work table the plan uses full access table to the table of work
Select JobComp.*, Job.name
of JobComp
Join jobs
on Job.id = JobComp.id_job
where JobComp.id_comp = 134
/
-runs in the 2.70 dry
With the help of the index
Select / * + INDEX (Job Job_PK) * /.
JobComp.*, Job.name
of JobComp
Join jobs
on Job.id = JobComp.id_job
where JobComp.id_comp = 134
/
-runs in 0.20 sec
* Doubt *.
This behavior is correct?
PS. : I tried to recalculate the statistics, but nothing changes:
analyze the job calculation table statistics.
/
change the statistical calculation of index Job_PK reconstruction;
/
Start
dbms_utility.analyze_schema (sys_context ('userenv', 'current_schema'), 'CALCULATE');
end;
/
[of]
Gustavo EhrhardtGus.EHR wrote:
Hello.
I'm sorry for the plan unformatted.
The execution time of the querys "without field name' and 'with the field name with suspicion" are equal.
He has no problem caching, because I get the plans of the sequence different from the querys and repeated the performance. The result is always the same.I don't think that there is no problem with oracle crossing LOOP IMBRIQUEE to the HASH JOIN when you include the field name and this should be the expected behavior. But it seems that your WORKING table has a degree of parallelism set against what is causing the query to run in parallel (as JOB table is now available with full table scan, instead of indexed access earlier). It could be that the parallel execution is contributor to extra Runtime.
(a) do you know why the degree of parallelism on the WORK table has been defined? Do you need it?You can see if the following query provides a better response time?
select /*+ NOPARALLEL(JOB) */ JobComp.*, Job.Name from JobComp join Job on Job.id = JobComp.id_job where JobComp.id_comp = 134 -
Performance problem after upgrade to 10G.
All,
We have recently updated to 10G (Version: 10.2.0.3.0) after which the sub query causes the problem. This query is written within a pl/sql package called by a Perl program. The Perl program for still runs without end of the work in a few attempts and sometimes it ends very quickly. We made some kind of debugging and found that whenever the program is raise stucked in this below given query and not the processing of same here if we leave 2-3 days. During a successful attempt, it ends with 3-4 hours. This request is to take 2 explain plan as shown below, and it seems that one of them is the best and the other is worse. Plan 2 is the best and plan 1 is worst.
Y at - it suggestions to fix this and the reason why two explain plans are picking up?... NUM of records on the tables is as below...
Can you please provide me with details as I am a beginner in the performance of these concepts?
Your help will be very appreciated...
Tables of records no.
ult_cust_master 551925
us_state_county 3223
customer 1559
turfbuilder_group2_empcnt_tmp 44K
ult_cust_sale 2430143
ucsi_item 9714371
------------------------------------------------------------------------------------------------------------------------SELECT cust.cust_num, cust.cust_name, cust.emp_count, cust.sic1, cust.s1_description, NVL (cust_sale.qty, 0) qty, NVL (cust_sale.mot_amt, 0) mot_amt, NVL (cust_sale.cust_amt, 0) cust_amt, cust.min_sale_dt, cust.max_sale_dt, cust.cust_status FROM (SELECT DISTINCT ucm.cust_num, f.cust_name cust_name, NVL (te.tet_emp_count, 0) emp_count, b.min_sale_dt, b.max_sale_dt, f.cust_status, sc1.sic1, sc1.s1_description FROM ult_cust_master ucm, us_state_county u, customer f, (SELECT div_cd, ctry_cd, cust_num, MIN (ucs_dt) min_sale_dt, MAX (ucs_dt) max_sale_dt FROM ult_cust_sale WHERE div_cd = :b4 AND ctry_cd = :b3 AND rec_status = 'A' GROUP BY div_cd, ctry_cd, cust_num) b, sic1 sc1, (SELECT tet_code, tet_vm_code, tet_type, tet_emp_count FROM turfbuilder_group2_empcnt_tmp WHERE tet_type = 'D') te WHERE f.div_cd = ucm.div_cd AND f.ctry_cd = ucm.ctry_cd AND f.cust_num = ucm.cust_num AND b.div_cd = ucm.div_cd AND b.ctry_cd = ucm.ctry_cd AND b.cust_num = ucm.cust_num AND te.tet_code(+) = ucm.cust_num AND te.tet_vm_code = sc1.sic1 AND f.div_cd = :b4 AND f.ctry_cd = :b3 AND ucm.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND ucm.rec_status = 'A' AND u.rec_status = 'A' AND sc1.rec_status = 'A' AND f.cust_imp21_dealer_fg = 'Y' AND NVL (f.cust_test_dealer_fg, 'N') <> 'Y') cust, (SELECT c.cust_num cust_num, sc2.sic1, SUM (DECODE (a.ucsii_unit_fg, 'Y', a.ucsii_qty * 1, a.ucsii_qty * 0 ) ) qty, SUM (a.ucsii_qty * a.ucsii_mot_unit_pr) mot_amt, SUM (a.ucsii_qty * a.ucsii_ult_unit_pr) cust_amt FROM ucsi_item a, ult_cust_sale b, ult_cust_master c, sic2 sc2, us_state_county u WHERE a.div_cd = b.div_cd AND a.ctry_cd = b.ctry_cd AND a.cust_num = b.cust_num AND a.ucm_mailbox_num = b.ucm_mailbox_num AND a.ucm_seq = b.ucm_seq AND a.ucs_seq = b.ucs_seq AND c.div_cd = b.div_cd AND c.ctry_cd = b.ctry_cd AND c.cust_num = b.cust_num AND c.ucm_mailbox_num = b.ucm_mailbox_num AND c.ucm_seq = b.ucm_seq AND SUBSTR (c.ucm_sic_cd, 1, 2) = sc2.sic2 AND c.ucm_stcnty_fips_cd = u.usc_st_cnty_cd AND a.ucsii_in_apmr_fg = 'Y' AND a.ucsii_audit_data_cd = 'G' AND a.ucsii_contract_id IN ('BRANDED', 'CTR', 'WARIS', 'RADIUS', 'BRNDCONV', 'BRNDTRNK' ) AND ( (a.ucsii_unit_fg = 'Y') OR (a.ucsii_unit_fg = 'N' AND a.ucsii_item_num LIKE '%.%') ) AND c.div_cd = :b4 AND c.ctry_cd = :b3 AND UPPER (u.usc_state_abbrev) NOT IN ('PR', 'VI') AND u.rec_status = 'A' AND c.rec_status = 'A' AND a.rec_status = 'A' AND sc2.rec_status = 'A' AND b.ua_cd = 'ENDCUST' AND b.rec_status = 'A' AND b.ucs_dt BETWEEN TO_DATE (:b2, 'dd mon yyyy') AND TO_DATE (:b1, 'dd mon yyyy') GROUP BY c.cust_num, sc2.sic1) cust_sale WHERE cust.cust_num = cust_sale.cust_num(+) AND cust.sic1 = cust_sale.sic1(+)
{color: blue}
Implementation plan - 1:
Hash value of plan: 2237978112
-----------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 643 (100) |
|* 1 | OUTER HASH JOIN | 1. 175. 643 (2) | 00:00:08 |
| 2. VIEW | 1. 118. 74 (5) | 00:00:01 |
| 3. UNIQUE HASH | 1. 310. 74 (5) | 00:00:01 |
| 4. HASH GROUP BY. 1. 310. 74 (5) | 00:00:01 |
|* 5 | FILTER |
| 6. NESTED LOOPS | 1. 310. 73 (3) | 00:00:01 |
| 7. NESTED LOOPS | 1. 278. 70 (2) | 00:00:01 |
| 8. NESTED LOOPS | 1. 187. 69 (2) | 00:00:01 |
| 9. NESTED LOOPS | 1. 148. 68 (2) | 00:00:01 |
| 10. NESTED LOOPS | 1. 100. 52 (2) | 00:00:01 |
| * 11 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 1. 52. 51 (2) | 00:00:01 |
| * 12 | TABLE ACCESS BY INDEX ROWID | KFS1AND | 1. 48. 1 (0) | 00:00:01 |
| * 13 | INDEX UNIQUE SCAN | SYS_C001278 | 1 | | 1 (0) | 00:00:01 |
| * 14 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 517. 24816 | 16 (0) | 00:00:01 |
| * 15 | INDEX RANGE SCAN | XIF9ULT_CUST_MASTER | 505. 1 (0) | 00:00:01 |
| * 16. TABLE ACCESS BY INDEX ROWID | US_STATE_COUNTY | 1. 39. 1 (0) | 00:00:01 |
| * 17. INDEX UNIQUE SCAN | XPKSTATE_COUNTY | 1 | | 1 (0) | 00:00:01 |
| * 18. TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1. 91. 1 (0) | 00:00:01 |
| * 19. INDEX UNIQUE SCAN | XPKCUSTOMER | 1 | | 1 (0) | 00:00:01 |
| * 20. INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 13514 | 422K | 2 (0) | 00:00:01 |
| 21. VIEW | 1. 57. 569 (2) | 00:00:07 |
| 22. HASH GROUP BY. 1. 209. 569 (2) | 00:00:07 |
| * 23. FILTER |
| * 24. TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1. 74. 1 (0) | 00:00:01 |
| 25. NESTED LOOPS | 1. 209. 568 (1) | 00:00:07 |
| 26. NESTED LOOPS | 1. 135. 567 (1) | 00:00:07 |
| * 27. HASH JOIN | 1491. 110K | 118 (3) | 00:00:02 |
| * 28. TABLE ACCESS FULL | KFS2 | 83. 996 | 2 (0) | 00:00:01 |
| 29. TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 186. 9858. 13 (0) | 00:00:01 |
| 30. NESTED LOOPS | 1500 | 96000 | 115 (2) | 00:00:02 |
| * 31. TABLE ACCESS FULL | US_STATE_COUNTY | 8. 88. 9 (12) | 00:00:01 |
| * 32 | INDEX RANGE SCAN | TEST | 186. 1 (0) | 00:00:01 |
| * 33 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1. 59. 1 (0) | 00:00:01 |
| * 34 | INDEX RANGE SCAN | XIE1ULT_CUST_SALE | 1 | | 1 (0) | 00:00:01 |
| * 35 | INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | 1 (0) | 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("CUST".") CUST_NUM "=" CUST_SALE. " "' CUST_NUM ' AND 'CUST '. "" KFS1AND "=" CUST_SALE. " ("' KFS1AND")
5 filter ((: = B3: B3 AND: B4 =: B4))
11 - filter("TET_TYPE"='D')
12 - filter("SC1".") "REC_STATUS"="A")
13 - access ("TET_VM_CODE"= "SC1"." KFS1AND')
14 - filter("UCM".") "REC_STATUS"="A")
15 - access("UCM".") DIV_CD ' =: B4 AND "UCM".» CTRY_CD' =: B3 AND "TET_CODE"="UCM". ("' CUST_NUM")
filter (("UCM". "DIV_CD" =: B4 AND "UCM". "" CTRY_CD "=:B3))
16 filter ((SUPÉRIEUR ("U".))) "USC_STATE_ABBREV") <>"PR" AND UPPER ("U". "<>USC_STATE_ABBREV") "VI" AND "
"U"." "REC_STATUS"="A"))
17 - access("UCM".") UCM_STCNTY_FIPS_CD '=' U '. ("' USC_ST_CNTY_CD")
18 filter (("F". "CUST_IMP21_DEALER_FG" = 'Y' AND NVL ("F." "" (((CUST_TEST_DEALER_FG', ' only) <>'Y'))
19 - access("F".") DIV_CD ' =: B4 AND 'F'.» CTRY_CD ' =: B3 AND 'F'.» CUST_NUM "=" UCM ". ("' CUST_NUM")
filter (("F". "DIV_CD" =: B4 AND 'F'. "" CTRY_CD "=:B3))
20 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "CUST_NUM"="UCM".") CUST_NUM' AND 'REC_STATUS' = 'A')
filter (("DIV_CD" =: B4 ET "CTRY_CD" =: B3 ET "REC_STATUS" = "A"))
23 filter (TO_DATE (: B2, ' DD month yyyy ') < = TO_DATE (: B1, ' DD month yyyy '))
24 filter ((("A". "UCSII_UNIT_FG" = "Y" OR ('A'. "" UCSII_ITEM_NUM' AS '%. %' AND 'A '. "UCSII_UNIT_FG"(='N')) AND "
"A"." UCSII_IN_APMR_FG ' = 'Y' AND INTERNAL_FUNCTION ("A". ". UCSII_CONTRACT_ID") AND"A ". "UCSII_AUDIT_DATA_CD" = "G"
AND 'A '. (("" REC_STATUS "=" A "))
27 - access("SC2".") KFS2 '= SUBSTR ("C.". UCM_SIC_CD', 1, 2))
28 - filter("SC2".") "REC_STATUS"="A")
31 filter ((SUPÉRIEUR ("U".))) "USC_STATE_ABBREV") <>"PR" AND UPPER ("U". "<>USC_STATE_ABBREV") "VI" AND "
"U"." "REC_STATUS"="A"))
32 - access("C".") UCM_STCNTY_FIPS_CD '=' U '. "' USC_ST_CNTY_CD ' AND 'C '. "DIV_CD ' =: B4 AND 'C'." ' CTRY_CD ' =: B3 AND.
"C"." "REC_STATUS"="A")
33 filter ((' B'. "UA_CD"= 'ENDCUST' AND 'C'." UCM_MAILBOX_NUM '=' B '. (("" UCM_MAILBOX_NUM "))
34 - access("B".") DIV_CD ' =: B4 AND 'B'. " CTRY_CD ' =: B3 AND 'C'. " CUST_NUM '=' B '. "" CUST_NUM "AND
"C"." UCM_SEQ '=' B '. "' UCM_SEQ ' AND 'B '. "" UCS_DT "> = TO_DATE(:B2,'dd mon yyyy') AND 'B '. "REC_STATUS" = "A" AND "
"B"." (UCS_DT"< = TO_DATE (: B1, ' DD month yyyy '))
filter ('B'. "REC_STATUS"="A")
35 - access("A".") DIV_CD ' =: B4 AND 'A'. '. CTRY_CD ' =: B3 AND 'A'. '. CUST_NUM '=' B '. "" CUST_NUM "AND
"A"." UCM_MAILBOX_NUM '=' B '. "' UCM_MAILBOX_NUM ' AND 'A '. "" UCM_SEQ "=" B ". "' UCM_SEQ ' AND 'A '. "" UCS_SEQ "=" B ". ("' UCS_SEQ")
---------------------------------------------------------------------------------------------------------------
{color}
{color: green}
Implementation plan - 2:
Hash value of plan: 2023039777
-----------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 3341 (100) |
|* 1 | EXTERNAL RIGHT HASH JOIN | 12967 | 2216K | 3341 (5) | 00:00:41 |
| 2. VIEW | 1. 57. 607 (6) | 00:00:08 |
| 3. HASH GROUP BY. 1. 209. 607 (6) | 00:00:08 |
|* 4 | FILTER |
|* 5 | TABLE ACCESS BY INDEX ROWID | UCSI_ITEM | 1. 74. 1 (0) | 00:00:01 |
| 6. NESTED LOOPS | 1. 209. 606 (6) | 00:00:08 |
| 7. NESTED LOOPS | 1. 135. 605 (6) | 00:00:08 |
|* 8 | HASH JOIN | 1. 123 | 604 (6) | 00:00:08 |
|* 9 | TABLE ACCESS BY INDEX ROWID | ULT_CUST_SALE | 1214. 71626 | 455 (7) | 00:00:06 |
| * 10 | INDEX SKIP SCAN | XIE1ULT_CUST_SALE | 1 | | | 455 (7) | 00:00:06 |
| 11. TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245. 12985. 17 (0) | 00:00:01 |
| 12. NESTED LOOPS | 1971 | 123K | 148 (2) | 00:00:02 |
| * 13 | TABLE ACCESS FULL | US_STATE_COUNTY | 8. 88. 9 (12) | 00:00:01 |
| * 14 | INDEX RANGE SCAN | TEST | 245. 1 (0) | 00:00:01 |
| * 15 | TABLE ACCESS BY INDEX ROWID | KFS2 | 1. 12. 1 (0) | 00:00:01 |
| * 16. INDEX UNIQUE SCAN | XPKSIC2 | 1 | | | 1 (0) | 00:00:01 |
| * 17. INDEX RANGE SCAN | XPKUCSI_ITEM | 1 | | | 1 (0) | 00:00:01 |
| 18. VIEW | 12967 | 1494K | 2732 (5) | 00:00:33 |
| 19. UNIQUE HASH | 12967 | 3254K | 6936K | 2732 (5) | 00:00:33 |
| * 20. HASH JOIN | 12967 | 3254K | 1998 (6) | 00:00:24 |
| 21. VIEW | 410. 16400 | 1781 (5) | 00:00:22 |
| 22. HASH GROUP BY. 410. 13120 | 1781 (5) | 00:00:22 |
| * 23. FILTER |
| * 24. INDEX RANGE SCAN | XIE1ULT_CUST_SALE | K 1963 | 59 M | 1781 (5) | 00:00:22 |
| * 25. HASH JOIN | 4792. 1015K | 215 (7) | 00:00:03 |
| * 26. TABLE ACCESS FULL | KFS1AND | 11. 528. 2 (0) | 00:00:01 |
| * 27. HASH JOIN | 4792. 790K | 212 (6) | 00:00:03 |
| * 28. TABLE ACCESS BY INDEX ROWID | CUSTOMER | 1003 | 79237 | 4 (0) | 00:00:01 |
| * 29. INDEX RANGE SCAN | XIF317CUSTOMER | 1371 | 1 (0) | 00:00:01 |
| * 30 | HASH JOIN | 4794. 421K | 207 (6) | 00:00:03 |
| 31. TABLE ACCESS BY INDEX ROWID | ULT_CUST_MASTER | 245. 8820 | 17 (0) | 00:00:01 |
| 32. NESTED LOOPS | 1971 | 136K | 148 (2) | 00:00:02 |
| * 33 | TABLE ACCESS FULL | US_STATE_COUNTY | 3 × 280. 9 (12) | 00:00:01 |
| * 34 | INDEX RANGE SCAN | TEST | 245. 1 (0) | 00:00:01 |
| * 35 | TABLE ACCESS FULL | TURFBUILDER_GROUP2_EMPCNT_TMP | 8914. 165K | 58 (14) | 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("CUST".") CUST_NUM "=" CUST_SALE. " "' CUST_NUM ' AND 'CUST '. "" KFS1AND "=" CUST_SALE. " ("' KFS1AND")
4 filter (TO_DATE (: B2, ' DD month yyyy ') < = TO_DATE (: B1, ' DD month yyyy '))
5 filter ((("A". "UCSII_UNIT_FG" = "Y" OR ('A'. "" UCSII_ITEM_NUM' AS '%. %' AND 'A '. "UCSII_UNIT_FG"(='N')) AND "
"A"." UCSII_IN_APMR_FG ' = 'Y' AND INTERNAL_FUNCTION ("A". ". UCSII_CONTRACT_ID") AND"A ". "UCSII_AUDIT_DATA_CD" = "G" AND "
"A"." "REC_STATUS"="A"))
8 - access("C".") DIV_CD '=' B '. "' DIV_CD ' AND 'C '. "" CTRY_CD "=" B ". "' CTRY_CD ' AND 'C '. "" CUST_NUM "=" B ". "" CUST_NUM "AND
"C"." UCM_MAILBOX_NUM '=' B '. "' UCM_MAILBOX_NUM ' AND 'C '. "" UCM_SEQ "=" B ". ("' UCM_SEQ")
9 - filter("B".") UA_CD "=" ENDCUST")
10 - access("B".") DIV_CD ' =: B4 AND 'B'. " CTRY_CD ' =: B3 AND 'B'. " UCS_DT' > = TO_DATE(:B2,'dd mon yyyy') AND
"B"." REC_STATUS ' = 'A' AND 'B'. " (UCS_DT"< = TO_DATE (: B1, ' DD month yyyy '))
filter ((' B'. "UCS_DT" > = TO_DATE(:B2,'dd mon yyyy') AND 'B' "." " REC_STATUS ' = 'A' AND 'B'. " UCS_DT"< = TO_DATE (: B1,'dd)
month yyyy ')))
13. ((SUPÉRIEUR ("U".) filter)) "USC_STATE_ABBREV") <>"PR" AND UPPER ("U". "<>USC_STATE_ABBREV") 'VI' AND 'U'. " (("" REC_STATUS "=" A "))
14 - access("C".") UCM_STCNTY_FIPS_CD '=' U '. "' USC_ST_CNTY_CD ' AND 'C '. "DIV_CD ' =: B4 AND 'C'." ' CTRY_CD ' =: B3 AND.
"C"." "REC_STATUS"="A")
15 - filter("SC2".") "REC_STATUS"="A")
16 - access("SC2".") KFS2 '= SUBSTR ("C.". UCM_SIC_CD', 1, 2))
17 - access("A".") DIV_CD ' =: B4 AND 'A'. '. CTRY_CD ' =: B3 AND 'A'. '. CUST_NUM '=' B '. "" CUST_NUM "AND
"A"." UCM_MAILBOX_NUM '=' B '. "' UCM_MAILBOX_NUM ' AND 'A '. "" UCM_SEQ "=" B ". "' UCM_SEQ ' AND 'A '. "" UCS_SEQ "=" B ". ("' UCS_SEQ")
20 - access("B".") DIV_CD "=" UCM ". "' DIV_CD ' AND 'B '. "" CTRY_CD "=" UCM ". "' CTRY_CD ' AND 'B '. "" CUST_NUM "=" UCM ". ("' CUST_NUM")
23 filter ((: = B3: B3 AND: B4 =: B4))
24 - access("DIV_CD"=:B4 AND "CTRY_CD"=:B3 AND "REC_STATUS"='A')
filter (("DIV_CD" =: B4 ET "CTRY_CD" =: B3 ET "DIV_CD" =: B4 ET "CTRY_CD" =: B3 ET "REC_STATUS" = "A"))
25 - access ("TET_VM_CODE"= "SC1"." KFS1AND')
26 - filter("SC1".") "REC_STATUS"="A")
27 - access("F".") DIV_CD "=" UCM ". "" DIV_CD "AND"F ". "" CTRY_CD "=" UCM ". "" CTRY_CD "AND"F ". "" CUST_NUM "=" UCM ". ("' CUST_NUM")
28 filter (("F". "DIV_CD" =: B4 AND 'F'. "" CUST_IMP21_DEALER_FG ' = 'Y' AND NVL ("F." ". (((CUST_TEST_DEALER_FG', ' only) <>'Y'))
29 - access("F".") CTRY_CD "(=:B3)"
30 - access ("TET_CODE"= "UCM"." CUST_NUM')
33. ((SUPÉRIEUR ("U".) filter)) "USC_STATE_ABBREV") <>"PR" AND UPPER ("U". "<>USC_STATE_ABBREV") 'VI' AND 'U'. " (("" REC_STATUS "=" A "))
34 - access("UCM".") UCM_STCNTY_FIPS_CD '=' U '. "" USC_ST_CNTY_CD "AND"UCM ". «DIV_CD ' =: B4 AND "UCM".» ' CTRY_CD ' =: B3 AND.
"UCM". ("" REC_STATUS "=" A ")
35 - filter("TET_TYPE"='D')
{color}
Published by: user3030284 on October 28, 2008 21:42user3030284 wrote:
All,We have recently updated to 10G (Version: 10.2.0.3.0) after which the sub query causes the problem. This query is written within a pl/sql package called by a Perl program. The Perl program for still runs without end of the work in a few attempts and sometimes it ends very quickly. We made some kind of debugging and found that whenever the program is raise stucked in this below given query and not the processing of same here if we leave 2-3 days. During a successful attempt, it ends with 3-4 hours. This request is to take 2 explain plan as shown below, and it seems that one of them is the best and the other is worse. Plan 2 is the best and plan 1 is worst.
Y at - it suggestions to fix this and the reason why two explain plans are picking up?... NUM of records on the tables is as below...
Can you please provide me with details as I am a beginner in the performance of these concepts?
Your help will be very appreciated...
As we already mentioned, please read the FAQ and use appropriate tags to format your messages.
For example, please use the noformat} [{noformat} code {noformat}] {noformat} before tag and {noformat} [{noformat} / code {noformat}] {noformat} tag or after the noformat} {{noformat} code {noformat}} {noformat} tag before and after to improve readability.
You don't need the re - publish, you can use the function "Modify" to edit your existing messages.
Regarding your question:
Among the changes, the most important in 10g are collection of default statistics, which runs by default, every night and the setting changed default setting METHOD_OPT, which is now 'for all THE COLUMNS of SIZE AUTO '. It was "FOR ALL COLUMNS SIZE 1" in 9i. The parameter "method_opt" affects column statistics. 9i 'SIZE 1' means that no histograms will be created. "AUTO SIZE" in 10g means that if the column is used in predicates (for example using equal or will the comparisons) and the data are biased Oracle will create a histogram.
A histogram can cause your execution plan change. Since this statement used bind variables (because PL/SQL uses by default) and is so optimized using 'bind variable peeking', the execution plan generated depends on the actual values passed when the statement is parsed.
If you are unlucky with the values passed when education gets analyzed you might end up with an implementation plan that runs poor for most executions remaining because Oracle will not be re - evaluate the execution plan as long as the statement remains in memory cache in the shared Pool.
Note that this change in 11g with the introduction of 'Adaptive Cursor sharing'.
For more information how to check if you have this problem and how to fix, please refer to this section of the excellent blog by the Pythian Group:
http://www.Pythian.com/blogs/867/stabilize-Oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Kind regards
RandolfOracle related blog stuff:
http://Oracle-Randolf.blogspot.com/SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/ -
Estimates of cardinality for index range scan with bind variables
Oracle 11.2.0.4
I am struggling to explain that the cardinality estimates for a scan of the index systematic range when using the bind variable.
Consider the following query:
SELECT /*+ INDEX(t1) */ * FROM t1 WHERE source_id <= ?;
Cardinalities for the INDEX RANGE SCAN and ACCESS of the TABLE are the same for different literal predicates, for example, source_id < = 5:
------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 50 | 350 | 12 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| T1 | 50 | 350 | 12 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | IX1 | 50 | | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("SOURCE_ID"<=5)If a variable binding is used instead of a literal, the overall selectivity is 5%. However, why the optimizer based on CSSTidy gives a cardinality estimated 11 for the scan of the index systematic range? As with the predicates literal, surely the cardinalities of the index range scan and access table should be the same?
------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 50 | 350 | 5 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| T1 | 50 | 350 | 5 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | IX1 | 11 | | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("SOURCE_ID"<=TO_NUMBER(:A))Unit test code:
CREATE TABLE t1 ( id NUMBER , source_id NUMBER ); CREATE INDEX ix1 ON t1 (source_id); INSERT INTO t1 SELECT level , ora_hash(level,99)+1 FROM dual CONNECT BY level <= 1000; exec DBMS_STATS.GATHER_TABLE_STATS(user,'T1') EXPLAIN PLAN FOR SELECT /*+ INDEX(t1) */ * FROM t1 WHERE source_id <= 5; SELECT * FROM TABLE(dbms_xplan.display); EXPLAIN PLAN FOR SELECT /*+ INDEX(t1) */ * FROM t1 WHERE source_id <= :a; SELECT * FROM TABLE(dbms_xplan.display);
There are various places where the optimizer uses an assumption, and lie unpeekable (and of Villa "unknowable value") introduced guess.
For unpeekable binds the conjecture for column<= {unknown}="" is="" 5%="" for="" table="" access="" (hence="" 50="" rows="" out="" of="" 1,000),="" but="" it's="" 0.009="" for="" index_column=""><= {unknown},="" which="" means="" i="" was="" expecting="" to="" see="" 9="" as="" the="" row="" estimate="" on="" the="" index="" range="">
I just ran some quick tests, and EXPLAIN the PLAN seems to just use 0.011 selectivity in this case (in different versions of Oracle) although if we do the bind variable unpeekable at run time (and sample dynamic block etc.) optimization for execution is 0.009%.
Concerning
Jonathan Lewis
Update: and this is a very old reference to the 0.009 (and 0.0045 for ' between the ' when it is applied to a clue: cost based Oracle - access Chapter 4 single B-tree )
-
Performance problem - oracle 10.2.0.4
HI Experts,
Today I met a performance problem. I pulled a simple query to get the number of records in a table existed in the databases of PROD and QA. The two databases are the same settings at parameter level. But when I launch the application, Prod database takes 10 minutes to get the result. Not sure why prod base it takes a lot of time.
Additional information:
---------------------
The number of lines is almost the same on the two databases
OPERATING SYSTEM: IBM AIX
Oracle: 10.2.0.4
QA Database - explain plan
==========================
06:40:49 SQL > select count (*) in the Siebel.s_prod_baseline;
COUNT (*)
----------
42146408
Elapsed time: 00:00:45.35 == > just 45 seconds
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Hash value of plan: 645963650
-------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Cost (% CPU). Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 1165 (1) | 00:00:14 |
| 1. GLOBAL TRI | | 1. | |
| 2. INDEX SCAN FULL | S_PROD_BASELINE_P1 | 42 M | 1165 (1) | 00:00:14 |
-------------------------------------------------------------------------------
Database of PROD explain plan
======================
06:42:59 SQL > select count (*) in the Siebel.s_prod_baseline;
COUNT (*)
----------
42730261
Elapsed time: 00:10:13.43 == > took more than 10 minutes
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Hash value of plan: 645963650
-------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Cost (% CPU). Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 4160 (1) | 00:00:50 |
| 1. GLOBAL TRI | | 1. | |
| 2. INDEX SCAN FULL | S_PROD_BASELINE_P1 | 42 M | 4160 (1) | 00:00:50 |
-------------------------------------------------------------------------------
Could if it you please let me know why oracle it takes a lot of time prod database?
Thank you..
> There was another option to check why prod database behaves differently?
Yes. The trace file, TRACE the request and review (or the tkprof).
Hemant K Collette
-
Should I wait until the end of the execution time of the query for the execution plan?
Hello Experts,
I want to see the execution plan of the query below. However, it takes more than 3 hours. Should I wait all the time to see the execution plan?
Note: EXPLAIN PLAN for does not work. (I mean that I do not see the actual line number, etc. with EXPLAIN the PLAN of market)
You can see the output of the execution plan when I canceled the execution after 1 minute.
My first question is: what should I do to see the execution plan for queries running out of time time?
2nd question: when I cancel the query during execution in order to see the execution plan, will I see the specific plan of execution or erroneous values? Because the first execution plan seems inaccurate, what do you think?
question 3: why EXPLAIN the PLAN for the clause does not work? Also, should I use EXPLAIN the PLAN of the clause to this scenerio? Can I see the result of running for long time without her queries?
Thnaks for your help.
Oracle Database 11 g Enterprise Edition Release 11.2.0.2.0 - 64 bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE Production 11.2.0.2.0
AMT for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SQL_ID, dznya6x7st0t8, number of children 0
-------------------------------------
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT,.
J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price of
CustInvoiceJour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
Hash value of plan: 2002317666
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Begins | E - lines. A - lines. A - time | Pads | Bed | OMem | 1Mem | Used Mem.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 1 | HASH JOIN | | 1. 3956. 0 | 00:00:00.01 | 0 | 0 | 2254K | 1061K | 2190K (0) |
|* 2 | HASH JOIN | | 1. 87. 16676. 00:00:01.64 | 227K | 3552. 3109K | 1106K | 4111K (0) |
|* 3 | TABLE ACCESS BY INDEX ROWID | CUSTINVOICEJOUR | 1. 1155 | 31889 | 00:00:01.16 | 223KO | 15. | | |
|* 4 | INDEX RANGE SCAN | I_062INVOICEDATEORDERTYPEIDX | 1. 4943 | 134K | 00:00:00.83 | 45440 | 0 | | | |
| 5. SIMPLE LIST OF PARTITION. | 1. 82360 | 173K | 00:00:00.08 | 3809 | 3537 | | | |
|* 6 | TABLE ACCESS FULL | AVTR_SEG_CUST_CAMPEND | 1. 82360 | 173K | 00:00:00.06 | 3809 | 3537 | | | |
| 7. TABLE ACCESS BY INDEX ROWID | CUSTINVOICETRANS | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 8 | INDEX RANGE SCAN | I_064INVLINENUMCAMPAIGNOFPRICE | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("J".") "SYS_NC00299$"="T". "' SYS_NC00165$ ' AND SUBSTR (NLS_LOWER ('J'. "" "" REFFACTURE")(, 1, 25) = SUBSTR (NLS_LOWER ("T"." "" "REFFACTURE")(, 1, 25)).
2 - access("J".") INVOICEACCOUNT '= SYS_OP_C2C ("EC". ". ACCOUNTNUM'))
3 - filter("J".") AVAWARDSALES"> 190)
4 - access("J".") SYS_NC00299$ "= U ' 201"AND "J". INVOICEDATE"> = TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"J"." SYS_NC00307$ "= U ' 201406"AND "J". INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss')))
filter ((' J'. "INVOICEDATE' > = 'J' AND TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') '." " SYS_NC00307$ "= U '201406' AND"
"J"." INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss'))))
6 filter (("CE". "SEGMENT_LEVEL" = A "OR"THIS"." SEGMENT_LEVEL "=" E"))
8 - access("T".") SYS_NC00165$ "= U ' 201"AND "T". AVBROCHURELINENUM "= 29457)
filter ("T". ("AVBROCHURELINENUM" = 29457)
EXPLAIN PLAN FOR
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR);
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR ('7h1nbzqjgwsp7', 2));
SQL_ID, 7h1nbzqjgwsp7, number of children 2
EXPLAIN PLAN for select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * /.
J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE,
(T.LINEAMOUNT + T.LINEAMOUNTTAX) join price j custinvoicejour
CustInvoiceTrans t on substr (nls_lower (j.dataareaid), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
NOTE: cannot fetch SQL_ID plan: 7h1nbzqjgwsp7, CHILD_NUMBER: 2
Check the value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in the cursor cache (check v$ sql_plan)
NightWing wrote:
Randolf,
I don't understand. What you hear from the above statement that you mean A-lines and E will be incorrect, but the ratio between them remain the same. Therefore, you can deduct the bad things by comparing the differences.
Thus, A-lines always give a wrong result for cancellation of queries, isn't it?
Charlie,
I think that Martin gave a good explanation. Here's another example that hopefully makes more obvious things:
17:56:55 SQL >-things go very wrong here with a small buffer cache
17:56:55 SQL >-T2 lines are badly scattered when you access through T1. FK
17:56:55 SQL >--
17:56:55 SQL >-"Small job" approach would have been a good idea
17:56:55 SQL >-if the estimate of 100 iterations of the loop was correct!
17:56:55 SQL > select
17:56:55 (t2.attr2) count 2
17:56:55 3 of
17:56:55 4 t1
17:56:55 5, t2
17:56:55 6 where
17:56:55 7 /*------------------*/
17:56:55 8 trunc (t1.attr1) = 1
17:56:55 9 and trunc (t1.attr2) = 1
17:56:55 10 / *-* /.
17:56:55 11 and t1.fk = t2.id
17:56:55 12.
T1
*
ERROR on line 4:
ORA-01013: user has requested the cancellation of the current operation
Elapsed time: 00:04:58.30
18:01:53 SQL >
18:01:53 SQL > @xplan_extended_display_cursor ' ' ' ' 'ALLSTATS LAST + COST.
18:01:53 SQL > set echo off verify off termout off
SQL_ID, 353msax56jvvp, number of children 0
-------------------------------------
SELECT count (t2.attr2) from t1, t2 where
/ / *-* trunc (t1.attr1) = 1 and
trunc (T1.attr2) = 1 / *-* / and t1.fk = t2.id
Hash value of plan: 2900488714
------------------------------------------------------------------------------------------------------------------------------------
| ID | The NEST | DSB | Operation | Name | Begins | E - lines. Cost (% CPU). A - lines. A - time | Pads | Bed |
------------------------------------------------------------------------------------------------------------------------------------
| 0 | | 7. SELECT STATEMENT | | 1. | 4999 (100) | 0 | 00:00:00.01 | 0 | 0 |
| 1. 0 | 8 2 GLOBAL TRI | | 1. 1. | 0 | 00:00:00.01 | 0 | 0 |
| 2. 1. 5. NESTED LOOPS | | 1. | | 57516 | 00:04:58.26 | 173K | 30770 |
| 3. 2. 3. NESTED LOOPS | | 1. 100. 4999 (1) | 57516 | 00:00:21.06 | 116K | 3632.
|* 4 | 3. 1. TABLE ACCESS FULL | T1 | 1. 100. 4799 (1) | 57516 | 00:00:00.19 | 1008 | 1087 |
|* 5 | 3. 2. INDEX UNIQUE SCAN | T2_IDX | 57516 | 1. 1 (0) | 57516 | 00:00:20.82 | 115K | 2545 |
| 8 2 2 | 4. TABLE ACCESS BY INDEX ROWID | T2 | 57516 | 1. 2 (0) | 57516 | 00:04:37.14 | 57516 | 27138 |
------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
4 filter ((TRUNC ('T1'. "ATTR1") = 1 AND TRUNC ('T1'. " ATTR2') = 1))
5 - access("T1".") FK '= 'T2'.' (ID')
You say here that I canceled a query after about 5 minutes, and looking at the statistics of content (RowSource) I can already say the following:
1. the estimation of cardinality of T1 is far - the optimizer estimated 100 lines, but it actually generated more than 57000 lines when the query was cancelled. If this definitely seems like a candidate at the origin of the problems
2. the query has spent most of the time in search of random table T2
So while it is true that I don't know final A-lines of this cancelled query information, I can still say a lot of this and begin to deal with the problems identified so far.
Randolf
-
Oracle NoSQL YCSB - continuous increase in execution time
Greetings,
I'm testing with YCSB nosql databases. I'm new to this type of databases, but I already tried few of them. I use the VM with 2 GB of RAM and hosted on Win 7. Although it is not recommended, because I work in the environment of capacity now, I use KVlite. But my problem is confusing and I can not find the reason. So, I have successfully loaded data and tested NoSQL Oracle using different workloads. However, each time, I get the higher execution time. For example, if 1 performance I get 20 seconds, if I stopped database and next day run even workload once again, I get 35 second run time and so on.
Do you have an idea of what may be the cause of that? As I said, I did research on some nosql databases, but I've never had that strange results.
Kind regards.
I can't say with certainty why you see the results you have described, probably is just that with every race on the same data store, more data is getting integrated into the KVlite.
It is not a good idea to use KVlite for a test YCSB.
KVlite links to your application instance and does not provide the kind of partitioning of a key space that is normally essential to YCSB workload.
The idea of YCSB is to provide a random workload on a large number of keys and then to make things as expand data store while the operations are happening and see the impact.
These kinds of operations on random data access workloads cannot be expected to scale on a single data store instance that distributes keys.
I suggest that you use an appropriate version of kvstore to run these tests.
Hope this helps,
-Robert
-
calculate statistical performance problems
Hi all
We run statistical calculation on a table that is completely deleted daily, filled and then analyzed. However, the statistical component of calculation takes more and more time each day. The table retains a kind of diary/history of statistics that were calculated before the deleted data? Or is there a reason why statistical calculation on about the same amount of data every day should take longer and longer time? We took 10g.
A few notes:
I can't truncate table because I need to restore in case of problems. I could drop and recreate once if it helps.
Before deleting and filling, I disable all indexes, and then re-create them.
Transfer us about 10 million rows every day in this table.
A year of the entire process (fill + analyze) has taken 3 hours, now it takes 18 hours.
We also got this error on the table: ORA-01555: snapshot too old: rollback segment number with the name ° ORA-02063 too small: before the T_SRC line
This is the script in the procedure:
V_SRC1 estimated T_SRC table on the remote system.execute immediate 'alter index IND_TAB1 unusable'; delete from TAB1; insert /*+ APPEND */ into TAB1 select COL1 ,COL2 from V_SRC1 where change_date between sysdate-1 and sysdate or creation_date between sysdate-1 and sysdate; execute immediate 'alter index IND_TAB1 rebuild'; execute immediate 'analyze table TAB1 compute statistics';
Thank you for the ideas.Hello
When you insert and remove a large amount of data in a table, it breaks and he could accumulate a significant amount of unused disk space. When you perform a full table scan, Oracle scans the segment of the upper limit (HWM) that points to the location of the block used above, i.e. it scans all empty blocks as well. In order to reset the HWM, you can issue ALTER TABLE
MOVE. Despite what the name suggest command, your table will not be moved anywhere, it will simply rebuild and recover any unused free space. If there are all the indexes defined on the table, they would have to rebuild after that as well (ALTER INDEX REBUILD of ). Alternatively, you may consider partitioning by date range (if your license allows it). With partitioning everything would become much simpler:
(1) you load your data into the table and everything check
(2) if it is ok, you just drop the previous partition; Otherwise, restore.With regard to the CALCULATION - it goes through all the data to calculate statistics, instead of using a small sample (in general, a few percentage points). It is slower than the ESTIMATE, and in most cases does not provide any advantage over it.
DBMS_STATS ANALYZE vs - using ANALYZE for the collection of statistics concerning is now obsolete and not recommended. DBMS_STATS offers the same features, and much more, given that your version is 10g you should use DBMS_STATS and not to ANALYZE.
Best regards
Nikolai
Maybe you are looking for
-
I'm trying to see if there is a list of passwords saved for my WIFI in Keychain Access. I need the code of my cell phone on my desk and I don't remember the exact password used, is there a way to do it without resetting the password.
-
Incomplete print only when printing on envelopes
CHARACTERS MISSING / INCOMPLETE (EPSON) PRINTER IS OK ON ALL THE OTHER IMPRESSIONS EPSON SAYS THAT IT IS A PROBLEM OF APPLICATION (MS WORKS 7 TASKBAR)
-
L7480 all-in-One sends white sheet 2 minutes after the print job.
Since the upgrade to Maverick on my imac 21 "new, my HP L7480 all-in-One emits a single sheet of blank paper, 2 minutes after each print job. When a print job has finnished, the screen says that it is still printing. Pressing cancel ejects a sheet bl
-
Whenever my computer restarts, the computer's clock going on at another time. Most of the mornings I resynchronize the time on the computer. Manual synchronization works very well but is annoying. It happened for about 6 months and my internet provi
-
my computer dell laptop has a built-in webcam, but it is not for all Web sites.
On some websites my webcam won't turn. It is on Yahoo and AOL, but other less popular sites on what is wrong. Why?