P. 1
Daily Tasks

Daily Tasks

|Views: 62|Likes:
Published by dman_vzla

More info:

Published by: dman_vzla on May 06, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/17/2009

pdf

text

original

System Administration Made Easy 4–1

Chapter 4: 8cheduled Daily Tasks
Contents
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


Chapter 4: Scheduled Daily Tasks
Overview

Release 4.6A/B
4–2
Overview
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
Chapter 4: Scheduled Daily Tasks
Critical Tasks

System Administration Made Easy
4–3
Critical Tasks
System: __________
Date: ____/ ____/ ____
Admin: _____________________

Task Transaction Chapter Procedure Check off/Initial
Check that the R/ 3
System is up.
Log onto the R/ 3
System

Check that daily
backups executed
without errors.
DB12 – Backup
Logs: Overview
13 Check database
backup.
Database backup
run time.

Check operating
system level
backup

Operating system
backup run time.




Chapter 4: Scheduled Daily Tasks
The R/3 System

Release 4.6A/B
4–4
The R/3 8ystem

Task Transaction Chapter Procedure Check off/Initial
Check that all application servers
are up.
SM51 – SAP
Servers
16 & 10 Check that all servers
are up.

Check the CCMS alert monitor
(4.0+).
RZ20 –
CCMS
Monitor (4.0)
10
Look for alerts.
Check work processes (started
from SM51).
SM50 –
Process
Overview
16 & 10 All work processes
with a “running” or a
“waiting” status

Look for any failed updates
(update terminates).
SM13 –
Update
Records
10
< Set date to one year
ago
< 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 jobs. SM37 –
Select
Background
jobs
16 Enter an asterisk (*) in
User ID.
Verify that all critical
jobs were successful.

Check for “old” locks. SM12 – Lock
entry list.
10 Enter an asterisk (*) for
the user ID.

Chapter 4: Scheduled Daily Tasks
The R/3 System

System Administration Made Easy
4–5

Task Transaction Chapter Procedure Check off/Initial
Check for entries for
prior days.

Check for users on the system. SMO4 –
Users
AL08 - Users
10 Review for an
unknown or different
user ID and terminal.
This task should be
done several times a
day.

Check for spool problems. SP01 – Spool:
Request
Screen
14 Look for spool jobs that
have been “in process”
for over an hour.

Check job log. SM35 – Batch
input: Initial
Screen
16 Check for:
< New jobs
< Incorrect jobs

Check work processes. SM50/SM51 -
Processes
16 & 10

Review and resolve dumps. ST22 – ABAP
Dump
Analysis
10 Look for an excessive
number of dumps.
Look for dumps of an
unusual nature.

Review workload statistics. STO3 –
Workload:
Analysis of
<SID>
19

Review buffer statistics. ST02 – Tune
Summary
19 Look for swaps.


Chapter 4: Scheduled Daily Tasks
Database

Release 4.6A/B
4–6
Database

Task Where Chapter Procedure Check off/Initial
Review error log for problems. AL02 –
Database (DB)
alert

ST04 – DB
Performance
Analysis
13


Operating 8ystem

Task Transaction Chapter Procedure Check off/Initial
Review system logs for
problems.
AL16 – OS
Alerts
15
OS06 – OS
Monitor
15
Review operating
system log

Review NT system logs for
problems.
NT system log 15
Look for any errors or
failures.

NT system log 15
Check for failed logon
attempts to the SAP
servers.

NT application
log
15
Look for errors or
failures.


Chapter 4: Scheduled Daily Tasks
Other

System Administration Made Easy
4–7
Other

Task Where Chapter Procedure Check off/Initial
Check the uninterruptible power
supply (UPS).
UPS
program log
15 Review for:
< Events
< UPS self test
< Errors



Notes

Problems Action Resolution




Chapter 4: Scheduled Daily Tasks
The R/3 System

Release 4.6A/B
4–8
System: __________
Date: ____/ ____/ ____
Admin: _____________________
The R/3 8ystem
These tasks are done several times a day.

Task Transaction Chapter Procedure Check
off/Initial
Look for any failed updates
(update terminates).
SM13 – Update
Records
10 < Set date to one year ago
< 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
critical jobs
SM37 – Select
Background jobs
16 Enter * in User ID
Verify that all critical jobs were
successful.


Review any cancelled jobs.

RZ01 – Graphical
job monitor
16 Same as for SM37.

Check users on system
SM04 – Users
AL08 – Users
10 Review for an unknown or
different user ID and terminal.
This task should be done several
times a day.


Chapter 4: Scheduled Daily Tasks
Critical Tasks

System Administration Made Easy
4–9
Critical Tasks
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 R/3 ¡s 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 8uccessfully
What
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
Chapter 4: Scheduled Daily Tasks
Critical Tasks

Release 4.6A/B
4–10
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.


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.
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.
Chapter 4: Scheduled Daily Tasks
Critical Tasks

System Administration Made Easy
4–11
O8 Monitor {Transaction O806}
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).
8elect Background Jobs/Graphical Job Monitor {Transaction
8M37/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.
CCM8 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 later in
this chapter.
Why
An alert indicates a potentially serious problem that should be quickly resolved. If not
contained, these problems could degenerate into a disaster.
Users {Transactions 8M04}
What
These transactions display all the users who are currently logged on to the system and show
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.
Chapter 4: Scheduled Daily Tasks
Critical Tasks

Release 4.6A/B
4–12
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 8M12}
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.



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 8M13}
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
Chapter 4: Scheduled Daily Tasks
Critical Tasks

System Administration Made Easy
4–13
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!
8ystem Log {Transaction 8M21}
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 ¡nput {Transaction 8M35}
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.
Chapter 4: Scheduled Daily Tasks
Critical Tasks

Release 4.6A/B
4–14
Work Processes {Transactions 8M50 and 8M51}
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.

8pool {Transaction 8P01}
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 8ummary {Transaction 8T02}
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 <8¡D> {Transaction 8T03}
What
Workload analysis is used to determine system performance.
Chapter 4: Scheduled Daily Tasks
Critical Tasks

System Administration Made Easy
4–15
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 8T04}
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 8T22}
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.
Chapter 4: Scheduled Daily Tasks
Critical Tasks

Release 4.6A/B
4–16

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->