Professional Documents
Culture Documents
Daily Tasks
Daily Tasks
&RQWHQWV
Overview ..................................................................................................................4–2
Critical Tasks...........................................................................................................4–3
The R/3 System .......................................................................................................4–4
Database ..................................................................................................................4–6
Operating System ...................................................................................................4–6
Other.........................................................................................................................4–7
Notes ........................................................................................................................4–7
The R/3 System .......................................................................................................4–8
Critical Tasks...........................................................................................................4–9
2YHUYLHZ
We have provided sample checklists that you may use and modify depending upon your
specific needs. The checklists provided for your convenience include:
< Critical tasks
< R/3 System
< Database
< Operating system
< Other
< Notes
Release 4.6A/B
4–2
Chapter 4: Scheduled Daily Tasks
Critical Tasks
&ULWLFDO7DVNV
System: __________
Date: ____/____/____
Admin: _____________________
7KH56\VWHP
Check that all application servers SM51 – SAP 16 & 10 Check that all servers
are up. Servers are up.
Check the CCMS alert monitor RZ20 – 10 Look for alerts.
(4.0+). CCMS
Monitor (4.0)
Check work processes (started SM50 – 16 & 10 All work processes
from SM51). Process with a “running” or a
Overview “waiting” status
Look for any failed updates SM13 – 10 < Set date to one year
(update terminates). Update ago
Records < Enter * in the user
ID
< Set to “all” updates
Check for lines with
“Err.”
Check system log. SM21 – 10 Set date and time to
System Log before the last log
review.
Check for:
< Errors
< Warnings
< Security messages
< Abends
< Database problems
< Any other different
event
Review for cancelled jobs. SM37 – 16 Enter an asterisk (*) in
Select User ID.
Background
Verify that all critical
jobs
jobs were successful.
Check for “old” locks. SM12 – Lock 10 Enter an asterisk (*) for
entry list. the user ID.
Release 4.6A/B
4–4
Chapter 4: Scheduled Daily Tasks
The R/3 System
'DWDEDVH
2SHUDWLQJ6\VWHP
Release 4.6A/B
4–6
Chapter 4: Scheduled Daily Tasks
Other
2WKHU
1RWHV
System: __________
Date: ____/____/____
Admin: _____________________
7KH56\VWHP
Look for any failed updates SM13 – Update 10 < Set date to one year ago
(update terminates). Records < Enter * in the user ID
< Set to “all” updates
Check for lines with “Err.”
Check System Log SM21- System Log 10 Set date and time to before the
last log review.
Check for:
< Errors
< Warnings
< Security messages
< Abends
< Database problems
Any other different event
Review for cancelled and SM37 – Select 16 Enter * in User ID
critical jobs Background jobs
Verify that all critical jobs were
successful.
Release 4.6A/B
4–8
Chapter 4: Scheduled Daily Tasks
Critical Tasks
&ULWLFDO7DVNV
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.
9HULI\WKDW5,V5XQQLQJ
Your first task of the day is to perform a high-level check to see if the R/3 System is
running.
:K\
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?
+RZ
From a workstation, log on with the SAP GUI. If you can log on, the test is successful.
9HULI\WKDWWKH%DFNXSV5DQ6XFFHVVIXOO\
:KDW
You need to verify that the backups that were supposed to run last night, ran successfully.
Backups of the R/3 database and related nondatabase operating system level files are
essential to recover the R/3 System.
Types of nondatabase 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
:K\
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).
:KHQ
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.
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.
In chapters 4–8, we have included a list of transactions like the one below. This list contains
basic information about the transactions in the checklist. For additional information on these
transactions, see the chapter referenced in each checklist.
8VHUV7UDQVDFWLRQ$/
:KDW
This transaction displays all the users who are currently logged on to the system. It shows
both the user’s ID and terminal name.
:K\
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.
Release 4.6A/B
4–10
Chapter 4: Scheduled Daily Tasks
Critical Tasks
260RQLWRU7UDQVDFWLRQ26
:KDW
The system logs are where the operating system and some applications write event records.
Depending on the operating system, there may be multiple logs.
:K\
There may be indications of a developing problem (for example, a hard drive generating
errors or a failing drive that needs to be replaced).
6HOHFW%DFNJURXQG-REV*UDSKLFDO-RE0RQLWRU7UDQVDFWLRQ
605=
:KDW
Background jobs are batch jobs scheduled to run at specific times during the day.
:K\
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.
&&06$OHUW0RQLWRU7UDQVDFWLRQ5=
:KDW
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 later in
this chapter.
:K\
An alert indicates a potentially serious problem that should be quickly resolved. If not
contained, these problems could degenerate into a disaster.
8VHUV7UDQVDFWLRQV60
:KDW
These transactions display all the users who are currently logged on to the system and show
the user’s ID and terminal name.
:K\
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
/RFN(QWU\/LVW7UDQVDFWLRQ60
:KDW
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.
([DPSOH
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.
:K\
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.
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.
8SGDWH5HFRUGV7UDQVDFWLRQ60
:KDW
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
Release 4.6A/B
4–12
Chapter 4: Scheduled Daily Tasks
Critical Tasks
database update to complete. In synchronous mode, users would have to wait until the
database successfully updated before they could continue to work.
:K\
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!
6\VWHP/RJ7UDQVDFWLRQ60
:KDW
The system log is the R/3 System’s log of events, errors, problems, and other system
messages.
:K\
The log is important because unexpected or unknown warnings and errors could
indicate a serious problem.
%DWFK,QSXW7UDQVDFWLRQ60
:KDW
This transaction shows jobs that need to be processed or started, and jobs with errors that
need to be resolved.
:K\
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.
:RUN3URFHVVHV7UDQVDFWLRQV60DQG60
:KDW
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.
:K\
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.
6SRRO7UDQVDFWLRQ63
:KDW
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.
:K\
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.
7XQH6XPPDU\7UDQVDFWLRQ67
:KDW
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.
:K\
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.
:RUNORDG$QDO\VLVRI6,'!7UDQVDFWLRQ67
:KDW
Release 4.6A/B
4–14
Chapter 4: Scheduled Daily Tasks
Critical Tasks
+RZ
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.
'DWDEDVH3HUIRUPDQFH$QDO\VLV7UDQVDFWLRQ67
:KDW
:K\
$%$3'XPS$QDO\VLV7UDQVDFWLRQ67
:KDW
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).
:K\
You use an ABAP dump to analyze and determine why the error occurred, and take
corrective action.
Release 4.6A/B
4–16