MRP performance on tools 9.2

[Gov]

Hello,

Before we move with 9.2.0.3 into PROD, we are running MRP in PY to see how it performs. It is too slow on new tools 9.2 compared to our old tools 8.98. When we run MRP for same set of data (PY refreshed with PD data), MRP in PY taking for more than 2 days, where as PD run takes 16 mins. Any one faced similar issue with new tools (like lag in performance)?

My Item selection count is about 26000 for one plant.

Thanks in advance for your input!

 

[Gov]

I noticed some SQL exceptions in the logs. Do you think this might be reason for performance?

May 24 11:19:56.812026 - 4992/7116 WRK:Starting jdeCallObject Entering JDB_SelectKeyed (hRequest 2B7F0968)
May 24 11:19:56.812027 - 4992/7116 WRK:Starting jdeCallObject ODBC[JDBODBC.C,4664] wSQLCloseCursor - warning: invalid cursor state failure. rc = -1
May 24 11:19:56.812028 - 4992/7116 WRK:Starting jdeCallObject ODBC[JDBODBC.C,4664] STMT:00 [24000][30022] [IBM][System i Access ODBC Driver]Invalid cursor state.
May 24 11:19:56.812029 - 4992/7116 WRK:Starting jdeCallObject ODBC:I DBResetRequest req=40D0E8D8 con=0BA9EE40 env=053DADB8 dbc=053DE800 spid=0 ATJDENP1 A (J_JDEPROXY@Business Data - CRP)
May 24 11:19:56.812030 - 4992/7116 WRK:Starting jdeCallObject SELECT SDKCOO, SDDOCO, SDDCTO, SDLNID, SDMCU, SDCO, SDRKCO, SDRORN, SDRCTO, SDRLLN, SDAN8, SDSHAN, SDPDDJ, SDITM, SDLOTN, SDLNTY, SDNXTR, SDEMCU, SDUOM, SDUORG, SDSOCN, SDQTYT, SDUOM4, SDSO11, SDCRCD, SDPRJM, SDBCRC, SDPDTT FROM CRPDTA/F4211 WHERE ( SDITM = 52019504.000000 AND SDMCU = ' 200100' ) AND ( SDPDDJ BETWEEN 00001 AND 116323 AND SDNXTR NOT IN ( '999','980' ) ) ORDER BY SDITM ASC,SDMCU ASC,SDPDDJ ASC,SDPDTT ASC

 

[aaro]

You can try:

1. Run BoM structure analysis- R30601
2. Verify processing options for R3483/R3482
3. Check SFC - should be setup 3-5 years ahead.
4. Check inclusion rules - P34004.
5. BRanch plant relationship for multi-plant planning.

Thanks

 

[sselman]

How did you refresh the data? Did you remember the indexes?

 

[Chan Rana]

Check the SQL statement generated if it is only selecting the records what it need to process?.

Chan

 

[Gov]

You can try:

1. Run BoM structure analysis- R30601
2. Verify processing options for R3483/R3482
3. Check SFC - should be setup 3-5 years ahead.
4. Check inclusion rules - P34004.
5. BRanch plant relationship for multi-plant planning.

Thanks

we run R30601 every night in PROD. so the data in PY should be ideally good as this is refreshed from PROD . I checked verified all other with Oracle guild lines. they look good to me.

 

[Gov]

How did you refresh the data? Did you remember the indexes?

The refresh was done by CNC just before tools upgrade. Not sure how he did. But if Indexes is an issue, will that also be an issue with Old tools in the same environment?

 

[sselman]

Run the index compare to central objects job to make sure.

or look at the SQL table and compare between the environments.

 

[john4444]

Hello,

Any Job completing late in PY as compared to PD. In your case PY 9.2 and PD on old release. PY has the data of PD. Slowness is not due to New JDE release.
Slowness caused relate to Hardware sizing of PY. Most of the time slowness links to Database activities of the JDE job. Reading / writing into database. Hardware/storage of the database. Indexing of the tables also plays major role in this.

Compare PY server configuration with the PD configuration , accordingly split the DS, PO and run the job.
Few clients set up Pre-production environment which has same configuration as PD.

Regards,
b

 

[Gov]

Thank you all for your valuable inputs. The slowness is because of a baseline ESU taken during tools upgrade. Today we run MRP by removing that, that run MRP less than the time it takes in Production. So it is not tools, it is the ESU. we are working with Oracle on this issue.

Thanks again,

 

[Toddly]

Hey Gov
Would you please tell me which baseline ESU was the culprit for you? We are experiencing the same issue. Is it one of the following?
JM14414 or JM18666 from the following ASI supplement? http://www.oracle.com/technetwork/tutorials/tutorial-2873993.pdf

Thanks Much

Todd

 

[kutch]

You mention "a baseline ESU taken during tools upgrade" as the cause of your issue -- Would you know the specific ESU to which you refer?

 

[Gov]

JL19248 was the baseline we removed

 

[Gov]

Hey Gov
Would you please tell me which baseline ESU was the culprit for you? We are experiencing the same issue. Is it one of the following?
JM14414 or JM18666 from the following ASI supplement? http://www.oracle.com/technetwork/tutorials/tutorial-2873993.pdf

Thanks Much

Todd

We have no issues with Tools ESU's. we had issues with other ESU - JL19248, which was taken part of MRP related issues.