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

 

1. Ping the server to see whether the  server is reachable.

1. Check the IP address of the SAPGUI icon .

3. See whether the proper SAP message server and gateway processes are running or not.
4. 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.