There are a few critical tasks that should be completed every morning. These tasks answer the following questions:
• Is the R/3 System running?
• Did the backups execute and complete successfully?
If the answer to either question is “no,” then the situation must be resolved quickly because:
• If the R/3 System is down, no work can be done.
• If the backups failed, and a disaster occurs, you could lose all the data since your most recent good backup.
Verify that SAP is running
Your first task of the day is to perform a high-level check to see if the R/3 System is running.
Why?
If the system is not running, your users will be calling to find out what happened and when the system will be up again.
As a basic level check, if you can connect to the R/3 System, the following questions are answered:
• Is the R/3 System working?
• Is the network between you and the R/3 System working?
How?
From a workstation, log on with the SAP GUI. If you can log on, the test is successful.
Verify that the Backups Ran Successfully
What
You need to verify that the backups that were supposed to run last night ran successfully.
Backups of the SAP database and related non-database operating system level files are essential to recover the SAP System.
Types of non-database files include:
• Database log dumps
• Data files for third-party applications that do not store their data in the system
Examples of such files are external tax files.
• Transport files
• Inbound and outbound interface files
• Externally stored print files
Why
If there is a problem with any of the backups, the problem needs to be quickly resolved. If a database failure occurs that requires a restore, and the last backup failed, you will have to recover using the last successful backup. If you do not have a good (usable) backup, you will have to go to an older backup. This process requires applying more logs the further back you go and increases the time required to restore the database and bring it current.
Once the problem has been fixed, if it does not significantly impact performance, execute an online backup. Even if it impacts performance, your company may make it policy to run the online backup. This step gives you a more recent backup.
At the operating system level, some of these files may need to be in sync with the R/3 database. Restoring the R/3 System without these files results in an incomplete (unusable) restore (for example, external tax files that need to be in sync with the system data or the tax systems reports will not match the R/3 reports).
When
These critical tasks need to be done first thing in the morning. If there is a “graveyard” operations shift, the backup check should be done once the backup job is complete. The “graveyard” shift is the third shift of the day and is typically from 10:00 p.m. to 7:00 a.m.
Caution: Any failed backup must be immediately investigated and resolved. Do not maintain a “we will just run the backup again tonight and see if it works” attitude. If that backup fails, you have another day without a backup.
Users (Transaction AL08)
What
This transaction displays all the users who are currently logged on to the system. It shows both the user’s ID and terminal name.
Why
In a smaller company, the administrator can recognize user IDs logged on to unfamiliar terminals. This step may indicate that someone—other than the designated user—is using
that user ID. A user is logged on to more than one terminal may indicate that the user ID is
being used or shared by more than one person.
OS Monitor (Transaction OS06)
What
The system logs are where the operating system and some applications write event records.
Depending on the operating system, there may be multiple logs.
Why
There may be indications of a developing problem (for example, a hard drive generating errors or a failing drive that needs to be replaced).
Select Background Jobs/Graphical Job Monitor (Transaction SM37/RZ01)
What
Background jobs are batch jobs scheduled to run at specific times during the day.
Why
If you are running critical jobs, you need to know if the job failed, because there may be other processes, activities, or tasks that are dependent on these jobs.
CCMS Alert Monitor (Transaction RZ20)
What
Transaction RZ20 is a centralized alert monitor and is new with Release 4.0. With this transaction, you can monitor the servers in your landscape, such as development, QA, testing, production, etc. You no longer have to individually log into each system to search for alerts. If there is an alert, the monitor will link to many of the other transactions.
Why
An alert indicates a potentially serious problem that should be quickly resolved. If not contained, these problems could degenerate into a disaster.
Users (Transaction SM04)
What
This transaction displays all the users who are currently logged on to the system. It shows both the user’s ID and terminal name.
Why
In a smaller company, the administrator can recognize user IDs logged on to “unfamiliar” terminals, indicating that someone—other than the designated user—is using that user ID.
A user logged on to more than one terminal indicates that the user ID is being:
• Used by someone else
• Used or shared by several people
Lock Entry List (Transaction SM12)
What
A lock is a mechanism that prevents other users from changing the record on which you are working. An example that illustrates the importance of using this function follows.
EXAMPLE:
You are changing a customer mailing address. Someone else is changing the customer’s telephone number at the same time. You save your change first; then the other person saves their change. The other person’s change overwrites your change, and your change will be lost.
Why
There may be old locks still in place from transactions that did not release, or from when the user was cut off from the network. Unless cleared, these locks prevent access or change to the record until the system is cycled. The easiest way to locate them is to look for locks from prior days.
Caution: We presume that the profile parameter rdisp/gui_auto_logout has been set. This parameter defines an automatic logout of the user if there is no activity for the set number of minutes.
Update Records (Transaction SM13)
What
A failed update, or an “update terminate,” is an update to the failed database. These failed updates occur when a user entry or transaction is not entered or updated in the database.
The following analogy should help clarify this concept:
1. A secretary gives a file-clerk a folder (similar to a save).
2. The file-clerk gives the secretary a receipt (similar to the R/3 document number).
3. On the way to the file cabinet, the clerk falls, and gets hurt.
The folder in not put into the cabinet (this is the failed update).
4. The end result is the folder is not in the cabinet—even though the secretary has the receipt.
For performance reasons, the database update is done in asynchronous mode. In this mode, the user continues to work while the system takes over the update process and waits for the database update to complete. In synchronous mode, users would have to wait until the database successfully updated before they could continue to work.
Why
The users probably received a document number, so they assume that the entry is in the system; however, if a failed update occurred, the entry is not in the system. In a customer order, unless the order is reentered, the customers would not get their order and no trace of it would be found in the system!
System Log (Transaction Sm21)
What
The system log is the R/3 System’s log of events, errors, problems, and other system messages.
Why
The log is important because unexpected or unknown warnings and errors could indicate a serious problem.
Batch Input (Transaction SM35)
What
This transaction shows jobs that need to be processed or started, and jobs with errors that need to be resolved.
Why
This transaction is important because it alerts you to batch input jobs that are:
• New
These are jobs that are waiting to be processed (for example, a posting from an interface file). If not processed, the data will not post to the system.
• Incorrect
These are jobs that have failed due to an error. The danger is that only a portion of the job may have posted to the system. This increases the potential for data corruption of a different sort, as only part of the data is in the system.
Work Processes (Transaction SM50 and SM51)
What
These transactions allow users to view the status of work processes and monitor for problems. Transaction SM51 is a central transaction from which you can select the instance to monitor. SM51 starts transaction SM50 for each application server. Transaction SM50 is used for systems without application servers.
Why
Transaction SM51 is one place to look for jobs or programs that may be “hung,” (indicated by long run times). If batch jobs are not running, if all the batch work processes are in use, transaction SM50 may provide a hint of the problem.
Spool (Transaction SP01)
What
The spool is the R/3 System’s output manager. Data sent to the printer is sent to the R/3 spool and then sent to the operating system to print.
Why
There may be problems with the printer at the operating system level. These problems need to be resolved immediately for time-critical print jobs (for example, checks, invoices, shipping documents, etc.) or there may be an operational impact. Active spool jobs that have been running for over an hour could indicate a problem with the operating system spool or the printer.
Tune Summary (Transaction ST02)
What
The buffer tune summary transaction displays the R/3 buffer performance statistics. It is used to tune buffer parameters of R/3 and, to a lesser degree, the R/3 database and operating system.
Why
The buffer is important because significant buffer swapping reduces performance. Look under Swaps for red entries. Regularly check these entries to establish trends and get a feel of the buffer behavior.
Workload Analysis of
What
Workload analysis is used to determine system performance.
How
Check statistics and record trends to get a feel for the system’s behavior and performance.
Understanding the system when it is running well helps you determine what changes may need to be made when it is not.
Database Performance Analysis (Transaction ST04)
What
A high-level database performance monitor.
Why
This transaction provides the ability to:
• Monitor the database in relation to:
Growth
Capacity
I/O statistics
Alerts
• Drill down for additional information.
• Monitor the database without logging on to it.
ABAP Dump Analysis (Transaction ST22)
What
An ABAP dump (also known as a short dump) is generated when a report or transaction terminates as the result of a serious error. The system records the error in the system log (transaction SM21) and writes a snapshot (dump) of the program termination to a special table. This transaction can also be called from the system log (transaction SM21).
Why
You use an ABAP dump to analyze and determine why the error occurred, and take corrective action.
