reports standards and performense

Former Member · ‎04-21-2007

hi ,interview questions......

1)wat r the standards we follow while developing a report.

2)tell some steps for rreports performance increase.

Former Member · ‎04-21-2007

hi

standards from company to company.

like naming conventions, programing standards(using pretty printer, declaration of variables...), documentation of the code etc.

There are so many tips which you can find in all these links

http://www.erpgenie.com/abap/performance.htm

https://wiki.sdn.sap.com/wiki/display/ABAP/ABAPPerformanceand+Tuning

http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm

http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp

**reward if helpful

regards,

madhu

Former Member · ‎04-22-2007

Hi Vijay,

Normally, we have to follow client standards if any. If not we have to use our company standards.For example :While creating a report, need to use the proper naming conventions for variables, internal tables, subroutines etc.

Should not use Select........Endselect statements. Should not use select statement within a loop and endloop. Freeing of memory used variables, internal tables etc at end of the report. Proper documentation of the report.Use Pretty Printer and have to use extended program check.

For Performance increase, we need to use proper select statements, we can use secondary indexes etc.

Hope this helps.

Please reward if useful.

Thanks,

Srinivasa

amit_khare · ‎04-22-2007

Check the following -

Regards,

Amit

Reward all helpful replies.

Former Member · ‎04-23-2007

Hi Vijay Reddy,

Tools available in SAP to pin-point a performance problem

The runtime analysis (SE30)

SQL Trace (ST05)

Tips and Tricks tool

The performance database

Optimizing the load of the database

Using table buffering

Using buffered tables improves the performance considerably. Note that in some cases a stament can not be used with a buffered table, so when using these staments the buffer will be bypassed. These staments are:

Select DISTINCT

ORDER BY / GROUP BY / HAVING clause

Any WHERE clasuse that contains a subquery or IS NULL expression

JOIN s

A SELECT... FOR UPDATE

If you wnat to explicitly bypass the bufer, use the BYPASS BUFFER addition to the SELECT clause.

Use the ABAP SORT Clause Instead of ORDER BY

The ORDER BY clause is executed on the database server while the ABAP SORT statement is executed on the application server. The datbase server will usually be the bottleneck, so sometimes it is better to move thje sort from the datsbase server to the application server.

If you are not sorting by the primary key ( E.g. using the ORDER BY PRIMARY key statement) but are sorting by another key, it could be better to use the ABAP SORT stament to sort the data in an internal table. Note however that for very large result sets it might not be a feasible solution and you would want to let the datbase server sort it.

Avoid ther SELECT DISTINCT Statement

As with the ORDER BY clause it could be better to avoid using SELECT DISTINCT.

********reword some points.

Rgds,

P.Naganjana Reddy

Former Member · ‎04-23-2007

Hi Vijay,

Performance Tools :

ST05

You use ST05, Trace Request, to do a SQL trace.

When using SQL trace, it is good to run the program in debugger and just before you execute the SQL, go to ST05 in another session and turn the trace on.

After, or when, the SQL is finished, you can turn the trace off.

Then click on List Trace to see the details.

This is the way to control the traces.

If you just turn the trace on and then execute the program, you will get everything and will be overflooded with unnecessary information.

Runtime Analysis checks program execution time in microseconds. When you go to se30.if you give desired program name in performance file. It will take you to below screen. You can get how much past is your program.

In SM30(Runtime Analysis), Abap, database and System are the three rows which indicate the performance of our program.

These indicate the load on them by the program, which is determined by the length of the bar beside them.

For better performance, abap should be around 90% +, database should be 10% - and system can be around 20% - 45%.

This means that if the load on the database is less , performance is more. For abap the % should be more indicating the fine tuning of the coding so that DB load can be reduced to improve the performance.

follow the steps mentioned for better performance:

1) Don’t use nested select statement

2) If possible use for all entries in addition

3) In the where addition make sure you give all the primary key

4) Use Index for the selection criteria.

5) You can also use inner joins

6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.

7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly

Check these links

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1...

/people/hema.rao/blog/2006/09/25/performance-tuning--an-overlooked-activity

/people/rob.burbank/blog/2007/03/19/joins-vs-for-all-entries--which-performs-better

/people/rob.burbank/blog/2006/02/07/performance-of-nested-loops

http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm

http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_Introduction.asp

Hope this resolves your query.

Reward all the helpful answers.

Regards

Former Member · ‎04-23-2007

Hai ,

Below are the some tips to increase the performance of the database aceess time.

Have a look at them.

Following are the performance standards need to be following in writing ABAP programs:

1. Unused/Dead code

Avoid leaving unused code in the program. Either comment out or delete the unused situation. Use program --> check --> extended program to check for the variables, which are not used statically.

2. Subroutine Usage

For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:

This is better:

IF f1 NE 0.

PERFORM sub1.

ENDIF.

FORM sub1.

...

ENDFORM.

Than this:

PERFORM sub1.

FORM sub1.

IF f1 NE 0.

...

ENDIF.

ENDFORM.

3. Usage of IF statements

When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND , place the mostly likely false first and for the OR, place the mostly likely true first.

Example - nested IF's:

IF (least likely to be true).

IF (less likely to be true).

IF (most likely to be true).

ENDIF.

Example - IF...ELSEIF...ENDIF :

IF (most likely to be true).

ELSEIF (less likely to be true).

ELSEIF (least likely to be true).

ENDIF.

Example - AND:

IF (least likely to be true) AND

(most likely to be true).

ENDIF.

Example - OR:

IF (most likely to be true) OR

(least likely to be true).

4. CASE vs. nested Ifs

When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.

5. MOVE statements

When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.

MOVE BSEG TO *BSEG.

is better than

MOVE-CORRESPONDING BSEG TO *BSEG.

6. SELECT and SELECT SINGLE

When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to three times.

7. Small internal tables vs. complete internal tables

In general it is better to minimize the number of fields declared in an internal table. While it may be convenient to declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.

For example:

Instead of this:

data: t_mara like mara occurs 0 with header line.

Use this:

data: begin of t_mara occurs 0,

matnr like mara-matnr,

...

end of t_mara.

8. Row-level processing and SELECT SINGLE

Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple SELECT-SINGLE commands on a non-buffered table (check Data Dictionary -> Technical Info), you should do the following to improve performance:

o Use the SELECT into <itab> to buffer the necessary rows in an internal table, then

o sort the rows by the key fields, then

o use a READ TABLE WITH KEY ... BINARY SEARCH in place of the SELECT SINGLE command. Note that this only make sense when the table you are buffering is not too large (this decision must be made on a case by case basis).

9. READing single records of internal tables

When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should:

o SORT the table

o use READ TABLE WITH KEY BINARY SEARCH for better performance.

10. SORTing internal tables

When SORTing internal tables, specify the fields to SORTed.

SORT ITAB BY FLD1 FLD2.

is more efficient than

SORT ITAB.

11. Number of entries in an internal table

To find out how many entries are in an internal table use DESCRIBE.

DESCRIBE TABLE ITAB LINES CNTLNS.

is more efficient than

LOOP AT ITAB.

CNTLNS = CNTLNS + 1.

ENDLOOP.

12. Performance diagnosis

To diagnose performance problems, it is recommended to use the SAP transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and programs.

13. Nested SELECTs versus table views

Since releASE 4.0, OPEN SQL allows both inner and outer table joins. A nested SELECT loop may be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should either create a view in the data dictionary then use this view to select data, or code the select using a join.

14. If nested SELECTs must be used

As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:

Use this:

form select_good.

data: t_vbak like vbak occurs 0 with header line.

data: t_vbap like vbap occurs 0 with header line.

select * from vbak into table t_vbak up to 200 rows.

select * from vbap

for all entries in t_vbak

where vbeln = t_vbak-vbeln.

...

endselect.

endform.

Instead of this:

form select_bad.

select * from vbak up to 200 rows.

select * from vbap where vbeln = vbak-vbeln.

...

endselect.

endform.

Although using "SELECT...FOR ALL ENTRIES IN..." is generally very fast, you should be aware of the three pitfalls of using it:

Firstly, SAP automatically removes any duplicates from the rest of the retrieved records. Therefore, if you wish to ensure that no qualifying records are discarded, the field list of the inner SELECT must be designed to ensure the retrieved records will contain no duplicates (normally, this would mean including in the list of retrieved fields all of those fields that comprise that table's primary key).

Secondly, if you were able to code "SELECT ... FROM <database table> FOR ALL ENTRIES IN TABLE <itab>" and the internal table <itab> is empty, then all rows from <database table> will be retrieved.

Thirdly, if the internal table supplying the selection criteria (i.e. internal table <itab> in the example "...FOR ALL ENTRIES IN TABLE <itab> ") contains a large number of entries, performance degradation may occur.

15. SELECT * versus SELECTing individual fields

In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performace gains can be substantial. For example:

Use:

select vbeln auart vbtyp from table vbak

into (vbak-vbeln, vbak-auart, vbak-vbtyp)

where ...

Instead of using:

select * from vbak where ...

16. Avoid unnecessary statements

There are a few cases where one command is better than two. For example:

Use:

append <tab_wa> to <tab>.

Instead of:

<tab> = <tab_wa>.

append <tab> (modify <tab>).

And also, use:

if not <tab>[] is initial.

Instead of:

describe table <tab> lines <line_counter>.

if <line_counter> > 0.

17. Copying or appending internal tables

Use this:

<tab2>[] = <tab1>[]. (if <tab2> is empty)

Instead of this:

loop at <tab1>.

append <tab1> to <tab2>.

endloop.

However, if <tab2> is not empty and should not be overwritten, then use:

append lines of <tab1> [from index1] [to index2] to <tab2>.

If you tell these tips,Definiotely tha interviewer get impressed.

Reward points if it helps you.

Regds,

Rama chary.Pammi

VijayasekarK · ‎04-23-2007

Hi ,

Reporting Standards are the one which is client specific . To know about performace optimization refer sap study material BC 490

Regards,

Vijay