Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Performance large (condition) tables advice

erik_mulder
Explorer
0 Likes
766

I am not sure if this is the right subforum for this, but thought this is the most suitable.

We are currently executing a roll out project integrating a new company

in our ECC 5.00 system in a existing client already used by 3 other

companies. We use a table (A950) in the system for storing general

sales prices (key: application/condition type/sales

organisation/distribution channel/material/end date valid).

MANDT

KAPPL

KSCHL

VKORG

VTWEG

MATNR

DATBI

DATAB

KNUMH

Currently the table holds 1,2 million entries. At the go-live of the

new company 3 new condition types will be added to the A950 table and

the table will then grow to hold approx.5-6 million entries. We expect

to add 3-4 million condition records for the new condition types.

We are concerned if this number of entries will significantly reduce

performance in pricing as we expect this table will be heavily

accessed as 1 of the added condition types will be needed during almost

every pricing determination for new sales orders/quotations.

Is it with regards to performance better to add the 3 new condition

types to (separate) new condition tables (We expect to add 3-4 million

condition records for the new condition types), so there is some

spreading of the load. Hope anyone has advice for us concerning this matter. Thanks in advance.

Kind Regards,

Erik Mulder

I am not sure if this is the right subforum for this, but thought this is the most suitable.

We are currently executing a roll out project integrating a new company

in our ECC 5.00 system in a existing client already used by 3 other

companies. We use a table (A950) in the system for storing general

sales prices (key: application/condition type/sales

organisation/distribution channel/material/end date valid).

MANDT

KAPPL

KSCHL

VKORG

VTWEG

MATNR

DATBI

DATAB

KNUMH

Currently the table holds 1,2 million entries. At the go-live of the

new company 3 new condition types will be added to the A950 table and

the table will then grow to hold approx.5-6 million entries. We expect

to add 3-4 million condition records for the new condition types.

We are concerned if this number of entries will significantly reduce

performance in pricing as we expect this table will be heavily

accessed as 1 of the added condition types will be needed during almost

every pricing determination for new sales orders/quotations.

Is it with regards to performance better to add the 3 new condition

types to (separate) new condition tables (We expect to add 3-4 million

condition records for the new condition types), so there is some

spreading of the load. Hope anyone has advice for us concerning this matter. Thanks in advance.

Kind Regards,

Erik Mulder

3 REPLIES 3
Read only

Jelena_Perfiljeva
Active Contributor
0 Likes
654

You need to talk to your DBA and Basis about this.

Read only

Former Member
0 Likes
654

Hi Erik

Just wondering if you resolved your condition table performance issue. We are having similar performance issue on A915 table. Please let me know if you have any ideas or any information.

Thanks

jampalat

Read only

0 Likes
654

We are not live yet, so we don't know for sure if there is gonna be a problem. We decided to split the condition types over separate tables to distribute the load.