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 background processes that would usually be fast, this is to check for a batch job that has become long running.
(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 job that runs on the source system is /BTI/AUT_SAVE_BTRAN_PERIODIC every minute it saves data out of the shared memory and into the database and will run for the full length of the recording, the central system also checks this job is running to update the central system and ensure that the RFC connection to the source system is still operating.
(4) Monitor Shared Memory – Testimony achieves what it does with near zero impact on production by using shared memory to save the recording before the job above runs to move this to the database. Shared memory is allocated per application server on the system being recorded and is set via the profile parameter rsdb/esm/buffersize_kb as a part of the installation there will be recommendations on the amount of shared memory that will be required.
To monitor shared memory in Testimony the Shared Memory Explorer (more details in the link) should be used it enables a view of all the app servers on one system as well as the objects contained in each app servers shared memory, it details the memory availability and usage as well as the maximum objects available and their usage.
If the RFC user to the source system does not have the correct authorisations the Shared Memory Explorer view can be restricted in this case you can use the SAP standard transaction ST02 on the source system to monitor 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) or any shared memory limits set with the Shared Memory Limits option. If the shared memory limit is reached or no shared memory is left then Testimony will abort the recording.
(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.