In buffered memory hash join
Hi allWhat is the operation of source line buffered hash join. I know that it uses the hash of the pass to send data but other then that what would be the difference in the hash join and put in buffered memory hash join. I would like to know work mechanisam.
Foreground:
========
The Coordinator query scans, aggregates and hash distributes ZIPXXX of line 13 to the slave series 2
Put slave 1 parallel analyses and hash distributes ZIPXXX from line 17 to series 2 slave
Slave set 2 joins these on line 7, then hash (probably on another column) distributes backward for slave set 1 - that is why the hash as line 7 join must be buffered.
Slave 2 set Parallels and hash analysis distribute REP_XXX on line 21 to the slave series 1
Hash slave joins them to line 4, then passes them the query with the Coordinator to write to the table.
It seems that you should 'alter session enable parallel DML' to allow parallel loading in select in line 4.
Second plan:
=========
The plan is virtually identical, although the collection of statistics seems to have changed the table names.
The query Coordinator scans, aggregates and the DIFFUSE GEO_XXX of line 13 to the slave set 2
Because the very small result set aired together slave 2 can analyze and join the GEO_SXXX of line 15 then diffuses back result (probably on another column) to the slave set 1
Because the very small result set aired slave together 1 can scan and join the REP_XXX of line 15, and then pass the results to the QC to write the table.
Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK
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 -
I am using 11.2.0.4.0 - oracle Version. I have underwear paremters on GV$ parameter
pga_aggregate_target - 8GB
hash_area_size - 128 KB
Sort_area_size - 64 KB
Now under query plan is running for ~ 1 HR and resulting in question tempspace. Unable to extend segment temp of 128 in tablespace TEMP.
We have currently allocated ~ 200GB at the tempspace. This query runs good for the daily race with Nested loop and the required index, but to run monthly that it changes the plan due to the volume I think and I went for the join of HASH, who believe is good decision by the optimizer.AFAIK, the hash join reverse to temp will slow query response time, so I need expert advice, if we increase the pga_aggregate_target so that HASH_AREA_SIZE will be raised to adequate to accommadate the driving table in this? howmuch size and should put us, it should be the same as the size of the array of conduct? or are there other work around the same? Note - the size of the driving table B is "~ 400GB.
----------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | ----------------------------------------------------------------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | | | | 10M(100)| | | | | 1 | LOAD TABLE CONVENTIONAL | | | | | | | | | | 2 | FILTER | | | | | | | | | | 3 | HASH JOIN | | 8223K| 1811M| | 10M (1)| 35:30:55 | | | | 4 | TABLE ACCESS STORAGE FULL | A_GT | 82 | 492 | | 2 (0)| 00:00:01 | | | | 5 | HASH JOIN | | 8223K| 1764M| 737M| 10M (1)| 35:30:55 | | | | 6 | PARTITION RANGE ITERATOR | | 8223K| 643M| | 10M (1)| 34:18:55 | KEY | KEY | | 7 | TABLE ACCESS STORAGE FULL| B | 8223K| 643M| | 10M (1)| 34:18:55 | KEY | KEY | | 8 | TABLE ACCESS STORAGE FULL | C_GT | 27M| 3801M| | 118K (1)| 00:23:48 | | | -----------------------------------------------------------------------------------------------------------------------------------
Find plans by trial and error is not an efficient use of the time - and if it was a good idea to avoid joins and hash, then Oracle have set up their in the first place. I can understand your DBA with a yen to avoid, however, because any spill of a hash for disc often join a (relative) effect much more important than you might expect. In this case, however, you have a loop nested in A_GT which operates 39M times to access a table of 82 lines index - clearly (a) CPU work to achieve would be reduced if you included table columns in the index definition, but more significantly the cost of CPU of the A_GT/C_GT join would drop if you have built a hash in memory of A_GT table that is not a hash join.
What you ask for is a description of how to optimize a warehouse of data on Exadata machine - a forum is not the right place for this discussion; all I can say is that you and your databases need to do some testing to find out the best way to match queries to the Exadata has, so keep an eye on queries that produces the application in case of change of usage patterns. There are a few trivial generalities that anyone could offer:
(a) partitioning a day is good, so you can ensure that your queries are able to do partitioning to remove only the days where they want; even better is if there is a limited set of partitions that you can
(b) e/s for joins of large hash spilling to disk can be catastrophic compared to the underlying i/o for tablescans for the first access to the data, which means that simple queries can give the impression that Exadata is incredibly fast (especially when the index the flash cache and storage are effective), but slightly more complex queries are surprisingly slow in comparison.
(c) once you have passed the flash server cell cache, single block reads are very large and slow - queries that do a lot of single e/s (viz: big reports using nested against randomly scattered data loops joins) can cause very slow IO.
You must know the data types, know the general structure of your queries, be ready to generate of materialized views for derived complex data and understand the strengths and weaknesses of the Exadata.
Concerning
Jonathan Lewis
-
change the selected column puts loop nested in the hash join
Hi all
If "select * from...". «I "select table.* of...» "then plan changes.
Why change if the cost to access the complete table OFFERS is identical in the two plans?PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------------- SQL_ID a4fgvz5w6b0z8, child number 0 ------------------------------------- select * from ofertas ofe, ofertas_renting ofer where ofer.codigodeempresa = ofe.codigodeempresa AND ofer.numerooferta = ofe.numerooferta AND ofe.captacion = '1' Plan hash value: 3056192218 ---------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem | ---------------------------------------------------------------------------------------------------------------------------------------- |* 1 | HASH JOIN | | 1 | 23766 | 4032 (2)| 27421 |00:00:00.96 | 5444 | 9608K| 1887K| 10M (0)| |* 2 | TABLE ACCESS FULL| OFERTAS | 1 | 23969 | 1324 (2)| 27421 |00:00:00.14 | 2140 | | | | | 3 | TABLE ACCESS FULL| OFERTAS_RENTING | 1 | 71297 | 937 (2)| 72385 |00:00:00.22 | 3304 | | | | ---------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("OFER"."CODIGODEEMPRESA"="OFE"."CODIGODEEMPRESA" AND "OFER"."NUMEROOFERTA"="OFE"."NUMEROOFERTA" AND SYS_OP_DESCEND("OFER"."NUMEROOFERTA")=SYS_OP_DESCEND("OFE"."NUMEROOFERTA")) 2 - filter("OFE"."CAPTACION"='1') 22 filas seleccionadas. PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 2410uqu059fgw, child number 0 ------------------------------------- select ofe.* from ofertas ofe, ofertas_renting ofer where ofer.codigodeempresa = ofe.codigodeempresa AND ofer.numerooferta = ofe.numerooferta AND ofe.captacion = '1' Plan hash value: 4206210976 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | ---------------------------------------------------------------------------------------------------------------- | 1 | NESTED LOOPS | | 1 | 23766 | 1333 (3)| 27421 |00:00:00.58 | 33160 | |* 2 | TABLE ACCESS FULL| OFERTAS | 1 | 23969 | 1324 (2)| 27421 |00:00:00.27 | 3910 | |* 3 | INDEX UNIQUE SCAN| PK_OFERTAS_RENTING | 27421 | 1 | 0 (0)| 27421 |00:00:00.26 | 29250 | ---------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter("OFE"."CAPTACION"='1') 3 - access("OFER"."CODIGODEEMPRESA"="OFE"."CODIGODEEMPRESA" AND "OFER"."NUMEROOFERTA"="OFE"."NUMEROOFERTA") 22 filas seleccionadas.
Thank you very much.
Joaquin Gonzalez
Published by: Joaquín González on November 4, 2008 17:32Joaquín González wrote:
HelloPerhaps the reason for Blevel = 0 is?
"This is."
some common cases that could result in a variation between the basic formula and the
"result:...
"Index where the blevel is set to 1 (the index goes directly from the root block in the).
leaf blocks). The optimizer ignores effectively the blevel if each column in the index
appears in a predicate of equality. "Joaquin,
you're referring to the chapter "access Simple B-tree", it is a nested loop operation, so this does not apply. You can see that the 'Simple B-tree access' refers to a cost of 1, you have tested yourself.
I think that it is a special case, if you have a nested loop operation that uses access unique index as the source of the inner line, then the cost of access unique index is simply BLEVEL - 1. You might get a different cost if access additional table of rowid is involved, which is usually the case. But even in this case access to the unique index is always encrypted in BLEVEL - 1, and access the table by rowid is usually encrypted to 1 by iteration.
You can see on page 313 (chapter "Nested Loop") that Jonathan has used an example involving a unique index scan that also has a cost of 0.
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/ -
Hi all
I'll ask very quick question, can I use the hash join to two tables with access by index as noop nested? Is this possible?
For example:
HASH JOIN
TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
* EditionThank you
Of course, you can, if you do reference it:
orclz > set autot traceonly exp
orclz > create index emp_ename_i on emp (ename);
The index is created.
orclz > create index dept_dname_i on dept (dname);
The index is created.
orclz > select / * + use_hash (emp dept) * / * from emp join natural dept where dname = 'SALES' and ename = 'MILLER ';
Execution plan
----------------------------------------------------------
Hash value of plan: 937889317
-----------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 117. 4 (0) | 00:00:01 |
|* 1 | HASH JOIN | | 1. 117. 4 (0) | 00:00:01 |
| 2. TABLE ACCESS BY ROWID INDEX BATCH | EMP | 1. 87. 2 (0) | 00:00:01 |
|* 3 | INDEX RANGE SCAN | EMP_ENAME_I | 1. | 1 (0) | 00:00:01 |
| 4. TABLE ACCESS BY ROWID INDEX BATCH | DEPT | 1. 30. 2 (0) | 00:00:01 |
|* 5 | INDEX RANGE SCAN | DEPT_DNAME_I | 1. | 1 (0) | 00:00:01 |
-----------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("EMP".") DEPTNO "=" DEPT ". ("' DEPTNO ')
3 - access("EMP".") ENAME "= 'MILLER')
5 - access("DEPT".") DNAME "= 'SALES')
Note
-----
-the dynamic statistics used: dynamic sampling (level = 4)
-
Hi friends,
If I have a table T1 and T2 table. Table T1 is to have 100 rows and table T2 has 20 rows. When you make a hash join, what table should be used to make the hash table, a larger or smaller, and why? IF the data set is too small for consideration then please keep table T1 with 10 million rows and the table T2 with 1 million rows.
Thanks as always :)If you are a developer: "the database optimizer chooses."
If you are a student: http://tahiti.oracle.com ' read the docs... we are not helping people cheat on tests. "
-
HP ProLiant DL360 G5 - should "fully buffered" memory modules ECC?
Hello
I hope I'm asking in the right forum, and I hope that my question isn't distracting.
We have 2 servers ESX 3.5 clocked at 2 servers "HP ProLiant DL360 G5" with 4 GB of RAM each.
We bought 4 GB of RAM to each server.
I understand that we need ECC DDR2-667 RAM, but I don't know if "fully buffered" modules more expensive are necessary.
Someone please have a Board how do I know? Esxcfg-info shows:
+ Host:
\==+Hardware info:
.........
|----Product Name............................................. ProLiant DL360 G5
........
\==+Memory info:
|----Page Size............................................. 4096 pages
|----Total Pages........................................... 978518 pages
|----Free Pages............................................ 457894 pages
|----Shared Pages.......................................... 417076 pages
|----Common Pages.......................................... 198808 pages
|----Heap Size............................................. 7680 pages
|----Heap Free............................................. 2217 pages
| - Map Free... pages of 1996
| - Size of the kernel Code... 1536 pages
|----System Mem............................................ 45120 pages
|----Num Nodes............................................. 1 knots
|----Physical Mem.......................................... 4293222400 bytes
|----Vmkernel Mem.......................................... 4008009728 bytes
| - Vmkernel free Mem... 1875533824 bytes
| - Service Console Mem... 272 MB
| - Service Console (Cfg) Mem... 272 MB
\==+Aux source memory Stats:
| - The physical memory is... 4192600 kilobytes
| - Service Console memory... 278528 kilobytes
| - Kernel memory... 3914072 kilobytes
| - Waived by VMkernel... 4 kilobytes
| - Mmap thing... kilobytes 26624
|----Mmap Buddy......................................... 4840 kilobytes
| - Core region Code... 6144 kilobytes
| - Benefits of core at the beginning... 3096 KB
| - Data of kernel and lot... 30720 kilobytes
|----Other Kernel....................................... 109056 kilobytes
|----Nonkernel.......................................... 1902012 kilobytes
|----Free............................................... 1831576 kilobytes
And unfortunately, there is no "lshw".
Thank you
Alex
Hello
HP have a few useful pages for their servers, I keep these around as reference, they are called Quickspecs... lists lots of interesting information about the server and its components..., it's the quickspec for the DL360 G5 it seems only the fully buffered collection list... so you may be stuck with requiring that...
__________________________________________________________________________________________
See my blog at http://www.ridethevirt.blogspot.com
-
Implementation plan: suddenly no information displayed more predicates
Hello readers of the forum.
on one of my 10.2.0.4 databases, I suddenly cannot display the main information of an execution plan more.
I tried with this script, as I have always done:
Unfortunately, the result is:=============== set timing on; set serveroutput off; set termout off; SELECT /*+ gather_plan_statistics */ table_name from user_tables; set termout on; select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST')); ===============
As you can see, no leaders of the asterisks that follow any don't predicate infromation.SQL_ID cjgkchwa4vpnm, child number 0 ------------------------------------- SELECT /*+ gather_plan_statistics */ table_name from user_tables Plan hash value: 4190597607 -------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | Reads | -------------------------------------------------------------------------------------------------------------------------------- | 1 | HASH JOIN RIGHT OUTER | | 1 | 1147 | 3172 (1)| 99 |00:00:00.20 | 12197 | 367 | | 2 | TABLE ACCESS FULL | USER$ | 1 | 123 | 3 (0)| 123 |00:00:00.01 | 9 | 0 | | 3 | HASH JOIN OUTER | | 1 | 1147 | 3169 (1)| 99 |00:00:00.20 | 12188 | 367 | | 4 | NESTED LOOPS OUTER | | 1 | 1147 | 2241 (1)| 99 |00:00:00.15 | 7970 | 367 | | 5 | HASH JOIN OUTER | | 1 | 1147 | 2241 (1)| 99 |00:00:00.15 | 7970 | 367 | | 6 | HASH JOIN | | 1 | 1147 | 761 (1)| 99 |00:00:00.05 | 1231 | 15 | | 7 | TABLE ACCESS FULL | TS$ | 1 | 25 | 8 (0)| 25 |00:00:00.01 | 31 | 0 | | 8 | NESTED LOOPS | | 1 | 1147 | 753 (1)| 99 |00:00:00.05 | 1200 | 15 | | 9 | MERGE JOIN CARTESIAN | | 1 | 1147 | 634 (1)| 656 |00:00:00.04 | 299 | 0 | | 10 | HASH JOIN | | 1 | 1 | 1 (100)| 1 |00:00:00.04 | 0 | 0 | | 11 | FIXED TABLE FULL | X$KSPPI | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 0 | 0 | | 12 | FIXED TABLE FULL | X$KSPPCV | 1 | 100 | 0 (0)| 1495 |00:00:00.01 | 0 | 0 | | 13 | BUFFER SORT | | 1 | 1147 | 634 (1)| 656 |00:00:00.01 | 299 | 0 | | 14 | TABLE ACCESS BY INDEX ROWID| OBJ$ | 1 | 1147 | 633 (0)| 656 |00:00:00.01 | 299 | 0 | | 15 | INDEX RANGE SCAN | I_OBJ2 | 1 | 1147 | 11 (0)| 656 |00:00:00.01 | 12 | 0 | | 16 | TABLE ACCESS CLUSTER | TAB$ | 656 | 1 | 1 (0)| 99 |00:00:00.01 | 901 | 15 | | 17 | INDEX UNIQUE SCAN | I_OBJ# | 656 | 1 | 0 (0)| 206 |00:00:00.01 | 658 | 0 | | 18 | TABLE ACCESS FULL | SEG$ | 1 | 32975 | 1479 (1)| 32527 |00:00:00.03 | 6739 | 352 | | 19 | INDEX UNIQUE SCAN | I_OBJ1 | 99 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | 0 | | 20 | TABLE ACCESS FULL | OBJ$ | 1 | 91731 | 927 (1)| 91727 |00:00:00.01 | 4218 | 0 | --------------------------------------------------------------------------------------------------------------------------------
On all other machines (this version and later), the result looks like:
.. that is what I want.SQL_ID cjgkchwa4vpnm, child number 0 ------------------------------------- SELECT /*+ gather_plan_statistics */ table_name from user_tables Plan hash value: 2241718361 -------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | -------------------------------------------------------------------------------------------------------------- |* 1 | HASH JOIN RIGHT OUTER | | 1 | 1129 | 284 (5)| 233 |00:00:00.05 | 3816 | | 2 | TABLE ACCESS FULL | USER$ | 1 | 41 | 2 (0)| 41 |00:00:00.01 | 5 | |* 3 | HASH JOIN OUTER | | 1 | 1129 | 281 (5)| 233 |00:00:00.05 | 3811 | | 4 | NESTED LOOPS OUTER | | 1 | 1129 | 230 (5)| 233 |00:00:00.04 | 3614 | |* 5 | HASH JOIN RIGHT OUTER | | 1 | 1129 | 230 (5)| 233 |00:00:00.04 | 3614 | | 6 | TABLE ACCESS FULL | SEG$ | 1 | 4723 | 37 (3)| 4723 |00:00:00.01 | 146 | |* 7 | HASH JOIN | | 1 | 1129 | 192 (5)| 233 |00:00:00.03 | 3468 | | 8 | TABLE ACCESS FULL | TS$ | 1 | 16 | 7 (0)| 16 |00:00:00.01 | 23 | | 9 | NESTED LOOPS | | 1 | 1129 | 185 (5)| 233 |00:00:00.02 | 3445 | | 10 | MERGE JOIN CARTESIAN| | 1 | 1129 | 54 (12)| 1950 |00:00:00.01 | 196 | |* 11 | HASH JOIN | | 1 | 1 | 1 (100)| 1 |00:00:00.01 | 0 | |* 12 | FIXED TABLE FULL | X$KSPPI | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 0 | | 13 | FIXED TABLE FULL | X$KSPPCV | 1 | 100 | 0 (0)| 1495 |00:00:00.01 | 0 | | 14 | BUFFER SORT | | 1 | 1129 | 54 (12)| 1950 |00:00:00.01 | 196 | |* 15 | TABLE ACCESS FULL | OBJ$ | 1 | 1129 | 53 (10)| 1950 |00:00:00.01 | 196 | |* 16 | TABLE ACCESS CLUSTER| TAB$ | 1950 | 1 | 1 (0)| 233 |00:00:00.01 | 3249 | |* 17 | INDEX UNIQUE SCAN | I_OBJ# | 1950 | 1 | 0 (0)| 763 |00:00:00.01 | 1952 | |* 18 | INDEX UNIQUE SCAN | I_OBJ1 | 233 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | | 19 | TABLE ACCESS FULL | OBJ$ | 1 | 14712 | 50 (4)| 14855 |00:00:00.01 | 197 | -------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("CX"."OWNER#"="CU"."USER#") 3 - access("T"."DATAOBJ#"="CX"."OBJ#") 5 - access("T"."FILE#"="S"."FILE#" AND "T"."BLOCK#"="S"."BLOCK#" AND "T"."TS#"="S"."TS#") 7 - access("T"."TS#"="TS"."TS#") 11 - access("KSPPI"."INDX"="KSPPCV"."INDX") 12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled') 15 - filter(("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)) 16 - filter(BITAND("T"."PROPERTY",1)=0) 17 - access("O"."OBJ#"="T"."OBJ#") 18 - access("T"."BOBJ#"="CO"."OBJ#")
So my question:
What affects the fact if the predicate information are displayed or not? The client is the same twice (tried with native SQL * more and Developer SQL 1.5.5).)
Any idea is appreciated, thanks in advance!
Martin KlierMartinKlier wrote:
Thanks for your response: they are empty!CN ID ACCESS_PREDICATES FILTER_PREDICATES --- --- ------------------------------ ------------------------------ 0 1 0 2 ... 1 20Best regards
MartinInteresting.
I see that Dominic Brooks gave you a suggestion on Oracle-L. try this script that uses his suggestion:
SPOOL OUTPUT.TXT ALTER SYSTEM FLUSH SHARED_POOL; ALTER SESSION SET "_cursor_plan_unparse_enabled"=FALSE; SELECT /*+ gather_plan_statistics */ table_name from user_tables; select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST')); COLUMN ACCESS_PREDICATES FORMAT A30 COLUMN FILTER_PREDICATES FORMAT A30 COLUMN ID FORMAT 99 COLUMN CN FORMAT 99 SELECT CHILD_NUMBER CN, ID, ACCESS_PREDICATES, FILTER_PREDICATES FROM V$SQL_PLAN_STATISTICS_ALL WHERE SQL_ID='cjgkchwa4vpnm' ORDER BY CHILD_NUMBER, ID; ALTER SESSION SET "_cursor_plan_unparse_enabled"=TRUE; SELECT /*+ gather_plan_statistics */ table_name from user_tables; select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST')); SELECT CHILD_NUMBER CN, ID, ACCESS_PREDICATES, FILTER_PREDICATES FROM V$SQL_PLAN_STATISTICS_ALL WHERE SQL_ID='cjgkchwa4vpnm' ORDER BY CHILD_NUMBER, ID; SPOOL OFFI see the following:
... SQL> ALTER SESSION SET "_cursor_plan_unparse_enabled"=FALSE; ... SQL_ID cjgkchwa4vpnm, child number 0 ------------------------------------- SELECT /*+ gather_plan_statistics */ table_name from user_tables Plan hash value: 2718527396 -------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | -------------------------------------------------------------------------------------------------------------- | 1 | HASH JOIN | | 1 | 1441 | 88 (12)| 395 |00:00:00.05 | 1475 | | 2 | TABLE ACCESS FULL | TS$ | 1 | 11 | 2 (0)| 11 |00:00:00.01 | 15 | | 3 | HASH JOIN RIGHT OUTER | | 1 | 1441 | 85 (11)| 395 |00:00:00.05 | 1460 | | 4 | TABLE ACCESS FULL | SEG$ | 1 | 5301 | 9 (0)| 5303 |00:00:00.01 | 156 | | 5 | HASH JOIN RIGHT OUTER | | 1 | 1441 | 75 (11)| 395 |00:00:00.04 | 1304 | | 6 | TABLE ACCESS FULL | USER$ | 1 | 154 | 2 (0)| 154 |00:00:00.01 | 15 | | 7 | NESTED LOOPS OUTER | | 1 | 1441 | 73 (11)| 395 |00:00:00.03 | 1289 | | 8 | HASH JOIN OUTER | | 1 | 1441 | 73 (11)| 395 |00:00:00.04 | 1289 | | 9 | HASH JOIN | | 1 | 1441 | 61 (10)| 395 |00:00:00.02 | 1078 | | 10 | TABLE ACCESS FULL | TAB$ | 1 | 2245 | 46 (3)| 2246 |00:00:00.01 | 892 | | 11 | MERGE JOIN CARTESIAN| | 1 | 1441 | 14 (29)| 986 |00:00:00.01 | 186 | | 12 | HASH JOIN | | 1 | 1 | 2 (100)| 1 |00:00:00.01 | 0 | | 13 | FIXED TABLE FULL | X$KSPPI | 1 | 1 | 1 (100)| 1 |00:00:00.01 | 0 | | 14 | FIXED TABLE FULL | X$KSPPCV | 1 | 1410 | 1 (100)| 1410 |00:00:00.01 | 0 | | 15 | BUFFER SORT | | 1 | 1441 | 13 (24)| 986 |00:00:00.01 | 186 | | 16 | TABLE ACCESS FULL | OBJ$ | 1 | 1441 | 12 (17)| 986 |00:00:00.01 | 186 | | 17 | TABLE ACCESS FULL | OBJ$ | 1 | 15853 | 11 (10)| 15855 |00:00:00.01 | 211 | | 18 | INDEX UNIQUE SCAN | I_OBJ1 | 395 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | -------------------------------------------------------------------------------------------------------------- ... CN ID ACCESS_PREDICATES FILTER_PREDICATES --- --- ------------------------------ ------------------------------ 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 0 16 0 17 0 18 ... SQL> ALTER SESSION SET "_cursor_plan_unparse_enabled"=TRUE; ... SQL_ID cjgkchwa4vpnm, child number 0 ------------------------------------- SELECT /*+ gather_plan_statistics */ table_name from user_tables Plan hash value: 2718527396 -------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | -------------------------------------------------------------------------------------------------------------- |* 1 | HASH JOIN | | 1 | 1441 | 88 (12)| 395 |00:00:00.05 | 1475 | | 2 | TABLE ACCESS FULL | TS$ | 1 | 11 | 2 (0)| 11 |00:00:00.01 | 15 | |* 3 | HASH JOIN RIGHT OUTER | | 1 | 1441 | 85 (11)| 395 |00:00:00.05 | 1460 | | 4 | TABLE ACCESS FULL | SEG$ | 1 | 5301 | 9 (0)| 5303 |00:00:00.01 | 156 | |* 5 | HASH JOIN RIGHT OUTER | | 1 | 1441 | 75 (11)| 395 |00:00:00.04 | 1304 | | 6 | TABLE ACCESS FULL | USER$ | 1 | 154 | 2 (0)| 154 |00:00:00.01 | 15 | | 7 | NESTED LOOPS OUTER | | 1 | 1441 | 73 (11)| 395 |00:00:00.03 | 1289 | |* 8 | HASH JOIN OUTER | | 1 | 1441 | 73 (11)| 395 |00:00:00.04 | 1289 | |* 9 | HASH JOIN | | 1 | 1441 | 61 (10)| 395 |00:00:00.02 | 1078 | |* 10 | TABLE ACCESS FULL | TAB$ | 1 | 2245 | 46 (3)| 2246 |00:00:00.01 | 892 | | 11 | MERGE JOIN CARTESIAN| | 1 | 1441 | 14 (29)| 986 |00:00:00.01 | 186 | |* 12 | HASH JOIN | | 1 | 1 | 2 (100)| 1 |00:00:00.01 | 0 | |* 13 | FIXED TABLE FULL | X$KSPPI | 1 | 1 | 1 (100)| 1 |00:00:00.01 | 0 | | 14 | FIXED TABLE FULL | X$KSPPCV | 1 | 1410 | 1 (100)| 1410 |00:00:00.01 | 0 | | 15 | BUFFER SORT | | 1 | 1441 | 13 (24)| 986 |00:00:00.01 | 186 | |* 16 | TABLE ACCESS FULL | OBJ$ | 1 | 1441 | 12 (17)| 986 |00:00:00.01 | 186 | | 17 | TABLE ACCESS FULL | OBJ$ | 1 | 15853 | 11 (10)| 15855 |00:00:00.01 | 211 | |* 18 | INDEX UNIQUE SCAN | I_OBJ1 | 395 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | -------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("T"."TS#"="TS"."TS#") 3 - access("T"."FILE#"="S"."FILE#" AND "T"."BLOCK#"="S"."BLOCK#" AND "T"."TS#"="S"."TS#") 5 - access("CX"."OWNER#"="CU"."USER#") 8 - access("T"."DATAOBJ#"="CX"."OBJ#") 9 - access("O"."OBJ#"="T"."OBJ#") 10 - filter(BITAND("T"."PROPERTY",1)=0) 12 - access("KSPPI"."INDX"="KSPPCV"."INDX") 13 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled') 16 - filter(("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)) 18 - access("T"."BOBJ#"="CO"."OBJ#") ... CN ID ACCESS_PREDICATES FILTER_PREDICATES --- --- ------------------------------ ------------------------------ 0 1 "T"."TS#"="TS"."TS#" 0 2 0 3 "T"."FILE#"="S"."FILE#" AND "T "."BLOCK#"="S"."BLOCK#" AND "T "."TS#"="S"."TS#" 0 4 0 5 "CX"."OWNER#"="CU"."USER#" 0 6 0 7 0 8 "T"."DATAOBJ#"="CX"."OBJ#" 0 9 "O"."OBJ#"="T"."OBJ#" 0 10 BITAND("T"."PROPERTY",1)=0 0 11 0 12 "KSPPI"."INDX"="KSPPCV"."INDX" 0 13 "KSPPI"."KSPPINM"='_dml_monito ring_enabled' 0 14 0 15 0 16 ("O"."OWNER#"=USERENV('SCHEMAI D') AND BITAND("O"."FLAGS",128 )=0) 0 17 0 18 "T"."BOBJ#"="CO"."OBJ#"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. -
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:
This query returned no data, however it - and subsequently, I also never knew that there was an inconsistency in the data, which would have had to go back to the lines.SELECT col1 FROM tab1 WHERE col1 NOT IN (SELECT col1 FROM tab2);
This was also proved/shown by the second query:
This query returned the expected difference. And this request is in fact identical to the first request!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:
and the correct lines to:SELECT * FROM tab1 WHERE tab1.col1 NOT IN (SELECT col1 FROM tab2) AND tab1.col1 = 'car';
After an hour of searching, trying to reproduce the problem, I was almost about to give up and send it to Oracle Support qualifying as a bug.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:
Whereas the execution plan of the query with the NOT EXISTS 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
See the difference?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:
seems to not work. Allthought the execution plan changes:alter session set "_optimizer_null_aware_antijoin" = false;
It will always return no line!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.
I have also written a ticket with the text above to http://managingoracle.blogspot.com-- 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
FJFrankenAs 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/ -
hash with very large internal table plan causes ORA-01652
Hello
We have a select with dubious plan:
SELECT * FROM T1 where T1. F1 in (select T2. F1 T2)
Plan:
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost |
| 0 | SELECT STATEMENT | 59 M | 12G | 1 401 K |
| 1. SEMI HASH JOIN | 59 M | 12G | 55G | 1 401 K |
| 2. TABLE ACCESS FULL | T1 | 260 M | 52G | 489K |
| 3. TABLE ACCESS FULL | T2 | 209K | 1843K | 84.
As you see a record 260 million (52 GB) T1 and T2 has approximately 200,000 records (approximately 2 MB)
Oracle chooses the hash with T1 inner table join. Thus all T1 is tempted to read first in memory.
And when the memory is full, the TEMP tablespace is filled.
And because the TEMP tablespace is less than 55 GB, an error has occurred:
ORA-01652: unable to extend segment temp of 128 in tablespace TEMP
Question:
Why oracle choose the hash with inner table so big join?
And how can we solve this problem?
Other notes:
T1 and T2 is analyzed today.
Presumably no index or table.
The database is Oracle 9i Enterprise.
Description of Oracle 9i hash (first there are more small table as you can see):
http://download.Oracle.com/docs/CD/B10501_01/server.920/a96533/optimops.htm#76074
THX: sides.Hello
Oracle 9i cannot make HASH JOIN RIGHT SEMI - were introduced in 10g.
---------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem | ---------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 |00:00:55.73 | 162K| 162K| | | | | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:55.73 | 162K| 162K| | | | |* 2 | HASH JOIN RIGHT SEMI| | 1 | 8147 | 0 |00:00:55.73 | 162K| 162K| 988K| 988K| 1031K (0)| | 3 | TABLE ACCESS FULL | T2 | 1 | 18 | 18 |00:00:00.01 | 3 | 0 | | | | | 4 | TABLE ACCESS FULL | T | 1 | 11M| 11M|00:02:09.99 | 162K| 162K| | | | ---------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("OBJECT_NAME"="USERNAME") -
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 table orders from clause
Hi all
Who is the effective way to join the tables in from clause. I have two tables first with 20 lakh records and second containing 10 lakh recods.
Who is the effective query 1 or 2. Please suggest me if you have an idea to rewrite the query.QUERY 1: SELECT T4.ID,T4.ISO_NAME FROM T,T4 WHERE T4.ISO_NAME LIKE '%US%' AND T.ID=T4.ID; QUERY 2: SELECT T4.ID,T4.ISO_NAME FROM T4,T WHERE T4.ID=T.ID AND T4.ISO_NAME LIKE '%US%'; T(ID IS PRIMARY KEY) (20 lakh records) T4 (ID IS PRIMARY KEY ) (10 lakh records) --------------------- ID ISO_NAME 100 US,UK,IN,BR 101 UK,US,BR,IN 102 BR,UK,US,IN Note: No index on ISO_NAME .
Kind regards
Rajasekhar
Published by: SuNRiZz68 on January 29, 2009 04:22In practical terms, Alex is right. Sometimes it matter what table is selected first, but does the CBO generally a very good job of deciding what you need to select the first (assuming that your statistics are up to date) but this is the situation you are trying to avoid as much as possible.
If you specify a table main command tables in the clause is not reliable and should be used - but think before using advice and don't do that when necessary.
Which table to select depends firstly on the join method in the execution plan. Nested loops joins perform better by selecting in the smaller table first, make a loop on the largest table. Joins the smaller set hash table in memory first, and then go through the larger table, perform searches in memory. He can't make any difference, what table is read using first the merger joins and sort.
Back to your original question. Using the cost-based optimizer, both queries will probably roll the same because newer versions of Oracle (9i, 10g) often transform queries for efficiency before the execution anyway. According to what do you or do not request should probably run a nested loop or hash join. With a small set of data creaing index and using a search of nested loops will probably be faster to avoid full table scans. the '%' in the LIKE clause leader would ignore an index on the ISO_NAME column in any case if a main column may be used in a composite index. All this is based on the approximation using the information provided; Tuning questions should always be tested to unexpected developments.
-
I am using version - 11.2.0.4.0 - Oracle.
I have below details of stats for the two tables with no histograms on columns
Table T1 - NUM_ROWS - 8 900 759
------------------------------
column_name num_nulls num_distinct density
C1 100800 0 9.92063492063492E - 6
0-7184 0.000139198218262806 C2
Table T2 - NUM_ROWS - 28835
---------------------------------
column_name num_nulls num_distinct density
C1 0 101 0.0099009900990099
0 39 0.0256410256410256 C2Query:
------Select * from T1, T2
WHERE t1.c1 = t2.c1;
Execution plan
----------------------------------------------------------
Hash value of plan: 4149194932--------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
--------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2546K | 675 M | | 65316 (1) | 00:13:04 | | |
|* 1 | HASH JOIN | | 2546K | 675 M | 5944K | 65316 (1) | 00:13:04 | | |
| 2. STORE TABLE FULL ACCESS | T2 | 28835 | 5603K | | 239 (1) | 00:00:03 | | |
| 3. RANGE OF PARTITION ALL THE | | 8900K | 670 M | | 26453 (1) | 00:05:18 | 1. 2.
| 4. STORE TABLE FULL ACCESS | T1 | 8900K | 670 M | | 26453 (1) | 00:05:18 | 1. 2.
--------------------------------------------------------------------------------------------------------------------------------
as the below rule says itsJoin selectivity =
((num_rows (t1) - num_nulls (t1.c1)) / (t1) num_rows) *.
((num_rows (t2) - num_nulls (t2.c2)) / (t2) num_rows).
Greater (num_distinct (T1. (C1), num_distinct (t2.c2))Join selectivity = (((28835-0) / (28835)) * ((8900759-0)/8900759)) / 100800)
Join cardinality = join selectivity * num_rows (t1) * num_rows (t2)
= (((28835-0) / (28835)) * ((8900759-0)/8900759)) / 100800) * (8900759 * 28835)
= 2546164.54, which corresponds to the output of the above plan.but when I add a different join condition as below, I am not able to understand, how the cardinality of the join becomes 28835? And what a difference it will behave in case of presence of histogram?
Select * from T1, T2
WHERE t1.c1 = t2.c1
and t1.c2 = t2.c2;
Execution plan
----------------------------------------------------------
Hash value of plan: 1645075573---------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 28835 | 7828K | | 65316 (1) | 00:13:04 | | |
|* 1 | HASH JOIN | | 28835 | 7828K | 5944K | 65316 (1) | 00:13:04 | | |
| 2. JOIN FILTER PART CREATE | : BF0000 | 28835 | 5603K | | 239 (1) | 00:00:03 | | |
| 3. STORE TABLE FULL ACCESS | T2 | 28835 | 5603K | | 239 (1) | 00:00:03 | | |
| 4. RANGE OF PARTITION-JOIN FILTER | | 8900K | 670 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
| 5. STORE TABLE FULL ACCESS | T1 | 8900K | 670 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
---------------------------------------------------------------------------------------------------------------------------------Total of selectivity = selectivity of c1 * c2 selectivity
= ((((28835 - 0)/(28835)) * ((8900759-0)/8900759))/ 100800)*((((28835 - 101)/(28835)) * ((8900759-0)/8900759))/ 7184)
total of cardinality = selectivity * num_rows (t1) * num_rows (t2) total
=
((((28835 - 0)/(28835)) * ((8900759-0)/8900759))/ 100800) * ((((28835 - 101)/(28835)) * ((8900759-0)/8900759))/ 7184) * (8900759) * ()28835) = 353.18 but its does not not at the outut above
--> C2 for table T2 is partitioned column. T1 is not partitioned.
--> There are two partitions of the range for the T2. And one of them is empty, the data resides in a single partition.
--> As a single partition is empty, so it would be to visit only one partition for the final results.
--> I use "set autotrace traceonly explain" to get the plan for the query.--> Here is the max and min for c1 and c2 for the T2 value
Max (C1) min (c1) (c2) max Min (c2)
86 383759 2/28 / 2011 23:59:38 28/02/2011 12:00:02 AMHere is the max and min for c1 and c2 for the T1 value
Max (C1) min (c1) (c2) max Min (c2)
4860 354087 2/28 / 2011 23:55:47 28/02/2011 12:07:49 AM--> Given below is the plan with the predicate section
Execution plan
----------------------------------------------------------
Hash value of plan: 1645075573---------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 28835 | 8166K | | 70364 (1) | 00:14:05 | | |
|* 1 | HASH JOIN | | 28835 | 8166K | 5944K | 70364 (1) | 00:14:05 | | |
| 2. JOIN FILTER PART CREATE | : BF0000 | 28835 | 5603K | | 239 (1) | 00:00:03 | | |
| 3. STORE TABLE FULL ACCESS | T1 | 28835 | 5603K | | 239 (1) | 00:00:03 | | |
| 4. RANGE OF PARTITION-JOIN FILTER | | 8900K | 772 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
| 5. STORE TABLE FULL ACCESS | T2 | 8900K | 772 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
---------------------------------------------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 - access("T2".") C2 '= 'T1'.' C2"AND"T2 ". ' C1 '= "T1". ("" C1 ")
--> I see below three values in all current data for Q2 of having County > 10 000
C1 C2 Count (*)
171966 2/28 / 2011 07:21:14 14990
41895 2/28 / 2011 08:41:36 12193
7408 2/28 / 2011 06:16:20 12158
53120 2/28 / 2011 06:16:13 7931
51724 2/28 / 2011 18:03:22 6783
51724 2/28 / 2011 18:02:58 6757
51724 2/28 / 2011 16:02:22 6451
51724 2/28 / 2011 16:02:01 6388
51724 2/28 / 2011 14:01:29 5979
234233 2/28 / 2011 07:21:14 5975
51724 2/28 / 2011 14:01:09 5917
7408 2/28 / 2011 06:16:13 5355
51724 2/28 / 2011 20:04:18 5074
51724 2/28 / 2011 20:03:54 5058I see below three values in the current data set for T1, which is to have County > 75
C1 C2 Count (*)
4860 2/28 / 2011 19:33:45
31217 2/28 / 2011 23:27:54
31217 2/28 / 2011 23:48:14
4860 2/28 / 2011 17:36:07
4860 2/28 / 2011 20:00:11
4860 2/28 / 2011 18:20:13
4860 2/28 / 2011 14:35:39
4860 2/28 / 2011 19:48:06
4860 2/28 / 2011 12:30:29
4860 2/28 / 2011 15:32:31
4860 2/28 / 2011 17:48:05
4860 2/28 / 2011 17:02:26
4860 2/28 / 2011 22:27:02--> Yes the join is targeted on the larger partition, because the other is just empty.
--> Here is the stats and the plan after having extended his stats collected on the Group column c1, c2 from T1 (by converting it to physics) with no histogram. now its giving a better estimate, which is the closure of real cardinality. But the problem is that in reality, table T1 is a global temporary table, so I'm not able to gather extended on that stat. Are there other work around for this quote?column_name density histogram Num_distinct
SYS_STUMW3X8MDKZEJOG$ AHPEND1W $2699 NO 0.000370507595405706
Execution plan
----------------------------------------------------------
Hash value of plan: 1645075573---------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 432K | 124 M | | 70380 (1) | 00:14:05 | | |
|* 1 | HASH JOIN | | 432K | 124 M | 6280K | 70380 (1) | 00:14:05 | | |
| 2. JOIN FILTER PART CREATE | : BF0000 | 28835 | 5941K | | 239 (1) | 00:00:03 | | |
| 3. STORE TABLE FULL ACCESS | T1 | 28835 | 5941K | | 239 (1) | 00:00:03 | | |
| 4. RANGE OF PARTITION-JOIN FILTER | | 8900K | 772 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
| 5. STORE TABLE FULL ACCESS | T2 | 8900K | 772 M | | 26453 (1) | 00:05:18 | : BF0000 | : BF0000 |
---------------------------------------------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 - access("T2".") C2 '= 'T1'.' C2"AND"T2 ". ' C1 '= "T1". ("" C1 ")
-
Partition wise joined possible with partitions of the interval?
Hello
I want to know the score wise join (NTC) is possible with interval partitioning - I can't find an explicit statement that he isn't, but I can't make it work - I did a simple test case to illustrate the issue.
below, I have 2 create table scripts - 1 for the case of interval and 1 for the case of hash - I then a simple query on these 2 objects which should produce a NTC.
In the case of hash, it works very well (see screenshot 2nd with a set of slaves), the first screenshot shows the case of the interval where I find myself with 2 sets of slaves and no NTC.
No idea if this is possible and I just missed something?
(for the test case choose the names of schema/storage appropriate for your system)
Oh and version (I almost forgot... :-))-East 11.2.0.4.1 SLES 11)
See you soon,.
Rich
-case interval
CREATE TABLE 'SB_DWH_IN '. "' TEST1 '.
TABLESPACE "SB_DWH_INTEGRATION".
PARTITION BY RANGE ("OBJECT_ID") INTERVAL (10000)
(PARTITION 'LESS_THAN_ZERO' VALUES LESS THAN (0) TABLESPACE "SB_DWH_INTEGRATION")
in select * from DBA_OBJECTS where object_id is not null;
CREATE TABLE 'SB_DWH_IN '. "" TEST2 ".
TABLESPACE "SB_DWH_INTEGRATION".
PARTITION BY RANGE ("OBJECT_ID") INTERVAL (10000)
(PARTITION 'LESS_THAN_ZERO' VALUES LESS THAN (0) TABLESPACE "SB_DWH_INTEGRATION")
in select * from DBA_OBJECTS where object_id is not null;
-case of hash
CREATE TABLE 'SB_DWH_IN '. "' TEST1 '.
TABLESPACE "SB_DWH_INTEGRATION".
8 partitions PARTITION OF HASH ("OBJECT_ID")
store in ("SB_DWH_INTEGRATION")
in select * from DBA_OBJECTS where object_id is not null;
CREATE TABLE 'SB_DWH_IN '. "" TEST2 ".
TABLESPACE "SB_DWH_INTEGRATION".
8 partitions PARTITION OF HASH ("OBJECT_ID")
store in ("SB_DWH_INTEGRATION")
in select * from DBA_OBJECTS where object_id is not null;
-query to run
Select / * + PARALLEL(TEST2,8) PARALLEL(TEST1,8) * / *.
of 'SB_DWH_IN '. "" TEST2 ","SB_DWH_IN ". "' TEST1 '.
where TEST1.object_id = test2.object_id
It is planned and a consequence of the estimate of the number of parallel slaves.
To the parallel 41 each slave made 3 passes (i.e. sleeves 3 partitions).
Add a partition (by table), and a set of slaves will have to manage a 4th pass: the cost of the query using NTC would increase from 33 percent even if the modification of the data is less than 0.8%.
I guess that in the production Oracle distributes your lines of 1 M for a hash join.
Because the decision is encrypted, it is possible that a very extreme tilt in partition in the table sizes billion line might overthrow the optimizer in a non - NTC join - but I have not tested that.
If you want to force the plan John Watson suggestion for a hint of pq_distribute is relevant. To cover all the bases and call your tables SMALL and LARGE
/*+
leading (FAT kid)
USE_HASH (large)
no_swap_join_inputs (large)
PQ_DISTRIBUTE (wide none none)
*/
If it's legal, that should do it.
Concerning
Jonathan Lewis
-
Bug with an outer join, or & Analytics function (or rownum)
Hello
Seems to be a combination of an outer join, OR and rownum confuses the CBO.
First request is without rownum, the second is with rownum.
The second query expects 203 t lines and never ends. It should behave the same as query 1, with 24 M lines.
Remove the GOLD clause query 2 allows him to behave as a query 1, with 24 M lines.
We never saw it? Is there a solution?
SELECT * FROM message i LEFT JOIN (SELECT hi.message_id, hi.update_dt FROM message_hist hi) h ON (t.id = h.master_id AND(t.update_dt = h.update_dt OR h.update_dt <TO_DATE('150901','RRMMDD'))); ----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 24M| 13G| 475G (2)|999:59:59 | | 1 | NESTED LOOPS OUTER | | 24M| 13G| 475G (2)|999:59:59 | | 2 | TABLE ACCESS FULL | MESSAGE | 8037K| 1318M| 29883 (2)| 00:06:59 | | 3 | VIEW | | 3 | 1302 | 59136 (2)| 00:13:48 | |* 4 | TABLE ACCESS FULL| MESSAGE_HIST | 3 | 168 | 59136 (2)| 00:13:48 | ----------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("I"."MESSAGE_ID"="HI"."MESSAGE_ID" AND ("HI"."UPDATE_DT"<TO_DATE('150901','RRMMDD') OR "I"."UPDATE_DT"="HI"."UPDATE_DT")) ---------------- SELECT * FROM message i LEFT JOIN (SELECT hi.message_id, hi.update_dt , ROWNUM FROM message_hist hi) h ON (t.id = h.master_id AND(t.update_dt = h.update_dt OR h.update_dt <TO_DATE('150901','RRMMDD'))); ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 203T| 112P| 475G (2)|999:59:59 | | 1 | NESTED LOOPS OUTER | | 203T| 112P| 475G (2)|999:59:59 | | 2 | TABLE ACCESS FULL | MESSAGE | 8037K| 1318M| 29883 (2)| 00:06:59 | | 3 | VIEW | | 25M| 10G| 59151 (2)| 00:13:49 | |* 4 | VIEW | | 25M| 10G| 59151 (2)| 00:13:49 | | 5 | COUNT | | | | | | | 6 | TABLE ACCESS FULL| MESSAGE_HIST | 25M| 1355M| 59151 (2)| 00:13:49 | ------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("I"."MESSAGE_ID"="H"."MESSAGE_ID" AND ("I"."UPDATE_DT"="H"."UPDATE_DT" OR "H"."UPDATE_DT"<TO_DATE('150901','RRMMDD')))RowNum in a subquery is supposed to ensure that the subquery is evaluated completely before filtering, otherwise, how could you go out rownum?
Your question is compounded because of the join condition that forces a level of nested loops, which means that the table should be fully analysed once for each line of conduct rowsource. You can either transform the join in an equijoin and allow a hash to run, or you join could materialize the subquery once.
Allow the hash join:
SELECT count (*)
Message FROM
LEFT JOIN (SELECT hi.message_id, hi.update_dt
ROWNUM
OF message_hist salvation) PM ON (i.message_id = h.message_id
AND i.update_dt = h.update_dt)
LEFT JOIN (SELECT hi.message_id, hi.update_dt
ROWNUM
OF message_hist salvation) h2 ON (i.message_id = h2.message_id
AND h2.update_dt<>
AND h2.update_dt <> i.update_dt)
/
----------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 66. 211 (1) | 00:00:01 |
| 1. GLOBAL TRI | | 1. 66. | |
|* 2 | EXTERNAL RIGHT HASH JOIN | | 800 | 52800 | 211 (1) | 00:00:01 |
|* 3 | VIEW | | 1. 22. 70 (0) | 00:00:01 |
| 4. COUNTY | | | | | |
| 5. TABLE ACCESS FULL | MESSAGE_HIST | 1. 22. 70 (0) | 00:00:01 |
|* 6 | EXTERNAL RIGHT HASH JOIN | | 800 | 35200. 141 (1) | 00:00:01 |
| 7. VIEW | | 1. 22. 70 (0) | 00:00:01 |
| 8. COUNTY | | | | | |
| 9. TABLE ACCESS FULL | MESSAGE_HIST | 1. 22. 70 (0) | 00:00:01 |
| 10. TABLE ACCESS FULL | MESSAGE | 800 | 17600 | 70 (0) | 00:00:01 |
----------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("I".") MESSAGE_ID '= 'H2'.' MESSAGE_ID "(+))"
filter ("H2". "UPDATE_DT" (+)<>'I'. " ("' UPDATE_DT")
3 - filter("H2".") UPDATE_DT "(+)<>
6 - access("I".") "UPDATE_DT" ="H" UPDATE_DT "(+) AND"
"I"." ' MESSAGE_ID ' ="H" MESSAGE_ID "(+))"
Materialize the subquery:
WITH h AS (SELECT / * + MATERIALIZE * / hi.message_id, hi.update_dt)
ROWNUM
OF message_hist salvation)
SELECT count (*)
Message FROM
LEFT JOIN: ON (i.message_id = h.message_id
AND (i.update_dt = h.update_dt OR h.update_dt<>
----------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 22. 1740 (0) | 00:00:01 |
| 1. TRANSFORMATION OF THE TEMPORARY TABLE. | | | | |
| 2. LOAD SELECT ACE | SYS_TEMP_0FD9D6810_5B8F6E67 | | | | |
| 3. COUNT | | | | | |
| 4. TABLE ACCESS FULL | MESSAGE_HIST | 1. 22. 70 (0) | 00:00:01 |
| 5. GLOBAL TRI | | 1. 22. | |
| 6. NESTED EXTERNAL LOOPS | | 800 | 17600 | 1670 (0) | 00:00:01 |
| 7. TABLE ACCESS FULL | MESSAGE | 800 | 17600 | 70 (0) | 00:00:01 |
| 8. VIEW | | 1. | 2 (0) | 00:00:01 |
|* 9 | VIEW | | 1. 22. 2 (0) | 00:00:01 |
| 10. TABLE ACCESS FULL | SYS_TEMP_0FD9D6810_5B8F6E67 | 1. 22. 2 (0) | 00:00:01 |
----------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
9 - filter("I".") ' MESSAGE_ID ' ="H" MESSAGE_ID' AND ('I'. "" "UPDATE_DT"="H" UPDATE_DT' OR
"H"." UPDATE_DT ".<>
You may need to change the first condition to make sure that you select the correct subquery.
-edit
Not able to view a plan but you can invade the second join condition select and then the result of a subquery with a predicate according to your requirement. This should delay the or rating and leave only an equijoin (although rowsource return may be slightly larger than the opposite).
-Second edition, it did not work exactly when I tried it.
A hybrid of the previous two plans with a slight modification of how he was imitating the GOLD:
WITH h AS (SELECT / * + MATERIALIZE * / hi.message_id, hi.update_dt)
ROWNUM Clotilde
OF message_hist salvation)
SELECT i.MESSAGE_ID
i.UPDATE_DT
COALESCE(h.message_id,h2.message_id) message_id
, COALESCE (h.update_dt, h2.update_dt) update_dt
Clotilde COALESCE (h.rown, h2.rown)
Message FROM
LEFT JOIN: ON (i.message_id = h.message_id
AND i.update_dt = h.update_dt)
LEFT JOIN: h2 WE (DECODE(h.message_id,,i.message_id) = h2.message_id - only try this if previous join returned NULL
AND h2.update_dt<>
/
--------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 66. 8 (0) | 00:00:01 |
| 1. TRANSFORMATION OF THE TEMPORARY TABLE. | | | | |
| 2. LOAD SELECT ACE | SYS_TEMP_0FD9D6605_28F27F | | | | |
| 3. COUNT | | | | | |
| 4. TABLE ACCESS FULL | MESSAGE_HIST | 150. 3300 | 2 (0) | 00:00:01 |
| 5. GLOBAL TRI | | 1. 66. | |
|* 6 | EXTERNAL RIGHT HASH JOIN | | 10497. 676K | 6 (0). 00:00:01 |
|* 7 | VIEW | | 150. 3300 | 2 (0) | 00:00:01 |
| 8. TABLE ACCESS FULL | SYS_TEMP_0FD9D6605_28F27F | 150. 3300 | 2 (0) | 00:00:01 |
|* 9 | OUTER HASH JOIN | | 328. 14432 | 4 (0) | 00:00:01 |
| 10. TABLE ACCESS FULL | MESSAGE | 200 | 4400 | 2 (0) | 00:00:01 |
| 11. VIEW | | 150. 3300 | 2 (0) | 00:00:01 |
| 12. TABLE ACCESS FULL | SYS_TEMP_0FD9D6605_28F27F | 150. 3300 | 2 (0) | 00:00:01 |
--------------------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------6 - access("H2".") MESSAGE_ID "(+) = DECODE (TO_CHAR ('H'". "))" MESSAGE_ID"), NULL, 'I '. (("' MESSAGE_ID '))
7 - filter("H2".") UPDATE_DT "(+)<>
9 - access("I".") "UPDATE_DT" ="H" UPDATE_DT "(+) AND 'I'." "" ' MESSAGE_ID '="H" MESSAGE_ID "(+))"(This plan is another system if costs are not comparable)
Maybe you are looking for
-
Logic stops when searching for media
I have a really weird problem. When I open the media browser, type a string of characters and press ENTER, logic stops immediately when I press the Enter key. I've recently updated to el capitan. Here are the first lines of the error message: Process
-
WIN 7 32 BIT DRIVER CHART FOR PAVILION DV9823CL
I DON'T THINK WIN 7 32 BIT DRIVER CHART FOR PAVILION DV9823CL
-
need to rest by car to its original merger
Greeting I get my iMac with a clean install and I think I re-partition my drive also. After more than a week, I noticed the difference in speed when running applications and start the system, I check my disk in disk utilities it shows two disks (disk
-
How can I set up a landing page for the guest network of wndr3400v2? Thank you in advance for your help!
-
HP G6 2240-sh gpu drivers does not properly
Dear HP, I bought a HP Pavilion G6 - 2240sh C6C63EA 3 months ago. I am quite satisfied with the performance of every day, but I always had problems with the display drivers. I have Windows 8 X 64 pro and a Windows X 64 pro also 8.1. First I used it w