During the recording phase, which may last for any length of time, it is important whilst you become accustomed to Testimony that you monitor the production systems that are being recorded.
Ad-hoc monitoring of the system whilst the recording is turned on.
Audience / Users
There are various standard SAP tools that can be used to monitor the SAP system for anomalies. Most of these transactions would be run directly in the system to be monitored. These include:
(1) Monitor Short-dumps (ST22) – Testimony has been designed to ensure that it has no impact on production. However, in the early days of use of Testimony, you might like to ensure that users and batch jobs are not being impacted by monitoring for any short-dumps. Run transaction ST22 in the systems being recorded and look for any short-dumps directly specifying that Testimony related objects are involved (i.e. /BTI/AUT* related objects). You might like to check this more regularly after recording is turned on (e.g. every 5 minutes), then reduce the frequency as the recording progresses (e.g. every 1 hour after the first hour of recording is complete).
(2) Monitor Long Running Processes (SM66) – We recommend the use of SM66 (rather than SM50) since it is across all application servers of the system you are monitoring. In this transaction you are looking for long running processes that would usually be fast. So batch jobs are .
(3) Monitoring Testimony jobs (/BTI/AUT) – As recordings are running in the source systems, the central system (Solution Manager) is also running a monitoring job to perform a number of activities on the systems being recorded. These can be monitored in the central system via transaction (/n/BTI/AUT). Then navigate to the “Recording” drawer and select “Job Manager”. You will see the different types of jobs that are run by Testimony in the list.
The main one to monitor is “Business transactions DB storage” which runs every 1 minute (this period is configurable). Double-click this entry and you will see the most recent job executions. You can change the time period to look at via the “Period” filter. The field to check is the “Dur.” (Duration) to ensure that these are not taking too long (they should not be more than 10 seconds and certainly should not be more than 1 minute).
(4) Monitor Shared Memory (ST02) – Testimony achieves what it does with near zero impact on production by using shared memory. Shared memory is allocated per application server on the system being recorded and is set via the profile parameter rsdb/esm/buffersize_kb. A check step prior to recording ensures that this value is set sufficiently and the value required is completely dependent upon the transaction volume of the system including the various types of interactions.
To monitor the shared memory levels, you run transaction ST02 upon each application server. This transaction only shows you the shared memory of the application server you are currently logged onto. In order to check other application servers, you should use transaction SM51 in order to jump between the application servers and then once switched, run transaction ST02.
You should be checking the row that says “Exp./ Imp. SHM”. The column “Alloc. KB” shows how much has been allocated for that particular application server. This should be reflected in the profile parameter setting in transaction RZ11. The current level of shared memory (the amount of free space) is then seen in the following column “Freesp. KB”. Other processes in SAP can use up the shared memory (not just Testimony), so this means you’ll see this value typically lower than what was allocated in the profile parameter.
The key task is to ensure that this value does not get close to zero (0KB). If it does, then it means Testimony will not be able to capture interactions and will thus lose this data from the recording and potentially render the recording invalid.
(5) System Messages (SM21) – You can check various system messages via transactions in SM21 whilst the recording is running. Short-dumps would be reflected in here. If there looks to be any anomalies that you do not expect, then investigate appropriately and if required, deactivate the recording.
If any significant impacts are detected (e.g. from a performance or impact perspective), you can deactivate the recording immediately.