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 issue with MSEG table

Former Member
0 Likes
718

Hi all,

I need to fetch materials(MATNR) based on the service order number (AUFNR) in the selection screen,but there is performance isssue with this , how to over come this issue .

Regards ,

Amit

1 ACCEPTED SOLUTION
Read only

former_member251078
Participant
0 Likes
638

Hi,

There could be various reasons for performance issue with MSEG.

1) database statistics of tables and indexes are not upto date.

because of this wrong index is choosen during the execution.

2) Improper indexes, because there is no indexes with the fields mentioned in the WHERE clause of the statement. Because of this reason, CBO would have choosen wrong index and did a range scan.

3) Optimizer bug in oracle.

4) Size of table is very huge, archive.

Better switch on ST05 trace before you run this statements, so it will give more detailed information, where exactly time being spent during the execution.

Hope this helps

dileep

Hi all,

I need to fetch materials(MATNR) based on the service order number (AUFNR) in the selection screen,but there is performance isssue with this , how to over come this issue .

Regards ,

Amit

4 REPLIES 4
Read only

Former Member
0 Likes
638

hi Amit,

MSEG is a cluster table and has huge data ... so Try including all the key fields while fetching the data to improve the performance...

Regards,

Santosh

Read only

0 Likes
638

Is there any other table so that i can hit before hitting mseg table for material based on service order .

Read only

0 Likes
638

not sure, what exactly ur requirement is,

but try aufk, aFPO tables..

Read only

former_member251078
Participant
0 Likes
639

Hi,

There could be various reasons for performance issue with MSEG.

1) database statistics of tables and indexes are not upto date.

because of this wrong index is choosen during the execution.

2) Improper indexes, because there is no indexes with the fields mentioned in the WHERE clause of the statement. Because of this reason, CBO would have choosen wrong index and did a range scan.

3) Optimizer bug in oracle.

4) Size of table is very huge, archive.

Better switch on ST05 trace before you run this statements, so it will give more detailed information, where exactly time being spent during the execution.

Hope this helps

dileep