Upgrade Superuser Privilege Management or Firefighter to latest support package.
Creating an Index on CDHDR:
1. Even though an ABAPer can create the database index on table CDHDR using transaction SE11, it is advisable for a BASIS / DBA to be involved in the creation of the index because they know the system landscape well and would be in a much better position to make the call.
2.If the number of rows in table CDHDR is near one million, creation of an index should not be a major task. In any case, this index creation should be done preferably over the weekend when the system load is minimal. If the number is substantially higher than a million, then it is better to observe overall system performance for a week or so after creation of the index. If no adverse effects are noticed, then it is fine. If not, the index may have to be dropped.
3. Initially, the index can be created on fields MANDANT, USERNAME, UDATE, and UTIME. The index fields should be in the sequence in which the fields appear in the table and are queried.
4. After creation of the index, configuration parameter (Change Retrieve Log) can be set to YES and a few activities performed under a firefighter id such as changing a material master (MM02).
5.Switch on SQL Trace using transaction ST05.
6. Execute report /VIRSA/ZVFATBAK using
transaction SE38. (NOTE: Report should run quicker if the index gets used). The /VIRSA/ZVFATBAK program has been modified to read back to the last time the Firefighter user logged in and retrieves all data. Example: If FFID2 logs in at 8:00 AM, logs off, and then logs on again at 1:00 PM, the program automatically reads data prior to 1:00 PM back to the last 8:00 AM login for the FFID2 user.
7. Switch off the SQL trace created in step 5 using transaction ST05 and analyze the results for table CDHDR to check if the newly created index is being used. If it is not, then the index may have to be adjusted by removing field MANDANT (USERNAME field is important). A BASIS/ DBA person(s) would be able to get the optimum results with a few iterations.
Job Scheduling Options:
We recommend you schedule the background job to update the log every hour, which will read the previous hour and two minutes.
IMPORTANT NOTE: At times you may notice when the Superuser/Firefighter logs in or out around the time when the /VIRSA/ZVFATBAK job is running, the log report may reflect "BACKGROUND JOB NOT SCHEDULED/FILE NOT YET GENERATED...". As a precautionary measure to ensure that all data is captured in the case of system or job scheduling issues, is to create a job that runs every four hours (with a read time of four (4) hours) or at the end of the day (with a read time of twelve (12) hours) in addition to having the regular hourly job scheduled.
*** There can be a degradation in performance if the hourly job and 4 hour job run simultaneously.
If the job is scheduled to run at 12:00 PM, it will update the log for any activity that was executed from 11:00-12:00 PM.
When you schedule the job, the time parameters should be as follows: Start Time: 00:00:00 Read Time: 01:00:00 (Read time means that what is defined here, the report will be run to extract activity from the selected number of hours) This job should be set to run periodically, every hour. If it is being scheduled hourly verify that the job finishes before the next begins.
Note: Superuser Privilege Management pulls transactional data from STAT files so check to see how often the STAT collector job is running and verify that it finishes. The Superuser job should run after that has completed.
Instructions for creating job variant:
If, for example, you have 100 FF IDS and 77 application servers. RFC call returns should take approximately 30 seconds for each user. Variant will run faster if you check for specific user IDs. If all the FF IDs start with FF create a variant for FF* when scheduling the job. The job will run more quickly.