A016 & KAPOL Performance Tuning

[dean_hinson2]

Hi all,

We have a custom program that extracts all the pricing conditions for all applicable contracts.

We are using table A016 whch is a pooled table. During the performance trace, we noticed that the system use KAPOL instead the A016.

The problem is that that access to that table is very slow, and the program run for more that 8 hours.

1) Do you know some method to optimize the performances of the access in this A016/KAPOL?

2) Or maybe there's some call function to be used to extract contracts & condition without doing the classic select from A016 and then the KONP?

Here is our current code snippet..

SELECT * FROM a016 INTO TABLE g_t_a016

FOR ALL ENTRIES IN t_ekpo

WHERE kappl = 'M'

AND kschl IN r_kschl

AND evrtn = t_ekpo-ebeln

AND evrtp = t_ekpo-ebelp

AND datbi >= date_beg.

Thank you in advance.

Regards, Dean.

[dean_hinson2]

Hi all,

We have a custom program that extracts all the pricing conditions for all applicable contracts.

We are using table A016 whch is a pooled table. During the performance trace, we noticed that the system use KAPOL instead the A016.

The problem is that that access to that table is very slow, and the program run for more that 8 hours.

1) Do you know some method to optimize the performances of the access in this A016/KAPOL?

2) Or maybe there's some call function to be used to extract contracts & condition without doing the classic select from A016 and then the KONP?

Here is our current code snippet..

SELECT * FROM a016 INTO TABLE g_t_a016

FOR ALL ENTRIES IN t_ekpo

WHERE kappl = 'M'

AND kschl IN r_kschl

AND evrtn = t_ekpo-ebeln

AND evrtp = t_ekpo-ebelp

AND datbi >= date_beg.

Thank you in advance.

Regards, Dean.

[Former Member]

The SELECT on A016 in actuals fetches data from KAPOL pool.

Try fetching data using each Condition type one at a time if the number of condition types is less.

For POOL tables that contain large amounts of data and are highly accessed, convert the pooled table into a transparent table and add an index. POOLED tables are supposed to be collections of smaller tables that are quickly accessed from the database or are completely buffered in memory.

Pooled tables containing more than a few hundred rows and are accessed many times in a report or transaction are candidates for POOL to TRANSPARENT Conversion. For example, table A053 contains tax jurisdiction condition information and are accessed more than ten times in the sales order create transaction.

If the entire United States tax codes are loaded into these condition tables, the time to save a sales order increases to unacceptable levels. Converting the tax condition table to transparent and creating an index based upon the key fields, decreases processing time from minutes to seconds.

Hope this helps.

Reward points for all helpful answers.

Thanks,

Balaji

[dean_hinson2]

Hello all,

We finally figure it out... instead of using kschl IN r_kschl, we changed it to kschl = 'xxxx' and added a second select with the other conditon type with an APPENDING. That reduced the time spent parsing through the pooled table (ie. from 2 hours to 2 minutes). Woohoo!

Hope this helps anyone if the same situation in the future.

Regards, Dean.