OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

Dear all,
10.2.0.4 on solaris..
below is the trace file content.. Do I have to increase the SGA size considering this ?
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       93      0.01       0.01          0          0         10           0
Execute   1337      0.54       0.62          0          0         18           0
Fetch     5302   1498.35    2743.11   13049277 188386516          0        6631
total     6732   1498.90    2743.76   13049277 188386516         28        6631
Misses in library cache during parse: 21
Misses in library cache during execute: 55
   18 user SQL statements in session.
1119 internal SQL statements in session.
1137 SQL statements in session.Please advise
Kai

The bulk o the "Recursive Statements" load probably comes from the "18 user SQL statements in session".
Those are SQLs likely inside a PLSQL block / procedure.
Also, it seems that tracing was enabled after the PLSQL procedure began running (abd stopped before it completed ?)
Hemant K Chitale
(aka "hkchital" in forums)
http://hemantoracledba.blogspot.com

Similar Messages

Getting control totals for all the objects

Hi All,
1. I want to get the control totals for all the tables along with table names in Oracle
the below I google and found, but I am not aware of xml in Oracle, I tested this on small scott db it works fine
select
table_name,
to_number(
extractvalue(
xmltype(
dbms_xmlgen.getxml('select count(*) c from '||table_name)
),'/ROWSET/ROW/C')) count
from user_tables order by 1is the above query correct?
2. I want all the view name
This I can get it from user_views ( but I want for entire database excluding system views and only user created views)
select view_name from user_objects3. I want all the sporc name( including the ones in the package and stand alone)
I am not sure how to get this.

Be aware of the statement "Some columns in these views contain statistics that are generated by the DBMS_STATS package or ANALYZE statement."
See this page specially "Columns marked with an asterisk (*) are populated only if you collect statistics on the table with the ANALYZE statement or the DBMS_STATS package."
http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/statviews_2117.htm#REFRN20286
If your statistic is not updated, it can give you totally wrong impression.

Select FOR ALL ENTRIES statement cannot get duplicates entries

Hi all,
t_yxapy_fields consist of
inty field
0001 kostl
0002 perid
0008 ansal
0008 preas
0008 trfst
The following is the code for me to transfer the contents of t_yxapy_fields into t_pa_fields.
SELECT dbtab
      FROM t777d
      INTO TABLE t_pa_fields
      FOR ALL ENTRIES IN t_yxapy_fields
      WHERE infty = t_yxapy_fields-infty.
And t_pa_fields just ended up with
field   infty
pa0001
pa0002
pa0008
Question:The first table have 3 similar infotype 0008 but the result table only have one pa0008. I need to filled up acordingly as what table 1 have. I need another 2 pa0008 in my 2nd table. What is wrng with my Select for all entries statement here?
Edited by: Siong Chao on Mar 27, 2010 10:35 AM

This has nothing to do with duplicates in t777d.
Correct, I failed to recognize that table t777d has only infty as key as pointed out by Aby. Thus in your particular case my comment was misleading. In general though FOR ALL ENTRIES removes all duplicate rows from your result set.
If you want the other 2 values just loop t_yxapy_fields this table and read t_pa_fields and if record found add the other values to t_pa_fields table. --> will trigger performance tuning issue
I'm pretty sure if you'd code this, you won't run into any performance issues, so follow Aby's recipe. To be more concrete, here's what I'd do: Define a mapping table t777d_tab, which holds the translation from infty to dbtab:
types:
begin of T_T777D_VIEW,
    INFTY type T777D-INFTY,
    DBTAB type T777D-DBTAB,
end of T_T777D_VIEW.
data:
T777D_TAB type hashed table of T_T777D_VIEW with unique key INFTY.
Fill table t_pa_fields, typed using t_t777d_tab from above, from table t777d. Then loop over your table t_yxapy_fields (I'd use [LOOP AT ... ASSIGNING|http://help.sap.com/abapdocu_70/en/ABAPLOOP_AT_ITAB_RESULT.htm] instead of LOOP AT ... INTO) and for each entry get the corresponding DBTAB value from t777d_tab (again use the [READ TABLE ... ASSIGNING|http://help.sap.com/abapdocu_70/en/ABAPREAD_TABLE_OUTDESC.htm] variant) and build your result table t_pa_fields.
Anyhow, I suspect that even with less optimal coding (e.g. using just standard table for lookup of DBTAB values) you'd not see much of an performance impact, because it seems that your internal tables are most likely rather small...
Cheers, harald

Regarding 'Select .... for all entries' statement

Hi experts,
Can anyone suggest me that whether we can use two internal tables in 'Select .... for all entries' statement?

Hi,
You can use ranges instead of second for all entries.
Eg:
Say for example i need to write selec statement using fields from two int tables in where conidition namely itab1, itab2.
RANGES: r_vbeln FOR wa_tab1-vbeln.
LOOP AT itab1 INTO wa_tab1.
r_vbeln-sign = 'I'.
r_vbeln-option = 'EQ'.
r_vbeln-low = wa_tab1-vbeln.
APPEND r_vbeln.
ENDLOOP.
SELECT * FROM vbap INTO TABLE itab3
FOR ALL ENTRIES IN itab2
WHERE vbeln IN r_vbeln "range contains all vbeln from the table itab1
AND matwa = itab2-matwa.
Hope this helps you.
Regards,
Manoj Kumar P

Coupling INNER JOIN   with   FOR ALL ENTRIES statement

Hi All,
     I   am coupling   INNER JOIN with FOR ALL ENTRIES statement .....
     Would   you please highlight its implications ??   Is it a best practise ?
     Is it advicable to use MULTIPLE   INNER JOINs with a FOR ALL ENTRIES ???
    SORT itab BY matnr.
    IF NOT itab[] IS INITIAL.
      SELECT       epmatnr epebeln ep~ebelp
                   epwerks epmenge ep~netpr
                   ekps_psp_pnr ebbelnr eb~menge
                   INTO TABLE iekpo
                   FROM ekpo AS ep
                   INNER JOIN ekkn AS ek
                   ON ekebeln = epebeln
                   AND ekebelp = epebelp
                   INNER JOIN ekbe AS eb
                   ON     ebebeln = epebeln
                   AND    ebebelp = epebelp
                   AND    eb~bwart = '101'
                   FOR ALL ENTRIES IN itab
                   WHERE   ep~matnr = itab-matnr.
      IF sy-subrc EQ 0.
        SORT iekpo BY matnr werks.
        LOOP AT itab ASSIGNING <itab>.
          READ TABLE iekpo WITH KEY matnr = <itab>-matnr
                                    werks = <itab>-werks
                                    BINARY SEARCH.
          IF sy-subrc EQ 0.
            MOVE iekpo-matnr      TO   itab1-matnr.
            MOVE iekpo-ebeln      TO   itab1-ebeln.
            MOVE iekpo-ebelp      TO   itab1-ebelp.
            MOVE iekpo-netpr      TO   itab1-poprice.
            MOVE iekpo-werks      TO   itab1-werks.
            MOVE iekpo-menge      TO   itab1-menge1.
            MOVE iekpo-menge1     TO   itab1-menge2.
            MOVE iekpo-belnr      TO   itab1-belnr.
            MOVE iekpo-ps_psp_pnr TO   itab1-pspel.
            MOVE <itab>-pspel     TO   itab1-tpspel.
            MOVE <itab>-sobkz     TO   itab1-sobkz.
            MOVE <itab>-fo_qty    TO   itab1-fo_qty.
            MOVE <itab>-schgt     TO   itab1-schgt.
            MOVE <itab>-postp     TO   itab1-postp.
            MOVE <itab>-beskz     TO   itab1-beskz.
            pend_qty = iekpo-menge1 - iekpo-menge2.
            MOVE pend_qty         TO   itab1-pending.
            APPEND itab1.
            pend_qty = 0.
          ENDIF.
        ENDLOOP.
      ENDIF.
    ENDIF.
ENDIF.
Regards
Jaman
Edited by: ABAP Techie on Sep 15, 2008 12:39 PM
Edited by: ABAP Techie on Sep 15, 2008 12:41 PM

best practise ... don't know ... it is allowed and o.k.
If possible you should of coourse to have no FOR ALL ENTRIES at all !
Joins, there is no general rule, check indexes etc.
The first SORT, I don't that it help for anything, use it together with the delete adjacent duplicates if you expect duplicates in the driver table.
o.k., it can help, if there is a loop afterwards and an append inside, because the new table itab1 is then sorted.
Siegfried

Allowing duplicate in FOR ALL ENTRIES statement

Hi folks,
I am using a select query using FOR ALL ENTRIES statement. I could observe one entry is missing from the table data.When i checked that in the data base table, there are two duplicate records among which one entry is missed in the output data from the query.Is duplicates are restricted if we use FOR ALL ENTRIES statement ? Is there any key word like 'ALLOWING DUPLICATES' for this ? if not what is the solution for this.Could any body help me regarding this.
Thanks,
Shyam.
Edited by: Matt on Jul 9, 2009 1:27 PM

Hi Shyam,
In For all entries you should give unique records only.
sort your base table with key which you are passing in for all entries clause.
delete all duplicate entries.
Hope this will help .
Regards,
Vijay

Calculate Total for All Values in a Hierarchy Selection

In Fox, I want to calculate the total for multiple cost elements that are selected in a package with a hierarchy restriction. The total of the hierarchy will then be saved into another cost element.
Does anyone have a Fox logic that they would suggest?
Thanks very much!

Found a solution that works....
Basically I want to call all the hierarchy values in as reference data, and restict the package to only the account that I am creating.
Calculation for Total Sales ( Account 0000100000 )
HF000001 is the hierachy variable that contains all account to be totaled.
DATA ACT TYPE 0ACCOUNT.
DATA SUM TYPE F.
DATA COUNT TYPE I.
DATA INDEX TYPE I.
COUNT = VARC('HF000001').
INDEX = 0.
DO.
INDEX = INDEX + 1.
ACT = VARI('HF000001',INDEX).
SUM = SUM + .
IF INDEX = COUNT.
EXIT.
ENDIF.
ENDDO.
= SUM.

Problem with FOR ALL ENTRIES statement

Hi all
please find the problem in the select statement.
SELECT vbbe~vbeln
         vbap~vstel
         marc~dispo
         vbbe~matnr
         vbbe~kunnr
         vbbe~werks
         vbbe~mbdat
         vbbe~omeng
INTO TABLE l_t_dvbeln
FROM vbbe
INNER JOIN vbak
ON
vbbe~vbeln = vbak~vbeln
inner join vbap
on
vbbe~vbeln = vbap~vbeln and
vbbe~matnr = vbap~matnr
inner join marc
on
vbbe~matnr = marc~matnr and
vbbe~werks = marc~werks
FOR ALL entries IN g_t_stock
WHERE vbbe~matnr = g_t_stock-matnr
AND   vbbe~werks = g_t_stock-werks
AND   vbak~vkorg = g_t_stock-vkorg
AND   vbak~vtweg = g_t_stock-vtweg
AND   vbbe~kunnr = g_t_stock-kunnr
AND   vbbe~mbdat IN r_mbdat.
g_t_stock is having only one record i.e.,
g_t_stock-vstel = 'DF01'.
g_t_stock-dispo = 'DEI'.
g_t_stock-matnr = '00100833'.
g_t_stock-maktx = 'SAC (300X400)'.
g_t_stock-kunnr = '0000600431'.
g_t_stock-werks = 'PF71'.
g_t_stock-labst = '7727'.
g_t_stock-vkorg = 'SF71'.
g_t_stock-vtweg = 'IC'.
and r_mbdat has the date range as
r_mbdat-sign = I
r_mbdat-option = BT
r_mbdat-low = 15.05.2008
r_mbdat-high = 08.06.2008
In vbak vbap & marc tables i have only one record as per the above selection criteria.
in VBBE table i have 7 records which satisfies the above criteria. But the select staement retrieves only 5 records.
if we remove for all entries and hardcode the values in the select statement then it retrieves all 7 records.
can anybody help me.
what is the reason it is showing only 5 records.

Hi all
actually it has to retrieve the following records
VBELN      MATNR    KUNNR WERKS MBDAT    LABST
30001417     00100833     600431 PF71   15.05.2008   20.000
30001417     00100833     600431 PF71   15.05.2008   20.000
30001417     00100833     600431 PF71   22.05.2008   5.000
30001417     00100833     600431 PF71   22.05.2008   7.000
30001417     00100833     600431 PF71   27.05.2008 10.000
30001417     00100833     600431 PF71   27.05.2008 10.000
30001417     00100833     600431 PF71   29.05.2008 10.000
But it is retrieving only 5 records as below
VBELN      MATNR    KUNNR WERKS MBDAT    LABST
30001417     00100833     600431 PF71   15.05.2008   20.000
30001417     00100833     600431 PF71   22.05.2008   5.000
30001417     00100833     600431 PF71   22.05.2008   7.000
30001417     00100833     600431 PF71   27.05.2008 10.000
30001417     00100833     600431 PF71   29.05.2008 10.000
Please give the reason

I have 3 guest lists names. How do I create a total for each list and a fourth total for all of them combined?

I am getting married and I want to stay organized. I have a spread sheet for my guest list. It is 3 columns/lists (my family, his family, and friends). How do I make a running total of each list and a fourth total of all of them combined?
Thanks so much!!!!

If I understand your problem you want to keep a list for the bride, the groom and friends as well as a total of all guests.
The total is the easiest. If you have the other three numbers then you can use the function SUM() to add those three together.
The rest of the problem is solved by assumeing:
1) the lists are in columns
2) the header does not count in the total
taking the difference of the total rows and the blank rows minus 1 will give you the total guest names in the a column.
The contents of cell:
C2 =ROWS(Bride)-COUNTBLANK(Bride)-1
C3=ROWS(Groom)-COUNTBLANK(Groom)-1
C4=ROWS(Friends)-COUNTBLANK(Friends)-1
C5=SUM(G2:G4)

Select for all entries statement

Hi
can some one send me a for allentries staterment for the following :
Tables : cvers, cvers_ref.
common field component.
very urgent.
points will be given....

Hi!
DATA: gt_cvers LIKE STANDARD TABLE OF cvers,
gs_cvers LIKE LINE OF gt_cvers.
DATA: gt_cvers_ref LIKE STANDARD TABLE OF cvers_ref,
gs_cvers_ref LIKE LINE OF gt_cvers_ref.
SELECT-OPTIONS: s_comp FROM cvers-component.
SELECT * FROM cvers INTO TABLE gt_cvers
WHERE compnent IN s_comp.
IF sy-subrc = 0.
SELECT * FROM cvers_ref INTO TABLE gt_cvers_ref
FOR ALL ENTRIES IN gt_cvers
WHERE component = gt_cvers-component AND langu = sy-langu.
ENDIF.
Regards
Tamá

PNGs for all three states of a picture button

Heyup.
I'm using the SDK CS3 for InDesign/InCopy, I'm currently using it for plugin development in InCopy only, and I'm using the InCopy CS3 Debug version on MacOS X 10.4.10.
I made a button based on RollOverIconButtonWidget and used something like
resource PNGA(123) "button_normal.png"
resource PNGR(123) "button_rollover.png"
To set its icon and change it on mouse rollover. My question now is: how can I add a PNG for the third state, when the mousebutton is pressed on the button?
Any directions would be appreciated.
Oliver

So, i go on:
sym.setVariable( "info", 0 ); //now: info=0
var infoVar = sym.getVariable( "info" ); //now: infoVar=0
infoVar = 1; //now: infoVar=1
sym.setVariable( "info", "infoVar" ); //now: info="infoVar". The info variable contains the string infoVar.
var infoVar = sym.getVariable( "info" ); // now: infoVar="infoVar"
Therefore,
sym.setVariable( "info", infoVar ); //now: info contains the value of infoVar; info, here, is a variable.
sym.getVariable( "info" ); //now: this line will return a number.

I need to supress the printing of a blank page if the total for an AR Statement is 0 or null.

I have an issue where the XML file for the R03B5001 AR Statement is outputting records with Header information, (name and address), but the total due for the statement is 0. I have been able to suppress the printing of the header, and detail in my template, but it still generates a single blank page. How can I suppress the printing of this page?

Thanks for your answer. Instead of formatting through FireFox, I had to go in and format it via the printer. Duh! Feel stupid not doing this first. If any one else has this problem, I was able to set it up on the printer by going to Printers > Printer Properties > Printer Preferences and set it up. Good luck and thank you for your reply.

How do you link several totals in various tables to create a summary total for all tables?

I have several tables like an expense form, expenses, meals, and mileage. How do I enter them in a Pages document and get the totals to update to a summary of all expenses in the same document?
Charles Smith

You open iWork Formulas and Functions User Guide.
Yes, what a surprise, the user guides are also for you
You will learn that there is no way to do what you ask in a Pages document.
You are forced to work in a Numbers one.
If I remember well, searching with an obscure keyword like reference brings us to a table describing the different syntax required to extract values from cells.
Yvan KOENIG (VALLAURIS, France) dimanche 24 juillet 2011 16:21:15
iMac 21”5, i7, 2.8 GHz, 4 Gbytes, 1 Tbytes, mac OS X 10.6.8
Please : Search for questions similar to your own before submitting them to the community
To be the AW6 successor, iWork MUST integrate a TRUE DB, not a list organizer !

Tuning PL/SQL - tkprof shows much more work for RECURSIVE STATEMENTS

Hi,
Firstly I'm not sure if this should be in "Database - General" or "SQL and PL/SQL". Since it's more of a performance tuning question than specifically about the PL/SQL, I'm going to put it here in "Database - General". I hope that doesn't offend anyone.
I've just started looking at a reported performance problem in our app. One of the developers set me up a procedure that replicates the issue, I ran it while tracing the session and then fed the trace file to tkprof. The results at the bottom of my tkprof output file look like this:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.07         10         60          0           0
Execute      3      0.01       0.01          0          3          0           3
Fetch        0      0.00       0.00          0          0          0           0
total        6      0.03       0.08         10         63          0           3
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       5        0.00          0.00
SQL*Net message from client                     4        1.68          1.70
db file sequential read                        18        0.01          0.10
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse      416      0.00       0.01          0          0          2           0
Execute   1456      0.71       0.75         26       1739        425         590
Fetch     2932      0.12       2.21        337       6338          0        3061
total     4804      0.84       2.98        363       8077        427        3651
Misses in library cache during parse: 25
Misses in library cache during execute: 24
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                       343        0.08          2.09
db file scattered read                          1        0.00          0.00
   47 user SQL statements in session.
888 internal SQL statements in session.
935 SQL statements in session.
   31 statements EXPLAINed in this session.I'm looking in particular at that relatively high activity for RECURSIVE STATEMENTS, because to me, the NON-RECURSIVE (ie the actual submitted statements that form our code) looks pretty harmless. This is my first experience of trying to tune some complex looking PL/SQL and I've no idea what could be considered more "normal", but from what I think I know, and google searches, the results look quite odd to me.
Is this high activity for RECURSIVE STATEMENTS a problem, and if so, what should I start looking at to reduce that activity?
Regards,
Ados

If you have a PLSQL block or stored procedure running SQL statements, the SQL statements, too, will appear as RECURSIVE STATEMENTS in the trace file and tkprof.
It is a misconception that RECURSIVE STATEMENTS are only SYS statements doing data dictionary lookups / updates.
For example, I ran this :
SQL> create or replace procedure test_procedure as
2 begin
3 insert into my_emp_table select * from my_emp_table;
4 dbms_output.put_line('Rows Inserted : ' || sql%rowcount);
5 insert into my_emp_table select * from my_emp_table where emplid=1;
6 dbms_output.put_line('Rows Inserted : ' || sql%rowcount);
7 end;
8 /
Procedure created.
SQL> alter session set events '10046 trace name context forever, level 8';
Session altered.
SQL> execute test_procedure;
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select 'x' from dual;
x
SQL> exitThe tkprof shows ;
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          1           1
Fetch        2      0.00       0.00          0          0          0           1
total        8      0.00       0.00          0          0          1           2
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       5        0.00          0.00
SQL*Net message from client                     5        5.31         11.97
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        4      0.00       0.00          0          2          0           0
Execute      4      0.00       0.00          2         16          7           5
Fetch        2      0.00       0.00          0         14          0           2
total       10      0.01       0.01          2         32          7           7
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         2        0.00          0.00
    7 user SQL statements in session.
    0 internal SQL statements in session.
    7 SQL statements in session.Which were the Non-Recursive statements ?
BEGIN test_procedure; END;
commit
select 'x' from dualWhich were the RECURSIVE statements (which you can identify by the keywords : (recursive depth) ?
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("MY_EMP_TABLE") FULL("MY_EMP_TABLE")
NO_PARALLEL_INDEX("MY_EMP_TABLE") */ :"SYS_B_2" AS C1, :"SYS_B_3" AS C2
FROM "MY_EMP_TABLE" "MY_EMP_TABLE") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          7          0           1
total        3      0.00       0.00          0          7          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 2)
INSERT INTO MY_EMP_TABLE SELECT * FROM MY_EMP_TABLE
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.00       0.00          2          8          4           3
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          2          9          4           3
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 1)
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("MY_EMP_TABLE")
FULL("MY_EMP_TABLE") NO_PARALLEL_INDEX("MY_EMP_TABLE") */ :"SYS_B_2" AS C1,
CASE WHEN "MY_EMP_TABLE"."EMPLID"=:"SYS_B_3" THEN :"SYS_B_4" ELSE
:"SYS_B_5" END AS C2 FROM "MY_EMP_TABLE" "MY_EMP_TABLE") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          7          0           1
total        3      0.00       0.00          0          7          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 2)
INSERT INTO MY_EMP_TABLE SELECT * FROM MY_EMP_TABLE WHERE EMPLID=1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          1          0           0
Execute      1      0.00       0.00          0          8          3           2
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          9          3           2
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 64     (recursive depth: 1)The INSERT statments are recursive depth 1 while the SELECTS they cause are recursive depth 2.
Note that neither of these are are actually SYS statements agaisnt the data dictionary !!
Edit :
IF you read the last few lines, it would become evident that some (in my case all) the RECURSIVE STATEMENTS are non-SYS statements, actually being my code, not Oracle's code.
       1 session in tracefile.
       7 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       7 SQL statements in trace file.
       7 unique SQL statements in trace file.
      87 lines in trace file.
       6 elapsed seconds in trace file.I have 3 non-recursive and 4 "RECURSIVE" statements. All 7 are correctly identified as "user SQL statements in trace file".
Hemant K Chitale
http://hemantoracledba.blogspot.com
Edited by: Hemant K Chitale on Jul 29, 2009 11:44 PM
Edited by: Hemant K Chitale on Jul 29, 2009 11:47 PM

For All Entries is NOT better than INNER JOIN in most cases

I quote from Siegfried Boes' excellent post here: Will writing an inner join be better or creating a view?
For all the FOR ALL ENTRIES lovers ... there is no proof for these reappearing recommendation.
There is nearly nobody who receives forum points, who recommends FOR ALL ENTRIES instead of Joins. What is the reason ???
It is easier to prove the opposite. A Join is a nested loop inside the database, a FOR ALL ENTRIES is partly outside of the database. FOR ALL ENTRIES works in blocks, joins on totals.
FOR ALL ENTRIES are not recommded on really large tables, because the chances are too high that
too many records are transferred.
People prefer FOR ALL ENTRIES, because JOINs are not so easy to understand. Joins can go wrong, but with a bit of understanding they can be fixed.
Some Joins are slow and can not be fixed, but then the FOR ALL ENTRIES would be extremely slow.
There are several kinds of views:
- projection views, i.e. only one table involved just fields reduced
- join views, several tables, joins conditions stored in dictionary
- materialized views, here the joined data are actually stored in the database. Storing and synchronisation has to be done manually.
Only the last one creates real overhead. It should be the exception.
Join Views and Joins are nearly identical. The view is better for reuse. The join is better in complicated, becuase if the access goes wrong, it can often be fixed by adding a hint. Hints can not be added to views.
Abraham Bukit points out:
If it is cluster table, (you can't use join). If it is buffered table, I would also say avoid join.
If they all are transaction table which are not buffered and are not cluster tables.
He further supports Siegfried's statement that FAE is easier to undestand than INNER JOINs.
Thomas Zloch says, regarding buffered tables:
At least think twice, maybe compare runtimes if in doubt.
So, unless someone has some EVIDENCE that FOR ALL ENTRIES is better, I don't think we want to see this discussed further.
Kind regards
Matt

To give food for thought here's an example I gave in a thread:
If you have a statement like
SELECT ... FOR ALL ENTRIES IN FAE_itab WHERE f = FAE_itab-f.
SAP sends it to the database depending how the parameter rsdb/prefer_union_all is set:
rsdb/prefer_union_all = 0 =>
SELECT ... WHERE f = FAE_itab[1]-f
          OR    f = FAE_itab[2]-f
          OR    f = FAE_itab[N]-f
You have some influence of the generated statement type: Instead of OR'ed fields an IN list can be used
if you have only a single coulmn N to compare:
rsdb/prefer_in_itab_opt parameter:
SELECT ... WHERE f IN (itab[1]-f, itab[2]-f, ..., itab[N]-f)
rsdb/prefer_union_all = 1 =>
SELECT ... WHERE f = FAE_itab[1]-f
UNION ALL SELECT ... WHERE f = FAE_itab[2]-f
UNION ALL SELECT ... WHERE f = FAE_itab[N]-f
see: Note 48230 - Parameters for the SELECT ... FOR ALL ENTRIES statement
As you can see for the 2nd parameter several statements are generated and combined with a UNION ALL,
the first setting generates statements with OR's (or uses IN if possible) for the entries in FAE_itab.
I give you a little example here (my parameters are set in a way that the OR's are translated to IN lists; i traced the execution in ST05)
Select myid into table t_tabcount from mydbtable
for all entries in t_table    " 484 entries
    where myid = t_table-myid .
ST05 trace:
|Transaction SEU_INT|Work process no 0|Proc.type DIA|Client 200|User |
|Duration |Obj. name |Op.    |Recs.|RC    |Statement|
| 640|mydbtable |PREPARE|   | 0|SELECT WHERE "myid" IN ( :A0 , :A1 , :A2 , :A3 , :A4 ) AND "myid" = :A5|
| 2|mydbtable |OPEN   |   | 0|SELECT WHERE "myid" IN ( 1 , 2 , 3 , 4 , 5 ) AND "myid" = 72 |
| 2.536|mydbtable |FETCH |    0| 1403|   |
| 3|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 6 , 7 , 8 , 9 , 10 ) AND "myid" = 72 |
| 118|mydbtable |FETCH | 0| |
| 2|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 11 , 12 , 13 , 14 , 15 ) AND "myid" = 72     |
| 3|mydbtable |REOPEN | | 0|SELECT WHERE "myid" IN ( 475 , 476 , 477 , 478 , 479 ) AND "myid" = 72 |
| 94|mydbtable |FETCH | 0| 1403|   |
| 2|mydbtable |REOPEN |   | 0|SELECT WHERE "myid" IN ( 480 , 481 , 482 , 483 , 484 ) AND "myid" = 72 |
You see the IN list contained 5 entries each , wich made up about 97 statements for all 484 entries.
For every statment you have a single fetch operation wich means a separate access to the database.
If you would replace the FAE with a join you would only have one fetch to the database.
With the example above we can derive these observations:
1. From database point of view these settings kill performance when you access a big table and/or have a lot of entries or columns in your FAE_itab. Furthermore, you hide information what data you will access
at all and thus you block the database from creating a more efficient execution plan because it DOESN'T KNOW wich data you will select in the next step. I.e. it may be more efficient to scan the table in one shot instead of having many index accesses - but the database can make this decision only if it can examine ONE statement that has ALL the information of what data to retrieve.
2. A second impact is that with every statement execution you trigger the allocation of database resources
wich will contribute to the overhead described above.
Said that, FAE can never be a replacement for joining big tables (think of having a table with thousands of records in a FAE table )
Edited by: kishan P on Nov 2, 2010 2:16 PM - Format Fixed

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

Similar Messages

Maybe you are looking for