Need Performance tuning in delete operation

Hi Gurus,
I am performing delete operation by following SQL query.
delete from gl_account where bu_id = -99
but it take long time to execute. Table contains 1 trigger and 5 index. I have disabled the trigger and rebuild the index but still it not executing.
Here is my explain plan.
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS          561            19
DELETE     OFFLINETESTDB.GL_ACCOUNT
INDEX RANGE SCAN     OFFLINETESTDB.BU_ID     561      27 K     2
Pls help me out to solve this.

Hi All,
I am still facing the same performs problem for deleting row in a table.
here by i have attached my TKPROF for your consideration.
TKPROF: Release 10.2.0.1.0 - Production on Tue Oct 12 14:01:13 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: rubikon_s002_3952.trc
Sort options: exeela exerow
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
DELETE FROM GL_ACCOUNT
WHERE
GL_ACCT_ID IN (16908,16909,16456)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.13          0          0          0           0
Execute      1      0.03       0.26          0          6        221           3
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.04       0.40          0          6        221           3
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 40 (OFFLINETESTDB)
Rows     Row Source Operation
      0 DELETE GL_ACCOUNT (cr=177742 pr=160538 pw=0 time=31518664 us)
      3   INLIST ITERATOR (cr=6 pr=0 pw=0 time=103 us)
      3    INDEX RANGE SCAN GL_ACCOUNT_PK (cr=6 pr=0 pw=0 time=86 us)(object id 65637)
Rows     Execution Plan
      0 DELETE STATEMENT   MODE: ALL_ROWS
      0   DELETE OF 'GL_ACCOUNT'
      3    INLIST ITERATOR
      3     INDEX   MODE: ANALYZED (RANGE SCAN) OF 'GL_ACCOUNT_PK'
                (INDEX (UNIQUE))
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_SUMMARY" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.06          0          0          0           0
Fetch        3      0.00       0.00          0          6          0           3
total        7      0.00       0.06          0          6          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=6 pr=0 pw=0 time=236 us)
      0   VIEW index$_join$_001 (cr=6 pr=0 pw=0 time=185 us)
      0    HASH JOIN (cr=6 pr=0 pw=0 time=172 us)
      0     INDEX RANGE SCAN GL_ACCOUNT_SUMMARY_IX2 (cr=6 pr=0 pw=0 time=82 us)(object id 65648)
      0     INDEX RANGE SCAN GL_ACCOUNT_SUMMARY_IX1 (cr=0 pr=0 pw=0 time=0 us)(object id 65647)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_QUARTERLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.06          0          0          0           0
Fetch        3      1.64      20.79     108398     109500          0           3
total        7      1.64      20.86     108398     109500          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=109500 pr=108398 pw=0 time=20797344 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_QUARTERLY_STAT (cr=109500 pr=108398 pw=0 time=20797279 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_MONTHLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute      4      0.00       0.06          0          0          1           0
Fetch        3      0.75      10.11      52140      59532          0           3
total        9      0.75      10.18      52140      59532          1           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Parsing user id: SYS
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=59532 pr=52140 pw=0 time=10116280 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_MONTHLY_STAT (cr=59532 pr=52140 pw=0 time=10116221 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_RECON_TXN_JOURNAL" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.02          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.02          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=138 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_RECON_TXN_JOURNAL (cr=9 pr=0 pw=0 time=97 us)
select text
from
view$ where rowid=:1
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.00          0          0          0           0
Execute      3      0.01       0.00          0          0          2           0
Fetch        3      0.00       0.00          0          6          0           3
total        9      0.03       0.00          0          6          2           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      1 TABLE ACCESS BY USER ROWID VIEW$ (cr=1 pr=0 pw=0 time=34 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_BULK_CRITERIA" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=109 us)
      0   TABLE ACCESS FULL GL_BULK_CRITERIA (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_HISTORY" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.01       0.02          0       5070          0           3
total        7      0.01       0.02          0       5070          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=5070 pr=0 pw=0 time=22519 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_HISTORY (cr=5070 pr=0 pw=0 time=22472 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_BULK_HISTORY" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=106 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_BULK_HISTORY (cr=9 pr=0 pw=0 time=69 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ALLOTMENT" where "POOL_ACCT_ID" = :1 and "POOL_ACCT_NO" =
   :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.02          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          3          0           3
total        7      0.00       0.02          0          3          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=3 pr=0 pw=0 time=113 us)
      0   TABLE ACCESS BY INDEX ROWID GL_ALLOTMENT (cr=3 pr=0 pw=0 time=68 us)
      0    INDEX RANGE SCAN GL_ALLOTMENT_IX1 (cr=3 pr=0 pw=0 time=50 us)(object id 65651)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_YEARLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.01       0.01          0       3453          0           3
total        7      0.01       0.01          0       3453          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=3453 pr=0 pw=0 time=10485 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_YEARLY_STAT (cr=3453 pr=0 pw=0 time=10440 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "CASH_GL_ACCT_ID" = :1 and
"CASH_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=110 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "DEPOT_GL_ACCT_ID" = :1 and
"DEPOT_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=107 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_TXN_ALLOTTEE" where "GL_ALLOTTEE_ACCT_ID" = :1 and
"GL_ALLOTTEE_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=122 us)
      0   TABLE ACCESS FULL GL_TXN_ALLOTTEE (cr=9 pr=0 pw=0 time=84 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "POSN_GL_ACCT_ID" = :1 and
"POSN_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=110 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=69 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ALLOTTEE" where "RECIPIENT_ACCT_ID" = :1 and
"RECIPIENT_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=155 us)
      0   TABLE ACCESS FULL GL_ALLOTTEE (cr=9 pr=0 pw=0 time=119 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "INTER_BU_GL_ACCT_ID" = :1
and "INTER_BU_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=102 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=67 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_BUDGET_ITEM_DATA" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=151 us)
      0   TABLE ACCESS FULL GL_BUDGET_ITEM_DATA (cr=9 pr=0 pw=0 time=108 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_TOTALLING_ACCOUNT_LINE" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.02          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.02          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=119 us)
      0   TABLE ACCESS FULL GL_TOTALLING_ACCOUNT_LINE (cr=9 pr=0 pw=0 time=82 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."SWEEP_FUNDS_XFER" where "TO_GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.01       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.01       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=123 us)
      0   TABLE ACCESS FULL SWEEP_FUNDS_XFER (cr=9 pr=0 pw=0 time=84 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCESS_ACCOUNT_LIST" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=117 us)
      0   TABLE ACCESS FULL GL_ACCESS_ACCOUNT_LIST (cr=9 pr=0 pw=0 time=79 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."SETTLEMENT_BANK_ACCOUNT" where "MIRROR_GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=121 us)
      0   TABLE ACCESS FULL SETTLEMENT_BANK_ACCOUNT (cr=9 pr=0 pw=0 time=86 us)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        8      0.01       0.29          0          0          8           0
Execute     11      0.03       0.32          0          6        222           3
Fetch        7      0.75      10.11      52140      59532          0           7
total       26      0.79      10.73      52140      59538        230          10
Misses in library cache during parse: 7
Misses in library cache during execute: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       47      0.01       0.06          0          0          0           0
Execute     85      0.03       0.18          0          0          2           0
Fetch       85      1.67      20.83     108398     118214          0          85
total      217      1.71      21.08     108398     118214          2          85
Misses in library cache during parse: 21
Misses in library cache during execute: 20
    7 user SQL statements in session.
   48 internal SQL statements in session.
   55 SQL statements in session.
    5 statements EXPLAINed in this session.
Trace file: rubikon_s002_3952.trc
Trace file compatibility: 10.01.00
Sort options: exeela exerow
       1 session in tracefile.
       7 user SQL statements in trace file.
      48 internal SQL statements in trace file.
      55 SQL statements in trace file.
      29 unique SQL statements in trace file.
       5 SQL statements EXPLAINed using schema:
           OFFLINETESTDB.prof$plan_table
             Default table was used.
             Table was created.
             Table was dropped.
     548 lines in trace file.
      32 elapsed seconds in trace file.Thanks & Regards
Sami

Similar Messages

Performance tuning for String operation in Field routine

Dear Experts,
I am writing a ABAP routine in field level for capturing an occurence of a string.
The string may occur in anny of the values in itab. The ITAB has around 100 thousand records and the source package 400 thousand records.
My coding goes as
LOOP AT INV_ITAB INTO INV_WA.
IF SOURCE_FIELDS-/BIC/X_ASSIGNM CS INV_WA-XFIELD3(7).+
     RESULT = INV_WA-PO_NO.
     EXIT.
ELSE.
     RESULT = 'NA'.
ENDIF.
ENDIF.
Now the coding takes more than 15 hours and still running. (It is working fine for small number of records) .
I beleive the problem is in the LOOP statement (goes around 400000*100000 times). Is it possible for me to somehow improve this code so as to decrease the load time.
Kindly help on this.
Thanks,
Rajarathnam.S

Hi,
I think you can use this code in your start routine instead of field level it will speed up your process.As it checks on datapacket level instead of checking records one by one.
I am just putting some logic
LOOP AT INV_ITAB INTO INV_WA.
IF Datapackage-/BIC/X_ASSIGNM   CS INV_WA-XFIELD+3(7).
Datapackage-targetfield = INV_WA-PO_NO.
EXIT.
ELSE.
Datapackage-targetfield = 'NA'.
ENDIF.
ENDIF.
Regards,
Ravi

How to override the default delete operation

Hi,
I am new to Jheadstart, java coding for that matter.
Here's my situation,
I have a view which is based on a function (function returns a collection).
I have created instead of triggers on this view to perform insert/update/delete operations.
All these DML operations work as expected in Oracle database.
Now, I created an Entity object and a view object on this view in my jheadstart project.
When I run this Jheadstart application my insert and search operations run fine but update and delete operations fail with JBO-26080 error.
The underlying oracle error is "ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc."
I know that delete and update operations work fine in Oracle and hence I would like to override the default Jheadstart operations. Can any body tell me how can I do it or point me in right direction?

Hi,
From the JHeadstart Developer's Guide, chapter TroubleShooting - Problem Assessment:
If you are getting a JBO error (Business Components for Java error), try to perform the same data retrieval or data manipulation action using the BC4J Tester. You can
invoke the tester through a right-mouse-click on the BC4J application module. If you get the same error using the BC4J tester, the problem is in the BC4J object definitions. If you added business rules, or other custom code to your BC4J objects that executes during your data retrieval or data manipulation action, you can debug this code line-by-line by running the tester in debug mode. You can also look up the JBO error in the JDeveloper online help, for each error possible causes and how to solve them are described.
It sounds to me like you will also get this error in the BC4J Tester. This means that the problem is not related to JHeadstart. You can go to the JDeveloper discussion forum http://otn.oracle.com/discussionforums/jdev.html and ask your question there without mentioning JHeadstart. Maybe there is some switch you can set in the BC4J object to let BC4J not use SELECT FOR UPDATE.
Hope this helps,
Sandra Muller
JHeadstart Team

Need to Set Current Row when Using Built-in Data Control Delete Operation?

I have an af:table bound to a ViewObject (VO) collection (no Entity Object) - within each row, I include a column that contains a 'Remove' command button so the user can remove the row. I add the command button by dragging/dropping the built-in delete operation from the VO on the Data Control Palette. When I use this as is (no changes), the Remove button always deletes the first row in the collection, not the selected row. Do I need to add code to set the current row, and if so can someone please provide an example and specify where I need to add? thanks.
------ .jspx af:table with command button to remove each row ------
<af:table value="#{bindings.ListView1.collectionModel}" var="row"
rows="#{bindings.ListView1.rangeSize}"
first="#{bindings.ListView1.rangeStart}"
// note: I don't have any code added for selectedRow or makeCurrent - assuming this is built-in?
selectionState="#{bindings.ListView1.collectionModel.selectedRow}"
selectionListener="#{bindings.ListView1.collectionModel.makeCurrent}">
<af:column>
<af:commandButton actionListener="#{bindings.Delete.execute}"
text="Remove"
disabled="#{!bindings.Delete.enabled}"/>
</af:column>
---------- corresponding pagedef file ------------
<bindings>.....
<action id="Delete" IterBinding="ListView1Iterator"
InstanceName="SrchDataControl.ListView1"
DataControl="SrchDataControl" RequiresUpdateModel="false"
Action="30"/>
</bindings>
Note: I also tried solution posted on following thread, but again, only first row is deleted, not the selected row?: Delete and Commit
Message was edited by:
javaX

I just want to delete (or remove) it from the VO. Data for this VO is not on the database.
The function is doing what I want it to do (delete from the VO), its just always deleting the first row, versus the selected row. I select the command button next on a column next to an item further down in the list and it deletes the first row. The problem is setting the selected row to be removed - I thought setting the current row would be taken care of by the SelectListener?
selectionState="#{bindings.MyIspListView1.collectionModel.selectedRow}"
selectionListener="#{bindings.MyIspListView1.collectionModel.makeCurrent}"

Need help in Performance tuning for function...

Hi all,
I am using the below algorithm for calculating the Luhn Alogorithm to calculate the 15th luhn digit for an IMEI (Phone Sim Card).
But the below function is taking about 6 min for 5 million records. I had 170 million records in a table want to calculate the luhn digit for all of them which might take up to 4-5 hours.Please help me performance tuning (better way or better logic for luhn calculation) to the below function.
A wikipedia link is provided for the luhn algorithm below
Create or Replace FUNCTION AddLuhnToIMEI (LuhnPrimitive VARCHAR2)
 RETURN VARCHAR2
 AS
 Index_no NUMBER (2) := LENGTH (LuhnPrimitive);
 Multiplier NUMBER (1) := 2;
 Total_Sum NUMBER (4) := 0;
 Plus NUMBER (2);
 ReturnLuhn VARCHAR2 (25);
 BEGIN
 WHILE Index_no >= 1
 LOOP
 Plus := Multiplier * (TO_NUMBER (SUBSTR (LuhnPrimitive, Index_no, 1)));
 Multiplier := (3 - Multiplier);
 Total_Sum := Total_Sum + TO_NUMBER (TRUNC ( (Plus / 10))) + MOD (Plus, 10);
 Index_no := Index_no - 1;
 END LOOP;
 ReturnLuhn := LuhnPrimitive || CASE
 WHEN MOD (Total_Sum, 10) = 0 THEN '0'
 ELSE TO_CHAR (10 - MOD (Total_Sum, 10))
 END;
 RETURN ReturnLuhn;
 EXCEPTION
 WHEN OTHERS
 THEN
 RETURN (LuhnPrimitive);
 END AddLuhnToIMEI;
http://en.wikipedia.org/wiki/Luhn_algorithmAny sort of help is much appreciated....
Thanks
Rede

There is a not needed to_number function in it. TRUNC will already return a number.
Also the MOD function can be avoided at some steps. Since multiplying by 2 will never be higher then 18 you can speed up the calculation with this.
create or replace
FUNCTION AddLuhnToIMEI_fast (LuhnPrimitive VARCHAR2)
 RETURN VARCHAR2
 AS
 Index_no pls_Integer;
 Multiplier pls_Integer := 2;
 Total_Sum pls_Integer := 0;
 Plus pls_Integer;
 rest pls_integer;
 ReturnLuhn VARCHAR2 (25);
 BEGIN
 for Index_no in reverse 1..LENGTH (LuhnPrimitive) LOOP
 Plus := Multiplier * TO_NUMBER (SUBSTR (LuhnPrimitive, Index_no, 1));
 Multiplier := 3 - Multiplier;
 if Plus < 10 then
 Total_Sum := Total_Sum + Plus ;
 else
 Total_Sum := Total_Sum + Plus - 9;
 end if;
 END LOOP;
 rest := MOD (Total_Sum, 10);
 ReturnLuhn := LuhnPrimitive || CASE WHEN rest = 0 THEN '0' ELSE TO_CHAR (10 - rest) END;
 RETURN ReturnLuhn;
 END AddLuhnToIMEI_fast;
/My tests gave an improvement for about 40%.
The next step to try could be to use native complilation on this function. This can give an additional big boost.
Edited by: Sven W. on Mar 9, 2011 8:11 PM

Performance Tuning Guide Needed.

I've seen numerous references to a "Performance Tuning Guide" Is there
any way this document could be posted on the weblogic customer
downloads.
We desperately need this information. Even with working with Support so
far the process has been trial and error. Try this, then try that. I've
burnt many days just playing around with the properties and so far no
luck.
I've read just about every post in the performance newsgroup. Some seem
to be the same types of problems we are currently facing. Great
response when there are about 50 users. Horrible around 65. Slowness
doesn't seem to be gradual. All of a sudden it starts to crawl. So far
I haven't seen any posts regarding solutions (weblogic.properties
settings) which I could try and use.
We are currently using weblogic 4.0.3 on AIX 4.3 with Oracle 8.i. No
native performance pack for that release. Will upgrading to 4.5.1
increase performance dramatically? Our application is very database
dependent. We use a the weblogic connection pool using Oracle's jdbc
thin driver. Note Oracle's OCI driver has numerous bugs related to CLOB
and BLOB retrieval which are used heavily in our database.
Thanks,
Don DeLuca

Hi Don,
I can't comment on the public posting of the Capacity Planning document.
However, I can say that there is no magic formula for optimizing your
WebLogic application. The biggest things to look at are the application
design and code (e.g., unnecessary synchronization code), DBMS configuration
and database design, JVM heap size (bigger is not always better), number of
execute threads (more is not always better), number of database connections
in the pool, whether or not you are using the performance pack, how much
other activity is happening on the server machine, etc. I can tell you that
trying to simulate a large number of clients from a single JVM client (using
lots of threads) will lead you to believe that the server is having problems
when it is really the client software/hardware that is often the limiting
factor. In many of our large benchmarks, we end up using significantly more
hardware for driving the clients than for running the server(s).
Sorry I don't have any better answers for you,
Robert
Don DeLuca wrote:
I've seen numerous references to a "Performance Tuning Guide" Is there
any way this document could be posted on the weblogic customer
downloads.
We desperately need this information. Even with working with Support so
far the process has been trial and error. Try this, then try that. I've
burnt many days just playing around with the properties and so far no
luck.
I've read just about every post in the performance newsgroup. Some seem
to be the same types of problems we are currently facing. Great
response when there are about 50 users. Horrible around 65. Slowness
doesn't seem to be gradual. All of a sudden it starts to crawl. So far
I haven't seen any posts regarding solutions (weblogic.properties
settings) which I could try and use.
We are currently using weblogic 4.0.3 on AIX 4.3 with Oracle 8.i. No
native performance pack for that release. Will upgrading to 4.5.1
increase performance dramatically? Our application is very database
dependent. We use a the weblogic connection pool using Oracle's jdbc
thin driver. Note Oracle's OCI driver has numerous bugs related to CLOB
and BLOB retrieval which are used heavily in our database.
Thanks,
Don DeLuca

On performing continuous delete operation database hangs

Dear All,
On performing continuous delete operation , the instance on which delete operation is performed database hangs i.e it does not allows to make new connection and some times on alert log we get ORA-3136 error
Database version 10.2.0.3 , OS : HP-UXvi3
Regards

Refer this thread
ORA-3136 while performing bulk delete

How Increase performance of delete operation

Hi,
How Increase performance of delete operation. This delete is done on a table which has around millions of records and loaded back every day .
The statement is in a procedure and is as follows.
#$%%$#$;
commit;
delete from TVRBC_SITE_ROLLUP_T;
commit;

Hi,
execute immediate 'truncate table TVRBC_SITE_ROLLUP_T';
Regards,
Oleg
Message was edited by:
tsiboleg

Need clear steps for doing performance tuning on SQL Server 2008 R2 (DB Engine, Reporting Services and Integration Services)

We have to inverstigate about a reporting solution where things are getting slow (may be material, database design, network matters).
I have red a lot in MSDN and some books about performance tuning on SQL Server 2008 R2 (or other) but frankly, I feel a little lost in all that stuff
I'am looking for practical steps in order to do the tuning. Someone had like a recipe for that : a success story...
My (brain storm) Methodology should follow these steps:
Resource bottlenecks: CPU, memory, and I/O bottlenecks
tempdb bottlenecks
A slow-running user query : Missing indexes, statistics,...
Use performance counters : there are many, can one give us the list of the most important
how to do fine tuning about SQL Server configuration
SSRS, SSIS configuration ?
And do the recommandations.
Thanks
"there is no Royal Road to Mathematics, in other words, that I have only a very small head and must live with it..."
Edsger W. Dijkstra

Hello,
There is no clear defined step which can be categorized as step by step to performance tuning.Your first goal is to find out cause or drill down to factor causing slowness of SQL server it can be poorly written query ,missing indexes,outdated stats.RAM crunch
CPU crunch so on and so forth.
I generally refer to below doc for SQL server tuning
http://technet.microsoft.com/en-us/library/dd672789(v=sql.100).aspx
For SSIS tuning i refer below doc.
http://technet.microsoft.com/library/Cc966529#ECAA
http://msdn.microsoft.com/en-us/library/ms137622(v=sql.105).aspx
When I face issue i generally look at wait stats ,wait stats give you idea about on what resource query was waiting.
--By Jonathan KehayiasSELECT TOP 10
wait_type ,
max_wait_time_ms wait_time_ms ,
signal_wait_time_ms ,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
AS percent_total_waits ,
100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
AS percent_total_signal_waits ,
100.0 * ( wait_time_ms - signal_wait_time_ms )
/ SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0 -- remove zero wait_time
AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC
use below link to analyze wait stats
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
HTH
PS: for reporting services you can post in SSRS forum
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers

Need help in Delete operation using blazeDS

Please find the flex client code and servlet code given below
Trying to call a DELETE methods on the servlet using BlazeDS.Configuration is perfect in the proxy-config.xml and services-config.xml
when DELETE is called with paramter user="krishna it is being printed as
received DELETE operation with parameternull
My Question is why the servlet printing null value for the user where it should print "someuser"?Can some one help me on this?
FLEX CLIENT
<?xml version="1.0" encoding="utf-8"?><mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
<mx:Script><![CDATA[
import mx.controls.Alert;
import mx.rpc.http.HTTPService;
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
public function callServletDELETE():void {
var service:HTTPService = new HTTPService();
//service.url= "http://localhost:8080/examples/blazeDS";service.destination=
"BlazeDSHTTP"; //this is configured in proxy-config.xml fileservice.useProxy =
true; service.method =
"DELETE"; service.resultFormat=
"e4x"; service.addEventListener(
"result", billingCarrierResult);service.addEventListener(
"fault", httpFault); service.send({user:
'someuser'});}
protected function billingCarrierResult(event:ResultEvent):void{
serviceResultsTextArea.text =
"Success with BlazeDS!\n"+event.result;
protected function httpFault(event:FaultEvent):void{
serviceResultsTextArea.text =
"Failure trying to access service.\n"+ event.fault.faultString + "\n" + event.fault.faultDetail;}
]]>
</mx:Script> <mx:TextArea id="serviceResultsTextArea" width="50%" height="50%" />
<mx:Button label="DELETE" click="callServletDELETE()"/>
</mx:Application>
servlet
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
* Simple example intended to demonstrate BlazeDS with HttpService.
public class BlazeHttpExample extends HttpServlet
 //excluded other methods GET,POST as they are working fine
 * Handles the HTTP <code>DELETE</code> method.
 * @param request servlet request
 * @param response servlet response
 @Override
 protected void doDelete(HttpServletRequest request, HttpServletResponse response)
 throws ServletException, IOException
 System.out.println("received DELETE operation with parameter"+request.getParameter("user"));
 @Override
 public String getServletInfo()
 return "Simple intended to illustrate BlazeDS HttpService support.";

in your java code you are considering user as the parameter.. but that is not a parameter..
When making a http call in flex try something like this
var obj:Object = new Object();
obj["user"] = 'someuser';
service.send(obj);
this should work hopefully.

Need OES Performance tuning steps for 10g

Hi Guys,
I am looking for a performance tuning document for OES 10g?
can someone provide me that or can someone illustrate the steps please?
Regards,
Naveen

Hi Gopi,
Following are the different tools provided by SAP for performance analysis of an ABAP object
Run time analysis transaction SE30
This transaction gives all the analysis of an ABAP program with respect to the database and the non-database processing.
SQL Trace transaction ST05
The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.
check these links:
http://www.sapgenie.com/abap/performance.htm
http://www.sapdevelopment.co.uk/perform/performhome.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_Introduction.asp
regards,
keerthi.

Resources for performance tuning and RAC needed

Can you suggest me the best knowledge resources for performance tuning and RAC?
Besides Oracle doc ...
Thanks!

Before all, I'm searching for resources on web like performance tuning from Dizwell Informatics is.
Anyway thank you Eric for your suggestion!

Performance Tuning Tips

Dear All,
In our project we are facing lot of problems with the Performance, users are compaining about the poor performance of the few reports and all, we are in the process of fine tuning the reports by following the all methods/suggestions provided by SAP ( like removing the select queries from Loops, For all entries , Binary serach etc )
But still I want to know from you people what can we check from BASIS percpective ( all the settings ) and also ABAP percpective to improve the performance.
And also I have one more query that what is " Table Statistics " , what is the use of this ...
Please give ur valueble suggestions to us in improving the performance .
Thanks in Advance !

Hi
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 contdFor 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.
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 # 13SORT 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 usefull

Need performance tunning

select partner from but000 into (ITAB-PARTNER1)
WHERE PARTNER IN PARTNER AND TYPE = '2'.
 SELECT SINGLE PARTNER_GUID FROM BUT000 INTO CORRESPONDING FIELDS OF ITAB
 WHERE PARTNER = ITAB-PARTNER1.
 IF SY-SUBRC = 0.
 SELECT single CLASSIFIC FROM CRMM_BUT_FRG0041 INTO CORRESPONDING FIELDS OF ITAB
 WHERE PARTNER_GUID = ITAB-PARTNER_GUID.
 endif.
 IF SY-SUBRC = 0.
 SELECT SINGLE SALES_ORG FROM CRMM_BUT_LNK0031
 INTO CORRESPONDING FIELDS OF ITAB
 WHERE PARTNER_GUID = ITAB-PARTNER_GUID .
 ENDIF.
 IF SY-SUBRC = 0.
 IF GEOGRAPY EQ ' '.
 SELECT SINGLE SHORT STEXT FROM HRP1000 INTO CORRESPONDING FIELDS OF ITAB
 WHERE OTJID = ITAB-SALES_ORG AND LANGU = 'E' .
 ELSE.
 SELECT SINGLE SHORT STEXT FROM HRP1000 INTO CORRESPONDING FIELDS OF ITAB
 WHERE OTJID = ITAB-SALES_ORG AND LANGU = 'E' AND STEXT = GEOGRAPY .
 ENDIF.
 ENDIF.
 IF SY-SUBRC = 0.
 SELECT ADDRNUMBER FROM BUT020 INTO CORRESPONDING FIELDS OF ITAB
 WHERE PARTNER = ITAB-PARTNER1.
 ENDSELECT.
*ENDIF.
 IF SY-SUBRC = 0.
 SELECT NAME1 CITY1 TEL_NUMBER FROM ADRC
 INTO (ITAB-NAME1, ITAB-CITY, ITAB-TEL_NUMBER1)
 WHERE ADDRNUMBER = ITAB-ADDRNUMBER. "and country IN GEOGRAPY.
 ENDSELECT.
*ENDIF.
 SELECT SMTP_ADDR FROM ADR6 INTO CORRESPONDING FIELDS OF ITAB
 WHERE ADDRNUMBER = ITAB-ADDRNUMBER.
 ENDSELECT.
 APPEND ITAB.
 clear itab.
ENDSELECT.
********for responsible employee
SELECT PARTNER1 PARTNER2 RELTYP
 FROM BUT050
 INTO TABLE I_BUT050 FOR
 ALL ENTRIES IN ITAB WHERE PARTNER1 = ITAB-PARTNER1 and reltyp = 'BUR011'.
IF NOT I_BUT050[] IS INITIAL.
 loop at i_but050.
 SELECT PARTNER PARTNER_GUID NAME_FIRST NAME_LAST
 FROM BUT000
 INTO (I_BUT000-partner,I_BUT000-PARTNER_GUID2, I_BUT000-FNAME, I_BUT000-LNAME)
 WHERE PARTNER = I_BUT050-PARTNER2 .
 select partner_guid from but000 into (i_but000-partner_guid1)
 where partner = I_BUT050-PARTNER1.
 endselect.
 SELECT SALES_ORG CHANNEL DIVISION PARTNER_FCT FROM CRMM_BUT_FRG0081
 INTO (I_BUT000-RSALES_ORG, I_BUT000-CHANNEL,I_BUT000-DIVISION,I_BUT000-PARTNER_FCT)
 where rel_partner_guid = i_but000-partner_guid2 and partner_guid = I_BUT000-partner_guid1.
 where division <> ''.
 ENDSELECT.
 SELECT SINGLE DESCRIPTION FROM CRMC_PARTNER_FT INTO CORRESPONDING FIELDS OF I_BUT000
 WHERE PARTNER_FCT = I_BUT000-PARTNER_FCT AND SPRAS = 'E'.
 SELECT SINGLE STEXT FROM HRP1000 INTO (I_BUT000-STEXT_R)
 WHERE OTJID = I_BUT000-RSALES_ORG AND LANGU = 'E'.
 SELECT SINGLE DESCRIPTION FROM CRMC_DIVISION_T INTO (I_BUT000-DESC)
 WHERE DIVISION = I_BUT000-DIVISION AND LANGU = 'E'.
 SELECT SINGLE DESCRIPTION FROM CRMC_DISTCHAN_T INTO (I_BUT000-CHANNEL_DESC)
 WHERE DISTCHAN = I_BUT000-CHANNEL AND LANGU = 'E'.
 i_but000-partner1 = i_but050-partner1.
 append i_but000.
 clear i_but000.
 endselect.
 endloop.
ENDIF.
*************for contract person **************
SELECT PARTNER1 PARTNER2 RELTYP
 FROM BUT050
INTO TABLE I_BUT050 FOR
 ALL ENTRIES IN ITAB WHERE PARTNER1 = ITAB-PARTNER1 and reltyp = 'BUR001'.
IF NOT I_BUT050[] IS INITIAL.
 loop at i_but050.
 SELECT PARTNER NAME_FIRST NAME_LAST
 FROM BUT000
 INTO (IC_BUT000-partner2, IC_BUT000-NAME_FIRST, IC_BUT000-NAME_LAST)
 WHERE PARTNER = I_BUT050-PARTNER2 .
 iC_but000-partner1 = i_but050-partner1.
 append iC_but000.
 clear iC_but000.
 endselect.
 endloop.
ENDIF.
SELECT PARTNER1 PARTNER2 PAFKT PAAUTH ABTNR
FROM BUT051
INTO TABLE I_BUT051
FOR ALL ENTRIES IN IC_BUT000 WHERE PARTNER2 = IC_BUT000-PARTNER2.
SELECT PAFKT BEZ30
FROM TB913
INTO TABLE I_TB913
FOR ALL ENTRIES IN I_BUT051 WHERE PAFKT = I_BUT051-PAFKT AND SPRAS = 'EN'.
SELECT PAAUTH BEZ20
FROM TB915
INTO TABLE I_TB915
FOR ALL ENTRIES IN I_BUT051 WHERE PAAUTH = I_BUT051-PAAUTH AND SPRAS = 'EN'.
SELECT ABTNR BEZ20
FROM TB911
INTO TABLE I_TB911
FOR ALL ENTRIES IN I_BUT051 WHERE ABTNR = I_BUT051-ABTNR AND SPRAS = 'EN'.
SELECT PARTNER ADDRNUMBER
FROM BUT020
INTO TABLE I_BUT020
 FOR ALL ENTRIES IN IC_BUT000 WHERE PARTNER = IC_BUT000-PARTNER2.
SELECT ADDRNUMBER TEL_NUMBER FROM ADCP
INTO TABLE I_ADCP
FOR ALL ENTRIES IN I_BUT020 WHERE ADDRNUMBER = I_BUT020-ADDRNUMBER .
SELECT ADDRNUMBER SMTP_ADDR FROM ADR6
INTO TABLE I_ADR6
FOR ALL ENTRIES IN I_BUT020 WHERE ADDRNUMBER = I_BUT020-ADDRNUMBER .
LOOP AT IC_BUT000.
 READ TABLE I_BUT051 WITH KEY PARTNER1 = IC_BUT000-PARTNER1 PARTNER2 = IC_BUT000-PARTNER2.
 IF SY-SUBRC = 0.
 READ TABLE I_TB913 WITH KEY PAFKT = I_BUT051-PAFKT .
 IF SY-SUBRC = 0.
 MOVE I_TB913-BEZ30 TO IC_BUT000-BEZ30.
 ENDIF.
 READ TABLE I_TB915 WITH KEY PAAUTH = I_BUT051-PAAUTH .
 IF SY-SUBRC = 0.
 MOVE I_TB915-BEZ20 TO IC_BUT000-BEZ20.
 ENDIF.
 READ TABLE I_TB911 WITH KEY ABTNR = I_BUT051-ABTNR .
 IF SY-SUBRC = 0.
 MOVE I_TB911-BEZ2 TO IC_BUT000-BEZ2.
 ENDIF.
 ENDIF.
 READ TABLE I_BUT020 WITH KEY PARTNER = IC_BUT000-PARTNER2.
 IF SY-SUBRC = 0.
 READ TABLE I_ADCP WITH KEY ADDRNUMBER = I_BUT020-ADDRNUMBER.
 IF SY-SUBRC = 0.
 MOVE I_ADCP-TEL_NUMBER TO IC_BUT000-TEL_NUMBER.
 ENDIF.
 READ TABLE I_ADR6 WITH KEY ADDRNUMBER = I_BUT020-ADDRNUMBER.
 IF SY-SUBRC = 0.
 MOVE I_ADR6-SMTP_ADDR TO IC_BUT000-SMTP_ADDR2.
 ENDIF.
 ENDIF.
 MODIFY IC_BUT000.
ENDLOOP.

Hi
DON"T USE SELECT and ENDSELECT staments it acts like an LOOP
see these points
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.
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.
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.

Performance Tuning in IR

Hello All,
We have created some reports using Interactive Reporting Studio. The volume of data in that Oracle database are huge and in some tables of the relational database are having above 3-4 crores rows individually. We have created the .oce connection file using the 'Oracle Net' option. Oracle client ver is 10g. We earlier created pivot, chart and report in those .bqy files but had to delete those where-ever possible to decrease the processing time for getting those report generated.
But deleting those from the file and retaining just the result section (the bare minimum part of the file) even not yet helped us out solving the performance issue fully. Still now, in some reports, system gives error message 'Out of Memory' at the time of processing those reports. The memory of the client PCs,wherefrom the reports are being generated are 1 - 1.5 GB. For some reports, even it takes 1-2 hours for saving the results after process. In some cases, the PCs gets hanged at the time of processing. When we extract the query of those reports in sql and run them in TOAD/SQL PLUS, they take not so much time like IR.
Would you please help us out in the aforesaid issue ASAP? Please share your views/tips/suggestions etc in respect of performance tuning for IR. All reply would be highly appreciated.
Regards,
Raj

SQL + & Toad are tools that send SQL and spool results; IR is a tool that sends a request to the database to run SQL and then fiddles with the results before the user is even told data has been received. You need to minimize the time spent by IR manipulating results into objects the user isn't even asking for.
When a request is made to the database, Hyperion will wait until all of the results have been received. Once ALL of the results have been received, then IR will make multiple passes to apply sorts, filters and computed items existing in the results section. For some unknown reason, those three steps are performed more inefficiently then they would be performed in a table section. Only after all of the computed items have been calculated, all filters applied and all sorts sorted, then IR will start to calculate any reports, charts and pivots. After all that is done, the report stops processing and the data has been "returned"
To increase performance, you need to fine tune your IR Services and your BQY docs. Replicate your DAS on your server - it can only transfer 2g before it dies, restarts and your requested document hangs. You can replicated the DAS multiple times and should do so to make sure there are enough resources available for any concurrent users to make necessary requests and have data delivered to them.
To tune your bqy documents...
1) Your Results section MUST be free of any sorts, filters, or computed items. Create a staging table and put any sorts or local filters there. Move as many of your computed items to your database request line and ask the database to make the calculation (either directly or through stored procedures) so you are not at the mercy of the client machine. Any computed items that cannot be moved to the request line, need to be put on your new staging table.
2) Ask the users to choose filters. Programmatically build dynamic filters based on what the user is looking for. The goal is to cast a net only as big as the user needs so you are not bringing back unnecessary data. Otherwise, you will bring your server and client machines to a grinding halt.
3) Halt any report pagination. Built your reports from their own tables and put a dummy filter on the table that forces 0 rows in the table until the report is invoked. Hyperion will paginate every report BEFORE it even tells the user it has results so this will prevent the user from waiting an hour while 1000s of pages are paginated across multiple reports
4) Halt any object rendering until request. Same as above - create a system programmically for the user to tell the bqy what they want so they are not waiting forever for a pivot and 2 reports to compile and paginate when they want just a chart.
5) Saved compressed documents
6) Unless this document can be run as a job, there should be NO results stored with the document but if you do save results with the document, store the calculations too so you at least don't have to wait for them to pass again.
7) Remove all duplicate images and keep the image file size small.
Hope this helps!
PS: I forgot to mention - aside from results sections, in documents where the results are NOT saved, additional table sections take up very, very, very small bits of file size and, as long as there are not excessively larger images the same is true for Reports, Pivots and Charts. Additionally, the impact of file size only matters when the user is requesting the document. The file size is never an issue when the user is processing the report because it has already been delivered to them and cached (in workspace and in the web client)
Edited by: user10899957 on Feb 10, 2009 6:07 AM

Need Performance tuning in delete operation

Similar Messages

Maybe you are looking for