Performance problem in SAP ECC6.0 environment on MaxDB

[Former Member]

Hi,

We are using SAP ECC 6.0 on MaxDB 7.7.03.24. We have imported the snapshot into the target system from the master. From the movement we have imported, we are getting a performance problem.

Everything is working fine, but for every transaction which we execute for the first time is taking really long.

Some times I even get time out error for the first time.

I cannot run SGEN on the target system as we did it on the master. So kindly let me know whether

there is something need to be done with the I/O buffer size or with the cache. Right now it is hit and try method I am adopting. But a perfect known solution will be good to save my time.

Yathi.

[Former Member]

HI,

for timeout error

increase value of rdisp/max_wprun_time parmaeter in instance profile.

during execution of tranasaction check SM50 which report is execute if it's generate the report then you have to perform SGEN on target system also.

regards,

kaushal

[markus_doehr2]

> We are using SAP ECC 6.0 on MaxDB 7.7.03.24.

I'm not sure ERP 6.0 is supported on 7.7 (it was only for SRM 6.0, CRM 2007 and others...)

> I cannot run SGEN on the target system as we did it on the master. So kindly let me know whether

> there is something need to be done with the I/O buffer size or with the cache. Right now it is hit and try method I am adopting. But a perfect known solution will be good to save my time.

Why can't you run SGEN?

What is the database doing when those problems occur? execute

x_cons show <SID> ac 1

on command line and post some of the output lines.

Markus

[Former Member]

Hi Markus,

The result of X_cons <sid> active is:

ID UKT Win TASK APPL Current Timeout Region Wait

tid type pid state priority cnt try item

T109 8 0x1A08 User 6796 IOWait(R)(041) 0 0 42368735(s)

T110 8 0x1A08 User 5792 IO Wait (R) 0 0 22 42368735(s)

T117 8 0x1A08 User 6584 IO Wait (R) 0 0 13 42368735(s)

Console command finished (2008-07-07 13:53:30).

For this report to execute it is taking really a long time.

I cannot run SGEN on the target because we are trying out a different conecept of copying systems where we can save our time. As we have taken a snapshot from the master it will not really help much even though we run SGEN. I cannot also tell more on this concept now.

Yathi.

[lbreddemann]

> I cannot run SGEN on the target because we are trying out a different conecept of copying systems where we can save our time. As we have taken a snapshot from the master it will not really help much even though we run SGEN. I cannot also tell more on this concept now.

>

> Yathi.

Ok, so you're working on a super-confidential new way of systemcopy and wonder that you don't get much help??

Funny - really.

Could it be that a recompilation of the reports/transaction is just necessary on the copied system (e.g. platform has changed?).

From the x_cons output we see that the usertasks are waiting for I/O ... so perhaps the I/O performance is bad or the chosen access path to the data is wrong...

In any case it would be a good idea to switch on ST05 - SQL Trace to get the sql commands that take so long.

regards,

Lars

[Former Member]

Hi Lars,

How to increase the I/O performance? Is it something I need to do with the I/O buffer size?

I am asking about I/O buffer size particularly because the Datalog cache figures are smaller than the normal.

How is Datalog cache related to the performance of a system?

*Could it be that a recompilation of the reports/transaction is just necessary on the copied system (e.g. platform has changed?).*

Do you mean that I need to run all the reports/transactions manually?

Yathi

[lbreddemann]

> How to increase the I/O performance? Is it something I need to do with the I/O buffer size?

> I am asking about I/O buffer size particularly because the Datalog cache figures are smaller than the normal.

Ok, what are the 'normal' datalog cache figures? What is a 'datalog' anyhow (there is nothing in MaxDB that has this name...).

I/O performance is not improved by a bigger database cache - a bigger cache just avoids I/O!

> How is Datalog cache related to the performance of a system?

Tell me what you mean by 'Datalog cache'

> *Could it be that a recompilation of the reports/transaction is just necessary on the copied system (e.g. platform has changed?).*

> Do you mean that I need to run all the reports/transactions manually?

No - I meant that a recompilation (e.g. via SGEN) can be necessary for the reports to run.

ABAP reports are not interpreted - they are compiled to byte code before execution time. To do that the source code for the transaction needs to be loaded from the database, the code needs to be compiled and the copiled bytecode is stored back into the database.

That happens always if no appropriate bytecode for a report is found in the REPOLOAD table.

Regards,

Lars

[Former Member]

Hi Lars,

Sorry it is a typo, I mean Catalog cache. It is 70% and I should not run SGEN as we are accessing data directly from the master.

[lbreddemann]

>

> Hi Lars,
> 
> Sorry it is a typo, I mean Catalog cache. It is 70% and I should not run SGEN as we are accessing data directly from the master.

Hmm... you're accessing data directly from the master ... that rings a bell to me.

Is this "new system copy" procedure supported by SAP? If so, you should open a support message for this.

As experience shows, it's pretty difficult to analyze performance issues via the forum - thus better use the support infrastructure of SAP for this.

regards Lars