Join hash Anti-NA
A simple another day at the office...What has been the case.
A colleague contacted me saying that he had two similar queries. One of the data return, the other not.
The "simplified" version of both applications looked like:
SELECT col1
FROM tab1
WHERE col1 NOT IN (SELECT col1 FROM tab2);This was also proved/shown by the second query:
SELECT col1
FROM tab1
WHERE NOT EXISTS
(SELECT col1
FROM tab2
WHERE tab1.col1 = tab2.col1);Even when we have hardcoded extra WHERE clause, the result was the same. No line for:
SELECT *
FROM tab1
WHERE tab1.col1 NOT IN (SELECT col1 FROM tab2)
AND tab1.col1 = 'car';SELECT *
FROM tab1
WHERE NOT EXISTS
(SELECT 1
FROM tab2
WHERE tab1.col1 = tab2.col1)
AND tab1.col1 = 'car';However, there is a difference that I saw, that could be the cause of the problem.
Although the statements are almost the same, the execution plan showed a slight difference. The NOT IN query execution plan looked like:
Plan
SELECT STATEMENT ALL_ROWS Cost: 5 Bytes: 808 Cardinality: 2
3 HASH JOIN ANTI NA Cost: 5 Bytes: 808 Cardinality: 2
1 TABLE ACCESS FULL TABLE PIM_KRG.TAB1 Cost: 2 Bytes: 606 Cardinality: 3
2 TABLE ACCESS FULL TABLE PIM_KRG.TAB2 Cost: 2 Bytes: 404 Cardinality: 2 Plan
SELECT STATEMENT ALL_ROWS Cost: 5 Bytes: 808 Cardinality: 2
3 HASH JOIN ANTI Cost: 5 Bytes: 808 Cardinality: 2
1 TABLE ACCESS FULL TABLE PIM_KRG.TAB1 Cost: 2 Bytes: 606 Cardinality: 3
2 TABLE ACCESS FULL TABLE PIM_KRG.TAB2 Cost: 2 Bytes: 404 Cardinality: 2 Is not knowing what a "HASH JOIN ANTI NA" was exactly, I entered My Oracle Support knowledge base as a search command. In addition to a few lists of patch-set, I also found Document 1082123.1, which explains all about the HASH JOIN ANTI NULL_AWARE.
In this document, the behavior we've seen explained, with the most important is the note:
"*' If t2.n2 contains NULL values, do not return all t1 lines and cancel."
And then it suddenly hit me as I was unable to reproduce the case using my own created test tables.
In our case, this meant that if tab2.col1 would have contained all the rows with a NULL value, the join between the two tables could not be achieved based on a clause 'NOT IN'.
The query would end without any result!
And that's exactly what we saw.
The query with the NOT EXISTS does not use an ANTI NULL_AWARE JOIN and therefore does not return the results
Also the workaround solution mentioned:
alter session set "_optimizer_null_aware_antijoin" = false;Plan
SELECT STATEMENT ALL_ROWS Cost: 4 Bytes: 202 Cardinality: 1
3 FILTER
1 TABLE ACCESS FULL TABLE PIM_KRG.TAB1 Cost: 2 Bytes: 606 Cardinality: 3
2 TABLE ACCESS FULL TABLE PIM_KRG.TAB2 Cost: 2 Bytes: 404 Cardinality: 2 And now?
As a document explaining the behavior, I'm doubting if we can classify this as a bug. But in my opinion, if the developers do not know this strange behavior, they easily call it a bug.
The 'problem' is easily solved (or work around) using the NOT EXISTS or NVL solution with the joined columns. However, I expect the optimizer to sort these things himself.
For all those who want to reproduce/investigate this case, I have listed my test code.
The database version, we used was 11.1.0.7 on Windows 2008 R2. I don't know anyone here of the operating system.
-- Create two tables, make sure they allow NULL values
CREATE TABLE tab1 (col1 VARCHAR2 (100) NULL);
CREATE TABLE tab2 (col1 VARCHAR2 (100) NULL);
INSERT INTO tab1
VALUES ('bike');
INSERT INTO tab1
VALUES ('car');
INSERT INTO tab1
VALUES (NULL);
INSERT INTO tab2
VALUES ('bike');
INSERT INTO tab2
VALUES (NULL);
COMMIT;
-- This query returns No results
SELECT col1
FROM tab1
WHERE col1 NOT IN (SELECT col1 FROM tab2);
-- This query return results
SELECT col1
FROM tab1
WHERE NOT EXISTS
(SELECT col1
FROM tab2
WHERE tab1.col1 = tab2.col1);Anyone who has the true explanation of this behavior as in why the HASH JOIN ANTI takes end. Please give details
Thank you
Kind regards
FJFranken
As you have discovered, NOT IN and EXISTS are NOT the same.
This is expected behavior when comparing with the value NULL.
See:
http://jonathanlewis.WordPress.com/2007/02/25/not-in/
Tags: Database
Similar Questions
-
Always parallel hash join paginate in TEMP
Hello
I've known some strange behaviors on Oracle 9.2.0.5 recently: hash query simple join of two tables - smaller with 16 k records/1 MB in size and more important with 2.5 m records/1.5 GB in size is trading at TEMP at the launch in parallel mode (4 game PQ slaves). What is strange performance series runs as expected - in memory occurs hash join. It should be added that running parallel and series correctly selects smaller table as an intern but parallel query always decides to buffering data source (no matter what is its size).
To be more precise - all the table statistics gathered, I have enough memory PGA assigned to queries (WORKAREA_POLICY_SIZE = AUTO, PGA_AGGREGATE_TARGET = 6 GB) and I analyze the results. Same hidden parameter px_max_size MMSis set correctly to about 2 GB, the problem is that parallel execution still decides to Exchange (even if the internal size of data for each slave is about 220 KB.).
I dig in the footsteps (event 10104) and found a substantial difference between series and parallel execution. It seems that some internal indicator order PQ slaves to the buffer always data, here's what I found in trace slave PQ:
HASH JOIN STATISTICS (INITIALIZATION)
Original brief: 4428800
Memory after all overhead costs: 4283220
Memory for the slot machines: 3809280
Calculated overhead for partitions and slot machine/line managers: 473940
Fan-out hash join: 8
Number of sheets: 9
Number of slots: 15
Diluvium IO: 31
Block size: 8
Cluster size (slot): 248
Join hash fanout (manual): 8
Cluster/slot size (manual): 280
Minimum number of bytes per block: 8160
Bit memory allocation (KB) vector: 128
By partition bit vector length (KB): 16
Possible maximum line length: 1455
Size (KB) of construction found: 645
Estimates the length of the line (including overhead): 167
Immutable flags:
The result of the join of the BUFFER for a parallel query
kxhfSetPhase: phase = BUILD
kxhfAddChunk: Add 0 (sz = 32) piece to the table slot machine
kxhfAddChunk: chunk 0 (lb = 800003ff640ebb50, slotTab = 800003ff640ebce8) successfully added
kxhfSetPhase: phase = PROBE_1
In bold is the part that is not present in serial mode. Unfortunately that I can't find something that could help identify the reason or the definition that drives this behavior :(
Best regards
Bazyli
Published by: user10419027 on October 13, 2008 03:53Buzzylee wrote:
Jonathan,
>
After the trials of today that my understanding of the problem has not significantly changed - I still don't understand why Oracle swaps table of probe on the disc.
The only new, is that I see it's not typical hash join of "on the disk", because the inner table is not written to TEMP. More you confirmed this immutable flag is not forcing this kind of behavior (BTW, thanks for that!).So maybe that's the bug? In the meantime, I checked it against never version of DB (9.2.0.8) - always the same behavior.
I copied your example - the behavior also appears in 10g and 11g.
This probably isn't a bug, but it may be a case where a generic strategy is not appropriate.The extra partition does NOT probe table, now is the result of the hash join. The result is built until this draft is sent to the next 'series of slave' (who is being the Coordinator of the application in this case). Your allocation of memory allowed for about 18 slots (diluvium IO lots) of 31 blocks each. You used 8 of them for the hash table, the rest is available to hold the result.
Somewhere in your path, around the point where you go from scripture readings, you should see a summary on the partition 8 and set the number of "memory seats" that will tell you the size of the result.
If the difference between the clusters and the slots in the memory is low, you can see that by setting the '_hash_multiblock_io_count' to a value less than 31 than the selected optimizer free you enough memory for the hash table for the result set to build in memory.
Another option - to circumvent this spill - is to switch to a (broadcast, none) distribution.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK -
Hi experts,
When any type of join (hash join, merge join), please correct me if I'm wrong, first Oracle have to store all data for the other set of data, right join operation? Where do I store it? PGA is used for this operation? In other words, say that optimizer use the hash join method, (in-memory hash table must be built for this operation), he built in PGA or CMS?
If it's in the PGA, what happens if the sorted data set will not match the memory?
Thank you
basically: Yes.
If the input set is less than the value (explicitly defined or assigned automatically) for hash_area_size, then the hash join is made in memory of the PGA (as best of activities execution). If the game is bigger, it is necessary to empty the intermediate result in TEMP tablespace (causing onepass or operations activities even multipass). Jonathan Lewis described the mechanism in detail cost base fundamental Oracle.
-
Join the execution of several Tables Plan
Try to understand the query execution plan:
So he needs to MERGE between DEPARTMENTS (that has been sorted by index) JOIN and (here's the part confusing...) LOCATIONS including oracle used HASH JOIN (?) to bring the information from and then sort the opinion generated by the system that has been created...?HR> SELECT e.last_name , d.department_name, l.city 2 FROM employees e, departments d , locations l 3 WHERE e.department_id = d.department_id 4 AND 5 d.location_id = l.location_id; Execution Plan ---------------------------------------------------------- Plan hash value: 1235509609 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 106 | 4346 | 9 (23)| 00:00:01 | |* 1 | HASH JOIN | | 106 | 4346 | 9 (23)| 00:00:01 | | 2 | MERGE JOIN | | 27 | 837 | 6 (34)| 00:00:01 | | 3 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 513 | 2 (0)| 00:00:01 | | 4 | INDEX FULL SCAN | DEPT_LOCATION_IX | 27 | | 1 (0)| 00:00:01 | |* 5 | SORT JOIN | | 23 | 276 | 4 (50)| 00:00:01 | | 6 | VIEW | index$_join$_003 | 23 | 276 | 3 (34)| 00:00:01 | |* 7 | HASH JOIN | | | | | | | 8 | INDEX FAST FULL SCAN | LOC_CITY_IX | 23 | 276 | 1 (0)| 00:00:01 | | 9 | INDEX FAST FULL SCAN | LOC_ID_PK | 23 | 276 | 1 (0)| 00:00:01 | | 10 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1070 | 3 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------
Is that this HASH JOIN to step 7 only refers to a view that is generated by the system that oracle had to sort and not actually HASH JOIN
between two tables?
Thanks much for you patienceHello
Perhaps, it helps to understand things better if we walk in the plan.
Plans have a hierarchical structure (which is translated graphically by fingerprints). Operating needs parent all the children completed operations before it can do its job (which is generally combining lines with children in one way or another).
Another point is that joins can have anything like their entries, tables not only. That is a hash join can join an index for an index or a table to an index, or then to join a table results of hash one another and so on and so forth.
With this in mind, we can go back on what is happening here step by step:
The needs of the join by hash (1) (2) and (10) to finish. (10) is a basic operation, since a table scan depends on nothing else, but merge join handset (2) (3) and (5), who both are complex operations (i.e. dependent on one or more children). Specifically, lines (3) from the DEPARTMENTS table using ROWID obtained from a full analysis of the index of DEPT_LOCATION_IX (4), (5) is simply lines join hash (7) and sorted in the order required.
I hope this helps.
Best regards
NikolaiPublished by: Nikolay Savvinov on January 26, 2012 05:26
-
Optimizer how SQL prefer a kind of join method on other
Hello
I use Oracle version 10.2.0.3.
I have a question, how the oracle SQL optimizer decides that to three different types of joins (hash join, sort Merge nested loop join join) which meet the method to be applied to a particular place?
How etc it done before opting for a particular mode of join?
I read below, the oracle documentation.
Because the default purpose of the cost-based approach is better throughput, the optimizer chooses an operation of nested loops, a merge sort operation or a hash operation in order to join these tables, which are likely to return all of the rows selected by the query faster in function.
But how oracle decides that which join method will return lines "QUICKLY"?
Thanks in advance.
oratest
Published by: oratest on August 10, 2010 01:57oratest wrote:
HelloI use Oracle version 10.2.0.3.
I have a question, how the oracle SQL optimizer decides that to three different types of joins (hash join, sort Merge nested loop join join) which meet the method to be applied to a particular place?
How etc it done before opting for a particular mode of join?
I read below, the oracle documentation.
Because the default purpose of the cost-based approach is better throughput, the optimizer chooses an operation of nested loops, a merge sort operation or a hash operation in order to join these tables, which are likely to return all of the rows selected by the query faster in function.
But how oracle decides that which join method will return lines "QUICKLY"?
According to me, this quote can be found here:
http://download.Oracle.com/docs/CD/A97630_01/server.920/a96533/hintsref.htm#5655Optimizer of Oracle does not necessarily on which will be return lines more quickly, but rather what join method will have the lowest calculated (estimated) cost. There is, however, a correlation between the calculated cost and estimated time. This calculation is visible by reviewing a trace 10053 for a query. For example:
... NL Join Outer table: Card: 255.00 Cost: 61.50 Resp: 61.50 Degree: 1 Bytes: 26 Inner table: T1 Alias: L Access Path: TableScan NL Join: Cost: 94237.11 Resp: 94237.11 Degree: 0 Cost_io: 89563.00 Cost_cpu: 19435977712 Resp_io: 89563.00 Resp_cpu: 19435977712 OPTIMIZER PERCENT INDEX CACHING = 100 Access Path: index (RangeScan) Index: SYS_C004736 resc_io: 4.00 resc_cpu: 42152 ix_sel: 1.6903e-004 ix_sel_with_filters: 1.6903e-004 NL Join: Cost: 266.02 Resp: 266.02 Degree: 1 Cost_io: 262.00 Cost_cpu: 16710000 Resp_io: 262.00 Resp_cpu: 16710000 OPTIMIZER PERCENT INDEX CACHING = 100 Access Path: index (AllEqJoin) Index: T1_IND2 resc_io: 335.00 resc_cpu: 3580792 ix_sel: 0.015748 ix_sel_with_filters: 0.015748 NL Join: Cost: 17190.42 Resp: 17190.42 Degree: 1 Cost_io: 17143.00 Cost_cpu: 197180657 Resp_io: 17143.00 Resp_cpu: 197180657 Best NL cost: 266.02 resc: 266.02 resc_io: 262.00 resc_cpu: 16710000 resp: 266.02 resp_io: 262.00 resp_cpu: 16710000 Join Card: 0.09 = outer (255.00) * inner (812.91) * sel (4.2166e-007) Join cardinality for HJ/SMJ (no post filters): 34.96, outer: 255.00, inner: 812.91, sel: 1.6867e-004 Join Card - Rounded: 1 Computed: 0.09 SM Join Outer table: resc: 61.50 card 255.00 bytes: 26 deg: 1 resp: 61.50 Inner table: T1 Alias: L resc: 67.77 card: 812.91 bytes: 32 deg: 1 resp: 67.77 using dmeth: 2 #groups: 1 SORT resource Sort statistics Sort width: 598 Area size: 1048576 Max Area size: 104857600 Degree: 1 Blocks to Sort: 2 Row size: 39 Total Rows: 255 Initial runs: 1 Merge passes: 0 IO Cost / pass: 0 Total IO sort cost: 0 Total CPU sort cost: 4250063 Total Temp space used: 0 SORT resource Sort statistics Sort width: 598 Area size: 1048576 Max Area size: 104857600 Degree: 1 Blocks to Sort: 5 Row size: 46 Total Rows: 813 Initial runs: 1 Merge passes: 0 IO Cost / pass: 0 Total IO sort cost: 0 Total CPU sort cost: 4512317 Total Temp space used: 0 SM join: Resc: 131.38 Resp: 131.38 [multiMatchCost=0.00] SM cost: 131.38 resc: 131.38 resc_io: 125.60 resc_cpu: 24044481 resp: 131.38 resp_io: 125.60 resp_cpu: 24044481 SM Join (with index on outer) Access Path: index (FullScan) Index: SYS_C004653 resc_io: 441.00 resc_cpu: 17604740 ix_sel: 1 ix_sel_with_filters: 1 Cost: 89.05 Resp: 89.05 Degree: 1 Outer table: resc: 89.05 card 255.00 bytes: 26 deg: 1 resp: 89.05 Inner table: T1 Alias: L resc: 67.77 card: 812.91 bytes: 32 deg: 1 resp: 67.77 using dmeth: 2 #groups: 1 SORT resource Sort statistics Sort width: 598 Area size: 1048576 Max Area size: 104857600 Degree: 1 Blocks to Sort: 5 Row size: 46 Total Rows: 813 Initial runs: 1 Merge passes: 0 IO Cost / pass: 0 Total IO sort cost: 0 Total CPU sort cost: 4512317 Total Temp space used: 0 SM join: Resc: 157.91 Resp: 157.91 [multiMatchCost=0.00] HA Join Outer table: resc: 61.50 card 255.00 bytes: 26 deg: 1 resp: 61.50 Inner table: T1 Alias: L resc: 67.77 card: 812.91 bytes: 32 deg: 1 resp: 67.77 using dmeth: 2 #groups: 1 Cost per ptn: 0.53 #ptns: 1 hash_area: 0 (max=256) Hash join: Resc: 129.80 Resp: 129.80 [multiMatchCost=0.00] HA cost: 129.80 resc: 129.80 resc_io: 125.60 resc_cpu: 17480759 resp: 129.80 resp_io: 125.60 resp_cpu: 17480759 Best:: JoinMethod: Hash Cost: 129.80 Degree: 1 Resp: 129.80 Card: 0.09 Bytes: 58As it is apparent from the foregoing, a hash join was the lowest calculated cost to 129,80, the cost calculated for the nested loop join was 266,02, and the merge join and sort had a cost calculated between the two. If you want to learn more about traces of 10053 pick up a copy of the book "basic Oracle cost-based. Interestingly, the author of this book has recently proposed that all the joints are actually nested loops joins just with different start-up costs. See the following blog post:
http://jonathanlewis.WordPress.com/2010/08/02/joins/Charles Hooper
Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
http://hoopercharles.WordPress.com/
IT Manager/Oracle DBA
K & M-making Machine, Inc. -
Hi all
I use under version
Connected to Oracle Database 11g Express Edition Release 11.2.0.2.0
SQL > SELECT DEPTNO
DEPT 2
3. WHERE DEPTNO! = ALL
4 (DEPTNO SELECT FROM EMP WHERE DEPTNO IS NOT NULL);
DEPTNO
----------
40
Execution plan
----------------------------------------------------------
Hash value of plan: 474461924
---------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4. 104. 5 (20) | 00:00:01 |
|* 1 | HASH ANTI JOIN | | 4. 104. 5 (20) | 00:00:01 |
| 2. TABLE ACCESS FULL | DEPT | 4. 52. 2 (0) | 00:00:01 |
|* 3 | TABLE ACCESS FULL | EMP | 14. 182. 2 (0) | 00:00:01 |
---------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access ("DEPTNO" ="DEPTNO")
3 - filter ("DEPTNO" IS NOT NULL)
Note
-----
-dynamic sample used for this survey (level = 2)
----------------------------------------------------------------------------------------------------
SQL > SELECT DEPTNO FROM DEPT
2. IF YOU USE NOT IN DEPTNO (DEPTNO SELECT FROM EMP WHERE DEPTNO IS NOT NULL);
DEPTNO
----------
40
Execution plan
----------------------------------------------------------
Hash value of plan: 474461924
---------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4. 104. 5 (20) | 00:00:01 |
|* 1 | HASH ANTI JOIN | | 4. 104. 5 (20) | 00:00:01 |
| 2. TABLE ACCESS FULL | DEPT | 4. 52. 2 (0) | 00:00:01 |
|* 3 | TABLE ACCESS FULL | EMP | 14. 182. 2 (0) | 00:00:01 |
---------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access ("DEPTNO" ="DEPTNO")
3 - filter ("DEPTNO" IS NOT NULL)
Note
-----
-dynamic sample used for this survey (level = 2)
--------------------------------------------------------------------------------------------------
SQL > SELECT DEPTNO
DEPT 2
3. WHERE THERE IS NO
4 (SELECT * FROM EMP WHERE EMP.) DEPTNO = DEPT. DEPTNO);
DEPTNO
----------
40
Execution plan
----------------------------------------------------------
Hash value of plan: 474461924
---------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4. 104. 5 (20) | 00:00:01 |
|* 1 | HASH ANTI JOIN | | 4. 104. 5 (20) | 00:00:01 |
| 2. TABLE ACCESS FULL | DEPT | 4. 52. 2 (0) | 00:00:01 |
| 3. TABLE ACCESS FULL | EMP | 14. 182. 2 (0) | 00:00:01 |
---------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("EMP".") DEPTNO "=" DEPT ". ("' DEPTNO ')
Note
-----
-dynamic sample used for this survey (level = 2)
My doubt is as all the query 3 generates even explain plan
Can we consider that all queries to be the same as in the review of the performance.
Thank you
NOT IN and EXISTS are not the same. If there is only one NULL value in the sub query used with NOT IN then any condition fails.
Here is a note of AskTom on this topic
https://asktom.Oracle.com/pls/Apex/f?p=100:11:0:P11_QUESTION_ID:442029737684
-
Unable to understand the Plan to explain
Hi gurus
I'm trying to understand some basics of explain plan and get a hard time, I was reading the book tuning performance and incapable of understanding explain plan for the following query:
Example query
EXPLAIN PLAN FOR
SELECT *.
WCP
WHERE THERE IS NOT (SELECT 0
OF THE Department
WHERE dept.dname = 'SALES' AND dept.deptno = emp.deptno)
AND NOT EXISTS (SELECT 0
Bonus OF
WHERE bonus.ename = emp.ename);
-------------------
Select * from table (dbms_xplan.display);
---------------
Output
Hash value of plan: 734347697
-----------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5. 290. 7 (15) | 00:00:01 |
|* 1 | HASH ANTI JOIN | | 5. 290. 7 (15) | 00:00:01 |
|* 2 | HASH ANTI JOIN | | 5. 255. 5 (20) | 00:00:01 |
| 3. TABLE ACCESS FULL | EMP | 14. 532. 2 (0) | 00:00:01 |
|* 4 | TABLE ACCESS FULL | DEPT | 1. 13. 2 (0) | 00:00:01 |
| 5. TABLE ACCESS FULL | BONUS | 1. 7. 2 (0) | 00:00:01 |
-----------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("BONUS".") ENAME "=" EMP ". ("' ENAME ')
2 - access("DEPT".") DEPTNO "=" EMP ". ("' DEPTNO ')
4 - filter("DEPT".") DNAME "= 'SALES')
-------------------------
Grateful if someone help out me. Thank you
In addition, I really appreciate if someone proposes a simple tutorial to explain plan. Thanks again
Concerning
Shu
Hi Shuumail,
Here is the tutorial http://allthingsoracle.com/execution-plans-part-1-finding-plans/
-
Hello all: I have a small question:
What exactly is the SQL tuning advisor advising me to do? Usually he will specify to create an index or something similar, but I'll have trouble deciphering the underside of deliberation.
Thanks for your help and have a great day!
Aqua
Profile search SQL (see explain the plans below)
--------------------------------------------------------
A potentially better execution plan found for this statement.
Recommendation (estimated delivery < = 10%)
---------------------------------------
-Consider accepting the recommended SQL profile.
run dbms_sqltune.accept_sql_profile (task_name = > 'staName20789',)
replace = > TRUE);
------------------------------------------------------------------------------
EXPLAIN SECTION PLANES
-------------------------------------------------------------------------------
1 original
-----------
Hash value of plan: 2311080268
------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1052 | 99K| | 730 (3)| 00:00:09 | | 1 | HASH GROUP BY | | 1052 | 99K| | 730 (3)| 00:00:09 | |* 2 | HASH JOIN OUTER | | 1052 | 99K| | 729 (2)| 00:00:09 | |* 3 | FILTER | | | | | | | |* 4 | HASH JOIN OUTER | | 572 | 40040 | | 275 (3)| 00:00:04 | |* 5 | HASH JOIN RIGHT ANTI | | 362 | 20634 | | 223 (4)| 00:00:03 | | 6 | VIEW | MEDICAL_LEAVE | 125 | 625 | | 103 (4)| 00:00:02 | | 7 | VIEW | | 125 | 6625 | | 103 (4)| 00:00:02 | |* 8 | FILTER | | | | | | | |* 9 | HASH JOIN OUTER | | 125 | 8750 | | 103 (4)| 00:00:02 | | 10 | VIEW | | 94 | 5358 | | 69 (3)| 00:00:01 | |* 11 | FILTER | | | | | | | |* 12 | HASH JOIN OUTER | | 94 | 2632 | | 69 (3)| 00:00:01 | |* 13 | TABLE ACCESS FULL | EMP_LEAVE | 60 | 900 | | 17 (6)| 00:00:01 | | 14 | TABLE ACCESS FULL | EMP_CONTRACT | 11156 | 141K| | 52 (2)| 00:00:01 | | 15 | TABLE ACCESS FULL | POSITION_OFFERED | 9420 | 119K| | 33 (4)| 00:00:01 | |* 16 | HASH JOIN | | 376 | 19552 | | 119 (2)| 00:00:02 | |* 17 | TABLE ACCESS FULL | POSITION_OFFERED | 376 | 6392 | | 33 (4)| 00:00:01 | |* 18 | TABLE ACCESS FULL | AMPEMP | 2579 | 90265 | | 86 (2)| 00:00:02 | | 19 | TABLE ACCESS FULL | EMP_CONTRACT | 11156 | 141K| | 52 (2)| 00:00:01 | | 20 | VIEW | | 4572 | 120K| | 453 (2)| 00:00:06 | | 21 | HASH GROUP BY | | 4572 | 825K| 1992K| 453 (2)| 00:00:06 | | 22 | VIEW | | 4572 | 825K| | 265 (2)| 00:00:04 | | 23 | MERGE JOIN PARTITION OUTER| | 4572 | 263K| | 265 (2)| 00:00:04 | | 24 | SORT JOIN | | 18 | 774 | | 4 (25)| 00:00:01 | | 25 | TABLE ACCESS FULL | LU_MED_IMMUNO | 18 | 774 | | 3 (0)| 00:00:01 | |* 26 | SORT PARTITION JOIN | | 2731 | 43696 | | 6 (17)| 00:00:01 | | 27 | TABLE ACCESS FULL | MED_IMMUNO | 2731 | 43696 | | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------
Name of the query block / Alias object (identified by the operation identity card):
-------------------------------------------------------------
1 SALT$ DD824119
6 SALT$ 12 / ML@SEL$7
7 - SALT$ CCA5E655 / from$_subquery$_020@SEL$12
8 SALT$ CCA5E655
10 - SALT$ A0D20652 / from$_subquery$_018@SEL$11
11 SALT$ A0D20652
13 SALT$ A0D20652 / EL@SEL$9
14 SALT$ A0D20652 / EC@SEL$8
15 SALT$ CCA5E655 / PO@SEL$10
17 SALT$ DD824119 / PO@SEL$3
18 SALT$ DD824119 / AE@SEL$4
19 SALT$ DD824119 / EC@SEL$5
20 SALT$ 16 / BT@SEL$1
21 SALT$ 16
22 - SALT$ 15 / from$_subquery$_003@SEL$16
23 SALT $15
25 SALT$ 15 / LMI@SEL$15
27 SALT$ 15 / MI@SEL$15
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("AE".") EMP_ID '=' BT '. "EMP_ID" (+)) "
3 - filter("EC".") (ACTUAL_END"IS NULL)
4 - access("AE".") EMP_ID '=' EC '. "EMP_ID" (+)) "
5 - access("AE".") EMP_ID '=' ML '. ("' EMP_ID ')
8 - filter("PO".") (ACTUAL_END"IS NULL)
9 - access("PO".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
11 - filter("EC".") (ACTUAL_END"IS NULL)
12 - access("EC".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
13 - filter("EL".") LEAVE_END' IS NULL AND 'EL '. "LEAVE_TYPE"= 6)
16 - access("AE".") EMP_ID '=' PO '. ("' EMP_ID ')
17 - filter("PO".") ACTUAL_END' IS NULL AND 'PO '. ("' HOUSED <>' 30)
18 - filter("AE".") (CITIZENSHIP", <>1)
26 - access("LMI".") WITH THE ID '=' MI '. ("' IMM_REC")
filter ("LMI". "WITH THE '=' MI' ID '." " IMM_REC')
Projection of the column information (identified by the operation identity card):
-----------------------------------------------------------
1 (#keys = 3) "AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35], MAX (DECODE (TO_CHAR ("BT" "."))) " ID'), '1', TO_CHAR (INTERNAL_FUNCTION ("BT". "MY
((XDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '2', TO_CHAR (INTERNAL_FUNCTION ("BT"." ""
(('MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "3", TO_CHAR (INTERNAL_FUNCTION ("B
« « « T ». » ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '5', TO_CHAR (INTERNAL_FUNCTION" ""
('BT'. (((("' MAXDATE '), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "6", TO_CHAR (INTERNAL_FUNCT
ION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11], MAX (DECODE (TO_CHAR ("BT"." ID"),"8", TO_CHAR (INTERNAL_FU
FUNCTION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11],"
MAX (DECODE (TO_CHAR ("BT". "ID"), "9", TO_CHAR (INTERNAL_FUNCTION ("BT"." ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11
], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '10', TO_CHAR (INTERNAL_FUNCTION ("BT"." "" (MAXDATE'), 'DD-MON-YYYY'), NULL)
) [11].
2. (#keys = 1) "AE". "LAST_NAME" [VARCHAR2, 45], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], 'BT' "." " MAXDATE "[DATE, 7], 'BT'". "" ID '[NUMBER, 22].
3. "AE". "EMP_ID" [NO.22], "Æ" "." " LAST_NAME "[VARCHAR2, 45],"Æ"". "" FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11].
4. (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35], "Æ" "." " CLOCK_NUMBER "[VARCHAR2, 11], 'CBS'". "" ACTUAL_END "[DATE, 7].
5 (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45].
6 ' ML '. ' EMP_ID '[NUMBER, 22].
7. "EL". ' EMP_ID '[NUMBER, 22].
8. "EL". ' EMP_ID '[NUMBER, 22].
9. (#keys = 1) 'EL '. "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
10. "EL". ' EMP_ID '[NUMBER, 22].
11. "EL". ' EMP_ID '[NUMBER, 22].
12. (#keys = 1) 'EL '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
13. "EL". ' EMP_ID '[NUMBER, 22].
14. 'EC '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
15. "PO." "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
16. (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER ' [VARCHAR2, 11],
"AE". "LAST_NAME" [VARCHAR2, 45], "Æ" "." " FIRST NAME ' [VARCHAR2, 35].
17 "IN." ' EMP_ID '[NUMBER, 22].
18. "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER "[VARCHAR2, 11],"Æ"". "" LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35].
19. "EC". "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
20. "BT". "EMP_ID" [NO.22], 'BT' "." " ID "[NO.22], 'BT'". "" MAXDATE '[DATE, 7].
21. (#keys = 6) "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" DSB "[NO.22], MAX ("IMM_DATE") [7]"
22. "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55],"LMI"". "" SERIES "[VARCHAR2, 55],"IMM_DATE "[DATE, 7]"
23. (#keys = 0) "LMI". "ID" [NO.22], 'MI' "." " EMP_ID "[NO.22],"LMI"". "" SERIES "[VARCHAR2, 55],
"LMI". "IMM_DESC" [VARCHAR2, 55], "LMI" "." " DSB "[NO.22],"LMI"". "" DRUG "[VARCHAR2, 55],
"MI". "IMM_DATE"[DATE, 7].
24. (#keys = 1) "LMI". "ID" [NO.22], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55].
25. "DIA." "ID" [NO.22], "LMI" "." " IMM_DESC "[VARCHAR2, 55],"LMI"". "" DSB '[NUMBER, 22],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55].
26. (#keys = 1) "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
27. "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
2 original with adjusted
------------------------------
Hash value of plan: 2311080268
------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 151 | 14647 | | 730 (3)| 00:00:09 | | 1 | HASH GROUP BY | | 151 | 14647 | | 730 (3)| 00:00:09 | |* 2 | HASH JOIN OUTER | | 151 | 14647 | | 729 (2)| 00:00:09 | |* 3 | FILTER | | | | | | | |* 4 | HASH JOIN OUTER | | 14 | 980 | | 275 (3)| 00:00:04 | |* 5 | HASH JOIN RIGHT ANTI | | 9 | 513 | | 223 (4)| 00:00:03 | | 6 | VIEW | MEDICAL_LEAVE | 21 | 105 | | 103 (4)| 00:00:02 | | 7 | VIEW | | 21 | 1113 | | 103 (4)| 00:00:02 | |* 8 | FILTER | | | | | | | |* 9 | HASH JOIN OUTER | | 21 | 1470 | | 103 (4)| 00:00:02 | | 10 | VIEW | | 332 | 18924 | | 69 (3)| 00:00:01 | |* 11 | FILTER | | | | | | | |* 12 | HASH JOIN OUTER | | 332 | 9296 | | 69 (3)| 00:00:01 | |* 13 | TABLE ACCESS FULL | EMP_LEAVE | 210 | 3150 | | 17 (6)| 00:00:01 | | 14 | TABLE ACCESS FULL | EMP_CONTRACT | 11156 | 141K| | 52 (2)| 00:00:01 | | 15 | TABLE ACCESS FULL | POSITION_OFFERED | 9420 | 119K| | 33 (4)| 00:00:01 | |* 16 | HASH JOIN | | 376 | 19552 | | 119 (2)| 00:00:02 | |* 17 | TABLE ACCESS FULL | POSITION_OFFERED | 376 | 6392 | | 33 (4)| 00:00:01 | |* 18 | TABLE ACCESS FULL | AMPEMP | 2579 | 90265 | | 86 (2)| 00:00:02 | | 19 | TABLE ACCESS FULL | EMP_CONTRACT | 11156 | 141K| | 52 (2)| 00:00:01 | | 20 | VIEW | | 4572 | 120K| | 453 (2)| 00:00:06 | | 21 | HASH GROUP BY | | 4572 | 825K| 1992K| 453 (2)| 00:00:06 | | 22 | VIEW | | 4572 | 825K| | 265 (2)| 00:00:04 | | 23 | MERGE JOIN PARTITION OUTER| | 4572 | 263K| | 265 (2)| 00:00:04 | | 24 | SORT JOIN | | 18 | 774 | | 4 (25)| 00:00:01 | | 25 | TABLE ACCESS FULL | LU_MED_IMMUNO | 18 | 774 | | 3 (0)| 00:00:01 | |* 26 | SORT PARTITION JOIN | | 2731 | 43696 | | 6 (17)| 00:00:01 | | 27 | TABLE ACCESS FULL | MED_IMMUNO | 2731 | 43696 | | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------
Name of the query block / Alias object (identified by the operation identity card):
-------------------------------------------------------------
1 SALT$ DD824119
6 SALT$ 12 / ML@SEL$7
7 - SALT$ CCA5E655 / from$_subquery$_020@SEL$12
8 SALT$ CCA5E655
10 - SALT$ A0D20652 / from$_subquery$_018@SEL$11
11 SALT$ A0D20652
13 SALT$ A0D20652 / EL@SEL$9
14 SALT$ A0D20652 / EC@SEL$8
15 SALT$ CCA5E655 / PO@SEL$10
17 SALT$ DD824119 / PO@SEL$3
18 SALT$ DD824119 / AE@SEL$4
19 SALT$ DD824119 / EC@SEL$5
20 SALT$ 16 / BT@SEL$1
21 SALT$ 16
22 - SALT$ 15 / from$_subquery$_003@SEL$16
23 SALT $15
25 SALT$ 15 / LMI@SEL$15
27 SALT$ 15 / MI@SEL$15
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("AE".") EMP_ID '=' BT '. "EMP_ID" (+)) "
3 - filter("EC".") (ACTUAL_END"IS NULL)
4 - access("AE".") EMP_ID '=' EC '. "EMP_ID" (+)) "
5 - access("AE".") EMP_ID '=' ML '. ("' EMP_ID ')
8 - filter("PO".") (ACTUAL_END"IS NULL)
9 - access("PO".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
11 - filter("EC".") (ACTUAL_END"IS NULL)
12 - access("EC".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
13 - filter("EL".") LEAVE_END' IS NULL AND 'EL '. "LEAVE_TYPE"= 6)
16 - access("AE".") EMP_ID '=' PO '. ("' EMP_ID ')
17 - filter("PO".") ACTUAL_END' IS NULL AND 'PO '. ("' HOUSED <>' 30)
18 - filter("AE".") (CITIZENSHIP", <>1)
26 - access("LMI".") WITH THE ID '=' MI '. ("' IMM_REC")
filter ("LMI". "WITH THE '=' MI' ID '." " IMM_REC')
Projection of the column information (identified by the operation identity card):
-----------------------------------------------------------
1 (#keys = 3) "AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35], MAX (DECODE (TO_CHAR ("BT" "."))) " ID'), '1', TO_CHAR (INTERNAL_FUNCTION ("BT". "MY
((XDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '2', TO_CHAR (INTERNAL_FUNCTION ("BT"." ""
(('MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "3", TO_CHAR (INTERNAL_FUNCTION ("B
« « « T ». » ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '5', TO_CHAR (INTERNAL_FUNCTION" ""
('BT'. (((("' MAXDATE '), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "6", TO_CHAR (INTERNAL_FUNCT
ION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11], MAX (DECODE (TO_CHAR ("BT"." ID"),"8", TO_CHAR (INTERNAL_FU
FUNCTION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11],"
MAX (DECODE (TO_CHAR ("BT". "ID"), "9", TO_CHAR (INTERNAL_FUNCTION ("BT"." ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11
], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '10', TO_CHAR (INTERNAL_FUNCTION ("BT"." "" (MAXDATE'), 'DD-MON-YYYY'), NULL)
) [11].
2. (#keys = 1) "AE". "LAST_NAME" [VARCHAR2, 45], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], 'BT' "." " MAXDATE "[DATE, 7], 'BT'". "" ID '[NUMBER, 22].
3. "AE". "EMP_ID" [NO.22], "Æ" "." " LAST_NAME "[VARCHAR2, 45],"Æ"". "" FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11].
4. (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35], "Æ" "." " CLOCK_NUMBER "[VARCHAR2, 11], 'CBS'". "" ACTUAL_END "[DATE, 7].
5 (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45].
6 ' ML '. ' EMP_ID '[NUMBER, 22].
7. "EL". ' EMP_ID '[NUMBER, 22].
8. "EL". ' EMP_ID '[NUMBER, 22].
9. (#keys = 1) 'EL '. "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
10. "EL". ' EMP_ID '[NUMBER, 22].
11. "EL". ' EMP_ID '[NUMBER, 22].
12. (#keys = 1) 'EL '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
13. "EL". ' EMP_ID '[NUMBER, 22].
14. 'EC '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
15. "PO." "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
16. (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER ' [VARCHAR2, 11],
"AE". "LAST_NAME" [VARCHAR2, 45], "Æ" "." " FIRST NAME ' [VARCHAR2, 35].
17 "IN." ' EMP_ID '[NUMBER, 22].
18. "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER "[VARCHAR2, 11],"Æ"". "" LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35].
19. "EC". "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
20. "BT". "EMP_ID" [NO.22], 'BT' "." " ID "[NO.22], 'BT'". "" MAXDATE '[DATE, 7].
21. (#keys = 6) "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" DSB "[NO.22], MAX ("IMM_DATE") [7]"
22. "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55],"LMI"". "" SERIES "[VARCHAR2, 55],"IMM_DATE "[DATE, 7]"
23. (#keys = 0) "LMI". "ID" [NO.22], 'MI' "." " EMP_ID "[NO.22],"LMI"". "" SERIES "[VARCHAR2, 55],
"LMI". "IMM_DESC" [VARCHAR2, 55], "LMI" "." " DSB "[NO.22],"LMI"". "" DRUG "[VARCHAR2, 55],
"MI". "IMM_DATE"[DATE, 7].
24. (#keys = 1) "LMI". "ID" [NO.22], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55].
25. "DIA." "ID" [NO.22], "LMI" "." " IMM_DESC "[VARCHAR2, 55],"LMI"". "" DSB '[NUMBER, 22],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55].
26. (#keys = 1) "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
27. "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
3. using SQL profile
--------------------
Hash value of plan: 1010297951
------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 151 | 14647 | | 704 (2)| 00:00:09 | | 1 | HASH GROUP BY | | 151 | 14647 | | 704 (2)| 00:00:09 | |* 2 | HASH JOIN OUTER | | 151 | 14647 | | 703 (2)| 00:00:09 | |* 3 | FILTER | | | | | | | | 4 | NESTED LOOPS OUTER | | 14 | 980 | | 250 (3)| 00:00:03 | |* 5 | HASH JOIN RIGHT ANTI | | 9 | 513 | | 223 (4)| 00:00:03 | | 6 | VIEW | MEDICAL_LEAVE | 21 | 105 | | 103 (4)| 00:00:02 | | 7 | VIEW | | 21 | 1113 | | 103 (4)| 00:00:02 | |* 8 | FILTER | | | | | | | |* 9 | HASH JOIN OUTER | | 21 | 1470 | | 103 (4)| 00:00:02 | | 10 | VIEW | | 332 | 18924 | | 69 (3)| 00:00:01 | |* 11 | FILTER | | | | | | | |* 12 | HASH JOIN OUTER | | 332 | 9296 | | 69 (3)| 00:00:01 | |* 13 | TABLE ACCESS FULL | EMP_LEAVE | 210 | 3150 | | 17 (6)| 00:00:01 | | 14 | TABLE ACCESS FULL | EMP_CONTRACT | 11156 | 141K| | 52 (2)| 00:00:01 | | 15 | TABLE ACCESS FULL | POSITION_OFFERED | 9420 | 119K| | 33 (4)| 00:00:01 | |* 16 | HASH JOIN | | 376 | 19552 | | 119 (2)| 00:00:02 | |* 17 | TABLE ACCESS FULL | POSITION_OFFERED | 376 | 6392 | | 33 (4)| 00:00:01 | |* 18 | TABLE ACCESS FULL | AMPEMP | 2579 | 90265 | | 86 (2)| 00:00:02 | | 19 | TABLE ACCESS BY INDEX ROWID| EMP_CONTRACT | 2 | 26 | | 3 (0)| 00:00:01 | |* 20 | INDEX RANGE SCAN | EC_INDEX1 | 2 | | | 1 (0)| 00:00:01 | | 21 | VIEW | | 4572 | 120K| | 453 (2)| 00:00:06 | | 22 | HASH GROUP BY | | 4572 | 825K| 1992K| 453 (2)| 00:00:06 | | 23 | VIEW | | 4572 | 825K| | 265 (2)| 00:00:04 | | 24 | MERGE JOIN PARTITION OUTER| | 4572 | 263K| | 265 (2)| 00:00:04 | | 25 | SORT JOIN | | 18 | 774 | | 4 (25)| 00:00:01 | | 26 | TABLE ACCESS FULL | LU_MED_IMMUNO | 18 | 774 | | 3 (0)| 00:00:01 | |* 27 | SORT PARTITION JOIN | | 2731 | 43696 | | 6 (17)| 00:00:01 | | 28 | TABLE ACCESS FULL | MED_IMMUNO | 2731 | 43696 | | 5 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------
Name of the query block / Alias object (identified by the operation identity card):
-------------------------------------------------------------
1 SALT$ DD824119
6 SALT$ 12 / ML@SEL$7
7 - SALT$ CCA5E655 / from$_subquery$_020@SEL$12
8 SALT$ CCA5E655
10 - SALT$ A0D20652 / from$_subquery$_018@SEL$11
11 SALT$ A0D20652
13 SALT$ A0D20652 / EL@SEL$9
14 SALT$ A0D20652 / EC@SEL$8
15 SALT$ CCA5E655 / PO@SEL$10
17 SALT$ DD824119 / PO@SEL$3
18 SALT$ DD824119 / AE@SEL$4
19 SALT$ DD824119 / EC@SEL$5
20 SALT$ DD824119 / EC@SEL$5
21 SALT$ 16 / BT@SEL$1
22 SALT$ 16
23 - SALT$ 15 / from$_subquery$_003@SEL$16
24 SALT $15
26 SALT$ 15 / LMI@SEL$15
28. THE SALT $15 / MI@SEL$15
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("AE".") EMP_ID '=' BT '. "EMP_ID" (+)) "
3 - filter("EC".") (ACTUAL_END"IS NULL)
5 - access("AE".") EMP_ID '=' ML '. ("' EMP_ID ')
8 - filter("PO".") (ACTUAL_END"IS NULL)
9 - access("PO".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
11 - filter("EC".") (ACTUAL_END"IS NULL)
12 - access("EC".") EMP_ID' (+) = 'EL '. ("' EMP_ID ')
13 - filter("EL".") LEAVE_END' IS NULL AND 'EL '. "LEAVE_TYPE"= 6)
16 - access("AE".") EMP_ID '=' PO '. ("' EMP_ID ')
17 - filter("PO".") ACTUAL_END' IS NULL AND 'PO '. ("' HOUSED <>' 30)
18 - filter("AE".") (CITIZENSHIP", <>1)
20 - access("AE".") EMP_ID '=' EC '. "EMP_ID" (+)) "
27 - access("LMI".") WITH THE ID '=' MI '. ("' IMM_REC")
filter ("LMI". "WITH THE '=' MI' ID '." " IMM_REC')
Projection of the column information (identified by the operation identity card):
-----------------------------------------------------------
1 (#keys = 3) "AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35], MAX (DECODE (TO_CHAR ("BT" "."))) " ID'), '1', TO_CHAR (INTERNAL_FUNCTION ("BT". "MY
((XDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '2', TO_CHAR (INTERNAL_FUNCTION ("BT"." ""
(('MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "3", TO_CHAR (INTERNAL_FUNCTION ("B
« « « T ». » ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '5', TO_CHAR (INTERNAL_FUNCTION" ""
('BT'. (((("' MAXDATE '), 'DD-MON-YYYY'), NULL)) [11], MAX (DECODE (TO_CHAR ("BT". "ID"), "6", TO_CHAR (INTERNAL_FUNCT
ION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11], MAX (DECODE (TO_CHAR ("BT"." ID"),"8", TO_CHAR (INTERNAL_FU
FUNCTION ("BT". "MAXDATE'), 'DD-MON-YYYY')(, NULL)) [11],"
MAX (DECODE (TO_CHAR ("BT". "ID"), "9", TO_CHAR (INTERNAL_FUNCTION ("BT"." ((MAXDATE'), 'DD-MON-YYYY'), NULL)) [11
], MAX (DECODE (TO_CHAR ("BT". "' ' 'ID'), '10', TO_CHAR (INTERNAL_FUNCTION ("BT"." "" (MAXDATE'), 'DD-MON-YYYY'), NULL)
) [11].
2. (#keys = 1) "AE". "FIRST NAME" [VARCHAR2, 35], "Æ" "." " CLOCK_NUMBER ' [VARCHAR2, 11],
"AE". "LAST_NAME" [VARCHAR2, 45], 'BT' "." " MAXDATE "[DATE, 7], 'BT'". "" ID '[NUMBER, 22].
3. "AE". "EMP_ID" [NO.22], "Æ" "." " FIRST NAME "[VARCHAR2, 35],"Æ"". "" CLOCK_NUMBER ' [VARCHAR2, 11],
"AE". "LAST_NAME" [VARCHAR2, 45].
4. (#keys = 0) 'AE '. "EMP_ID" [NO.22], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME "[VARCHAR2, 45], 'CBS'". "" ACTUAL_END "[DATE, 7].
5 (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " FIRST NAME ' [VARCHAR2, 35],
"AE". "CLOCK_NUMBER" [VARCHAR2, 11], "Æ" "." " LAST_NAME ' [VARCHAR2, 45].
6 ' ML '. ' EMP_ID '[NUMBER, 22].
7. "EL". ' EMP_ID '[NUMBER, 22].
8. "EL". ' EMP_ID '[NUMBER, 22].
9. (#keys = 1) 'EL '. "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
10. "EL". ' EMP_ID '[NUMBER, 22].
11. "EL". ' EMP_ID '[NUMBER, 22].
12. (#keys = 1) 'EL '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
13. "EL". ' EMP_ID '[NUMBER, 22].
14. 'EC '. "EMP_ID" [NO.22], 'CBS' "." " ACTUAL_END "[DATE, 7].
15. "PO." "EMP_ID" [NO.22], "PO" "." " ACTUAL_END "[DATE, 7].
16. (#keys = 1) "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER ' [VARCHAR2, 11],
"AE". "LAST_NAME" [VARCHAR2, 45], "Æ" "." " FIRST NAME ' [VARCHAR2, 35].
17 "IN." ' EMP_ID '[NUMBER, 22].
18. "AE". "EMP_ID" [NO.22], "Æ" "." " CLOCK_NUMBER "[VARCHAR2, 11],"Æ"". "" LAST_NAME ' [VARCHAR2, 45],
"AE". "FIRST NAME" [VARCHAR2, 35].
19. "EC". "ACTUAL_END"[DATE, 7].
20. "EC". ROWID [ROWID, 10]
21. "BT". "EMP_ID" [NO.22], 'BT' "." " ID "[NO.22], 'BT'". "" MAXDATE '[DATE, 7].
22. (#keys = 6) "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" DSB "[NO.22], MAX ("IMM_DATE") [7]"
23. "MI". "EMP_ID" [NO.22], "LMI" "." " ID "[NO.22],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55],"LMI"". "" SERIES "[VARCHAR2, 55],"IMM_DATE "[DATE, 7]"
24. (#keys = 0) "LMI". "ID" [NO.22], 'MI' "." " EMP_ID "[NO.22],"LMI"". "" SERIES "[VARCHAR2, 55],
"LMI". "IMM_DESC" [VARCHAR2, 55], "LMI" "." " DSB "[NO.22],"LMI"". "" DRUG "[VARCHAR2, 55],
"MI". "IMM_DATE"[DATE, 7].
25. (#keys = 1) "LMI". "ID" [NO.22], "LMI" "." " SERIES "[VARCHAR2, 55],"LMI"". "" IMM_DESC ' [VARCHAR2, 55],
"LMI". "DSB" [NO.22], "LMI" "." " DRUG "[VARCHAR2, 55].
26 "DIA." "ID" [NO.22], "LMI" "." " IMM_DESC "[VARCHAR2, 55],"LMI"". "" DSB '[NUMBER, 22],
"LMI". "DRUG" [VARCHAR2, 55], "LMI" "." " SERIES "[VARCHAR2, 55].
27. (#keys = 1) "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
28. "MI". "EMP_ID" [NO.22], 'MI' "." " IMM_REC "[NO.22], 'MI'". "" IMM_DATE "[DATE, 7].
-------------------------------------------------------------------------------
The SQL Profiler are actually implementation plans. Sometimes the tuning Advisor will find a best execution plan when the problem sql statement. If so, then it will tell you what you have posted above. If you accept the profile sql recommended for the tuned sql statement, it will always use this same by the profile of sql execution plan agreed.
Several times, including peoplesoft, plans of execution applications change all the time depending on the amount of data gets added/updated / deleted on a weekly or monthly basis, etc... For this reason a sql statement can perform very well at the beginning, but a month or 2 later, it is a poor performance due to the optimizer oracle modifying execution plan.
If the sql statement has a sql profile agreed to do this, it will always use the same execution plan. Note however that over time, the profile sql may not have the optimal execution plan more, they do not work forever, unless your database is not change and/or development...
The pl/sql tuning advisor came back with in your original post is what you need to perform to implement sql profile. I never implement if the improvement by setting Advisor is 90% or more (I noticed yours was)<= 10,="" which="" is="" pretty="">
I also always force_match-online set to true when you implement a sql profile, it's so if there are values of variables of different data values/identification, profile sql will always be used for iterations of the same sql statement.
Here is the syntax (I added the force below the end of your original)
run dbms_sqltune.accept_sql_profile (task_name-online 'staName20789', replace-online TRUE, force_match-online true);
-
The name of column in the clause not should be indexed?
Hello world
I have the version of database oracle 11.0.1.6 on windows server 2003 R2.
I have a query like this:
Select * CIM
If customer_no not in (select customer_no from icm_pre);
I would like to know if we should index the customer_no column in the icm_pre table too? I indexed customer_no column in icm.
Is there a better performance if I index the two columns in tables 2?
Thank youuser10636796 wrote:
----------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 1 | 147 | 764 (1)| 00:00:10 | | 1 | LOAD TABLE CONVENTIONAL | ICM_UPSEL_0_ALL | | | | | | 2 | HASH GROUP BY | | 1 | 147 | 764 (1)| 00:00:10 | | 3 | NESTED LOOPS | | | | | | | 4 | NESTED LOOPS | | 1 | 147 | 763 (1)| 00:00:10 | |* 5 | HASH JOIN RIGHT ANTI NA | | 1 | 78 | 687 (1)| 00:00:09 | | 6 | TABLE ACCESS FULL | ICM_UPSEL_1_ALL | 18556 | 235K| 68 (0)| 00:00:01 | |* 7 | TABLE ACCESS FULL | ICM_UPSEL_MIN_PRDIFF_0 | 223K| 13M| 618 (1)| 00:00:08 | |* 8 | INDEX RANGE SCAN | PRICE_DIFF_IDX | 84 | | 3 (0)| 00:00:01 | |* 9 | TABLE ACCESS BY INDEX ROWID| ICM_PRE | 1 | 69 | 76 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - access("A"."PR_CODE_BBL"="PR_CODE_BBL") 7 - filter("A"."FLAG"=0 AND "A"."PRICE_DIFF">0 AND "A"."SCORE">=0.5 AND "A"."PRICE_DIFF"<=10) 8 - access("A"."PRICE_DIFF"="B"."PRICE_DIFF") filter("B"."PRICE_DIFF"<=10 AND "B"."PRICE_DIFF">0) 9 - filter("B"."SCORE">=0.5 AND "B"."FLAG"=0 AND "A"."CUSTOMER_NO"="B"."CUSTOMER_NO" AND "A"."PR_CODE_BBL"="B"."PR_CODE_BBL" AND "A"."SCORE"="B"."SCORE")How many lines are there in ICM_UPSEL_MIN_PRDIFF_0, how match the 'permanent' predicates, is an effective way to find them, how much will be left after having applied the test of the subquery.
Ditto for ICM_PRE, and that the numbers look like if you apply the subquery to ICM_PRE (which seems possible)
What is the precise path to reach two main tables - and y at - it a hint of support for this joinNotice that you have a duplicate in your original query - the query predicate is correct?
Notice that the subquery has turned into a "conscience anti join null" - to change NOT IN to a NOT EXISTS (suggested by another poster) is not logically the same query - you have a missing constraint (or two) that could help the optimizer to find a better way.Concerning
Jonathan Lewis -
Hello
We have sql Query which never even out after 2 hours.
DB = 10.2.0.4
OS = Solaris 10
Concerningbilling_trd@MIFEX3> select * from tibex_qscacheloadordering where qsid='QS1'; Execution Plan ---------------------------------------------------------- Plan hash value: 1371436155 ------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 154 | 3234 | | 40M (1)|135:17:50 | | 1 | VIEW | TIBEX_QSCACHELOADORDERING | 154 | 3234 | | 40M (1)|135:17:50 | | 2 | SORT ORDER BY | | 154 | 5236 | | 40M (1)|135:17:50 | | 3 | HASH GROUP BY | | 154 | 5236 | | 40M (1)|135:17:50 | | 4 | VIEW | | 154 | 5236 | | 40M (1)|135:17:50 | | 5 | SORT UNIQUE | | 154 | 3309 | | 40M (1)|135:17:50 | | 6 | UNION-ALL | | | | | | | | 7 | HASH GROUP BY | | 141 | 2961 | | 40M (1)|135:17:20 | | 8 | VIEW | TIBEX_ORDERSBYQSIDVIEW | 141 | 2961 | | 40M (1)|135:17:20 | | 9 | UNION-ALL | | | | | | | |* 10 | FILTER | | | | | | | | 11 | HASH GROUP BY | | 140 | 46760 | | 443K (1)| 01:28:47 | |* 12 | HASH JOIN | | 20M| 6488M| | 442K (1)| 01:28:36 | | 13 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 28 | 616 | | 2 (0)| 00:00:01 | |* 14 | INDEX RANGE SCAN | TIBEX_PARTICIPANTQSID | 28 | | | 1 (0)| 00:00:01 | |* 15 | HASH JOIN | | 20M| 6060M| | 442K (1)| 01:28:35 | | 16 | INLIST ITERATOR | | | | | | | | 17 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDERSTATUSENUM | 4 | 104 | | 2 (0)| 00:00:01 | |* 18 | INDEX RANGE SCAN | TIBEX_ORDERSTAT_ID_DESC | 4 | | | 1 (0)| 00:00:01 | |* 19 | HASH JOIN | | 20M| 5555M| 733M| 442K (1)| 01:28:34 | |* 20 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 549M| | 103K (1)| 00:20:47 | | 21 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 3818M| | 104K (1)| 00:20:49 | |* 22 | FILTER | | | | | | | |* 23 | HASH JOIN | | 8007K| 450M| | 104K (1)| 00:20:50 | | 24 | MERGE JOIN CARTESIAN | | 28 | 672 | | 3 (0)| 00:00:01 | | 25 | TABLE ACCESS BY INDEX ROWID | TIBEX_ORDERSTATUSENUM | 1 | 14 | | 2 (0)| 00:00:01 | |* 26 | INDEX RANGE SCAN | TIBEX_ORDERSTAT_ID_DESC | 1 | | | 1 (0)| 00:00:01 | | 27 | BUFFER SORT | | 28 | 280 | | 1 (0)| 00:00:01 | | 28 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 28 | 280 | | 1 (0)| 00:00:01 | |* 29 | INDEX RANGE SCAN | TIBEX_PARTICIPANTQSID | 28 | | | 0 (0)| 00:00:01 | | 30 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 534M| | 104K (1)| 00:20:49 | | 31 | SORT AGGREGATE | | 1 | 27 | | | | |* 32 | TABLE ACCESS BY INDEX ROWID | TIBEX_ORDER | 1 | 27 | | 5 (0)| 00:00:01 | |* 33 | INDEX RANGE SCAN | IX_ORDERBOOK | 1 | | | 4 (0)| 00:00:01 | | 34 | HASH GROUP BY | | 1 | 99 | | 2473 (2)| 00:00:30 | | 35 | NESTED LOOPS | | 1 | 99 | | 2471 (2)| 00:00:30 | | 36 | NESTED LOOPS | | 1 | 89 | | 2470 (2)| 00:00:30 | |* 37 | HASH JOIN RIGHT SEMI | | 1 | 75 | | 2469 (2)| 00:00:30 | | 38 | VIEW | VW_NSO_2 | 842 | 28628 | | 1237 (2)| 00:00:15 | | 39 | HASH GROUP BY | | 842 | 31154 | | 1237 (2)| 00:00:15 | |* 40 | TABLE ACCESS FULL | TIBEX_QUOTE | 191K| 6906K| | 1230 (1)| 00:00:15 | | 41 | TABLE ACCESS FULL | TIBEX_QUOTE | 191K| 7659K| | 1230 (1)| 00:00:15 | |* 42 | TABLE ACCESS BY INDEX ROWID | TIBEX_QUOTESTATUSENUM | 1 | 14 | | 1 (0)| 00:00:01 | |* 43 | INDEX UNIQUE SCAN | XPKTIBEX_QUOTESTATUSENUM | 1 | | | 0 (0)| 00:00:01 | |* 44 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 1 | 10 | | 1 (0)| 00:00:01 | |* 45 | INDEX UNIQUE SCAN | XPKTIBEX_PARTICIPANT | 1 | | | 0 (0)| 00:00:01 | | 46 | HASH GROUP BY | | 11 | 231 | | 59 (16)| 00:00:01 | | 47 | VIEW | | 11 | 231 | | 57 (13)| 00:00:01 | | 48 | SORT UNIQUE | | 11 | 2288 | | 57 (57)| 00:00:01 | | 49 | UNION-ALL | | | | | | | |* 50 | FILTER | | | | | | | | 51 | HASH GROUP BY | | 6 | 1248 | | 29 (14)| 00:00:01 | |* 52 | HASH JOIN | | 1541 | 313K| | 27 (8)| 00:00:01 | | 53 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 28 | 616 | | 2 (0)| 00:00:01 | |* 54 | INDEX RANGE SCAN | TIBEX_PARTICIPANTQSID | 28 | | | 1 (0)| 00:00:01 | |* 55 | HASH JOIN | | 1541 | 279K| | 24 (5)| 00:00:01 | |* 56 | HASH JOIN RIGHT ANTI | | 1541 | 86296 | | 14 (8)| 00:00:01 | |* 57 | TABLE ACCESS FULL | TIBEX_BESTEXECSTATUSENUM | 1 | 14 | | 3 (0)| 00:00:01 | | 58 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 2311 | 97062 | | 10 (0)| 00:00:01 | | 59 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 2311 | 293K| | 10 (0)| 00:00:01 | |* 60 | FILTER | | | | | | | | 61 | HASH GROUP BY | | 5 | 1040 | | 29 (14)| 00:00:01 | |* 62 | HASH JOIN | | 1321 | 268K| | 27 (8)| 00:00:01 | | 63 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 28 | 616 | | 2 (0)| 00:00:01 | |* 64 | INDEX RANGE SCAN | TIBEX_PARTICIPANTQSID | 28 | | | 1 (0)| 00:00:01 | |* 65 | HASH JOIN | | 1321 | 239K| | 24 (5)| 00:00:01 | |* 66 | HASH JOIN RIGHT ANTI | | 1541 | 86296 | | 14 (8)| 00:00:01 | |* 67 | TABLE ACCESS FULL | TIBEX_BESTEXECSTATUSENUM | 1 | 14 | | 3 (0)| 00:00:01 | | 68 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 2311 | 97062 | | 10 (0)| 00:00:01 | |* 69 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1981 | 251K| | 10 (0)| 00:00:01 | | 70 | HASH GROUP BY | | 1 | 18 | | 7 (43)| 00:00:01 | | 71 | VIEW | TIBEX_TSTRADEBYQSIDVIEW | 1 | 18 | | 5 (20)| 00:00:01 | | 72 | HASH UNIQUE | | 1 | 818 | | 5 (20)| 00:00:01 | |* 73 | FILTER | | | | | | | | 74 | NESTED LOOPS | | 1 | 818 | | 2 (0)| 00:00:01 | | 75 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 808 | | 2 (0)| 00:00:01 | |* 76 | TABLE ACCESS BY INDEX ROWID | TIBEX_PARTICIPANT | 1 | 10 | | 0 (0)| 00:00:01 | |* 77 | INDEX UNIQUE SCAN | XPKTIBEX_PARTICIPANT | 1 | | | 0 (0)| 00:00:01 | | 78 | SORT AGGREGATE | | 1 | 35 | | | | |* 79 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 35 | | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 10 - filter("A"."MESSAGESEQUENCE"=MAX("C"."MESSAGESEQUENCE")) 12 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID") 14 - access("B"."QSID"='QS1') 15 - access("A"."ORDERSTATUS"="ORDERSTATUS") 18 - access("SHORTDESC"='ORD_CANCEL' OR "SHORTDESC"='ORD_EXPIRE' OR "SHORTDESC"='ORD_FILLED' OR "SHORTDESC"='ORD_OPEN') 19 - access("A"."ORDERID"="C"."ORDERID") 20 - filter("LASTINSTREJECTCODE"='OK') 22 - filter( (SELECT COUNT(*) FROM BILLING_TRD."TIBEX_ORDER" "C" WHERE "C"."ORDERID"=:B1 AND "C"."INSTRUMENTID"=:B2)=1) 23 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID" AND "ORDERSTATUS"="ORDERSTATUS") 26 - access("SHORTDESC"='ORD_REJECT') 29 - access("B"."QSID"='QS1') 32 - filter("C"."INSTRUMENTID"=:B1) 33 - access("C"."ORDERID"=:B1) 37 - access("A"."MESSAGESEQUENCE"="$nso_col_1" AND "A"."QUOTEID"="$nso_col_2") 40 - filter("LASTINSTREJECTCODE"='OK') 42 - filter("SHORTDESC"='QUO_OFFMKT' OR "SHORTDESC"='QUO_ONMKT' OR "SHORTDESC"='QUO_PREOPN') 43 - access("A"."QUOTESTATUS"="QUOTESTATUS") 44 - filter("B"."QSID"='QS1') 45 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID") 50 - filter("MESSAGESEQUENCE"=MAX("MESSAGESEQUENCE")) 52 - access("PARTICIPANTID"="B"."PARTICIPANTID") 54 - access("B"."QSID"='QS1') 55 - access("A"."INSTRUMENTID"="INSTRUMENTID" AND "A"."PARTNEREXID"="PARTNEREXID") 56 - access("B"."BESTEXECSTATUS"="BESTEXECSTATUS") 57 - filter("SHORTDESC"='BESTEX_REJ') 60 - filter("MESSAGESEQUENCE"=MAX("MESSAGESEQUENCE")) 62 - access("PARTICIPANTIDMM"="D"."PARTICIPANTID") 64 - access("D"."QSID"='QS1') 65 - access("A"."INSTRUMENTID"="INSTRUMENTID" AND "A"."PARTNEREXID"="PARTNEREXID") 66 - access("B"."BESTEXECSTATUS"="BESTEXECSTATUS") 67 - filter("SHORTDESC"='BESTEX_REJ') 69 - filter("PARTICIPANTID"<>"PARTICIPANTIDMM") 73 - filter("MESSAGESEQUENCE"= (SELECT MAX("MESSAGESEQUENCE") FROM BILLING_TRD."TIBEX_TSTRADE" "C" WHERE "C"."TSTRADEID"=:B1)) 76 - filter("B"."QSID"='QS1') 77 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID") 79 - filter("C"."TSTRADEID"=:B1) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- illing_trd@MIFEX3> SELECT participantid, qsid, count(*) as cnt FROM tibex_ordersbyqsidview GROUP BY participantid,qsid; Execution Plan ---------------------------------------------------------- Plan hash value: 2717629353 ----------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 141 | 2961 | | 40M (1)|135:17:20 | | 1 | HASH GROUP BY | | 141 | 2961 | | 40M (1)|135:17:20 | | 2 | VIEW | TIBEX_ORDERSBYQSIDVIEW | 141 | 2961 | | 40M (1)|135:17:20 | | 3 | UNION-ALL | | | | | | | |* 4 | FILTER | | | | | | | | 5 | HASH GROUP BY | | 140 | 46760 | | 443K (1)| 01:28:47 | |* 6 | HASH JOIN | | 20M| 6488M| | 442K (1)| 01:28:36 | | 7 | TABLE ACCESS FULL | TIBEX_PARTICIPANT | 28 | 616 | | 3 (0)| 00:00:01 | |* 8 | HASH JOIN | | 20M| 6060M| | 442K (1)| 01:28:35 | | 9 | INLIST ITERATOR | | | | | | | | 10 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDERSTATUSENUM | 4 | 104 | | 2 (0)| 00:00:01 | |* 11 | INDEX RANGE SCAN | TIBEX_ORDERSTAT_ID_DESC | 4 | | | 1 (0)| 00:00:01 | |* 12 | HASH JOIN | | 20M| 5555M| 733M| 442K (1)| 01:28:34 | |* 13 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 549M| | 103K (1)| 00:20:47 | | 14 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 3818M| | 104K (1)| 00:20:49 | |* 15 | FILTER | | | | | | | |* 16 | HASH JOIN | | 8007K| 450M| | 104K (1)| 00:20:50 | | 17 | MERGE JOIN CARTESIAN | | 28 | 672 | | 5 (0)| 00:00:01 | | 18 | TABLE ACCESS BY INDEX ROWID | TIBEX_ORDERSTATUSENUM | 1 | 14 | | 2 (0)| 00:00:01 | |* 19 | INDEX RANGE SCAN | TIBEX_ORDERSTAT_ID_DESC | 1 | | | 1 (0)| 00:00:01 | | 20 | BUFFER SORT | | 28 | 280 | | 3 (0)| 00:00:01 | | 21 | TABLE ACCESS FULL | TIBEX_PARTICIPANT | 28 | 280 | | 3 (0)| 00:00:01 | | 22 | TABLE ACCESS FULL | TIBEX_ORDER | 16M| 534M| | 104K (1)| 00:20:49 | | 23 | SORT AGGREGATE | | 1 | 27 | | | | |* 24 | TABLE ACCESS BY INDEX ROWID | TIBEX_ORDER | 1 | 27 | | 5 (0)| 00:00:01 | |* 25 | INDEX RANGE SCAN | IX_ORDERBOOK | 1 | | | 4 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("A"."MESSAGESEQUENCE"=MAX("C"."MESSAGESEQUENCE")) 6 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID") 8 - access("A"."ORDERSTATUS"="ORDERSTATUS") 11 - access("SHORTDESC"='ORD_CANCEL' OR "SHORTDESC"='ORD_EXPIRE' OR "SHORTDESC"='ORD_FILLED' OR "SHORTDESC"='ORD_OPEN') 12 - access("A"."ORDERID"="C"."ORDERID") 13 - filter("LASTINSTREJECTCODE"='OK') 15 - filter( (SELECT COUNT(*) FROM BILLING_TRD."TIBEX_ORDER" "C" WHERE "C"."ORDERID"=:B1 AND "C"."INSTRUMENTID"=:B2)=1) 16 - access("A"."PARTICIPANTID"="B"."PARTICIPANTID" AND "ORDERSTATUS"="ORDERSTATUS") 19 - access("SHORTDESC"='ORD_REJECT') 24 - filter("C"."INSTRUMENTID"=:B1) 25 - access("C"."ORDERID"=:B1)
NMNM says:
HelloHis stats are updated. Tibex_order table contains records of 16 M and rest of the tables have very less number the many lines in 100 and 1000.
This query should return records from 10 to 20.
Well, I don't know your data model, but I would like to have a go at rewriting the query defining your view.
You need to check if this query will ALWAYS equal your original query and see if it behaves better.SELECT "ORDERID", "USERORDERID", "ORDERSIDE", "ORDERTYPE", ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE, b.qsid FROM ( SELECT "ORDERID", "USERORDERID", "ORDERSIDE", "ORDERTYPE", ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE FROM ( SELECT "ORDERID", "USERORDERID", "ORDERSIDE", "ORDERTYPE", ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE, max(case when LastInstRejectCode = 'OK' then MessageSequence end) over (partition by OrderID) as maxseq FROM tibex_Order ) WHERE MessageSequence = maxseq ) A, tibex_Participant b WHERE a.participantID = b.participantID AND a.OrderStatus IN ( SELECT OrderStatus FROM tibex_orderStatusEnum WHERE ShortDesc IN ('ORD_OPEN', 'ORD_EXPIRE', 'ORD_CANCEL', 'ORD_FILLED') ) UNION ALL SELECT ORDERID, USERORDERID, ORDERSIDE, ORDERTYPE, ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE, qsid FROM ( SELECT ORDERID, USERORDERID, ORDERSIDE, ORDERTYPE, ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE FROM ( SELECT ORDERID, USERORDERID, ORDERSIDE, ORDERTYPE, ORDERSTATUS, BOARDID, TIMEINFORCE, INSTRUMENTID, REFERENCEID, PRICETYPE, PRICE, AVERAGEPRICE, QUANTITY, MINIMUMFILL, DISCLOSEDQTY, REMAINQTY, AON, PARTICIPANTID, ACCOUNTTYPE, ACCOUNTNO, CLEARINGAGENCY, LASTINSTRESULT, LASTINSTMESSAGESEQUENCE, LASTEXECUTIONID, NOTE, TIMESTAMP, QTYFILLED, MEID, LASTINSTREJECTCODE, LASTEXECPRICE, LASTEXECQTY, LASTINSTTYPE, LASTEXECUTIONCOUNTERPARTY, VISIBLEQTY, STOPPRICE, LASTEXECCLEARINGAGENCY, LASTEXECACCOUNTNO, LASTEXECCPCLEARINGAGENCY, MESSAGESEQUENCE, LASTINSTUSERALIAS, BOOKTIMESTAMP, PARTICIPANTIDMM, MARKETSTATE, PARTNEREXID, LastExecSETTLEMENTCYCLE, LASTEXECPOSTTRADEVENUETYPE, PRICELEVELPOSITION, PREVREFERENCEID, EXPIRYTIMESTAMP, matchType, lastExecutionRole, MDEntryID, PegOffset, haltReason, lastInstFixSequence, COMPARISONPRICE, count(*) over (partition by orderid, instrumentID) cnt FROM tibex_Order ) WHERE cnt = 1 ) A, tibex_Participant b WHERE a.participantID = b.participantID AND orderstatus in ( SELECT orderstatus FROM tibex_orderStatusEnum WHERE ShortDesc = 'ORD_REJECT' )* Not tested
-
Hello
The following query performs badly when the predicate
AND (v_actionFlag IS NULL or ACTION_CODE = v_actionFlag)
is present. In all executions of the query v_actionFlag will be NULL. In addition, because of the plan when the predicate is included, the returned results are incorrect. We seek to treat rows with the lowest priority. With the included predicate query performs the join, gets 20 lines, sorts, and puts back them rather than getting 20 lines with the lowest priority through the index of QUEUE_TAB0 and return of these.
The questions I have are-
-Why the predicate affects the query in this way
-What is the difference between the HASH JOIN ANTI and HASH JOIN RIGHT ANTI
We were able to remove this predicate as the functionality it supports has not yet been implemented.
Background
Version of DB - 10.2.0.4
optimizer_features_enable - 10.2.0.4
optimizer_mode - ALL_ROWS
Table - table has approximately 475,000 rows and the statistics are up to date sql> desc queue_tab Name Null? Type ----------------------------------------- -------- ---------------------------- ENTITY_KEY NOT NULL NUMBER(12) ENTITY_TYPE NOT NULL CHAR(1) ACTION_CODE NOT NULL CHAR(1) REPORT_NO NOT NULL NUMBER(12) PRIORITY NOT NULL NUMBER(4) Indexes Primary Key (QUEUE_TAB_PK) ENTITY_KEY ENTITY_TYPE ACTION_CODE REPORT_NO Non Unique Index (QUEUE_TAB0) PRIORITY ENTITY_KEY ENTITY_TYPE ACTION_CODE Cursor SELECT /*+ INDEX_ASC (main QUEUE_TAB0) */ REPORT_NO , ENTITY_TYPE , ENTITY_KEY , ACTION_CODE , PRIORITY FROM QUEUE_TABV01 main WHERE PRIORITY > 1 AND (v_actionFlag IS NULL OR ACTION_CODE = v_actionFlag ) AND NOT EXISTS ( SELECT /*+ INDEX_ASC (other QUEUE_TAB_pk) */ 1 FROM QUEUE_TABV01 other WHERE main.ENTITY_TYPE = other.ENTITY_TYPE AND main.ENTITY_KEY = other.ENTITY_KEY AND main._ACTION_CODE IN ( constant1, constant2 ) AND other.ACTION_CODE IN ( constant3, constant4 ) ) AND NOT EXISTS ( SELECT 1 FROM QUEUE_TABV01 multi WHERE main.ENTITY_TYPE = multi.ENTITY_TYPE AND main.ENTITY_KEY = multi.ENTITY_KEY AND multi.PRIORITY = 1 ) AND ROWNUM < rowCount + 1 ORDER BY PRIORITY, ENTITY_KEY, ENTITY_TYPE, ACTION_CODE; Plan when predicate "AND (v_actionFlag IS NULL OR ACTION_CODE = v_actionFlag )" is present 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 21 5.53 5.40 2 780463 0 20 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 23 5.53 5.40 2 780463 0 20 Misses in library cache during parse: 0 Optimizer mode: ALL_ROWS Parsing user id: 60 (recursive depth: 1) Rows Row Source Operation ------- --------------------------------------------------- 20 SORT ORDER BY (cr=780463 pr=2 pw=0 time=5400939 us) 20 COUNT STOPKEY (cr=780463 pr=2 pw=0 time=5400872 us) 20 HASH JOIN ANTI (cr=780463 pr=2 pw=0 time=5400823 us) 459033 TABLE ACCESS BY INDEX ROWID QUEUE_TAB (cr=780460 pr=2 pw=0 time=4640394 us) 459033 INDEX RANGE SCAN QUEUE_TAB0 (cr=608323 pr=1 pw=0 time=3263977 us)(object id 68038) 10529 FILTER (cr=599795 pr=1 pw=0 time=2573230 us) 10529 INDEX RANGE SCAN QUEUE_TAB_PK (cr=599795 pr=1 pw=0 time=2187209 us)(object id 68037) 0 INDEX RANGE SCAN QUEUE_TAB0 (cr=3 pr=0 pw=0 time=34 us)(object id 68038) Plan when predicate "AND (v_actionFlag IS NULL OR ACTION_CODE = v_actionFlag )" is removed call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.02 0.00 0 0 0 0 Fetch 21 0.05 0.05 0 6035 0 20 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 23 0.07 0.06 0 6035 0 20 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 60 (recursive depth: 1) Rows Row Source Operation ------- --------------------------------------------------- 20 SORT ORDER BY (cr=6035 pr=0 pw=0 time=54043 us) 20 COUNT STOPKEY (cr=6035 pr=0 pw=0 time=962 us) 20 HASH JOIN RIGHT ANTI (cr=6035 pr=0 pw=0 time=920 us) 0 INDEX RANGE SCAN QUEUE_TAB0 (cr=3 pr=0 pw=0 time=53 us)(object id 68038) 20 TABLE ACCESS BY INDEX ROWID QUEUE_TAB (cr=6032 pr=0 pw=0 time=701 us) 20 INDEX RANGE SCAN QUEUE_TAB0 (cr=6001 pr=0 pw=0 time=533 us)(object id 68038) 40 FILTER (cr=199 pr=0 pw=0 time=2048 us) 40 INDEX RANGE SCAN QUEUE_TAB_PK (cr=199 pr=0 pw=0 time=1975 us)(object id 68037)user599445 wrote:
Hello Justin and Camille,Thank you for taking the time to look at it. I changed the query to correctly practice the ROWNUM. I run and traced the query with the predicate IS NULL and without, with each track below. As you both have suggested that the predicate appears to have no impact on the plan does. All feedback is appeciated.
Mark,
the obvious problem with the new plan is that no record is filtered by the first NOT EXISTS clause (using anti-join operation), and then for each line an index seek is performed that filters the records only about 14 000. It is the search for index that takes most of the time, gets consistent since he performs about 2 e/s logic by research, in total nearly 1 million.
The last 456 000 rows are then sorted (top n) and the top 20 are returned.
A possible problem could be that the optimizer does not switch mode optimization first_rows_N due to the variable binding used in the filter ROWNUM.
You can try to execute the statement using a literal (ROWNUM< 21)="" instead="" of="" the="" bind="" variable="" to="" see="" if="" it="" changes="">
I think in this case, it could be much more effective for the QUEUE_TAB0 of the market index in the order requested and perform the two NOT EXISTS clause as activities of recursive filters provided as your ROWNUM predicate is generally rather low.
Be aware however that is you do not use a "binary" NLS_SORT index parameter can not be used for an operation of NOSORT ORDER BY STOPKEY of CHAR values, so please check your settings NLS (NLS_SESSION_PARAMETERS. PARAMETER = "NLS_SORT") in which case the optimizer will not use the index for sorting. Note that the NLS parameters are customer specific and can theoretically be different for each session / client.
You can test this by using a query simple top N: SELECT * FROM (SELECT * ACTION_CODE, ENTITY_TYPE, ENTITY_KEY, QUEUE_TAB ORDER OF PRIORITY) WHERE ROWNUM<>
If it does not use the QUEUE_TAB0 index to stop the sort operation, you might have a problem with the NLS parameters.
In order to prevent the transformation of the GUESSED you can also try adding a hint NO_UNNEST two subqueries ("SELECT / * + NO_UNNEST * /...") ("in the respective subquery) and you can also try to switch mode FIRST_ROWS (n) using for example the FIRST_ROWS indicator (20) in the body of the request (but which must be done by the ROWNUM predicate).
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/ -
"One time" column in dbms_xplan.display_cursor is summed up?
Hello
I did some research on the internet before this announcement, but I could find enough information.
"One time" column in dbms_xplan.display_cursor is summed up?
(hope this execution plan is reasonably legible)--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 155 |00:06:36.28 | 4957K| 34952 | | | | | 1 | SORT ORDER BY | | 1 | 1 | 155 |00:06:36.28 | 4957K| 34952 | 55296 | 55296 |49152 (0)| | 2 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.04 | 4957K| 34952 | | | | | 3 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.04 | 4957K| 34952 | | | | | 4 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.04 | 4957K| 34952 | | | | | 5 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.04 | 4956K| 34952 | | | | | 6 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.04 | 4956K| 34952 | | | | | 7 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4956K| 34952 | | | | | 8 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4956K| 34952 | | | | | 9 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4956K| 34952 | | | | | 10 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4955K| 34952 | | | | | 11 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4955K| 34952 | | | | | 12 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4955K| 34952 | | | | | 13 | NESTED LOOPS | | 1 | 1 | 155 |00:06:30.03 | 4954K| 34952 | | | | |* 14 | HASH JOIN | | 1 | 1 | 155 |00:06:30.03 | 4954K| 34952 | 872K| 872K| 927K (0)| | 15 | VIEW | | 1 | 15 | 8 |00:06:28.63 | 1305K| 34883 | | | | |* 16 | FILTER | | 1 | | 8 |00:06:28.63 | 1305K| 34883 | | | | | 17 | HASH GROUP BY | | 1 | 15 | 8 |00:06:28.63 | 1305K| 34883 | 760K| 760K| 1077K (0)| | 18 | VIEW | | 1 | 15 | 341 |00:00:50.44 | 1305K| 34883 | | | | | 19 | UNION-ALL | | 1 | | 341 |00:00:50.44 | 1305K| 34883 | | | | | 20 | VIEW | V_POSNR_2011000 | 1 | 7 | 303 |00:00:50.44 | 645K| 31282 | | | | | 21 | UNION-ALL | | 1 | | 303 |00:00:50.44 | 645K| 31282 | | | | | 22 | VIEW | V_POSNR_0200011 | 1 | 2 | 20 |00:00:50.42 | 429K| 31244 | | | | | 23 | UNION-ALL | | 1 | | 20 |00:00:50.42 | 429K| 31244 | | | | | 24 | NESTED LOOPS | | 1 | 1 | 20 |00:00:50.42 | 376K| 28979 | | | | |* 25 | HASH JOIN | | 1 | 1 | 20 |00:00:50.42 | 376K| 28979 | 1096K| 1096K| 1348K (0)| |* 26 | TABLE ACCESS BY INDEX ROWID | PROPERTIES | 1 | 6 | 2651 |00:00:00.02 | 2131 | 0 | | | | |* 27 | INDEX RANGE SCAN | P_SETAALDATE_IDX | 1 | 6 | 2651 |00:00:00.01 | 21 | 0 | | | | | 28 | VIEW | VW_JF_SET$7992605D | 1 | 2 | 504 |00:02:30.85 | 374K| 28979 | | | | | 29 | UNION-ALL | | 1 | | 504 |00:02:30.85 | 374K| 28979 | | | |
I thought that the columns A-time indicates the time of the operation in question (summarizing all time from the operation of the child)
but this seems different:
Line 25 is a JOIN hash including a tableTABLE (1) the ACCESS BY INDEX ROWID and (2) the result of a VIEW|* 25 | HASH JOIN | | 1 | 1 | 20 |00:00:50.42 | 376K| 28979 | 1096K| 1096K| 1348K (0)| |* 26 | TABLE ACCESS BY INDEX ROWID | PROPERTIES | 1 | 6 | 2651 |00:00:00.02 | 2131 | 0 | | | | |* 27 | INDEX RANGE SCAN | P_SETAALDATE_IDX | 1 | 6 | 2651 |00:00:00.01 | 21 | 0 | | | | | 28 | VIEW | VW_JF_SET$7992605D | 1 | 2 | 504 |00:02:30.85 | 374K| 28979 | | | |
The Timing of the HASH (line 25) JOIN is 00:00:50.42, but the timing of the VIEW is 00:02:30.85 who ought both to complete before you chop it can happen
So I thought the HASH JOIN would be (at least) a schedule of the 00:02:30.85 of the VIEW, plus the 00:00:00.02 of the TABLE ACCESS BY INDEX ROWID.
But it seems that it is a misconception, can anyone shed light on this?
Best regards
Published by: x45r32 on April 4, 2012 08:25
Published by: x45r32 on April 4, 2012 08:46Hello
How do you collect statistical plan - via STATISTICS_LEVEL = ALL or gather_plan_statistics reference to the declaration?
The indicator is known for producing inaccurate schedules from time to time (has to do with the sampling frequency), STATISTICS_LEVEL = ALL should be more specific.
Best regards
Nikolai -
Hi all
I have this SQL that runs a long time like 4 hrs.
Can you give me advice on how to improve this?
In the plan to explain it, the biggest cost I see isSELECT TNDRST.EXT_SOURCE_ID, TNDRST.EXT_TRANSMIT_ID, TNDRST.EXT_BATCH_ID, TNDRST.EXT_REFERENCE_ID, TNDRST.TENDER_AMT, TNDRST.ACCOUNTING_DT, TNDRST.TENDER_TYPE_CD, TNDRST.CUST_ID, TNDRST.MICR_ID, TNDRST.NAME1, TNDRST.CHECK_NBR, ACCT.ACCT_ID, ACCT.CURRENCY_CD, DEPCTLST.CURRENCY_CD, TNDRCTLST.TNDR_CTL_ID, TSRCE.SA_ID FROM CI_PAY_TNDR_ST TNDRST, CI_ACCT ACCT, CI_DEP_CTL_ST DEPCTLST, CI_TNDR_CTL_ST TNDRCTLST, CI_TNDR_SRCE TSRCE WHERE TNDRST.CUST_ID = ACCT.ACCT_ID AND TNDRST.PAY_TND_STG_ST_FLG = '10' AND DEPCTLST.DEP_CTL_STG_ST_FLG = '30' AND TNDRCTLST.EXT_SOURCE_ID = DEPCTLST.EXT_SOURCE_ID AND TNDRCTLST.EXT_TRANSMIT_ID = DEPCTLST.EXT_TRANSMIT_ID AND TNDRST.EXT_SOURCE_ID = TNDRCTLST.EXT_SOURCE_ID AND TNDRST.EXT_TRANSMIT_ID = TNDRCTLST.EXT_TRANSMIT_ID AND TNDRST.EXT_BATCH_ID = TNDRCTLST.EXT_BATCH_ID AND TSRCE.EXT_SOURCE_ID = TNDRCTLST.EXT_SOURCE_ID ORDER BY TNDRST.CUST_ID, TNDRST.EXT_SOURCE_ID, TNDRST.EXT_TRANSMIT_ID, TNDRST.EXT_BATCH_ID, TNDRST.EXT_REFERENCE_ID;
... all other index scans have a minimal cost.SORT ORDER BY cost = 181, 949
NESTED LOOPS cost = 114, 965
JOIN hash cost = 107, 205
NESTED LOOPS cost = 107, 199
NESTED LOOPS cost = 53, 648
How you mininized for LOOPS IMBRIQUEES and KINDS? There's tips to improve it.
Thank you very much
Edited by: KinsaKaUy? on March 21, 2012 01:00KinsaKaUy? wrote:
Thanks friend,But I still prefer the original. :)
If the condition is that, to get a specific plan to explain, the request must be completed?
Then I ran on our TEST server with the smallest amount of data? Will explain myself?
It may be different because there will be change in volume of data, so be careful. But its interesting to try and compare with the production :)
>The following procedure takes also the account just real explain the first showing you?
Yes it does, it's the other way to get full statistics.
>sql> alter session set statistics_level=ALL; sql> ..... execute the query sql> select * from table (dbms_xplan.display_cursor(NULL,NULL, 'ALLSTATS LAST'));Thank you very much
-
Using the loop will decrease performance
Hello
Using the loop with a query will decrease performance.
for r_row in (select * from table) Loop
end of loop.
This is done within another loop for, more cases, it returns a single value.
It will decrease the performance of the procedure.
kindly advice...
Kind regards
Baluuser575682 wrote:
Using the loop with a query will decrease performance.for r_row in (select * from table) Loop
end of loop.This is done within another loop for, more cases, it returns a single value.
It will decrease the performance of the procedure.Perhaps better understand everything that makes this PL/SQL loop construction.
PL/SQL is two languages. It's PL (logic programming code) like Pascal, C or Java. You can use a 2nd language in it called SQL. The PL engine will be able to recognize when the 2nd language is used. And it compiles all the things that are necessary for motor PL call the SQL engine, pass the data to the SQL engine and get back data, etc. (compare this with the complexity of the use of SQL in Pascal, C or Java language).
So what's this loop? The PL engine recognizes the SQL SELECT statement. It creates an implicit cursor by calling the SQL engine to analyze (I hope a soft Parser), then run it.
As part of the loop of the PL, the PL engine now calls the SQL engine to extract data (lines) of the cursor. With 10g and later, the engine of the PL is smart enough to use the implicit treatment in bulk.
Before 10 g that he used to extract a line from the SQL engine, make the loop, the next line extraction, the loop, etc. In other words, if there is a 1000 lines to pick up, he'll call the SQL engine after 1000.
With 10g and later he get a 100 lines, which store in a buffer internal and then make the loop once 100. With a 1000 lines to fetch, it requires 10 extractions in bulk instead of one 1000 rank of extractions.
These extractions require a change of context - as the engine PL must not out back, and in the SQL engine to extract a line. It is an overhead projector and can become so slow the context switch nothing more.
And it's the construction of bases for this loop (and most other cursor loops) in PL/SQL.
The ideal is to reduce the number of context switches. It is an overload that can have an impact on performance.
What about using a loop in a loop. As 'bad '. This example uses the outer loop to retrieve the data. These data are then used to excite the extraction in internal or nested loop. The outside loop draws data from the SQL engine in PL variables Inside loop drives that same data back to the SQL engine.
Why? It would have been much faster not to pull and push data between the loops using PL.
It will be much faster do so only through SQL. Write the two loops as a single SQL statement and have the SQL engine directly driving these loops itself. This is called a JOIN in SQL. And the SQL engine can do not only more quickly, but it has a few algorithms of multiplied can be used which are even faster than a nested loop process (called merge joins, hash joins, etc.).
Bottom line. Optimize SQL. Reduce to a minimum the PL. *
Do as much of your data, crunch in SQL as possible. SQL is the fastest 'place' and process the data. No PL (or C/Pascal/Java).
-
Dear all,
It is a 10.2.0.3 version. I have a situation where the client runs a few batches at the same time. This causes of serious "free buffer waits. Those batch jobs that execute some statement to join large tables (about 1 GB, about 400 to 500 MB).
In the setting of the query is not possible at this stage because this would require to remodel the entire program. So I thought of increasing the buffer cache as well and launch more db writer (additional just a plus).
It is rational to start more db writer if we increase the buffer cache, if we have this free buffer waits to come to the top of the top 5 events of waiting?
Most of the involved joints joins hash due to the large data and another approach is to increase the pga_aggregate_target. But I came across a note saying only 5% will be used and we need to define the parameter (_pga_max_size) undocumented if want to super-sized your. I'm just wandering if there is no capture here that i should be aware of?
Thank youAs a general rule, when the event free buffer wait waiting is encountered, its is advisable to first check the size of the buffer cache. Most of the time this will resolve this event. In addition, youmust make sure tehre is not any claim on the files of database through which the write speed are descended. Oracle uses the formula (CPU_COUNT + 7) / 8 to choose the number of DBWRs, so if you have a processor to 1, the number of DBWRs would be set to 1 only. And its not advisable to play with the CPU_COUNT setting. So, before you go for the path of the inrease of DBWRs my humble OPINION.
HTH
Aman...
Maybe you are looking for
-
CD/DVD is not working properly on the Satellite A200-1AI
I have a Satellite A200-1AI but it can't find the CD/DVD. The operating system is Vista Home premium. The control panel highlights the problem that"Windows cannot start this hardware device because its information of configuration (in the registry) i
-
Why when I update my iphone on itunes, my phone freezes!
What can I say am a technophobe!
-
The Windows Security Center error message: could not start the Security Center service
I did disk cleaning, defraged, ran Malawarebytes and defender of the window, unexpected uninstalled programs, all my updates are current, delete all but the most recent restore points and ran the System File Checker tool Vista who finds some errors f
-
I am running Windows 7 Ultimate 64 bit on a Toshiba laptop computer on a network that also has a Synology Diskstation 710 +. There are other Windows 7 machines that continue to work perfectly with the NAS. My LAN is only small, so I run a working gro
-
Can not get on my desktop backgrounds - appears only a black color background
I wanted a new theme for my computer so I decided to download the theme of 'Bing Maps aerial imagery of Europe. " After that I started to download the theme everthing was always very well - background images for this theme were projected on my desk.