2 Replies Latest reply: Jan 23, 2013 1:11 PM by Orkun Gedik RSS

Performance issue in KONP or KONV table

Ananya Mukherjee
Currently Being Moderated

Hi,

 

We are preparing a SD rebate agreement report where we need to fetch data from condition tables like KONP, KONV, KONH.

 

Firstly we need key fields (KNUMH, KOPOS) from KONP by providing Agreement no (KNUMA). Its taking a absurd time to fetch the data, sometimes showing time out error.

When we normally accessing the table via se16 or se11 or se16n, its also taking long time to run.

I have collected the trace also( attaching herewithin).

Kindly help us in how to reduce the time to fetch data from the tables.

  • Re: Performance issue in KONP or KONV table
    Stefan Koehler
    Currently Being Moderated

    Hi Ananya,

    these traces are fine from a SAP perspective, but they are useless for query performance troubleshooting.

     

    Please check my blog for a "drill down approach" of that particular query:

    http://scn.sap.com/community/oracle/blog/2013/01/10/oracle-advanced-performance-troubleshooting-with-oradebug-and-stack-sampling

     

    Hand it over to your DBA team ... this is a typical Oracle DBA / Engineer troubleshooting task.

     

    Regards

    Stefan

  • Re: Performance issue in KONP or KONV table
    Orkun Gedik
    Currently Being Moderated

    Hi Ananya,

     

    The best way to collect the data is using BAPI instead of accessing data from the table(s), directly. Under the specific conditions, you may need to read the data from the tables, without calling a standard  function module.

     

    Regarding the sql statement you provided, using KNUMA_BO field in the where conditions. To read the data efficiently, where condition and the index fields should be corresponded. Be sure that the optimizer has been selected correct index and prepared execution plan. You can check this on shared cursor cache, by using ST04 transaction.

     

    Additionally, be sure that the database statistics have been collected, regulary. You can check this on DB13 transaction.

     

    One more thing that check for the index which is used in the call, exist on the database. You can check this, on the DB02 transaction.

     

    In short, you can create a secondary index with the "MANDT" and "KNUMA_BO" fields and see the result. As a rule of thumb, number of indexes shouldn't be more than 5, on a table.

     

    You question is very generic question. So, check the BAPI is exist first. If it is not available, apply the steps I provided.

     

    Best regards,

     

    Orkun Gedik

Actions