cancel
Showing results for 
Search instead for 
Did you mean: 

Performance issue with MaxDB

Former Member
0 Kudos

Dear all,

we just migrated from Linux/Sap DB to Win2003 64bit /MaxDB (KERNEL 7.5.0 BUILD 030-123-100-791)

The migration went well and the system is fully available. The perfromances in general have been improved with the new hardware..

The problem is that there is a customer program, Z* object obviously very important..., that in random way run in very bad way.

We compared it's execution on the old system and on the new machine , with the same variant.

In general on the old machine it ran more faster than on new machine, and in these cases on the new machines it need till 3 or 4 times (more than 10 hours) the execution on the old machine.

Sometimes insted on the new machine, with the same variant, it's executed in very fast way, requiring less time than on the old machine.

The Data Buffer cache on the new machine has been enlarged, and also the performance parameters from th note for MaxDB 7.5 have beed applied.

The statistics are refreshed every day.

When the performances on the new machine become bad for this program there are not exausted resources and there are free work process.

We noticed only the programm require a lot of time to execute this statement on the new machine:

SELECT * FROM BSAD

INTO CORRESPONDING FIELDS OF TABLE TB_BSAD

WHERE AUGBL EQ P_BELNR

AND BELNR NE P_BELNR

AND BUKRS EQ P_BUKRS

AND GJAHR EQ P_GJAHR.

Any idea ?

regards

Accepted Solutions (0)

Answers (1)

Answers (1)

markus_doehr2
Active Contributor
0 Kudos

This is a really bad sql statement.

Check if you really need all 179 fields of the table BSAD.

Your statement does a full table scan - and depending on the number of entries of that table (select count(*) from BSAD) this will take a lot of time if the table must be read from disk. If the table is still in the data cache, the statement will be faster - a lot faster. That may be the phenomenon you see, that it's executed one time fast and one time slow.

I would suggest the following:

Modify your code so that it reads only those fields you really need and check if you can qualify the statement in that manner, that it uses keyfields. If that is not possible create an index for this particular statement.

--

Markus