cancel
Showing results for 
Search instead for 
Did you mean: 

Transaction MIRO working slow for certain vendors only.

Former Member
0 Kudos

Hi All,

One of the end user using tcode MIRO is facing a problem.

Whenever the user tries to simulation option in transaction MIRO; the response is very slow ( though the actual items in the document are very less in number viz. 5 to 6 ). This problem is not faced everytime. But according to the obsevation it was found that this happens only for certain vendor documnets only. ( ! )

And on the contrary, for many documents those contain may items ( viz. 15-20 ) get simulated very quickly.

I have checked for the processes and found everything Ok.

Then I took the trace for that user for transaction MIRO.

I found the following SQl statement which takes too much time for fetching.

But I don't understand how to rectify this. ( the program is standard SAP one).

<b>HH:MM:SS.MS Duration Program Obj. name Op. Curs Array Recs. RC Conn WP Statement </b>

<i>16:17:58.186 7 SAPLJ1I4 MSEG REOPEN 119 0 R/3 2 <b><u>SELECT WHERE "MANDT" = '400' AND "LFBJA" = 2007 AND "LFBNR" = '5000025466' AND "LFPOS" = 0003</u> </b>

16:17:58.186 <b><u>1,555,853</u></b> SAPLJ1I4 MSEG FETCH 119 42 1 1403 R/3 2 </i>

( See the underlined number which is the excessive time taken to fetch the statement underlined )

Can anybody please guide about the possible causes for this problem and the remedy.

Or else if I am on right track.., please let me know how to analyse the problem from the trace and what to do ..to reduce the time consumed by this particular SQL statement.

Thanks.

---Shamish

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

well MSEG is usually a huge table and the SELECT has a WHERE clause with non indexed fields;

I have searched some note about it without sucess; can you also trace the SQL when we the same operation goes fast? I guess the SELECT statement would then be different.

Depending on if this is critical for the business or not you may consider creating an INDEX (very last option) with LFBJA and LFBNR.

How many entries do you have in MSEG?

hope this helps...

Olivier.

Former Member
0 Kudos

Hi Olivier,

Thanks.

I took the trace when it was working fast. But found the same situation. viz. the same staement takes longer time.

The table MSEG has 178 entries.

Can you please help further. Can there be any reason for this problem??

Thanks.

-


Shamish

Former Member
0 Kudos

Hi,

The first thing I would do, is to check the oracle parameters. It is possible that you have forgotten to set some "underscore" parameters

Former Member
0 Kudos

Hi Fidel,

Thanks.

Can you please explain more in details.

Which parameters...should I check? ( are you talking about profile parameters to be set in RZ10..?? )

Could you please guide me how to set those parameters and to what value?

May be that is the cause of this problem.

Please explain a bit more since...I have not faced performance related problems much before..

Thanks.

-


Shamish

Former Member
0 Kudos

are you really sure the SELECT was with the same WEHRE clause?

this would be really weird.

Please let us know...

Olivier.

Former Member
0 Kudos

Hi Olivier,

I have checked once again.

It is the same statement which is taking that much time. ( shown in RED ).

-


Shamish

Former Member
0 Kudos

<i>> Hi Fidel,

>

> Thanks.

>

> Can you please explain more in details.

>

> Which parameters...should I check? ( are you talking

> about profile parameters to be set in RZ10..?? )</i>

No, I'm talking about the oracle parameters ( I assume you are using Oracle database because this is the oracle forum )

<i>>

> Could you please guide me how to set those parameters

> and to what value?</i>

I do not know your SAP Release, nor your Oracle database.

You should check the following notes:

<a href="http://service.sap.com/sap/support/notes/830576">830576 : Parameter recommendations for Oracle 10g</a>

<a href="http://service.sap.com/sap/support/notes/124361">124361 : Oracle parameterization (R/3 >= 4.x, Oracle 8.x/9.x)</a>

<i>> May be that is the cause of this problem.

> Please explain a bit more since...I have not faced

> performance related problems much before..</i>

SQL tuning si too broad area as to explain in a forum reply.

There are too many things to check.

First one is this, be sure your oracle parameters are properly set.