Tuning select query
Hi I have this select statement with 4 tables wich are accually 2 tables with 2 self joins.
table a,b contain about 1.000.000 records and table c,d about 40.000.000.
Because I use the same tables twice is there a way to let the database read them faster or something?
Here is my table a,b:
COLUMN_NAME DATA_TYPE
RECORD_ID NUMBER
CHANGE_DATE DATE
MARKET VARCHAR2
EAN_SUP NUMBER
EAN_BR NUMBER
EAN_DGO NUMBER
SLP_TYPE VARCHAR2
DIRECTION VARCHAR2
VALID_FROM DATE
VALID_TO DATE
EAN_GOS VARCHAR2
RCRN_SEQ NUMBER
RSS_STATUS VARCHAR2
table c,d:
COLUMN_NAME DATA_TYPE
TIMESTAMP DATE
VALUE NUMBER
RALVE_RECORD_ID NUMBER
the QUERY WHO NEEDS OPTIMIZATION
select c.value,d.value,c.timestamp,d.timestamp
from rcx_allocated_Values a,rcx_allocated_values b,rcx_allocated_lp_value c,rcx_allocated_lp_value d
where a.slp_type not in ('S89','S88','S10','S30')--AELP
and b.slp_type in('S89','S88')--residu
and a.ean_sup=b.ean_sup
and a.ean_br=b.ean_br
and a.ean_dgo=b.ean_dgo
and a.direction=b.direction
and a.valid_from=b.valid_from
and a.valid_to=b.valid_to
and a.ean_gos=b.ean_gos
and a.market = b.market
and a.valid_from >= to_date('01072003','DDMMYYYY')
and a.valid_to <= to_date('31122004','DDMMYYYY')
and c.ralve_Record_id = a.record_id
and d.ralve_Record_id = b.record_id
How do you think that we can help you, you didn't give use Oracle version, nor index desc, nor if stats are up-to-date and so on...
Anyway, glad for you if you have found a solution by yourself.
Nicolas.
Similar Messages
-
Performance Tuning on a Select Query
Hi,
We have a select statement as mentioned below.
SELECT loobj1 gpart vkont proid tdate lotyp lockr
INTO TABLE tb_dfkklocks
FROM dfkklocks
FOR ALL ENTRIES IN tb_fkkvkp
WHERE
lotyp = '02'
AND proid = '01'
AND lockr >= '0'
AND lockr <= '9'
AND gpart = tb_fkkvkp-gpart
AND vkont = tb_fkkvkp-vkont.
We have Primary key as shown below.
CLIENT
LOOBJ1
LOTYP
PROID
LOCKR
FDATE
TDATE
GPART
VKONT
We have a secondary index only on TDATE. What can be the ideal select stement to improve the performance?
Regards,
Lijo JosephHi Lijo,
Couple of pointers from my end.
1). Try avoiding a FOR ALL ENTRIES if the base table is huge. Instead use a array fetch and pick up more data instead of trying to restrict the data using a FOR ALL ENTRIES as this does a LOOP on the database while selecting the data.
So i would suggest not use FOR ALL ENTRIES if the base table is huge. So analyse before using a select query.
2). It is actually very difficult to mention which option is better. I would say that it all depends on the scenario. What amount of data is to be read, from which table it is being read, what kind of processing is required on database,..... and many more analysis goes to write a an efficient select statement.
3). If i am not wrong i think if you are using a FOR ALL ENTRIES and dont specify the key completely then there is no gaurentee that you fetch all the unique records. The system will compare all the character fields as a KEY field and it will not fetch all the records. So while using a FOR ALL ENTRIES its recommended to use all the key fields.
4). If you would like to really spend time and work on a efficient select statement then try using the tcode ST05 --> Select the button EXPLAIN SQL REQUEST.
type in your select query and see what is the cost of the select statement fired on the database. This will help you to select the best statement. This is a very useful tool if we have complex select statements.
Hope this info is helpful.
Cheers
VJ
Message was edited by: Vijayendra Rao -
Select query in MB51 failing only for posting date(BUDAT)02/02/2010
Hello Experts,
I am having below select query.
It is running perfectly fine for all the dates except 02/02/2010.On all other dates it is getting executed with in second.
For 02/02/2010 it keeps on running for more than 10 minutes and then fails with timeout error.
Please let me know if anyone know any solution for this.
select (g_t_fields)
into corresponding fields of table itab
from mkpf inner join mseg
on mkpfmandt = msegmandt
and mkpfmblnr = msegmblnr
and mkpfmjahr = msegmjahr
WHERE MKPF~BUDAT in BUDAT
and MSEG~BWART in BWART
and MSEG~CHARG in CHARG
and MKPF~FRBNR in FRBNR
and MSEG~KUNNR in KUNNR
and MSEG~LGORT in LGORT
and MSEG~LIFNR in LIFNR
and MSEG~MATNR in MATNR
and MSEG~SOBKZ in SOBKZ
and MKPF~USNAM in USNAM
and MKPF~VGART in VGART
and MSEG~WERKS in WERKS
and MKPF~XBLNR in XBLNR
%_HINTS
ORACLE '&SUBSTITUTE VALUES&'
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting and please use code tags when posting code - post locked
Edited by: Rob Burbank on Feb 4, 2010 9:02 AMHi Sameer,
Please check on which date the production order has status as "completed".
It could be on 01.02.2015.
Thanks,
Vimal -
Performance issue with select query and for all entries.
hi,
i have a report to be performance tuned.
the database table has around 20 million entries and 25 fields.
so, the report fetches the distinct values of two fields using one select query.
so, the first select query fetches around 150 entries from the table for 2 fields.
then it applies some logic and eliminates some entries and makes entries around 80-90...
and then it again applies the select query on the same table using for all entries applied on the internal table with 80-90 entries...
in short,
it accesses the same database table twice.
so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
is around 80-90 entries too much for using "for all entries"?
the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
i really cant find the way out...
please help.chinmay kulkarni wrote:Chinmay,
Even though you tried to ask the question with detailed explanation, unfortunately it is still not clear.
It is perfectly fine to access the same database twice. If that is working for you, I don't think there is any need to change the logic. As Rob mentioned, 80 or 8000 records is not a problem in "for all entries" clause.
>
> so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
>
It is not clear what you tried to do here. Did you try to bring all 20 million records into an internal table? That will certainly cause the program to short dump with memory shortage.
> the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
>
That is fine. Actually, it is better (performance wise) to do much of the work in ABAP than writing a complex WHERE clause that might bog down the database. -
Dear experts,
Is there a way for the following SELECT query to be improved?
The problem that I'm seeing here is that the same table (l_item_tab) is being queried twice in the SELECT query (due to the "table joins", a and b). How can I improve the data retrieval here? And I also can't change the SELECT query to be out of the loop - ledger is a select-option and multiple values are possible.
* Get Ledger
SELECT * FROM t881 INTO TABLE lt_t881
WHERE rldnr IN s_rldnr.
LOOP AT lt_t881.
* Get FI-SL user-defined item table based on ledger
PERFORM get_sl_item_tab USING lt_t881-rldnr CHANGING l_item_tab.
" L_ITEM_TAB is populated here
* Get SL line items
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE gt_glu1
FROM (l_item_tab) AS a
WHERE
rldnr IN s_rldnr " Ledger
AND rbukrs IN s_bukrs " Company code
AND ryyrkeg_wwsub IN s_wwsub " Subsystem
AND racct IN s_racct " Account no
AND ryymac IN s_yymac " Management area
AND rtcur IN s_rtcur " Trx currency
AND docnr IN s_docnr " Doc. number
AND docty IN s_docty " Doc. type
AND docct EQ c_docct_l " Doc. category (L = Local)
AND ryear IN s_ryear " Fiscal year
AND budat IN s_budat " Posting date
AND yystodt IN s_stodt " Reversal date
AND yystgrd IN s_stgrd " Reversal reason
AND yyintref IN s_intref " Interface ID
AND NOT exists
( SELECT * FROM (l_item_tab) AS b
WHERE
b~rldnr = a~rldnr AND
b~docnr = a~docnr AND
b~rbukrs = a~rbukrs AND
( ( ( b~docct = c_docct_y
OR b~docct = c_docct_x ) AND
b~refryear = a~ryear ) OR
( ( b~docct = c_docct_u
OR b~docct = c_docct_t ) AND
b~ryear = a~ryear ) )
ENDLOOP.
Edited by: Rob Burbank on Jun 23, 2010 12:33 PM>
Siegfried Boes wrote:
> > Will certainly try this out too..
> maybe you should think twice .... The usage of a subselect is that the result set is not transferred to the application server it is only needed
> during the selection.
>
> You should anser the following questions:
> + who wrote the code? you or? I get the impression that you don't know what is intended.
> + SQL Trace, what are the numbers for repeated executions, (go to summary by SQL statement), duration, execution, records
> + how many different tables are accessed, l_item_tab is dynamic
> + what knid of tables are accessed?
>
> Siegfried
Hi Siegfried,
- The codes are currently existing ones and they were not written by me too. I just do know that the first / main SELECT statement in the query is for retrieving FI special ledger line item data records, while the second / sub SELECT statement is to ensure that the line item data records are not already reversed, and not a reversal.
- In the summarized SQL trace of a sample test run: executions = 1, identical executions = 0, duration = 700247324 (almost 100% of the total processing durations), records = 0 (there should be more records returned in an actual production run)
- Only one table, ZZGLV4A (custom) is accessed based on the selection screen variant. ZZGLV4A is an FI special ledger line item table and its data volume: 455 mil. data records. Note: The codes are written for a report that runs in the background, and the selection screen variant is used for the executions too. The table accessed (l_item_tab is ZZGLV4A in this case) depends on the ledger inputted here - only one ledger is specified for the current selection screen variant.
- Table accessed - FI special ledger line item data.
I tried tuning the query a little further by just properly specifying the WHERE fields - only a minimal improvement is observed, an average of about 6% of runtime improvement only (tested via SE30 in the development box for ZZGLV4A but its table volume is 4 mil. data records here only). This obviously works only for the table ZZGLV4A for now, I'm afraid.
Any other ideas on how such subqueries can be improved generally (maybe secondary indexes)? The subquery is certainly re-hitting the same table at least twice.
Thanks for the inputs once again! -
Parallel process in select query
Hi Experts
its production
stats are good
indexes are good
issue :
a select query is taking time 20min , the indexes exists on the where clause columns, I tried the query using parallel hint it gave the results iin 20 sec.
the DOP of the table set to 10, but when I run the query it picks old plan
constraints : I cannot modify the query, it needs to be tuned without modifying it
if DOP is >1 then select is expected to use parallellism in explain plan..is my understanding correct?
if I am wrong please advice how can i force the query to use the parallellism
Please advice and guide asap
THanks in advance
Ajay Kumaruser513478 wrote:
Hi Experts
its production
stats are good
indexes are good
issue :
a select query is taking time 20min , the indexes exists on the where clause columns, I tried the query using parallel hint it gave the results iin 20 sec.
the DOP of the table set to 10, but when I run the query it picks old plan
constraints : I cannot modify the query, it needs to be tuned without modifying itWhat version of Oracle?
Tuning SQL without modifying the SQL can be very hard but you may have options.
Could you use a materialized view with automatic query rewrite?
Can you use a SQL profile to affect performance?
Have you looked very+ carefully at the indexes to see if other indexes might be more efficient?
20 minutes to 20 seconds sounds too good to be true. Are you sure you aren't reading cached data and that the 2nd, faster run really is running in parallel? -
SELECT query takes too much time! Y?
Plz find my SELECT query below:
select w~mandt
wvbeln wposnr wmeins wmatnr wwerks wnetwr
wkwmeng wvrkme wmatwa wcharg w~pstyv
wposar wprodh wgrkor wantlf wkztlf wlprio
wvstel wroute wumvkz wumvkn wabgru wuntto
wawahr werdat werzet wfixmg wprctr wvpmat
wvpwrk wmvgr1 wmvgr2 wmvgr3 wmvgr4 wmvgr5
wbedae wcuobj w~mtvfp
xetenr xwmeng xbmeng xettyp xwepos xabart
x~edatu
xtddat xmbdat xlddat xwadat xabruf xetart
x~ezeit
into table t_vbap
from vbap as w
inner join vbep as x on xvbeln = wvbeln and
xposnr = wposnr and
xmandt = wmandt
where
( ( werdat > pre_dat ) and ( werdat <= w_date ) ) and
( ( ( erdat > pre_dat and erdat < p_syndt ) or
( erdat = p_syndt and erzet <= p_syntm ) ) ) and
w~matnr in s_matnr and
w~pstyv in s_itmcat and
w~lfrel in s_lfrel and
w~abgru = ' ' and
w~kwmeng > 0 and
w~mtvfp in w_mtvfp and
x~ettyp in w_ettyp and
x~bdart in s_req_tp and
x~plart in s_pln_tp and
x~etart in s_etart and
x~abart in s_abart and
( ( xlifsp in s_lifsp ) or ( xlifsp = ' ' ) ).
The problem: It takes too much time while executing this statement.
Could anybody change this statement and help me out to reduce the DB Access time?
ThxWays of Performance Tuning
1. Selection Criteria
2. Select Statements
Select Queries
SQL Interface
Aggregate Functions
For all Entries
Select Over more than one internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
4. For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
5. Use Select Single if all primary key fields are supplied in the Where condition .
If all primary key fields are supplied in the Where conditions you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
SET SEATSOCC = SEATSOCC - 1.
2. For all frequently used Select statements, try to use an index.
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
AND CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
3. Using buffered tables improves the performance considerably.
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
Select Statements Aggregate Functions
If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
Maxno = 0.
Select * from zflight where airln = LF and cntry = IN.
Check zflight-fligh > maxno.
Maxno = zflight-fligh.
Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements For All Entries
The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif.
Select Statements Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
WHERE DOMNAME = DD01L_WA-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L_WA-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
AND DDLANGUAGE = SY-LANGU.
ENDSELECT
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
3. 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.
1. Table operations should be done using explicit work areas rather than via header lines.
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 ) ).
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
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.
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.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
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
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.
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
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)) .
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
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.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
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.
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
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. -
Select query is taking lot of time to fetch data.....
Select query is taking lot of time to fetch data.
SELECT algnum atanum abdatu abzeit abname abenum bmatnr bmaktx bqdatu bqzeit bvlenr bnlenr bvltyp bvlber b~vlpla
bnltyp bnlber bnlpla bvsola b~vorga INTO TABLE it_final FROM ltak AS a
INNER JOIN ltap AS b ON btanum EQ atanum AND algnum EQ blgnum
WHERE a~lgnum = p_whno
AND a~tanum IN s_tono
AND a~bdatu IN s_tocd
AND a~bzeit IN s_bzeit
AND a~bname IN s_uname
AND a~betyp = 'P'
AND b~matnr IN s_mno
AND b~vorga <> 'ST'.
Moderator message: Please Read before Posting in the Performance and Tuning Forum
Edited by: Thomas Zloch on Mar 27, 2011 12:05 PMHi Shiva,
I am using two more select queries with the same manner ....
here are the other two select query :
***************1************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
FROM ztftelpt LEFT JOIN ztfzberep
ON ztfzberep~gjahr = st_input-gjahr
AND ztfzberep~poper = st_input-poper
AND ztfzberepcntr = ztftelptrprctr
WHERE rldnr = c_telstra_projects
AND rrcty = c_actual
AND rvers = c_ver_001
AND rbukrs = st_input-bukrs
AND racct = st_input-saknr
AND ryear = st_input-gjahr
and rzzlstar in r_lstar
AND rpmax = c_max_period.
and the second one is
*************************2************************
SELECT * APPENDING CORRESPONDING FIELDS OF TABLE tbl_summary
FROM ztftelnt LEFT JOIN ztfzberep
ON ztfzberep~gjahr = st_input-gjahr
AND ztfzberep~poper = st_input-poper
AND ztfzberepcntr = ztftelntrprctr
WHERE rldnr = c_telstra_networks
AND rrcty = c_actual
AND rvers = c_ver_001
AND rbukrs = st_input-bukrs
AND racct = st_input-saknr
AND ryear = st_input-gjahr
and rzzlstar in r_lstar
AND rpmax = c_max_period.
for both the above table program is taking very less time .... although both the table used in above queries have similar amount of data. And i can not remove the APPENDING CORRESPONDING. because i have to append the data after fetching from the tables. if i will not use it will delete all the data fetched earlier.
Thanks on advanced......
Sourabh -
Please can you help me in Tuning this query..?
Hi ,
Please can you help me in re-structuring this query? .Details are given below.
I have 2 tables as shown below and data is like this.
Position
COD IND
AAA N
BBB N
CCC N
DDD Y
Distance
orig dest
AAA BBB
BBB CCC
AAA CCC
I need to create the records like this
start end
DDD AAA
DDD BBB
DDD CCC
The query which i am using now for this is
select p.code AS start,
P1.CODE AS end
from position p, position p1
where
P.CODE != P1.CODE
AND (P.ind = 'Y' or P1.IND = 'Y')
AND not exists
(select 1
from distance d
where (d.orig = p.code or d.dest = p.code)
and (d.orig = p1.code or d.dest = p1.code))
table is having above a crore record. so its taking a lot of time.
Please someone please help in tuning this query?
Thanks and regards,
ShabirLooks like you want this
select a.strt, b.ends from
(select p.code strt from position p where p.ind='Y') a,
(select p.code ends from position p where p.ind='N') b
where not exists (select 1 from distance d where d.orig=a.strt or d.dest=a.strt);
DDD AAA
DDD BBB
DDD CCCYour query result is:
AAA DDD
BBB DDD
CCC DDD
DDD AAA
DDD BBB
DDD CCCYou should be more descriptive about what kind of result you want, so that people can get more interested in helping you. -
Hi,
Following query is taking about 30-40 mins to fetch the data in a procedure.I tried using the hints and ran the explain plan but the cost is still the same (151,894) . Can anyone please help me in tuning the query.
SELECT SYSDATE c_creation_date, glcc.code_combination_id c_ccid,
glcc.segment1 c_funding, glcc.segment2 c_resp_ctr,
glcc.segment3 c_account, glcc.segment4 c_pgm_phase,
glcc.segment5 c_project_cd, null c_vendor_id,
null c_vendor_num, null c_vendor_name,
null c_site_code,
null c_vendor_type,
null c_project_id, null c_project,
null c_project_name,
null c_organization_id,
null c_organization, null c_expenditure_type_id,
null c_expenditure_type,
null c_task_id, null c_task,
null c_task_name, null c_award_id,
null c_award, null c_award_name,
jel.je_header_id c_document_batch_id,
jeh.name c_document_batch_name,
-- jel.reference_2 c_document_id, --- Note: reference_2 invoice_id,po_header_id,req_header_id
case
when je_source = 'Purchasing'
then jel.reference_2
when je_source = 'Payables'
then jel.reference_2
else null
end c_document_id,
case
when je_source = 'Purchasing'
then 'GLJE-'||je_source||' '||jel.reference_1
else 'GLJE-'||je_source
end c_document_type,
case
when je_source = 'Payables'
then jel.reference_5
when je_source = 'Purchasing'
then reference_4
else
reference_4
end c_document_number,
NULL c_document_release_id, NULL c_document_release,
NULL c_document_line_id,
null c_document_line_num,
case
when je_source = 'Purchasing'
then jel.reference_3
else null
end c_document_dist_id,
case
when je_source = 'Payables'
then jel.reference_3
else null
end c_document_dist_num,
0 c_distr_amount,
(nvl(accounted_dr,0) - nvl(accounted_cr,0)) c_encumbered_amount,
0,0,0,0,0,0,NULL,jel.je_line_num c_je_line_num
FROM gl_je_lines jel,
gl_je_headers jeh,
gl_encumbrance_types jee ,
gl_code_combinations glcc
WHERE jel.je_header_id = jeh.je_header_id
AND jel.CODE_COMBINATION_ID = glcc.CODE_COMBINATION_ID
AND jee.encumbrance_type_id = jeh.encumbrance_type_id
AND actual_flag = 'E'
and glcc.segment1
|| '-'
|| glcc.segment2
|| '-'
|| glcc.segment3
|| '-'
|| glcc.segment4
|| '-'
|| glcc.segment5
|| '-'
|| glcc.segment6
|| '-'
|| glcc.segment7 between nvl(:p_min_flex, :l_min_flex) and nvl(:p_max_flex,: l_max_flex )
and encumbrance_type = nvl(:l_enc_type,encumbrance_type)
and jel.EFFECTIVE_DATE between nvl(:p_encumbrance_date_from,:l_date_low)
and nvl(:p_encumbrance_date_to,:l_date_high)
and decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5)
=nvl(:l_doc_number,decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5))
and je_source != 'Payables';
I will appreciate the help!
Regards,
DarshiniHi,
Thanks Sundar and Miguel for the article, it is very helpful.
I was able to get the output from explain plan as well as sql_trace.But I could not understand how to compare the files and optimize the query. follwing are the outputs
select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 336 | 151K|
| 1 | CONCATENATION | | | | |
| 2 | FILTER | | | | |
| 3 | NESTED LOOPS | | 1 | 168 | 54873 |
| 4 | NESTED LOOPS | | 1 | 155 | 54872 |
| 5 | NESTED LOOPS | | 1633 | 180K| 53237 |
| 6 | TABLE ACCESS FULL | GL_CODE_COMBINATIONS | 1387 | 77672 | 3713 |
| 7 | TABLE ACCESS BY INDEX ROWID| GL_JE_LINES | 1 | 57 | 66 |
| 8 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 135 | | 3 |
| 9 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 42 | 1 |
| 10 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 0 |
| 11 | TABLE ACCESS BY INDEX ROWID | GL_ENCUMBRANCE_TYPES | 1 | 13 | 1 |
| 12 | INDEX UNIQUE SCAN | GL_ENCUMBRANCE_TYPES_U1 | 1 | | 0 |
| 13 | FILTER | | | | |
| 14 | NESTED LOOPS | | 1 | 168 | 97021 |
| 15 | NESTED LOOPS | | 1633 | 200K| 95386 |
| 16 | NESTED LOOPS | | 1387 | 95703 | 3714 |
PLAN_TABLE_OUTPUT
| 17 | TABLE ACCESS BY INDEX ROWID| GL_ENCUMBRANCE_TYPES | 1 | 13 | 1 |
| 18 | INDEX UNIQUE SCAN | GL_ENCUMBRANCE_TYPES_U2 | 1 | | 0 |
| 19 | TABLE ACCESS FULL | GL_CODE_COMBINATIONS | 1387 | 77672 | 3713 |
| 20 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 1 | 57 | 66 |
| 21 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 135 | | 3 |
| 22 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 42 | 1 |
| 23 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 0 |
sql_trace
PARSING IN CURSOR #2 len=3812 dep=0 uid=173 oct=3 lid=173 tim=3338840240188 hv=2038351921 ad='aaf94e98'
SELECT SYSDATE c_creation_date, glcc.code_combination_id c_ccid ,
glcc.segment1 c_funding, glcc.segment2 c_resp_ctr,
glcc.segment3 c_account, glcc.segment4 c_pgm_phase,
glcc.segment5 c_project_cd, null c_vendor_id,
null c_vendor_num, null c_vendor_name,
null c_site_code,
null c_vendor_type,
null c_project_id, null c_project,
null c_project_name,
null c_organization_id,
null c_organization, null c_expenditure_type_id,
null c_expenditure_type,
null c_task_id, null c_task,
null c_task_name, null c_award_id,
null c_award, null c_award_name,
jel.je_header_id c_document_batch_id,
jeh.name c_document_batch_name,
case
when je_source = 'Purchasing'
then jel.reference_2
when je_source = 'Payables'
then jel.reference_2
else null
end c_document_id,
case
when je_source = 'Purchasing'
then 'GLJE-'||je_source||' '||jel.reference_1
else 'GLJE-'||je_source
end c_document_type,
case
when je_source = 'Payables'
then jel.reference_5
when je_source = 'Purchasing'
then reference_4
else
reference_4
end c_document_number,
NULL c_document_release_id, NULL c_document_release,
NULL c_document_line_id,
null c_document_line_num,
case
when je_source = 'Purchasing'
then jel.reference_3
else null
end c_document_dist_id,
case
when je_source = 'Payables'
then jel.reference_3
else null
end c_document_dist_num,
0 c_distr_amount,
(nvl(accounted_dr,0) - nvl(accounted_cr,0)) c_encumbered_amount,
0,0,0,0,0,0,NULL,jel.je_line_num c_je_line_num
FROM gl_je_lines jel,
gl_je_headers jeh,
gl_encumbrance_types jee ,
gl_code_combinations glcc
WHERE jel.je_header_id = jeh.je_header_id
AND jel.CODE_COMBINATION_ID = glcc.CODE_COMBINATION_ID
AND jee.encumbrance_type_id = jeh.encumbrance_type_id
AND actual_flag = 'E'
and glcc.segment1
|| '-'
|| glcc.segment2
|| '-'
|| glcc.segment3
|| '-'
|| glcc.segment4
|| '-'
|| glcc.segment5
|| '-'
|| glcc.segment6
|| '-'
|| glcc.segment7 between nvl(null,'F017-M029300-1980200200-CF2004-000000-00000-00000')
and nvl(null,'F017-M029300-1980200200-CF2004-000000-00000-00000' )
and encumbrance_type = nvl('Obligation',encumbrance_type)
and jel.EFFECTIVE_DATE between nvl(null,'01-JAN-1900')
and nvl(null,'31-DEC-4712')
and decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5)
=nvl('5013794',decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5))
and je_source != 'Payables'
END OF STMT
PARSE #2:c=50000,e=42317,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=3338840240172
EXEC #2:c=0,e=621,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3338840243240
FETCH #2:c=5910000,e=5837875,p=13246,cr=19198,cu=0,mis=0,r=1,dep=0,og=1,tim=3338846081769
FETCH #2:c=0,e=1166,p=0,cr=8,cu=0,mis=0,r=15,dep=0,og=1,tim=3338846086521
*** 2008-08-06 12:24:18.016
FETCH #2:c=10000,e=2155,p=0,cr=21,cu=0,mis=0,r=15,dep=0,og=1,tim=3338854116887
FETCH #2:c=0,e=1812,p=0,cr=14,cu=0,mis=0,r=15,dep=0,og=1,tim=3338860800729
*** 2008-08-06 12:24:31.298
FETCH #2:c=10000,e=1729,p=0,cr=10,cu=0,mis=0,r=15,dep=0,og=1,tim=3338867087393
FETCH #2:c=0,e=1810,p=0,cr=14,cu=0,mis=0,r=15,dep=0,og=1,tim=3338872996057
*** 2008-08-06 12:24:43.317
FETCH #2:c=0,e=1728,p=0,cr=9,cu=0,mis=0,r=15,dep=0,og=1,tim=3338878825390
FETCH #2:c=0,e=2058,p=0,cr=12,cu=0,mis=0,r=15,dep=0,og=1,tim=3338884698870
*** 2008-08-06 12:24:57.286
FETCH #2:c=0,e=2095,p=0,cr=10,cu=0,mis=0,r=10,dep=0,og=1,tim=3338892467618
STAT #2 id=1 cnt=116 pid=0 pos=1 obj=0 op='HASH JOIN (cr=19296 pr=13246 pw=0 time=5837597 us)'
STAT #2 id=2 cnt=5464 pid=1 pos=1 obj=33979 op='TABLE ACCESS FULL GL_JE_HEADERS (cr=6120 pr=183 pw=0 time=796948 us)'
STAT #2 id=3 cnt=174 pid=1 pos=2 obj=34028 op='TABLE ACCESS BY INDEX ROWID GL_JE_LINES (cr=13176 pr=13063 pw=0 time=5576761 us)'
STAT #2 id=4 cnt=176 pid=3 pos=1 obj=0 op='NESTED LOOPS (cr=13088 pr=13063 pw=0 time=487814114 us)'
STAT #2 id=5 cnt=1 pid=4 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=13076 pr=13063 pw=0 time=5575083 us)'
STAT #2 id=6 cnt=1 pid=5 pos=1 obj=34354 op='TABLE ACCESS FULL GL_ENCUMBRANCE_TYPES (cr=6 pr=0 pw=0 time=453 us)'
STAT #2 id=7 cnt=1 pid=5 pos=2 obj=0 op='BUFFER SORT (cr=13070 pr=13063 pw=0 time=5574591 us)'
STAT #2 id=8 cnt=1 pid=7 pos=1 obj=33834 op='TABLE ACCESS FULL GL_CODE_COMBINATIONS (cr=13070 pr=13063 pw=0 time=5573921 us)'
STAT #2 id=9 cnt=174 pid=4 pos=2 obj=34055 op='INDEX RANGE SCAN GL_JE_LINES_N1 (cr=12 pr=0 pw=0 time=349 us)'
=====================
I will greatly appreciate if any one can help me further.
Thanks,
Darshini -
Select query giving Time out dump
Hi All,
I have written a select query on a table in BW system.The code for the same is attached below.The table contains some 6,00,000 records.This query is giving a time out error.Kindly look into the query and advice ways to make it work.Thanks.
IF NOT lt_temp[] IS INITIAL.
SELECT /bic/zprrmatnr objvers /bic/zprclwynr /bic/zprrmdlr
FROM /bic/pzprrmatnr
INTO CORRESPONDING FIELDS OF TABLE lt_zprrmatnr
FOR ALL ENTRIES IN lt_temp
WHERE /bic/zprclwynr = lt_temp-temp
AND objvers = 'A'.
ENDIF.
Thanks and Regards,
FaisalNot only is it BW, it is also a customer table. Have a look here on how to research yourself:
Please Read before Posting in the Performance and Tuning Forum
Thomas -
Regarding to perform in select query
could any tell the select query in this piece of code would affect the performance of the programe
DATA: BEGIN OF OUTREC,
BANKS LIKE BNKA-BANKS,
BANKL LIKE BNKA-BANKL,
BANKA LIKE BNKA-BANKA,
PROVZ LIKE BNKA-PROVZ, "Region (State, Province, County)
BRNCH LIKE BNKA-BRNCH,
STRAS LIKE BNKA-STRAS,
ORT01 LIKE BNKA-ORT01,
SWIFT LIKE BNKA-SWIFT,
END OF OUTREC.
OPEN DATASET P_OUTPUT FOR OUTPUT IN TEXT MODE.
IF SY-SUBRC NE 0. EXIT. ENDIF.
SELECT * FROM BNKA
WHERE BANKS EQ P_BANKS
AND LOEVM NE 'X'
AND XPGRO NE 'X'
ORDER BY BANKS BANKL.
PERFORM TRANSFER_DATA.
ENDSELECT.
CLOSE DATASET P_OUTPUT.
*& Transfer the data to the output file
FORM TRANSFER_DATA.
OUTREC-BANKS = BNKA-BANKS.
OUTREC-BANKL = BNKA-BANKL.
OUTREC-BANKA = BNKA-BANKA.
OUTREC-PROVZ = BNKA-PROVZ.
OUTREC-BRNCH = BNKA-BRNCH.
OUTREC-STRAS = BNKA-STRAS.
OUTREC-ORT01 = BNKA-ORT01.
OUTREC-SWIFT = BNKA-SWIFT.
TRANSFER OUTREC TO P_OUTPUT.
ENDFORM. " READ_IN_DATAHi
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
Select Queries
SQL Interface
Aggregate Functions
For all Entries
Select Over more than one Internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
Points # 1/2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
5. Use Select Single if all primary key fields are supplied in the Where condition .
Point # 1
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
Point # 2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
SBOOK_WA-CONNID = '0400'.
Point # 3
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
Point # 4
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
Point # 5
If all primary key fields are supplied in the Where condition you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements contd.. SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use an index.
3. Using buffered tables improves the performance considerably.
Point # 1
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
SET SEATSOCC = SEATSOCC - 1.
Point # 2
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
AND CARRID = 'LH'
AND CONNID = '0400'.
ENDSELECT.
Point # 3
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
AND ARBGB = '00'
AND MSGNR = '999'.
Select Statements contd Aggregate Functions
If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
Maxno = 0.
Select * from zflight where airln = LF and cntry = IN.
Check zflight-fligh > maxno.
Maxno = zflight-fligh.
Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements contd For All Entries
The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
The plus
Large amount of data
Mixing processing and reading of data
Fast internal reprocessing of data
Fast
The Minus
Difficult to program/understand
Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
Check that data is present in the driver table
Sorting the driver table
Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.
Endif.
Select Statements contd Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
3. Instead of using nested Select loops it is often better to use subqueries.
Point # 1
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
WHERE DOMNAME = DD01L_WA-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS = DD01L_WA-AS4VERS
AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
AND DDLANGUAGE = SY-LANGU.
ENDSELECT
Point # 2
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
FROM EKKO AS P INNER JOIN EKAN AS F
ON PEBELN = FEBELN.
Point # 3
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.
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. -
Hi,
Can anybody please help me in tuning this query?
update tablec c set c.col1 = (select b.col1 from tableb b where c.col2 = b.col2 ) where
c.col2 in (select distinct a.col1 from tablec a, tableb b where a.col2 = b.col2 and a.col1 != b.col1 )
When i use "alter session force parallel DML" before running this query it takes only seconds, but when i use parallel hint or run it without hint, its running for hours.
Thanks for your HelpHi itssan,
You could try EXISTS.
I think this is the same:
update tablec c
set c.col1 =
(select b.col1
from tableb b
where b.col2 = c.col2)
where exists (select null
from tablec a, tableb b
where a.col2 = b.col2
and a.col1 != b.col1
and a.col1 = c.col2);Regards
Peter -
Please help me in tuning this query. This view has around 2 million of records
SELECT * FROM employee_v
WHERE status_id IN (SELECT MAX(v2.status_id)status_id
FROM employee_v v2
WHERE UPPER(v2.name) LIKE UPPER(:v_name)||'%'
GROUP BY v2.emp_id, v2.project_id)
ORDER BY status_type_id;
Here:
employees may work on one or more projects
employee working on a given project may have one or more status_ids associated.
for example:
emp_id project_id status_id
10 100 1
10 100 2
20 100 2
20 200 3
30 100 4
30 200 5
30 200 6
40 200 6
If you have any other suggestions , please let me know too. For example, I was thinking that the subquery should use actual tables instead of the view because view is based on 10 tables and the subquery can instead use two tables . Does it make sense?
Thanks a lot for the help!
Edited by: user5406804 on Apr 20, 2010 5:42 AMIf you have any other suggestions , please let me know too. Wild shot in the dark, but maybe using EXISTS instead of IN speeds up your query:
untested for obvious reasons
select *
from employee_v v
where upper(v.name) like upper(:v_name)||'%'
where not exists ( select null
from employee_v v2
and v2.status_id > v.status_id
and v2.emp_id = v.emp_id -- assuming you have some emp_id PK column
-- if necessary, you need to change the name of this column ofcourse
order by status_type_id;Do compare the resultsets, not sure this will give you the same/desired result, but it might give you an idea.
For example, I was thinking that the subquery should use actual tables instead of the view because > view is based on 10 tables and the subquery can instead
use two tables . Does it make sense?Sounds like worth a try to me, yes. Less data to plough through = faster response.
As well as using a function based index on UPPER(name) might be worth a try. -
Restrict user SELECT query time on a particular VIEW
Hi - I am trying to restrict user SELECT statemnet time on a particular view.There is a user called ABC and he is accessing many objects in database.All SELECT statments are fine execept when he query a particular VIEW.That view SELECT causing performance problem.So I am trying to restrict the SELECT query time on a VIEW.
Can you please help me to achive this task through some SQL command like ALTER USER etc...
Thanks for your help.user2538196 wrote:
Hi - I am trying to restrict user SELECT statemnet time on a particular view.There is a user called ABC and he is accessing many objects in database.All SELECT statments are fine execept when he query a particular VIEW.That view SELECT causing performance problem.So I am trying to restrict the SELECT query time on a VIEW.
Can you please help me to achive this task through some SQL command like ALTER USER etc...
Thanks for your help.It sounds like you are really trying to solve a performance problem with the view. I agree with Justin that the solution to restrict access to the view dynamically sounds unwieldy.
Consider tuning the view, or perhaps the query using the view. Post the view and see if anyone can help you tune it.
Maybe you are looking for
-
How to get the output path in Java?
Hi all, is there a way (method) to get the output path (where compiled classes are put) in Java? thx a lot! Michele
-
VM will not boot after moving using Failover Cluster Manager - "a disk read error occurred......"
My current Configuration: 3 node cluster, using clustered shared storage and about 22 VM's. The Host servers are running 2012 Data Center while all guest are running 2012 Standard. The SAN is EqualLogic and we are using HIT Kit 4.5. I have a CSV t
-
I have two Mac's running Mountain Lion - my MBP shows mail attachments as expected (connected to the same gmail account) and my iMac insists on showing them as UUEncoded text. It's not all attachments - just some of them. For exmple, things I send ar
-
Hi all I was user of sony ericsson now switch to nokia and bought 6303 classic recently updated to latest firm ware pack 10.10 but if two thing added in future firmware upgarde will make this phone master piece. 1) please add support for multitasking
-
How to make navigation header a dropdown
I'm trying to make one of my main navigation headers (About Us) into a rollover drop down like the rest of my headers. When I try to do so on my main navigation page it throws the rest of my headers off of the correct alighnment. Here is what I want