RSMO:
Used to monitor data flow to target system from source system. We
can see data by request, source system, time request id etc.It
provides all necessary information on times spent in different processes during
the load (e.g., extraction time, transfer, posting to PSA, processing
transformation rules, writing to fact tables).
In the upload monitor you are
also able to debug transfer and update rules.
If the extraction from an SAP source system consumes significant time, use the extractor checker (transaction RSA3) in the source system.
If the data transfer times are too high, check if too many work processes are busy (if so, avoid large data loads with “Update Data Targets in Parallel” method), and check swapping on one application server (set “rdisp/bufrefmode = “sendoff, exeauto” during load phase if you use several application servers).
If the extraction from an SAP source system consumes significant time, use the extractor checker (transaction RSA3) in the source system.
If the data transfer times are too high, check if too many work processes are busy (if so, avoid large data loads with “Update Data Targets in Parallel” method), and check swapping on one application server (set “rdisp/bufrefmode = “sendoff, exeauto” during load phase if you use several application servers).
RSRT:
The Query Monitor (transaction RSRT)
allows you to execute queries and to trace queries in a debug mode with several
parameters (e.g., do not use aggregates, do not use buffer, show SQL
statement).
In the debug mode, you can investigate if the correct aggregate(s) are used and which statistics the query execution generates. For checking reasons, you can switch off the usage of aggregates, switch to no parallel processing (see for more details in the MultiProvider section) or display the SQL statement and the run schedule.
In the debug mode, you can investigate if the correct aggregate(s) are used and which statistics the query execution generates. For checking reasons, you can switch off the usage of aggregates, switch to no parallel processing (see for more details in the MultiProvider section) or display the SQL statement and the run schedule.
Select a particular query and then click on performance
info.
Like this query we can generate detailed performance info for every query. Below is the screen shot containing the detailed information for this query.
Like this query we can generate detailed performance info for every query. Below is the screen shot containing the detailed information for this query.
Query tracing
:
RSRTRACE: The Query Trace Tool (transaction RSRTRACE) allows you to record some important function module calls and process and debug them at a later stage. Transaction RSRCATTTRACE takes the log of RSRTRACE as input and gives aggregates suggestions for the first execution AND all further navigations performed.
RSRV: BW objects can be checked for consistency in transaction RSRV and inconsistent objects can be repaired.
Apart from these BW tools, we have standard ABAP based tools like ST05, ST03n,
SE30, SM50 and SM51 to check and measure the performance of
the system.
In SE30, we have special options like if cases, field conversions and monitoring the SQL interface.
ST05:
The SQL trace (transaction ST05) records
all activities on the database and enables you to check long runtimes on a DB
table or several similar accesses to the same data.
If we find problems for an isolated process (upload or query) and we have analyzed for example the existence of aggregates, we can detail our analyses by using the SQL trace . Filter on a specific user (e.g. query user or extraction user ALEREMOTE) and make sure that no concurrent jobs run at the same time with this execution. We will find out which tables are accessed, what time is consumed and if some tables are accessed redundantly.
Another important tool to be used is ST10.
Here we can find out the statistics
of the table and get more detailed
info on a particular table. If we assume a general buffer problem, check
ST10 and check the buffer settings of all tables; compare usage of buffer vs.
invalidations.
ST04, DB02, SM50, SM51, ST02, ST06 are some the important tools which we normally use in R/3. These transaction codes should be extensively used here as well for gauging and optimizing the performance of the system.
Thank you for sharing knowledge and thanks for fantastic efforts
ReplyDeleteThank you for sharing nice information . I like to know more about what is new and i think that we must always learn from each other
ReplyDeleteJobs
ReplyDeleteI appreciate any good efforts and i always like to learn more and more ... thanks a lot for nice efforts
sai