R/3 System
- SM21 System Log
All warnings and error messages should be analyzed and corrected. This procedure should include documenting all problems and their resolution.
- AL01 SAP Alert Monitor
All Alerts should be acknowledged, analyzed, corrected, and documented.
- RZ02 System Monitor
Administrators should monitor the system monitor first thing each morning. This procedure should confirm all systems are running and using the proper Operation Mode.
- SM37 Job Log Overview
Administrators should examine all canceled jobs. These jobs should be analyzed and repaired if necessary. Problems and resolution should be documented.
Administrators should check all logs, including list output and application logs for all critical jobs.
Administrators must release all jobs scheduled by users with no rights to release.
- RZ01 Graphical Job Monitor
Administrators should monitor run-time statistics for each job. This information should be used to fine-tune background job schedules and can provide administrators with some advance warning if jobs begin to perform badly.
- SM13 Update Records
This transaction displays aborted updates; it should never occur in a production system. These updates should be reported to and corrected by the developers as soon as possible.
- SM66/SM50 Process Overview
Administrators should check the system processes throughout the day. Long-running background jobs, and runaway or poorly written reports can consume enormous system resources if not controlled. Administrators can use this transaction to spot-check their environments. It is appropriate to investigate these activities with the end users before killing these processes. All unexplained process failures should be investigated as well.
- SP01 Spool Request Overview
Failed print jobs can be restarted. Often these jobs fail because of problems on the client end (for example, PC running SAPLPD is shut off). Because R/3 tracks print jobs only to the target queue, actual successful print jobs are not guaranteed by a complete status in the output controller. Critical and mass print jobs should be confirmed by the end users before they are deleted from the TemSe.
- SE01 Transport Logs
All warnings and error messages should be analyzed and corrected. This procedure should include documenting all problems and resolutions.
- ST03 Workload Analysis
When it comes to tuning an R/3 system, there is no replacement for experience. Administrators should stay on top of the workload analysis numbers in their system, especially when you have no performance problems. Having a clear picture of how your system performs when working well, provides a “feel” for the system. This “feel” enables you to see problems coming and, in many cases, prevent them.
- ST02 Buffer Analysis
Buffers should be monitored on a regular basis. Hit ratios, free space, free dir entries, and swaps should be monitored. This process helps the administrator in the ongoing tuning process.
- SM35 Batch Input Logs
Batch Input logs should be checked after each run. The batch input process flags errors and allows you to reprocess after repairing .
- SM12 Lock Entries
From time to time, a user may lock an object and for some reason (such as a lost connection or program error) the lock remains. All old lock entries should be analyzed and corrected.
- SP12 TemSe Administration
Administrators should check the file system and database storage requirements, especially when printing mass quantities of data. A TemSe consistency check (RSPO0043) should be scheduled to run daily, just prior to the spool reorganization (RSPO0041).
- TU02 Profile Parameter Changes
The R/3 System monitors all system profiles for changes. Although not perhaps a daily activity, administrators should confirm that profiles are adjusted only by authorized users and whenever possible with the R/3 profile maintenance tool.
Database
- DB12 SAPDBA Logs
- Verify success of nightly backup.
- Verify free space in log directory
- DB02 Storage Management
- Monitor database growth.
- Monitor table and index growth and fragmentation.
- Monitor optimizer statistics if necessary for your database.
- Monitor the database error log daily.
- Monitor total logical and physical reads per day to keep track of the development of database workload through time.
- If they are supported by your database, pay particular attention to the most expensive SQL statements.
- ST04 Database Logs
- AL02 Database Alert Monitor
All alerts should be acknowledged, analyzed, corrected and documented.
- DB03 Parameter Changes
The R/3 System monitors all database profiles for changes. Administrators should regularly confirm that profiles are adjusted only by authorized users.
Host Operating System
- OS06 OS Monitor
All alerts should be acknowledged, analyzed, corrected, and documented.
- AL16 OS Alert Monitor
All alerts should be acknowledged, analyzed, corrected, and documented.
- OS03 Parameter Changes
The R/3 System monitors all operating system kernel changes. Administrators should regularly confirm that kernel parameters are adjusted only by authorized users.
Network
- ST09/ST08 Network Alert Monitor
All alerts should be acknowledged, analyzed, corrected and documented.
Clients
- SM04 User Overview
Administrators should consider doing spot checks throughout the day to monitor users and their activities. Are all users using the logon groups? Are users logging on using several machines? Are there any unrecognizable user IDs? Are users trying or using transactions they shouldn’t? Are there any phantom users (users who have lost their connections)?
Reorganization Reports
The following information was taken from OSS note 16083.
Various programs, unrelated to any application, need to be run in most R/3 installations. These reports are responsible for reorganizing or keeping up records no longer needed in the system. If this upkeep process is not maintained, a significant amount of disk space may be used wastefully.
These programs typically are run from within the background processing system at periodic intervals. A description of each program describing its function and recommended periodic runtime interval is given below. Most programs require a variant (set of parameters) when running in the background processing system. These variants can be produced from within the ABAP development environment, by choosing Tools Case:Development Program Maintenance ABAP Development.
As an added note, correspondence may be noticed between various operating system files and those that require cleaning up from within the R/3 System. These operating system files are located in the /usr/SAP/<sap_system_name>/SYS/global directory, where <sap_system_name> = C21, or PC1 or PC2. It is strongly recommended that these operation system files never be deleted from the operating system level, the removal of which could result in a data inconsistency within the R/3 System.
Note: Application-specific reorganization programs are not included in this list.
RSBTCDEL
This program cleans up the background jobs. Typically, this program is used to remove all background job records from the queue that have run successfully and are at least X days old. Various constraints can be defined, in addition to those already mentioned, from within the ABAP programming environment. From within this environment, a full list of input parameters can be seen.
Recommended frequency: During off-peak load hours, every day
Notes: This job should run under the batch administrator privilege to make sure all jobs are deleted, regardless of the client. To delete jobs within a single client, make sure the user does not have the batch administrator privilege.
RSPO0041
This program is responsible for removing spooling objects. Every print request produces a spool object and is archived in case of system failure. These spool objects, printed or not, can then be removed depending upon the input criteria.
Recommended frequency: At least once daily, depending on system load and the number of spool object printouts
RSBDCREO
This program is responsible for cleaning up the batch input session log. If the batch input function of the R/3 System is used, log entries are produced. This program requires a variant.
Recommended frequency: If used, once daily
RSSNAPDL
This program cleans the ABAP runtime error dumps logged from within the system. To make the scheduling of this job easy, a second report called RSNAPJOB exists. The function of this job is to automatically schedule RSSNAPDL to run. The report RSNAPJOB makes two assumptions. The first is that there is already a variant existing called DEFAULT. If this variant does not exist, it must be created. The second assumption is that the repetition period is daily. The initial start time is 1:00 a.m.
Recommended frequency: Daily
RSBPCOLL
This program calculates the job runtime statistics information. A variant is not needed to run this program. The program takes only the periodic jobs that have terminated normally and calculates an average runtime statistic for each job. This data is stored in the transparent database table btcjstat. This table needs periodic reorganization to get rid of any old runtime statistics.
Recommended frequency: Should be run daily depending upon system load
RSBPSTDE
This program cleans the job runtime statistics information. A variant is needed to run this program. This job deletes the statistics that have not been updated since the specified date or number of days.
Recommended frequency: Should be run once a month
RSCOLL00
This program collects performance data across all applicable R/3 servers. No variant is needed.
Recommended frequency: Once an hour
RSM13002
This program cleans the process update requests. No variant is required.
Recommended frequency: Daily
Note: RSM13002 is necessary only if automatic deletion of the process update requests is turned off. By default, this is turned on.
Please adhere to the recommended job names, as listed in the table below, because the naming conventions enable qualified R/3 Basis support to quickly check whether these jobs have been activated in your system.
Summary
Job Name |
Program |
Variant |
Frequency |
SAP_REORG_JOBS |
RSBTCDEL |
YES |
DAILY |
SAP_REORG_SPOOL |
RSPO0041 |
YES |
DAILY |
SAP_REORG_BATCHINPUT |
RSBDCREO |
YES |
DAILY |
SAP_REORG_ABAPDUMPS |
RSSNAPDL |
YES |
DAILY |
SAP_REORG_JOBSTATISTIC |
RSBPSTDE |
YES |
MONTHLY |
SAP_REORG_UPDATERECORDS |
RSM13002 |
NO |
DAILY |
SAP_COLLECTOR_FOR_JOBSTATISTIC |
RSBPCOLL |
NO |
DAILY |
SAP_COLLECTOR_FOR_PERFMONITOR |
RSCOLL00 |
NO |
HOURLY |
Note: SAP_COLLECTOR_FOR_PERFMONITOR was previously called COLLECTOR_FOR_PERFORMANCE_MONITOR.
Note: Batch input reorganization may not run at the same time as normal batch input activity. The associated job must be scheduled for a time at which no other batch input activity is scheduled.
Note: Job SAP_REORG_UPDATERECORDS is only required when automatic delete of update records after their processing has been deactivated. This is not normally the case, however, because automatic deleting is the default setting. This function is controlled by the profile parameter delete_after_execution.
Note: To eliminate ABAP dumps created by runtime errors within ABAP programs, use RSSNAPDL. To simplify job planning, utilize an additional existing program: RSNAPJOB. This program schedules RSSNAPDL within a job. Implicit assumptions:
- Job name: RSSNAPDL
- Variant: DEFAULT (must therefore exist)
- Start time: early, 1:00 a.m.
- Repeat interval: daily
Added Notes Concerning Individual Clients and Authorizations
Some of the jobs specified work with client-specific objects (for example, jobs). Whether reorganization then has any cross-client influence normally depends on particular authorizations. The following table gives an overview.
Job Name |
Client-specific |
SAP_REORG_JOBS |
Yes |
SAP_REORG_SPOOL |
Yes |
SAP_REORG_BATCHINPUT |
Yes |
SAP_REORG_ABAPDUMPS |
No |
SAP_REORG_JOBSTATISTIC |
No |
SAP_REORG_UPDATERECORDS |
No |
SAP_COLLECTOR_FOR_JOBSTATISTIC |
No |
SAP_COLLECTOR_FOR_PERFMONITOR |
No |
Note: Jobs that are not client-specific perform a reorganization in all clients affected. They require neither special authorizations nor a special user name.
Note: Job SAP_COLLECTOR_FOR_PERFMONITOR is always scheduled in client 000 with user DDIC.
For client-specific jobs, note the following correlations:
- SAP_REORG_JOBS: Authorization S_BTCH_ADM = ‘N’
Authorization S_BTCH_JOB-JOBGROUP = ‘* - S_BTCH_JOB-JOBACTION = ‘DELE’
(Reorganization only in the client in which the actual job is running)
Authorization S_BTCH_ADM = ‘Y’
(Reorganization in all clients)
- SAP_REORG_SPOOL: Authorization S_ADMI_FCD-S_ADMI_FCD = ‘SPAD’
Reorganization runs in chosen client
(Client = ‘*’ then in all clients)
Authorization S_ADMI_FCD-S_ADMI_FCD = ‘SPAR’
(Reorganization only in the client in which the actual job is running)
- SAP_REORG_BATCHINPUT: Authorization profile S_BDC_ALL
(Reorganization only in the client in which the job is running)
Additional Comments
The authorizations always relate to the user under whose ID the job is being processed.
If this user has the necessary authorizations to work independent of the client, then it does not matter in which client the actual job is running.
Examples
User ADMIN has the authorization S_BTCH_ADM = ‘Y’. If job SAP_REORG_JOBS is now scheduled with user ADMIN, the jobs are reorganized in all clients.
User REORG has the authorization profile S_BDC_ALL. If job SAP_REORG_BATCHINPUT is now scheduled with user REORG in client 002, the batch input objects are reorganized in client 002.
If job SAP_REORG_ABAPDUMPS is scheduled in any client, all ABAP short dumps are reorganized in all clients.
User SPOOLADM has the authorization S_ADMI_FCD-S_ADMI_FCD = ‘SPAD’. If job SAP_REORG_SPOOL is now scheduled with user SPOOLADM and client 123 program parameters are specified, then the spool objects in client 123 are reorganized irrespective of the client in which the actual job is running. With client value ‘*’, all clients are reorganized.
References to related OSS notes
0005855 Job logs occupy a lot of storage space
0006604 Deleting job logs at operating system level
0007224 Deleting old corrections and transport requests
0009419 System shutdown at 31000 spool requests
0011070 Space requirements of TemSe and spooler
0016513 File system is full – what do I do?
0018307 Batch input logs and reorganization
0019706 Tuning the Spooler
0031927 file l_outfilename – L_RETURNCODE 8
0041547 How does report RSPO0041 work?
0048400 Reorganization of TemSe and Spool
SAP Database Administration
The SAP database administration involves the administration activities of the SAP database primarily through SAPDBA SAP’s proprietory database administration tool and very rarely through native database tools. Since the SAP Servers at Subros Ltd are all on Oracle database so the activities would describe all Oracle related administration issues .
Tool: SAPDBA
Activity |
Frequency |
Objective of the activity |
Using SAPDBA to execute the report tablespace administration à Free space
And fragmentation
|
Once daily | To proactively monitor for any future freespace problem in any tablespace, and minimise fragmentation |
Using SAPDBA to check system integrity selecting db check verificationà
DB system check or à DB verification using DB verify |
Once weekly | To check databse structure and verify that there is no oracle
Block corruption. Also it confirms that the all the datafiles And control files and log files is safe and in proper place. |
Using SAPDBA to check statistics by selecting Additional functionsàdb optimizer control panelà
Show all statistics information or check for new statistics or Create missing statistics for tables and indexes |
Twice weekly | To enhance the database performance |
Using SAPDBA to add a datafile to a tablespace by selecting Tablespace administrations à Alter tablespaces and add datafile | As and when required | To add freespace (max 2GB) to a tablespace facing freespace problem |
Using SAPDBA to
Check extent wise fragmentation By selecting Reorganization à check extents and fragmentation |
At least twice a
Week |
To get a picture of the free space and fragmentation table and extent wise |
Apart from the SAPDBA menu sapdba should be run from the OS prompt with the following switches . For details refer “Starting SAPDBA : SAP Help : BC SAP Database Administration : Oracle”.
sapdba –analyze
- -check : Generates a log with
- Storage statistics for all tablespaces
- A log of the database structure
- Information on the file systems used by the database
The information in this log gives a very good overview of your database system. You can influence the statistics output Critical number of new extents to be checked: <n> (<n>: number of extents) by defining a number of extents when you start the check run ( sapdba -e <number of extents> -check ), so that the check is against a value which corresponds to your requirements and not against the proposed value 2. You should start the check function weekly, if possible as a background process
sapdba –analyze
- -analyze <tablespace(s)|table(s)|<file>|<key_word> : Determines the storage situation in the specified table or tablespaces, and the 20 tables and/or 20 indexes of each tablespace specified that have the most freespace. The ORACLE command on which it is based (ANALYZE <object> COMPUTE/ESTIMATE STATISTICS) is also used during reorganization ( Reduce object size) and when creating current statistics for the DB Cost-based Optimizer (CBO).
sapdba –next
- -next <tablespace/s> : Alters the NEXT parameters when necessary.
sapdba –startup
- -startup : Normal startup of database.
sapdba –shutdown
- -shutdown : Shutting down the database.
Please note that since the production server is ruunning in an archive log mode so the filesystem /oracle/<SAPSID>/saparch should be monitored Constantly and accordingly brbackup and brarchive should be scheduled.
Other Network ,OS and SAP tool related issues
Though Network , OS and SAP tool related administration issues can be monitored from the R3 frontend itself but intervention is needed at the OS level from time to time . Some tools that are mentioned here are tp, R3trans , R3chop.
SAP Tools
Activity |
Frequency |
Objective of the activity |
tp addtobuffer <change request > <SID> | As and when required | To add a change request to buffer for importing into the database |
tp showbuffer <SID> | As and when required | To display the contents of the buffer and status of the change requests imported into the buffer |
tp delfrombuffer <change request> <SID> | As and when required | To delete the change request from the buffer |
tp import <change request> <SID> <clientXXX> | As and when required | To import the contents of the change request into the database |
R3trans –w logfile.txt –u inputfile.ctrl | As and when required | To delete a client; the inputfile.ctrl contains the commands for client deletion; logfile.txt is used for recording the logs of the action |
R3chop -ecs or ics from pipe
Or to pipe |
As and when required | While exporting or importing a large client beyond 2GB |
Os related commands for administration
Process Status : ps –aef
File System Status : df –k
Vertual Memory : vmstat
Swap Space : swap –s
Note : Check for existence of any core file in the /usr/sap/<SID>/DVEBMGS00/work and remove them immediately.
Network Related Issues
In case there is a connectivity issue then the following should be done
- Ping the server to see whether the server is reachable.
- Check the IP address of the SAPGUI icon .
- See whether the proper SAP message server and gateway processes are running or not.
- If all the above steps are OK then check whether the hub is reachableand proper route add entries are there in the route table. Possibly one can check that by netstat –nr or contact Network support group of your organization.
I was examining some of your posts on this site and I conceive this site is very instructive! Continue posting .