NESTED LOOP or SORT MERGE

Hi All,
How can we judge which one is best to use for the query- NESTED LOOP
- SORT MERGE
- HASH JOINThanx.. Ratan

Hi...
For Nested Loop Joins:
Nested loop joins are useful when small subsets of data are being joined and if the join condition is an efficient way of accessing the second table.
It is very important to ensure that the inner table is driven from (dependent on) the outer table. If the inner table's access path is independent of the outer table, then the same rows are retrieved for every iteration of the outer loop, degrading performance considerably. In such cases, hash joins joining the two independent row sources perform better.
For Hash Join:
Hash joins are used for joining large data sets. The optimizer uses the smaller of two tables or data sources to build a hash table on the join key in memory. It then scans the larger table, probing the hash table to find the joined rows.
For Sort Merge Joins:
Sort merge joins can be used to join rows from two independent sources. Hash joins generally perform better than sort merge joins. On the other hand, sort merge joins can perform better than hash joins if both of the following conditions exist:
The row sources are sorted already.
A sort operation does not have to be done.
However, if a sort merge join involves choosing a slower access method (an index scan as opposed to a full table scan), then the benefit of using a sort merge might be lost.
Sort merge joins are useful when the join condition between two tables is an inequality condition (but not a nonequality) like <, <=, >, or >=. Sort merge joins perform better than nested loop joins for large data sets. You cannot use hash joins unless there is an equality condition.
In a merge join, there is no concept of a driving table. The join consists of two steps:
Sort join operation: Both the inputs are sorted on the join key.
Merge join operation: The sorted lists are merged together.
If the input is already sorted by the join column, then a sort join operation is not performed for that row source.

Similar Messages

Nested loop join v/s Sort merge

I have seen that nested loops are better if the inner table is being indexed, because for each outer table row, we are looking for a match in the inner table. But is there any case when optimizer still goes for a nested loop even if there is no index on the inner table. That is my first question ?
My second question := When doing a sort merge join oracle has to sort both result sets and then merge them. Oracle says that if both the row sets, if already sorted is definately better for performance. Ya thats obvious. But back to my upper question, when there is no index on the inner table, is it the situation when oracle goes for a sort merge join ?

My response should really have examples but since I do not have any handy I will just say about your first question. If there is no index available from table A to table B yes it is possible a nested loop join may still be used and table B read via full table scan within a nested loop. If table B is very small and consists of only a block or two this may be relatively efficient plan. It is more likely you sould see table B full scanned and the result feed into a hash join, but I have seen the plan you mention.
Back before hash joins were introduced with 7.3 (if my memory is correct) you would see sort/merge joins used more often than you do now. Generally speaking no index on the join conditions would exist for this option to be chosen.
If you really want to know why and sometimes what the optimizer is going to do buy Jonathan Lewis's book Cost-Based Oracle Fundamentals. If explains the optimizer in more depth than any other source I know of.
HTH -- Mark D Powell --

Is merge join cartesian more cpu intensibe than nested loop ?

Hi,
just wonderning which access method is more cpu intensive , lets supposed we got 2 the same row sources and doing joing via merge join cartesian and next case is nested loop .
I know NL can be cpu intensive because of tight loop access , but what abour MJC ?
I can see bufferd sort but not sure is that cpu friendly ?
Regards
GregG

Hi,
I think in your case it's more accurate to compare a NESTED LOOP (NL) to a MERGE JOIN (MJ), because CARTESIAN MERGE JOIN is a rather special case of MJ.
Merge join sorts its inputs before combining them, and it could be efficient when one or both of inputs are already sorted.
Regarding your question (which is more CPU intensive):
1) if MERGE JOIN involves disk spills, then CPU is probably irrelevant, because disk operations are much more expensive
2) the amount of work to combine rowsources via a MJ depends on how well they are aligned with respect to each other, so I don't think it can be expressed via a simple formula.
For nested loops, the situation is much more simple: you don't need to do any special work do combine the rowsource, so the cost is just the sum of the cost acquiring the outer rowsource plus the number of iterations times the cost of one iteration. If the data is read from disk, then CPU probably won't matter much, if most of reads are logical ones than CPU becomes of a factor (it's hard to tell how much work CPU will have to do per one logical read because there are two many factors here -- how many columns are accessed, how they are located within the block, are there any expensive math functions applied to any of them etc.)
Best regards,
Nikolay

Nested loop, merge join and harsh join

Can any one tell me the difference/relationship between nested loop, harsh join and merge join...Thanx

Check Oracle Performance Tuning Guide
13.6 Understanding Joins
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/optimops.htm#i51523

HASH JOIN or NESTED LOOP

I've been asked to check if HASH JOIN is more suitable than NESTED LOOP(which CBO chose by default) for the following query.
SELECT CM_DETAILS.TASK_ID FROM GEN_TYPE, CM_DETAILS WHERE ( ( ( ( ( CM_DETAILS.STAT_CODE < 8 ) AND ( GEN_TYPE.TASK_ID = CM_DETAILS.TASK_ID ) ) AND ( GEN_TYPE.DEST_LOCN_ID = 5 ) ) AND ( GEN_TYPE.COM_ID = 7 ) ) AND ( ( ( CM_DETAILS.CASE_NO = 1 ) OR ( CM_DETAILS.CASE_NO = 3 ) ) OR ( CM_DETAILS.CASE_NO = 9 ) ) )
Both GEN_TYPE and CM_DETAILS tables have over 330,000 rows.
Version: 10g R2
Any thoughts?

As gintsp gave you very nice tip but there is initialization parameter " OPTIMIZER_INDEX_COST_ADJ" which cause what path to be chose for CBO,but usually expert says for changing init paramter setting should be at last resort.
It has default value of 100 which indicates to the CBO that indexed access is 100% as costly (i.e., equally costly) as FULL table scan access.
SQL> column plan_plus_exp format a100
SQL> set linesize 1000
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT e.ename,d.dname
2 FROM emp e,dept d
3 WHERE e.deptno=d.deptno
4 /
14 rows selected.
Execution Plan
 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=10 Bytes=320)
 1 0 HASH JOIN (Cost=7 Card=10 Bytes=320)
 2 1 TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=3 Card=5 Bytes=90)
 3 1 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=196)
Statistics
 672 recursive calls
 0 db block gets
 151 consistent gets
 27 physical reads
 0 redo size
 793 bytes sent via SQL*Net to client
 508 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 15 sorts (memory)
 0 sorts (disk)
 14 rows processed
SQL> /
14 rows selected.
Execution Plan
 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=10 Bytes=320)
 1 0 HASH JOIN (Cost=7 Card=10 Bytes=320)
 2 1 TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=3 Card=5 Bytes=90)
 3 1 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=196)
Statistics
 0 recursive calls
 0 db block gets
 15 consistent gets
 0 physical reads
 0 redo size
 793 bytes sent via SQL*Net to client
 508 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 0 sorts (memory)
 0 sorts (disk)
 14 rows processed
SQL> SHOW PARAMETER optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.1.0
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100<--------
optimizer_mode string ALL_ROWS
SQL> ALTER SESSION SET optimizer_index_cost_adj=35
2 /
Session altered.
SQL> SELECT e.ename,d.dname
2 FROM emp e,dept d
3 WHERE e.deptno=d.deptno
4 /
14 rows selected.
Execution Plan
 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=5 Card=10 Bytes=320)
 1 0 MERGE JOIN (Cost=5 Card=10 Bytes=320)
 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT' (TABLE) (Cost=1 Card=5 Bytes=90)
 3 2 INDEX (FULL SCAN) OF 'DEPT_PRIMARY_KEY' (INDEX (UNIQUE)) (Cost=1 Card=5)
 4 1 SORT (JOIN) (Cost=4 Card=14 Bytes=196)
 5 4 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=196)
Statistics
 1 recursive calls
 0 db block gets
 11 consistent gets
 1 physical reads
 0 redo size
 733 bytes sent via SQL*Net to client
 508 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 1 sorts (memory)
 0 sorts (disk)
 14 rows processed
SQL> /
14 rows selected.
Execution Plan
 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=5 Card=10 Bytes=320)
 1 0 MERGE JOIN (Cost=5 Card=10 Bytes=320)
 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT' (TABLE) (Cost=1 Card=5 Bytes=90)
 3 2 INDEX (FULL SCAN) OF 'DEPT_PRIMARY_KEY' (INDEX (UNIQUE)) (Cost=1 Card=5)
 4 1 SORT (JOIN) (Cost=4 Card=14 Bytes=196)
 5 4 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=196)
Statistics
 0 recursive calls
 0 db block gets
 11 consistent gets
 0 physical reads
 0 redo size
 733 bytes sent via SQL*Net to client
 508 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 1 sorts (memory)
 0 sorts (disk)
 14 rows processedKhurram

Sort-Merge outer join, why? when?

Hi All,
How Oracle runs/optimizes outer joins has always been my subject of curiocity.
In Oracle documentation V 10.1 -> Performance tuning guide -> Chap. 14 ( The Query Optimizer) -> Go almost at the bottom
There is a small section of "Sort Merge outer joins".
It has a sentence
"When an outer join cannot drive from the outer (preserved) table to the inner (optional) table, it cannot use a hash join or nested loop joins. Then it uses the sort merge outer join for performing the join operation"
Can you help me understanding this ??
Thanks in advance

You actually need a sort-merge join sometimes: a join on inequality can't be run as a hash join, and may be very inefficient as a nested loop.
e.g.
select ...
where del.delivery_date between ord.order_date + 5 and ord.order_date + 8Unfortunately there are other cases where a sort merge join could be a very efficient join mechansim - because of suitable indexes - but the optimizer won't take it because there is a bug (from my perspective, at any rate) in the cost for sorting.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

How to disable nested loop option on a 10gR2 OLAP environment?

is it possible to disable nested loop option on a 10gR2 OLAP environment? There are some thousands of automatically generated report queries and whenever a join is needed we want to force hash join if possible(equality) or sort merge but never nested loop. optimizer sometimes can go for NL because of broken ETL, last steps as collecting statistics can not be finished successfully before the users start to do their reporting.
of course looking for a global parameter and do not want to hint each and every possible report query :)
thank you.

In general, connections that use a thin (type 4) JDBC driver will bypass the tnsnames.ora and sqlnet.ora files because they don't need those files to exist. One of the primary benefit of the type 4 JDBC drivers is that the Java code's connection string is fully specified in Java and doesn't depend on configuration files outside the JVM. So I wouldn't be surprised that any Java-based application could use the EZConnect syntax.
It is not obvious to me, though, why EZConnect would bypass any SSL tunnel that you had established. Assuming that you've instructed your client to send all traffic on a particular port going to a particular IP address to use a tunnel, I'm not sure why (or how) EZConnect syntax would bypass that. I would tend to expect that the problem was with the SSL tunnel configuration but perhaps I'm missing something on the network side.
Justin

Explain Plan shows Nested Loops, Is it good or bad?

Hi All,
I have a doubt in the explain plan, I would like to know if the Nested Loops , will it degrade the query performance?
Note: I have pasted only few output that I had taken from the expalin plan.
Do let me know if there is any article I could read to get clear understanding about the same.
17 NESTED LOOPS ANTI Cost: 125 Bytes: 186 Cardinality: 1
15 NESTED LOOPS ANTI Cost: 124 Bytes: 166 Cardinality: 1
12 NESTED LOOPS Cost: 122 Bytes: 140 Cardinality: 1
     9 NESTED LOOPS Cost: 121 Bytes: 117 Cardinality: 1
Thanks

Hi,
there is absolutely nothing wrong about nested loops (NL). It's a very efficient way of combining data from two rowsources. It works pretty much like a regular loop: it takes all rows from one rowsource (the "outer" one) and for each of them it looks up a row matching the join condition in the other rowsource (the "inner" one).
Note that there are not so many alternatives in Oracle: there are only 3 ways to join data in Oracle, and one of them is used in rather special circumstances (merge join). So normally the choice is between a NL and a hash join. Hash join (HJ) takes the smaller dataset and builds an in-memory lookup table using a hash function on join column(s). Then it goes through the other dataset and as it goes, it applies the hashing function to join column(s) and picks the matching rows from the smaller dataset.
Actually, hash joins and nested loops are not all that different. The basic mechanism is same: you go through one datasource and as you go, you pick matching rows from the other and do the join. The main difference is that a HJ requires some preparation work (it costs resources to build the in-memory table) and thus HJ are typically associated with less-selective queries and full table scans.
In your particular case it's nor possible to tell whether or not NL is in order based on just a few rows from the explain plan. We need to know the structure of your tables (the DDL), what kind of data they hold (optimizer stats) and what query you are running to be able to tell.
Best regards,
Nikolay

Hi how to avoid nested loops in this program to improve the performence

Hi all
How to avoide the nested loops in this programing what is the replacement for the nested loops in this program coding......
LOOP AT itb_ekpo.
 READ TABLE itb_marc WITH KEY
 matnr = itb_ekpo-matnr
 werks = itb_ekpo-werks BINARY SEARCH.
 CHECK sy-subrc = 0.
FAE 26446 fin remplacement
 itb_pca-ebeln = itb_ekpo-ebeln.
 itb_pca-ebelp = itb_ekpo-ebelp.
itb_pca-lifnr = itb_ekko-lifnr. "-FAE26446
 itb_pca-lifnr = itb_ekpo-lifnr. "+FAE26446
 itb_pca-ekgrp = itb_ekpo-ekgrp. "+FAE26446
 itb_pca-dispo = itb_ekpo-dispo. "+FAE26446
 itb_pca-matnr = itb_ekpo-matnr.
 itb_pca-werks = itb_ekpo-werks.
Recherche du libellé article
 READ TABLE itb_makt
 WITH KEY matnr = itb_ekpo-matnr
 spras = text-fra
 BINARY SEARCH.
 IF sy-subrc = 0.
 itb_pca-maktx = itb_makt-maktx.
 ELSE.
 READ TABLE itb_makt
 WITH KEY matnr = itb_ekpo-matnr
 spras = text-ang
 BINARY SEARCH.
 IF sy-subrc = 0.
 itb_pca-maktx = itb_makt-maktx.
 ENDIF.
 ENDIF.
 IF NOT itb_ekpo-bpumn IS INITIAL.
 itb_pca-menge = itb_ekpo-menge * itb_ekpo-bpumz /
 itb_ekpo-bpumn.
 ENDIF.
Sélect° ds la table EKES des dates de livraisons et des qtés
en transit
 CLEAR w_temoin_ar.
 CLEAR w_etens.
 LOOP AT itb_ekes
 FROM w_index_ekes.
 IF itb_ekes-ebeln = itb_ekpo-ebeln
 AND itb_ekes-ebelp = itb_ekpo-ebelp.
 IF itb_ekes-ebtyp = text-arn.
 itb_pca-eindt = itb_ekes-eindt.
 w_temoin_ar = 'X'.
 ELSE.
 Si c'est une qté en transit alors on recupere
 la quantité et la date.
 IF itb_ekes-dabmg < itb_ekes-menge.
 itb_pca-qtran = itb_pca-qtran + itb_ekes-menge -
 itb_ekes-dabmg.
 ENDIF.
 IF itb_ekes-etens > w_etens.
 w_etens = itb_ekes-etens.
 itb_pca-dtran = itb_ekes-eindt.
 ENDIF.
 ENDIF.
 ELSEIF itb_ekes-ebeln > itb_ekpo-ebeln
 OR ( itb_ekes-ebeln = itb_ekpo-ebeln
 AND itb_ekes-ebelp > itb_ekpo-ebelp ).
 w_index_ekes = sy-tabix.
 EXIT.
 ENDIF.
 ENDLOOP.
S'il n'y a pas d'AR alors récupérat° de la date livraison dans EKET.
 LOOP AT itb_eket
 FROM w_index_eket.
 IF itb_eket-ebeln = itb_ekpo-ebeln
 AND itb_eket-ebelp = itb_ekpo-ebelp.
 IF w_temoin_ar IS INITIAL.
 itb_pca-eindt = itb_eket-eindt.
 ENDIF.
 itb_pca-slfdt = itb_eket-slfdt.
 Calcul du portefeuille fournisseur à partir de la
 qté commandée et la qté reçue
 itb_pca-attdu = itb_pca-attdu + itb_eket-menge -
 itb_eket-wemng.
 Calcul du montant du poste
 itb_pca-netpr = itb_ekpo-netpr * itb_pca-attdu.
 IF itb_ekpo-peinh NE 0.
 itb_pca-netpr = itb_pca-netpr / itb_ekpo-peinh.
 ENDIF.
 Calcul quantité réceptionnée.
 itb_pca-wemng = itb_pca-wemng + itb_eket-wemng.
 Calcul du retard en nombre de jours calendaires
 Le calcul du retard ne doit pas prendre en compte
 le jour de livraison
 ADD 1 TO itb_eket-eindt.
 IF NOT itb_pca-attdu IS INITIAL
 AND itb_eket-eindt LT sy-datum.
 Calcul du retard en nombre de jours ouvrés
 CLEAR w_retard.
 CALL FUNCTION 'Z_00_BC_WORKDAYS_PER_PERIOD'
 EXPORTING
 date_deb = itb_eket-eindt
 date_fin = sy-datum
 IMPORTING
 jours = w_retard.
 itb_pca-rtard = itb_pca-rtard + w_retard .
 ENDIF.
 ELSEIF itb_eket-ebeln > itb_ekpo-ebeln
 OR ( itb_eket-ebeln = itb_ekpo-ebeln
 AND itb_eket-ebelp > itb_ekpo-ebelp ).
 w_index_eket = sy-tabix.
 EXIT.
 ENDIF.
 ENDLOOP.
Recherche de la derniere date de livraison.
 LOOP AT itb_mseg
 FROM w_index_mseg.
 IF itb_mseg-ebeln = itb_ekpo-ebeln
 AND itb_mseg-ebelp = itb_ekpo-ebelp.
 READ TABLE itb_mkpf
 WITH KEY mblnr = itb_mseg-mblnr
 mjahr = itb_mseg-mjahr
 BINARY SEARCH.
 IF sy-subrc = 0.
 IF itb_mkpf-bldat > itb_pca-bldat.
 itb_pca-bldat = itb_mkpf-bldat.
 ENDIF.
 ENDIF.
 ELSEIF itb_mseg-ebeln > itb_ekpo-ebeln
 OR ( itb_mseg-ebeln = itb_ekpo-ebeln
 AND itb_mseg-ebelp > itb_ekpo-ebelp ).
 w_index_mseg = sy-tabix.
 EXIT.
 ENDIF.
 ENDLOOP.
 APPEND itb_pca.
 CLEAR itb_pca.
FAE26446 suppression parag. suivant
 ELSEIF itb_ekpo-ebeln > itb_ekko-ebeln.
 w_index_ekpo = sy-tabix.
 EXIT.
 ENDIF.
 ENDLOOP.
Fin FAE26446
ENDLOOP.
Thanks in advance for all.....

Hi
these are the performance tips
Instead of using nested Select loops it is often better to use subqueries.
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
 INTO SFLIGHT_WA
 FOR ALL ENTRIES IN T_SPFLI
 WHERE SEATSOCC < F~SEATSMAX
 AND CARRID = T_SPFLI-CARRID
 AND CONNID = T_SPFLI-CONNID
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
 WHERE SEATSOCC < F~SEATSMAX
 AND EXISTS ( SELECT * FROM SPFLI
 WHERE CARRID = F~CARRID
 AND CONNID = F~CONNID
 AND CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK' )
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
Internal Tables
1. Table operations should be done using explicit work areas rather than via header lines.
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
Point # 2
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Point # 3
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
Point # 5
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
Point # 6
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
Point # 7
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
 <WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
 WA-FLAG = 'X'.
 MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
Point # 8
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
 ADD: WA1-VAL1 TO WA2-VAL1,
 WA1-VAL2 TO WA2-VAL2.
 MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
 INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
Point # 9
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 10
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
 DELETE ITAB.
ELSE.
 PREV_LINE = WA.
ENDIF.
ENDLOOP.
Point # 11
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
Point # 12
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 13
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
Reward if usefufll

Partition pruning, Nested loops

Hi,
I am having a problem with getting partition pruning in a query. I've managed to dumb down the problem to two tables and a minimal query (see below).
Basically, I have a partitioned table "Yearly Facts", and a helper table "Current Year" that always contain 1 row. The sole purpose of this one row is to tell what the curent year is, what the previous year was and what the next year will be. (In the real problem, there are non-standard timeperiods, so one cannot just calculate previous and next by adding/subtracting 1 as would be possible in this example).
The following query is executed the way I want.
It performs a scan on current_year, and then nested loop into the facts. And partition pruning was happening.
select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
from yearly_fact_t a
      ,current_year b
where a.year_key = b.curr_year;
| Id | Operation                  | Name          | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT           |               |     1 |    39 |     4   (0)| 00:00:01 |       |    |
|   1 | SORT AGGREGATE            |               |     1 |    39 |            |          |       |    |
|   2 |   NESTED LOOPS             |               |     1 |    39 |     4   (0)| 00:00:01 |       |    |
|   3 |    INDEX FAST FULL SCAN    | SYS_C00247890 |     1 |    13 |     2   (0)| 00:00:01 |       |    |
|   4 |    PARTITION RANGE ITERATOR|               |     1 |    26 |     2   (0)| 00:00:01 |   KEY |   KEY |
|* 5 |     TABLE ACCESS FULL      | YEARLY_FACT_T |     1 |    26 |     2   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
   5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR")The following query is where I have my problem.
The basic xplan is the same, but for some reason the cbo gave up and decide to scan all partitions, which was not very scalable on production data :)
I would have thought that the plan would be the same.
select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
      ,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
from yearly_fact_t a
      ,current_year b
where a.year_key = b.curr_year
    or a.year_key = b.prev_year;
| Id | Operation             | Name          | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT      |               |     1 |    52 |    13   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE       |               |     1 |    52 |            |          |       |       |
|   2 |   NESTED LOOPS        |               |     4 |   208 |    13   (0)| 00:00:01 |       |       |
|   3 |    TABLE ACCESS FULL | CURRENT_YEAR |     1 |    26 |     4   (0)| 00:00:01 |       |       |
|   4 |    PARTITION RANGE ALL|               |     4 |   104 |     9   (0)| 00:00:01 |     1 |     6 |
|* 5 |     TABLE ACCESS FULL | YEARLY_FACT_T |     4 |   104 |     9   (0)| 00:00:01 |     1 |     6 |
Predicate Information (identified by operation id):
   5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" OR "A"."YEAR_KEY"="B"."PREV_YEAR")
-- drop table yearly_fact_t purge;
-- drop table current_year purge;
create table current_year(
   curr_year number(4) not null
,prev_year number(4) not null
,next_year number(4) not null
,primary key(curr_year)
,unique(prev_year)
,unique(next_year)
insert into current_year(curr_year, prev_year, next_year) values(2010, 2009, 2011);
commit;
create table yearly_fact_t(
   year_key     number(4) not null
,some_dim_key number    not null
,some_measure number    not null
partition by range(year_key)(
   partition p2007 values less than(2008)
,partition p2008 values less than(2009)
,partition p2009 values less than(2010)
,partition p2010 values less than(2011)
,partition p2011 values less than(2012)
,partition pmax values less than(maxvalue)
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2007,1, 10);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2008,1, 20);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2009,1, 30);
insert into yearly_fact_t(year_key, some_dim_key, some_measure) values(2010,1, 40);
commit; What can I do to get partition pruning to happen in the second query?
Or even better, what is it in my query that prevents it from happening?
We're running Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit.
Best regards
Ronnie

Hi Ronnie,
Check whether your statistics are up to date.
SQL> set autotrace traceonly exp
SQL> select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
2        ,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
3    from yearly_fact_t a
4        ,current_year b
5   where a.year_key = b.curr_year
6      or a.year_key = b.prev_year;
Execution Plan
Plan hash value: 229094315
| Id | Operation             | Name          | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT      |               |     1 |    52 |    10   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE       |               |     1 |    52 |            |          |       |       |
|   2 |   NESTED LOOPS        |               |     4 |   208 |    10   (0)| 00:00:01 |       |       |
|   3 |    TABLE ACCESS FULL | CURRENT_YEAR |     1 |    26 |     3   (0)| 00:00:01 |       |       |
|   4 |    PARTITION RANGE ALL|               |     4 |   104 |     7   (0)| 00:00:01 |     1 |     6 |
|* 5 |     TABLE ACCESS FULL | YEARLY_FACT_T |     4 |   104 |     7   (0)| 00:00:01 |     1 |     6 |
Predicate Information (identified by operation id):
   5 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" OR "A"."YEAR_KEY"="B"."PREV_YEAR")
Note
   - dynamic sampling used for this statement
SQL> set autotrace off
SQL> exec dbms_stats.gather_table_stats(user, 'current_year', estimate_percent=>100, cascade=>true, method_opt
=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'yearly_fact_t', estimate_percent=>100, cascade=>true, method_op
t=>'for all columns size 1');
PL/SQL procedure successfully completed.
SQL> set autotrace traceonly exp
SQL> select sum(decode(a.year_key, b.curr_year, some_measure)) as curr_year_measure
2        ,sum(decode(a.year_key, b.prev_year, some_measure)) as prev_year_measure
3    from yearly_fact_t a
4        ,current_year b
5   where a.year_key = b.curr_year
6      or a.year_key = b.prev_year;
Execution Plan
Plan hash value: 2253546831
| Id | Operation                   | Name          | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT            |               |     1 |    15 |     8   (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE             |               |     1 |    15 |            |          |       |       |
|   2 |   CONCATENATION             |               |       |       |            |          |       |       |
|   3 |    NESTED LOOPS             |               |     1 |    15 |     4   (0)| 00:00:01 |       |       |
|   4 |     TABLE ACCESS FULL       | CURRENT_YEAR |     1 |     8 |     3   (0)| 00:00:01 |       |       |
|   5 |     PARTITION RANGE ITERATOR|               |     1 |     7 |     1   (0)| 00:00:01 |   KEY |   KEY |
|* 6 |      TABLE ACCESS FULL      | YEARLY_FACT_T |     1 |     7 |     1   (0)| 00:00:01 |   KEY |   KEY |
|   7 |    NESTED LOOPS             |               |     1 |    15 |     4   (0)| 00:00:01 |       |       |
|   8 |     TABLE ACCESS FULL       | CURRENT_YEAR |     1 |     8 |     3   (0)| 00:00:01 |       |       |
|   9 |     PARTITION RANGE ITERATOR|               |     1 |     7 |     1   (0)| 00:00:01 |   KEY |   KEY |
|* 10 |      TABLE ACCESS FULL      | YEARLY_FACT_T |     1 |     7 |     1   (0)| 00:00:01 |   KEY |   KEY |
Predicate Information (identified by operation id):
   6 - filter("A"."YEAR_KEY"="B"."PREV_YEAR")
10 - filter("A"."YEAR_KEY"="B"."CURR_YEAR" AND LNNVL("A"."YEAR_KEY"="B"."PREV_YEAR"))
SQL> set autotrace off
SQL>Asif Momen
http://momendba.blogspot.com

Need nested loop's solution....

hi..
i have done following coding for my one senario..i've used nested loop.but can anyone pls give me other solution than nested loop statement?
i dont wnat to use nested loop...
SELECT WI_ID WI_STAT WI_CD WI_AAGENT FROM SWWWIHEAD "FETCHING WORK ITEM DATA FROM THE SWWWIHEAD
 INTO TABLE IT_SWWWIHEAD
 WHERE WI_CD IN SO_WI_CD.
SORT IT_SWWWIHEAD.
IF SY-SUBRC = 0.
 LOOP AT IT_SWWWIHEAD INTO WA_SWWWIHEAD.
 CALL FUNCTION 'SWI_GET_DEPENDENT_WORKITEMS' "FUNCTION MODULE TO GET DEPENDENT WORK ITEM ID, IF ANY.
 EXPORTING
 WI_ID = WA_SWWWIHEAD-WI_ID
 TABLES
 DEPENDENT_WIS = IT_SWWWIHEAD_D.
 IF IT_SWWWIHEAD_D IS NOT INITIAL.
 DELETE IT_SWWWIHEAD_D WHERE WI_TYPE <> 'W'.
 SORT IT_SWWWIHEAD_D.
 LOOP AT IT_SWWWIHEAD_D INTO WA_SWWWIHEAD_D.
 CALL FUNCTION 'SAP_WAPI_READ_CONTAINER' "FUNCTION MODULE TO GET DATA FROM EVERY DEPENDENT ID.
 EXPORTING
 WORKITEM_ID = WA_SWWWIHEAD_D-WI_ID
 LANGUAGE = SY-LANGU
 USER = SY-UNAME
 IMPORTING
 RETURN_CODE =
 IFS_XML_CONTAINER =
 IFS_XML_CONTAINER_SCHEMA =
 TABLES
 SIMPLE_CONTAINER = IT_SIM_CONT
 MESSAGE_LINES =
 MESSAGE_STRUCT =
 SUBCONTAINER_BOR_OBJECTS =
 SUBCONTAINER_ALL_OBJECTS = IT_SUBCONTAINER
 READ TABLE IT_SIM_CONT
 INTO WA_SIM_CONT WITH KEY ELEMENT = '_WI_RESULT'. "getting the result(approved or rejected).
 IF SY-SUBRC = 0.
 IF wa_sim_cont-value = '0001'.
 WA_FINAL-WI_STAT = 'APPROVED'.
 ELSEIF WA_SIM_CONT-VALUE = '0002'.
 WA_FINAL-WI_STAT = 'REJECTED'.
 ENDIF.
 ENDIF.
 READ TABLE IT_SUBCONTAINER
 INTO WA_SUBCONTAINER WITH KEY ELEMENT = 'SODATA'. "getting SO DOCUMENT for this workitem.
 IF SY-SUBRC = 0.
 WA_FINAL-WI_AAGENT = WA_SWWWIHEAD_D-WI_AAGENT.
 ENDIF.
 WA_FINAL-WI_ID = WA_SWWWIHEAD-WI_ID.
 WA_FINAL-WI_ID_D = WA_SWWWIHEAD_D-WI_ID.
 WA_FINAL-WI_CD = WA_SWWWIHEAD-WI_CD.
 WA_FINAL-WI_SO = wa_subcontainer-value+0(10).
 WA_FINAL-WI_RESULT = WA_SIM_CONT-VALUE.
 SELECT SINGLE VKORG MAHDT FROM VBAK
 INTO (VKORG, MAHDT)
 WHERE VBELN = WA_FINAL-WI_SO.
 IF SY-SUBRC = 0.
 WA_FINAL-WI_VKORG = VKORG.
 IF MAHDT <> '00000000'.
 WA_FINAL-WI_FINAL_RESULT = 'OK'.
 ELSE.
 WA_FINAL-WI_FINAL_RESULT = 'PENDING'.
 ENDIF.
 ENDIF.
 APPEND WA_FINAL TO IT_FINAL.
 CLEAR WA_FINAL.
 ENDLOOP.
 CLEAR IT_SWWWIHEAD_D[].
 CLEAR IT_SIM_CONT[].
 ENDIF.
 ENDLOOP. ENDIF.

hi sagar,
Pls go through the following explanations for understanding abt control level processing.
Control level processing is allowed within a LOOP over an internal table. This means that you can divide sequences of entries into groups based on the contents of certain fields.
Internal tables are divided into groups according to the sequence of the fields in the line structure. The first column defines the highest control level and so on. The control level hierarchy must be known when you create the internal table.
The control levels are formed by sorting the internal table in the sequence of its structure, that is, by the first field first, then by the second field, and so on. Tables in which the table key occurs at the start of the table are particularly suitable for control level processing.
The following diagram illustrates control level processing in a sorted table, where different field contents in the first three fields are indicated by different colors:
Each change of color in a column indicates a control level change in the corresponding hierarchy level. Within the processing block of a loop, you can use the control level statement AT to react to a control level change. This enables you to restrict statements to a certain set of lines. You can thus use the SUM statement to calculate totals from subsets of all lines.
The AT statement introduces a statement block that you end with the ENDAT statement.
AT <level>.
<statement block>
ENDAT.
You can react to the following control level changes:
<level>
Meaning
FIRST
First line of the internal table
LAST
Last line of the internal table
NEW <f>
Beginning of a group of lines with the same contents in the field <f> and in the fields left of <f>
END Of <f>
End of a group of lines with the same contents in the field <f> and in the fields left of <f>
You can use control level statements to react to control breaks in internal tables instead of programming them yourself with logical expressions. Within the loop, you must order the AT-ENDAT statement blocks according to the hierarchy of the control levels. If the internal table has the columns <f1>, <f 2>, ...., and if it is sorted by these columns, you must program the loop as follows:
LOOP AT <itab>.
AT FIRST. ... ENDAT.
 AT NEW <f1>. ...... ENDAT.
 AT NEW <f2 >. ...... ENDAT.
 <single line processing>
 AT END OF <f2>. ... ENDAT.
 AT END OF <f1>. ... ENDAT.
AT LAST. .... ENDAT.
ENDLOOP.
The innermost hierarchy level <single line processing> processes the table lines that do not correspond to a control level change. You do not have to use all control level statements. But you must place the used ones in the above sequence. You should not use control level statements in loops where the line selection is restricted by WHERE or FROM and TO. Neither should the table be modified during the loop.
If a control level field <fi> is not known until runtime, you can specify it dynamically as (<n i>) where <n i> contains the field of <f i>. If <n i> is empty at runtime, the criterion for changing the control level is ignored. You can restrict the search to partial fields by specifying offset and length.
If you are working with a work area <wa>, it does not contain the current line in the AT... ENDAT statement block. All character fields to the right of the current group key are filled with asterisks (*). All other fields to the right of the current group key contain their initial value.
Within an AT...ENDAT block, you can calculate the contents of the numeric fields of the corresponding control level using the SUM statement.
SUM.
You can only use this statement within a LOOP. If you use SUM in an AT - ENDAT block, the system calculates totals for the numeric fields of all lines in the current line group and writes them to the corresponding fields in the work area (see example in ). If you use the SUM statement outside an AT - ENDAT block (single entry processing), the system calculates totals for the numeric fields of all lines of the internal table in each loop pass and writes them to the corresponding fields of the work area. It therefore only makes sense to use the SUM statement in AT...ENDAT blocks.
If the table contains a nested table, you cannot use the SUM statement. Neither can you use it if you are using a field symbol instead of a work area in the LOOP statement.
Examples
DATA: BEGIN OF LINE,
 COL1 TYPE C,
 COL2 TYPE I,
 COL3 TYPE I,
 END OF LINE.
DATA ITAB LIKE HASHED TABLE OF LINE
 WITH UNIQUE KEY COL1 COL2.
LINE-COL1 = 'A'.
DO 3 TIMES.
LINE-COL2 = SY-INDEX.
LINE-COL3 = SY-INDEX ** 2.
INSERT LINE INTO TABLE ITAB.
ENDDO.
LINE-COL1 = 'B'.
DO 3 TIMES.
LINE-COL2 = 2 * SY-INDEX.
LINE-COL3 = ( 2 * SY-INDEX ) ** 2.
INSERT LINE INTO TABLE ITAB.
ENDDO.
SORT ITAB.
LOOP AT ITAB INTO LINE.
WRITE: / LINE-COL1, LINE-COL2, LINE-COL3.
AT END OF COL1.
 SUM.
 ULINE.
 WRITE: / LINE-COL1, LINE-COL2, LINE-COL3.
 SKIP.
ENDAT.
AT LAST.
 SUM.
 ULINE.
 WRITE: / LINE-COL1, LINE-COL2, LINE-COL3.
ENDAT.
ENDLOOP.
The output is:
A 1 1
A 2 4
A 3 9
A 6 14
B 2 4
B 4 16
B 6 36
B 12 56
 18 70
The program creates a hashed table ITAB, fills it with six lines, and sorts it. In the LOOP - ENDLOOP block, the work area LINE is output for each loop pass. The first field of the table key, COL1, is used for control level processing. The total for all numeric fields is always calculated when the contents of COL1 change and when the system is in the last loop pass.
DATA: BEGIN OF LINE,
 CARRID TYPE SBOOK-CARRID,
 CONNID TYPE SBOOK-CONNID,
 FLDATE TYPE SBOOK-FLDATE,
 CUSTTYPE TYPE SBOOK-CUSTTYPE,
 CLASS TYPE SBOOK-CLASS,
 BOOKID TYPE SBOOK-BOOKID,
 END OF LINE.
DATA ITAB LIKE SORTED TABLE OF LINE WITH UNIQUE KEY TABLE LINE.
SELECT CARRID CONNID FLDATE CUSTTYPE CLASS BOOKID
 FROM SBOOK INTO CORRESPONDING FIELDS OF TABLE ITAB.
LOOP AT ITAB INTO LINE.
AT FIRST.
 WRITE / 'List of Bookings'.
 ULINE.
ENDAT.
 AT NEW CARRID.
 WRITE: / 'Carrid:', LINE-CARRID.
 ENDAT.
 AT NEW CONNID.
 WRITE: / 'Connid:', LINE-CONNID.
 ENDAT.
 AT NEW FLDATE.
 WRITE: / 'Fldate:', LINE-FLDATE.
 ENDAT.
 AT NEW CUSTTYPE.
 WRITE: / 'Custtype:', LINE-CUSTTYPE.
 ENDAT.
 WRITE: / LINE-BOOKID, LINE-CLASS.
 AT END OF CLASS.
 ULINE.
 ENDAT.
ENDLOOP.
In this example, the sorted internal table ITAB is filled with data from the database table SBOOK using the Open SQL statement SELECT. The sequence of the columns in the internal table defines the control level hierarchy. Since the table key is the entire line, the sort sequence and the control level hierarchy are the same. The sequence of the AT-ENDAT blocks within the LOOP and ENDLOOP statements is important.
The output is as follows:
List of Bookings
Carrid: AA
Connid: 0017
Fldate: 1998/11/22
Custtype: B
00063509 C
00063517 C
00063532 F
00063535 F
Custtype: P
00063653 C
00063654 C
00063668 F
00063670 F
Fldate: 1998/29/11
Custtype: B
00064120 C
00064121 C
and so on.
pls reward if helpful.

Nested Loop in Oracle 11g

Hi All,
I recently upgraded my Oracle DB from 10.2.0.4 to 11.2.0.3 on Aix 6.1
My below query is very slow after the upgrade
select count(*) from v$lock where block > 0;
I compared the explain plan and found that in 11g its using HASH JOIN while in 10g its using Nested Loop
When I am giving NL hint in 11g its returning fast.
I check almost all optimizer related DB parameters and its all are same as it in 10g.
Has anyone faced this issue in your DB upgrade or help me to find the reason
Thanks in advance

user12207083 wrote:
Thanks
But how come explan plan change for dynamic views
ThanksOrdered hint used in case of that query extracting from multiple tables, To define driving of that particular tables.
There are changes in explain plan. Am in learning stage in PT, You can expect response from Jonathan Lewis
Am just comparing those two explain plans.
SQL> set timing on
SQL> select count(*) from v$lock t1;
COUNT(*)
 168
Elapsed: 00:00:00.01
SQL> select /*+ ordered */ count(*) from v$lock;
COUNT(*)
 168
Elapsed: 00:00:00.02
SQL>
SQL> set autotrace traceonly explain;
SQL> set line 500
SQL> select count(*) from v$lock t1;
Elapsed: 00:00:00.00
Execution Plan "Without HINT"
Plan hash value: 2329815124
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 50 | 1 (100)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 50 | | |
| 2 | NESTED LOOPS | | 1 | 50 | 1 (100)| 00:00:01 |
|* 3 | HASH JOIN | | 1 | 44 | 1 (100)| 00:00:01 |
|* 4 | FIXED TABLE FULL | X$KSUSE | 1 | 19 | 0 (0)| 00:00:01 |
| 5 | VIEW | GV$_LOCK | 10 | 250 | 0 (0)| 00:00:01 |
| 6 | UNION-ALL | | | | | |
|* 7 | FILTER | | | | | |
| 8 | VIEW | GV$_LOCK1 | 2 | 178 | 0 (0)| 00:00:01 |
| 9 | UNION-ALL | | | | | |
|* 10 | FIXED TABLE FULL | X$KDNSSF | 1 | 102 | 0 (0)| 00:00:01 |
|* 11 | FIXED TABLE FULL | X$KSQEQ | 1 | 102 | 0 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KTADM | 1 | 102 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KTATRFIL | 1 | 102 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KTATRFSL | 1 | 102 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KTATL | 1 | 102 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KTSTUSC | 1 | 102 | 0 (0)| 00:00:01 |
|* 17 | FIXED TABLE FULL | X$KTSTUSS | 1 | 102 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KTSTUSG | 1 | 102 | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FULL | X$KTCXB | 1 | 102 | 0 (0)| 00:00:01 |
|* 20 | FIXED TABLE FIXED INDEX| X$KSQRS (ind:1) | 1 | 6 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 3 - access("SADDR"="S"."ADDR")
 4 - filter("S"."INST_ID"=USERENV('INSTANCE'))
 7 - filter(USERENV('INSTANCE') IS NOT NULL)
10 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
11 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
12 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
13 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
14 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
15 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
16 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
17 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
18 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
19 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSPAFLG",1)<>0)
20 - filter("RADDR"="R"."ADDR")
SQL> select /*+ ordered */ count(*) from v$lock; "ORDERED HINT"
Elapsed: 00:00:00.01
Execution Plan
Plan hash value: 3174212559
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 50 | 1 (100)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 50 | | |
| 2 | NESTED LOOPS | | 1 | 50 | 1 (100)| 00:00:01 |
|* 3 | HASH JOIN | | 1 | 44 | 1 (100)| 00:00:01 |
| 4 | VIEW | GV$_LOCK | 10 | 250 | 0 (0)| 00:00:01 |
| 5 | UNION-ALL | | | | | |
|* 6 | FILTER | | | | | |
| 7 | VIEW | GV$_LOCK1 | 2 | 178 | 0 (0)| 00:00:01 |
| 8 | UNION-ALL | | | | | |
|* 9 | FIXED TABLE FULL | X$KDNSSF | 1 | 102 | 0 (0)| 00:00:01 |
|* 10 | FIXED TABLE FULL | X$KSQEQ | 1 | 102 | 0 (0)| 00:00:01 |
|* 11 | FIXED TABLE FULL | X$KTADM | 1 | 102 | 0 (0)| 00:00:01 |
|* 12 | FIXED TABLE FULL | X$KTATRFIL | 1 | 102 | 0 (0)| 00:00:01 |
|* 13 | FIXED TABLE FULL | X$KTATRFSL | 1 | 102 | 0 (0)| 00:00:01 |
|* 14 | FIXED TABLE FULL | X$KTATL | 1 | 102 | 0 (0)| 00:00:01 |
|* 15 | FIXED TABLE FULL | X$KTSTUSC | 1 | 102 | 0 (0)| 00:00:01 |
|* 16 | FIXED TABLE FULL | X$KTSTUSS | 1 | 102 | 0 (0)| 00:00:01 |
|* 17 | FIXED TABLE FULL | X$KTSTUSG | 1 | 102 | 0 (0)| 00:00:01 |
|* 18 | FIXED TABLE FULL | X$KTCXB | 1 | 102 | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FULL | X$KSUSE | 1 | 19 | 0 (0)| 00:00:01 |
|* 20 | FIXED TABLE FIXED INDEX| X$KSQRS (ind:1) | 1 | 6 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 3 - access("SADDR"="S"."ADDR")
 6 - filter(USERENV('INSTANCE') IS NOT NULL)
 9 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
10 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
11 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
12 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
13 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
14 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
15 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
16 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
17 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSOBFLG",1)<>0)
18 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
 BITAND("KSSPAFLG",1)<>0)
19 - filter("S"."INST_ID"=USERENV('INSTANCE'))
20 - filter("RADDR"="R"."ADDR")
SQL>

Avoiding Nested Loops

Hi all,
I want to populate a internal table with Header and Item Level Details. BKPF is the Header Table and BSEG is the Item Details table. Can this be done without using nested LOOPS?
Consider the Logic I am using.
SELECT bukrs
         belnr
         gjahr
         budat
         xblnr
         bktxt
         FROM   bkpf
         INTO TABLE t_bkpf
         WHERE      bukrs   IN p_bukrs " = p_bukrs
             AND    gjahr   IN p_gjahr "= p_gjahr
             AND    monat   IN p_monat " = p_monat
             AND    bstat    = space.
IF sy-subrc IS INITIAL.
    SORT t_bkpf BY bukrs belnr gjahr.
    SELECT bukrs
            belnr
            buzei
            gjahr
            hkont
            zlsch
            shkzg
            dmbtr
            FROM bseg
            INTO TABLE t_bseg
            FOR ALL ENTRIES IN t_bkpf
            WHERE     bukrs = t_bkpf-bukrs
               AND    gjahr = t_bkpf-gjahr
               AND    belnr = t_bkpf-belnr
               AND    hkont = w_hkont .
    IF sy-subrc IS INITIAL.
      SORT t_bseg BY bukrs belnr gjahr buzei.
    ENDIF.
ENDIF.
LOOP AT t_bkpf INTO wa_bkpf.
LOOP AT t_bkpf INTO wa_bkpf WHERE bukrs = wa_bkpf-bukrs
                              AND   belnr = wa_bkpf-belnr
                              AND   gjahr = wa_bkpf-gjahr.
      wa_final-bukrs    = wa_bkpf-bukrs.
      wa_final-budat    = wa_bkpf-budat.
      wa_final-belnr    = wa_bkpf-belnr.
      wa_final-shkzg    = wa_bseg-shkzg.
      wa_final-dmbtr    = wa_bseg-dmbtr.
      wa_final-xblnr    = wa_bkpf-xblnr.
      wa_final-bktxt    = wa_bkpf-bktxt.
      wa_final-hkont    = wa_bseg-hkont.
      wa_final-zlsch    = wa_bseg-zlsch.
   ENDLOOP.
ENDLOOP.
Thanks in advance.

Hai Arun try with the following code
SELECT
         bukrs
         belnr
         gjahr
         budat
         xblnr
         bktxt
         FROM   bkpf
         INTO TABLE t_bkpf
         WHERE   bukrs   IN p_bukrs " = p_bukrs
             AND gjahr   IN p_gjahr "= p_gjahr
             AND monat   IN p_monat " = p_monat
             AND bstat    = space.
IF sy-subrc IS INITIAL.
     SORT t_bkpf BY bukrs belnr gjahr.
endif.
if not t_bkpf[] is initial.
    SELECT
            bukrs
            belnr
            buzei
            gjahr
            hkont
            zlsch
            shkzg
            dmbtr
            FROM bseg
            INTO TABLE t_bseg
            FOR ALL ENTRIES IN t_bkpf
            WHERE     bukrs = t_bkpf-bukrs
               AND    belnr = t_bkpf-belnr
               AND    gjahr = t_bkpf-gjahr
               AND    hkont = w_hkont .
    IF sy-subrc IS INITIAL.
      SORT t_bseg BY bukrs belnr gjahr buzei.
    ENDIF.
loop at t_bkpf.
read table it_bseg with key   bukrs = t_bkpf-bukrs
                         AND    belnr = t_bkpf-belnr
                         AND    gjahr = t_bkpf-gjahr
                         binary search.
if sy-subrc = 0.
    wa_final-bukrs    = wa_bkpf-bukrs.
    wa_final-budat    = wa_bkpf-budat.
    wa_final-belnr    = wa_bkpf-belnr.
    wa_final-shkzg    = wa_bseg-shkzg.
    wa_final-dmbtr    = wa_bseg-dmbtr.
    wa_final-xblnr    = wa_bkpf-xblnr.
    wa_final-bktxt    = wa_bkpf-bktxt.
    wa_final-hkont    = wa_bseg-hkont.
    wa_final-zlsch    = wa_bseg-zlsch.
endif.
endloop.
Thanks & regards
Sreenivasulu P

Building Tree hierarchy Using nested loops and class cl_gui_column_tree

Hello gurus,
I want to create a tree report using custom container and class cl_gui_column_tree. I have read and understood the standard demo report which SAP has provided i.e. SAPCOLUMN_TREE_CONTROL_DEMO. But in this report all the levels nodes are created as constants and hardcoded. I want to create hierarchy using nested loops. For this i took one example of a hierarchy of VBAK-VBELN->VBAP-POSNR Like One sales order has many line items and each line item can have number of line items in billing plan.
I have done some coding for it.
FORM build_tree USING node_table TYPE treev_ntab
                                       item_table TYPE zitem_table.              " i created the zitem_table table type of mtreeitm in SE11.
DATA: node TYPE treev_node,
             item TYPE mtreeitm.
node-node_key = root.
CLEAR node-relatkey.
CLEAR node-relatship.
node-hidden = ' '.
node-disabled = ' '.
CLEAR node-n_image.
CLEAR node-exp_image.
node-isfolder = 'X'.
node-expander = 'X'.
APPEND node TO node_table.
item-node_key = root.
item-item_name = colm1.
item-class = cl_gui_column_tree=>item_class_text.
item-text = 'Root'.
APPEND item TO item_table.
item-node_key = root.
item-item_name = colm2.
item-class = cl_gui_column_tree=>item_class_text.
item-text = 'Amount'.
APPEND item TO item_table.
LOOP AT it_vbeln INTO wa_vbeln.
    node-node_key = wa_vbeln-vbeln.
    node-relatkey = root.
    node-relatship = cl_gui_column_tree=>relat_last_child.
    node-hidden = ' '.
    node-disabled = ' '.
    CLEAR node-n_image.
    CLEAR node-exp_image.
    node-isfolder = 'X'.
    node-expander = 'X'.
    APPEND node TO node_table.
    item-node_key = wa_vbeln-vbeln.
    item-item_name = colm1.
    item-class = cl_gui_column_tree=>item_class_text.
    item-text = wa_vbeln-vbeln.
    APPEND item TO item_table.
    item-node_key = wa_vbeln-vbeln.
    item-item_name = colm2.
    item-class = cl_gui_column_tree=>item_class_text.
    item-text = wa_vbeln-netwr.
    APPEND item TO item_table.
    LOOP AT it_posnr INTO wa_posnr.
    node-node_key = wa_posnr-posnr.
    node-relatkey = wa_vbeln-vbeln.
    node-relatship = cl_gui_column_tree=>relat_last_child.
    node-hidden = ' '.
    node-disabled = ' '.
    CLEAR node-n_image.
    CLEAR node-exp_image.
    node-isfolder = ' '.
    node-expander = ' '.
    APPEND node TO node_table.
    item-node_key = wa_posnr-posnr.
    item-item_name = colm1.
    item-class = cl_gui_column_tree=>item_class_text.
    item-text = wa_posnr-posnr.
    APPEND item TO item_table.
    item-node_key = wa_posnr-posnr.
    item-item_name = colm2.
    item-class = cl_gui_column_tree=>item_class_text.
    item-text = wa_posnr-netpr.
    APPEND item TO item_table.
    ENDLOOP.
ENDLOOP.
ENDFORM.
Now this program compiles fine and runs till there is only one level. That is root->vbeln. But when i add one more loop of it_posnr it gives me runtime error of message type 'X'. The problem i found was uniqueness of item-item_name as all the sales order have posnr = 0010. What could be done? I tried giving item_name unique hierarchy level using counters just like stufe field in prps eg. 10.10.10, 10.10.20,10.20.10,10.20.20,20.10.10 etc.. etc.. but still i am getting runtime error when i add one more hierarchy using nested loop. Plz guide.
Edited by: Yayati6260 on Jul 14, 2011 7:25 AM

Hello all,
Thanks the issue is solved. The node key was not getting a unique identification as nodekey. I resolved the issue by generating unique identification for each level. Thanks all,
Regards
Yayati Ekbote

Problem with Nested loop in Fox-Formula

Dear Experts,
Let s share the scenario :
MaterialGroups with following Keys for Example AAAA, BBBB, CCCC..., Materialgroups are selected in the 1st input ready query, which is assigned to DataProvider DP_1 in a webtemplate.
every Materialgroup has several Materials, for instance:
Materialgroup AAAA has following Materials: AAAA10, AAAA11, AAAA12, AAAA13...
Materials are selected in a second input ready Query, which is assigned to a second DataProvider DP_2 in the Same Webtemplate as the query 1.
Both Materialgroup and Material are based on the same Aggreagtion level and same real time cube.
I want to copy the input values for every MaterialGroup ( 1st query, DP_1) only to it s own Materials (2cond Query, DP_2).
To resolve this Issue i wrote the following Fox Formula code with a nested loop, however it does not work properly. when I m debugging the code, i could release that the second Loop was ignored.but wehn i replace the second loop (nested loop) with a fixed value it s seems to work properly
DATA MG1 TYPE MATG.<------ MaterialGroup
DATA MT1 TYPE MAT.<----
Material
DATA S1 TYPE STRING.
DATA S2 TYPE STRING.
DATA S3 TYPE STRING
DATA K TYPE F.
DATA Z TYPE F.
FOREACH MG1.
To check Materialgroup in debugger
S1= MG1.
BREAK-POINT.
K = {KEYfIG, #, MG1}.
BREAK-POINT.
FOREACH MT1. <----- if i set MT1 to a fixed value like AAAA11 then S3 get the wished value namely AAAA
S2 = MT1.
BREAK-POINT.
S3 = SUBSTR (MT1, 0, 4).
BREAK-POINT.
IF S1 = S3.
{KEYFIG, MT1, #} = K.
following Statement is only used To check in debugger if Material has become the same Materialgroup value
Z = {KEYFIG, MT1, #}.
BREAK-POINT.
ENDIF.
ENDFOR.
ENDFOR.
Thakns for any help
Frank
Edited by: FRYYYBM on Mar 17, 2011 10:54 PM
Edited by: FRYYYBM on Mar 17, 2011 11:06 PM

Hi,
Please try this way.
DATA MG1 TYPE MATG.<------ MaterialGroup
DATA MT1 TYPE MAT.<----
Material
DATA S1 TYPE STRING.
DATA S2 TYPE STRING.
DATA S3 TYPE STRING
DATA K TYPE F.
DATA Z TYPE F.
FOREACH MT1.
FOREACH MG1.
To check Materialgroup in debugger
S1= MG1.
BREAK-POINT.
K = {KEYfIG, #, MG1}.
BREAK-POINT.
FOREACH MT1. <----- if i set MT1 to a fixed value like AAAA11 then S3 get the wished value namely AAAA
S2 = MT1.
BREAK-POINT.
S3 = SUBSTR (MT1, 0, 4).
BREAK-POINT.
IF S1 = S3.
{KEYFIG, MT1, #} = K.
following Statement is only used To check in debugger if Material has become the same Materialgroup value
Z = {KEYFIG, MT1, #}.
BREAK-POINT.
ENDIF.
ENDFOR.
ENDFOR.
ENDFOR.
Thanks.
With regards,
Anand Kumar

NESTED LOOP or SORT MERGE

Similar Messages

Maybe you are looking for