About select data performance

Question

hi experts:
   about performance when select data from table
    if i use index to slect data,it can run fast,but costomer tell me can't use index,
for exmple: internel table itab_01[] has 2000 data, ztable has 1,000,000 data
then  select vbeln from ztable into table itab_02
for all entriesin itab_01
where vbeln = itab_01-vbeln.
it runs very slowly....
i try to use select vbeln from ztable into table itab_02.then use loop read ...
it runs ok. can i use this method?
does it increase memory???
chen xinrong

Answer 1

Hi,
You can see a report performance in SE30(Runtime analysis)and
SQLtrace(ST05).
ST05 tells you the list of selected statements.
You should remember some points when you tuning the code
- Use the GET RUN TIME command to help evaluate performance. It's
hard to know whether that optimization technique REALLY helps unless you
test it out. Using this tool can help you know what is effective, under what
kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so
you should use it to test small pieces of your program, rather than the
whole program.
- *Generally, try to reduce I/O first, then memory, then CPU activity.
*I/O operations that read/write to hard disk are always the most
expensive operations. Memory, if not controlled, may have to be written to
swap space on the hard disk, which therefore increases your I/O read/writes
to disk. CPU activity can be reduced by careful program design, and by using
commands such as SUM (SQL) and COLLECT (ABAP/4).
- Avoid 'SELECT *', especially in tables that have a lot of fields.
Use SELECT A B C INTO instead, so that fields are only read if they are
used. This can make a very big difference.
- Field-groups can be useful for multi-level sorting and displaying.
However, they write their data to the system's paging space, rather than to
memory (internal tables use memory). For this reason, field-groups are only
appropriate for processing large lists (e.g. over 50,000 records). If
you have large lists, you should work with the systems administrator to
decide the maximum amount of RAM your program should use, and from that,
calculate how much space your lists will use. Then you can decide whether to
write the data to memory or swap space.
- Use as many table keys as possible in the WHERE part of your select
statements.
- Whenever possible, design the program to access a relatively
constant number of records (for instance, if you only access the
transactions for one month, then there probably will be a reasonable range,
like 1200-1800, for the number of transactions inputted within that month).
Then use a SELECT A B C INTO TABLE ITAB statement.
- Get a good idea of how many records you will be accessing. Log into
your productive system, and use SE80 -> Dictionary Objects (press Edit),
enter the table name you want to see, and press Display. Go To Utilities ->
Table Contents to query the table contents and see the number of records.
This is extremely useful in optimizing a program's memory allocation.
- Try to make the user interface such that the program gradually
unfolds more information to the user, rather than giving a huge list of
information all at once to the user.
- Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS
is the number of records you expect to be accessing. If the number of
records exceeds NUM_RECS, the data will be kept in swap space (not memory).
- Use SELECT A B C INTO TABLE ITAB whenever possible. This will read
all of the records into the itab in one operation, rather than repeated
operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement.
Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the
number of records you expect to access.
- If the number of records you are reading is constantly growing, you
may be able to break it into chunks of relatively constant size. For
instance, if you have to read all records from 1991 to present, you can
break it into quarters, and read all records one quarter at a time. This
will reduce I/O operations. Test extensively with GET RUN TIME when using
this method.
- Know how to use the 'collect' command. It can be very efficient.
- Use the SELECT SINGLE command whenever possible.
- Many tables contain totals fields (such as monthly expense totals).
Use these avoid wasting resources by calculatin
Rgds,
P.Naganjana Reddy