I would like to share Comments on how client has given important preference for Performance on execution of transaction, Developments and Report.
What we can find through analysis from sap. How to get performance results in SAP for each execution and Back ground Jobs.
Transaction code for business transaction analysis is STAD.
Go to Menu bar Monitor –> performance—> Response time
Here you can get detailed analysis of Business transaction analysis
What we can find from business transaction analysis?
- Can easily find performance for each transaction on overall users or particular users.
- Can easily find performance for each Program.
- Can easily find performance for each back ground job for each user or overall.
- Can easily find from which server and Transaction and Program and user.
- Can easily find Response time and memory used in terms KB for each transaction and Program and user.
- Can easily find day by day how much memory using based on task types
- Can easily analyse how many calls per day based on task type or program.
- Can easily find Work load overview
Through Transaction code: ST03N also we can analyse the performance for transaction.
ST03N is transaction to direcly check work load monitor analysis.
Generally we have to analyse three external activities which will get more performance issues
- Transaction codes
- Developments/ coding impact on running transaction and Reports.
- Having performance issues with Transaction execution and posting the Documents?
Performance issue will get generally, because of huge records in Table level.
For example running MIRO transaction performance very slowly while posting and while checking the data. – Why the performance issue rising in particular transaction and How to resolve it?
Solution: In standard tables there was lot of huge records and while running transaction, program calling dependent tables, which have more data. To avoid this we have to create secondary index in Table level by using ABAPer.
In SAP we have two indexes 1) Primary index and 2) secondary index.
- Using primary keys will create automatically primary indexes. Used for primary keys in table.
- Secondary should be create manually as per the user requirement.
Secondary index is help full to effective way of retrieving the data from data base tables.
Index is like helping to you get easily data for your query.
It is not only use for Transactions, for reports also we will be create index. To generate the customized report with fast performance, Abaper will create indexes on dependent tables.
Please refer above link explained how to create secondary index in Transparent table.
Please refer above note and link explained how to create secondary index in standard table
- Having performance issues with Report execution and generating output?
Sometimes based on selection screen – system will perform and will take to execute the report.
Please refer below link
Arminda Jack explained clearly based on selection criteria the report performance get quickly. Thank you.
Please refer below link is explained standard report MB51 Performance improvement.
- Having performance issues with running of batch run for reports to get output?
When we get query on this, first we have to look into whether this batch run related to standard report or customized report. Mostly reason for customized report is coding.
We have to look into mostly into coding part which have more loops and FM and call functions which will be impact on performance of report.
Please refer below link explained reduce run time of batch program
Below Mentioned SAP notes on Performance
SAP Note 352979 – Collective note: Performance notes for IS-AFS-MM
SAP Note 134660 – Logistics Invoice Verification: Performance (RBKP)
SAP Note 158519 – Performance optimization in logistics invoice verification
SAP Note 311089 – Performance problems because of long PO history
SAP Note 389359 – MIRO: Performance problems check double invoice
SAP Note 756292 – Consulting: Performance MIRO Enter invoice
SAP Note 1143682 – MIRO/MIR7: Performance when entering an invoice document
SAP Note 191492- Performance: Customer developments in MM/WM
SAP Note 921164 – MB51: Improving the runtime using database hints
SAP Note 902675- MB51: Database hints to improve runtime / 4.70
SAP Note 1283280- MB51: Enhancements to multiple account assignment display
SAP Note 1233616- MB51: Bad performance by selection material numbers
SAP Note 555893- MB51: Preventing runtime error DBIF_RSQL_INVALID_RSQL
SAP Note 1159120- MB51: Selection of material numbers not quite correctly
SAP Note 531604- MB52: Performance improvement
SAP Note 540257- MB52: Performance improvement (only for Release 4.5B)
SAP Note 129599- MB52: Performance, incorrect display
SAP Note 1516684 MKPF fields added to MSEG – Performance optimization
SAP Note 1550000 MB51: Redesign of selection for performance optimization
SAP Note 1558298 MB5B: Redesign of selection to optimize performance
SAP Note 1567602 DB dependent steps to support the redesign of MB51
SAP Note 1598760 FAQ: MSEG Enhancement & Redesign MB51/MB5B
Hints: In SAP MM mostly will get performance issues in MIGO and MIRO. Why because there was huge records in standard tables like MSEG, EKBE, RBKP, and BSIP…
My humble request was if you are getting performance issue in MIRO, Please check first whether secondary index create in MSEG table or not.
Create secondary INDEX for MSEG table with the following fields as mentioned in note 413446 also.
Table MSEG: (Additional Index for CIN)
– Index: Index for reference documents.
If doesn’t work you can check if you are using the duplicate invoice.
Putting an index on RBKP (see note 134660) and BSIP (see note 389359)
could greatly improve the MIRO performance.
If in case if you have still issues then ……
In order to analyse, we need to create SQL trace from transaction ST05 for the user that will use transaction MIRO. First hit ST05 and hit Trace on. Then go to MIRO (and complete the transaction).Go back to ST05 > SWITCH OFF Trace. Hit Trace List > Here you should be getting the trace results. Please provide result to SAP, the analyse of this. They would like to ask you to check which tables are involved (most time) in the process?
Normally the creation of secondary indexes for MSEG
should suffice for considerable performance improvement as this avoids
a full table scan of MSEG
For reference please look into below link