Check this good link:
http://www.basisondemand.com/index.php?option=com_content&view=article&id=1338:performance-issue-sequential-reads-on-table-atpresb&catid=109:performance-tuning&Itemid=612
Sometimes after a monthly maintenance, when creating PO’s and maintaining purchase orders, we had performance issues in the R/3 system. Further we could see too many work processes running for a long time and they were doing fetch operation on table ATP_RESB.
Our end users used to create/modify the POs just in 2 seconds, but in the above mentioned situations, it was taking more than 3 minutes.
We took the query at SAP level which was causing this issue and tried to execute the same at the DB level. From SAP level it was taking the primary index RESB~0 (key fields) with an index scan and was taking more than a couple of minutes. Whereas from DB level it was completing inside 1 or 2 seconds using the index RESB~M (index on MATNR, WERKS) by doing an index seek and not an index scan. So in theory for some reason after the restart because SAP started using the wrong index at the first attempt, this got cached and the same was being used every time.
Solution : We tried to rebuild the index and immediately SAP started using the correct index ( RESB~M) and the performance issue was resolved
Check below link to know - How to rebuild index for RESB
http://sapist.blogspot.co.uk/2016/08/updating-statistics-index-regenerate.html
Check below link to know - How to rebuild index for RESB
http://sapist.blogspot.co.uk/2016/08/updating-statistics-index-regenerate.html
No comments:
Post a Comment