Facin problems in the 'Select... for all entries'

Question

I am facing problem with this piece of code, please share ur thoughts on it. I have specified the inputs.
I am extracting the open items from the BSIS table for specified 3 account number.
Inputs to the prg:
field     No. of values
r_bukrs       1
r_hkont      2
r_blart     6
r_budat  date range of 1 yr
r_bldat  nil
v_tosdef contain 1 account number
" In each FI document posted, one line will have the 'v_tosdef' account number and one account from the 'r_hkont' values."
So will this query efficient.
  SELECT bukrs
         hkont
         gjahr
         belnr
         budat
         bldat
         xblnr
         blart
         shkzg
         dmbtr
    FROM bsis
    INTO TABLE i_bsis
   WHERE bukrs IN r_bukrs                    " Company code
     AND hkont =  v_tosdef                  " Account number
     AND budat IN r_budat                    " Posting date
     AND bldat IN r_bldat                    " Document date
     AND blart IN r_blart.                   " Document type
  IF sy-subrc <> 0.
    MESSAGE i003.
    STOP.
  ENDIF.
*@ Collecting the BELNR & GJAHR From the extracted records
  li_bsis[] = i_bsis[].
  SORT li_bsis BY bukrs gjahr belnr.
  DELETE ADJACENT
  DUPLICATES FROM li_bsis
        COMPARING bukrs gjahr belnr.
  IF NOT li_bsis[] IS INITIAL.
    SELECT bukrs
           hkont
           gjahr
           belnr
           budat
           bldat
           xblnr
           blart
           shkzg
           dmbtr
      FROM bsis
APPENDING TABLE i_bsis
       FOR ALL ENTRIES IN li_bsis
     WHERE bukrs = li_bsis-bukrs               " Company code
       AND hkont IN r_hkont                    " Account number
       AND gjahr =  li_bsis-gjahr              " Fiscal year
       AND belnr =  li_bsis-belnr.             " Document num
BSIS table size around 86GB
primary index size aroung 33GB
and the index quality is 54%
the CBO shows less cost, but the actual runs takes too much disk read's / bgets..
Message was edited by:
        Sandy

Answer 1

Hi Sandy,
You indicated the size of the tables and index, what is the total number of records in your BSIS?
In your range tables, make sure they are postive formed.
Ex. r_bukrs :  I EQ '1001', and not I NE '1000'.
You should consider coding your statements to check for input for bldat, code it with r_bldat and then another set without. It should be better performance to not have empty where conditions. So two routines, Selects with bldat and without.
Don't know if you have a Basis person to help analyze the performance, but you should look at the indexes in BSIS. You may have several indexes that contain some of your input fields but they may be spread across several indexes or there may be none. But say you have 5 indexes and it happens that just one of your parameters are in each of those indexes. Well, it can only use one index so while you think you are providing alot of parameters to help performance only one field is being used to access the index. What you need to do then is to find an index that has the most fields in your where clause and see if you can add to that, so long it's not an SAP index. If it's a z index consider adding additional fields to it, or consider creating a new index.
You can at least analyze the first Select in your DEV client. Run a trace, ST05 and then execute your code. It will show you which index it has used if any.
Also, look at the query values it is passing to the database. You said you get 6 M records on the first Select. This just seem like a lot of records, which is for just one account number (v_tosdef) along with the other parameters. I'm wondering if there's a problem with your input data. With 6M in your first table, your FOR ALL ENTRIES statement will be executed 1.2 million times. Tyically the database interface breaks down your Select-For All entries statement into 5 records per query. Again, run ST05 and you will see this.
In SE16, on your BSIS table, what is your count of records if you enter only the account number?
As a test, you might want to try entering all your parameters in SE16, run ST05 to trace the SQL to see what it is doing. You may have to kill your SE16 session or it may time out on you. You can stop your ST05 trace before your SE16 finishes and it will still show how SAP is going after the data and what index it used.
Let me know if this helped any.
Regards,
Filler