&KDSWHU 56\VWHP$GPLQLVWUDWLRQ

%DVLFV

&RQWHQWV
Overview ..................................................................................................................12
Roles of an R/3 System Administrator .................................................................12
Traits of an R/3 System Administrator .................................................................14
R/3 System Guidelines ...........................................................................................14
Corollaries to Murphys Law................................................................................113
Special Definitions ................................................................................................114

System Administration Made Easy

11

Chapter 1: R/3 System Administration Basics

Overview

2YHUYLHZ
This chapter is about the roles that a system administrator plays. These roles cross all
functional areas, and the number and intensity of the tasks depends on the size of the
company. In a small company, one person can be the entire system administration
department. In a larger company, however, this person is probably part of a team. The
purpose of this definition is to help clarify the roles of a system administrator. This
chapter is a list of commonly used system administration terms and their definitions.
At the end of this chapter is a list of 14 R/3 System guidelines, which a system administrator
must be aware of while working with the system.
Sample guidelines include:
<

Keep it short and simple (KISS)

<

Use checklists

<

Do not allow direct database access

5ROHVRIDQ56\VWHP$GPLQLVWUDWRU
Depending on the size of the company and available resources, R/3 administrator(s) may
range from one person to several specialized people in several departments.
Factors that affect an R/3 system administrators tasks, staffing, and roles:
<

Company size

<

Available resources (the size of the Basis group)

<

Availability of infrastructure support for:

Desktop support
Database
Network
Facilities

The R/3 system administrator may wear many hats both in or directly related to, R/3 and
indirectly or external to R/3.

:LWKLQ5
<

User administrator
Set up and maintain user accounts

<

12

Security administrator
Create and maintain SAP security profiles
Monitor and manage security access and violations

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

Roles of an R/3 System Administrator

<

System administrator
Maintain the systems health
Monitor system performance and logs

<

Transport administrator
Transport changes between systems
Manage change requests

<

Batch scheduler
Create and manage the scheduling of batch jobs

<

Backup operator
Schedule, run, and monitor backup jobs of the SAP database and any required operating
system level files

<

Disaster recovery technical manager

Create, test, and execute the SAP disaster recovery plan

<

Programmer
Apply SAPNet R/3 note fixes to programs

<

Data Dictionary (DDIC) manager

Change the Data Dictionary (when applicable)

<

Data Base Administrator (DBA)

([WHUQDOWR5
<

<

<

<

DBA for the specific database on which the system is running

Manage database specific tasks
Maintain the databases health and integrity
Operating system administrator
Manage the operating system access and user IDs
Manage operating system specific tasks
Network administrator
Manage network access and user IDs
Manage network support and maintenance
Server administrator
Manage the servers

<

Desktop support
Supports the users desktop PC

<

Printers

<

Facilities
Manages facilities-related support issues, such as:
Power/utilities
Air conditioning (cooling)

System Administration Made Easy

13

Chapter 1: R/3 System Administration Basics

Traits of an R/3 System Administrator

Physical server access

7UDLWVRIDQ56\VWHP$GPLQLVWUDWRU
An R/3 system administrator should:
<

Have a proper attitude

Protect and safeguard the system.
The system administrator is the guardian of the system.
Know when to call for help
The ability to know when you need to get help is a strength.
The weakness is not knowing when to get help and getting into trouble.
Be willing to work the hours required to support the system
Certain tasks must be done after hours or on weekends to avoid disrupting normal
business operations.

<

Be technically competent
When necessary, the company must invest in training for the Basis staff.
You must also take responsibility for your own training and education, whether
your company pays for it or not.

<

Be a team-player
The system administrator will have to work with various functional groups, users, the IS
staff, and others to successfully complete the necessary tasks.

56\VWHP*XLGHOLQHV
When working on an R/3 System:

14

<

Protect the system

<

Do not be afraid to ask for help

<

Network with other customers and consultants

<

Keep it short and simple (KISS)

<
<

Keep proper documentation

Use checklists

<

Use the appropriate tool for the job

<

Perform preventive maintenance

<

Do not change what you do not have to

<

Do not make changes to the system during critical periods

<

Do not allow direct database access

<

Keep all non-SAP activity off the SAP servers

<

Minimize single points of failure

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

3URWHFWWKH6\VWHP
:KDW

Everything you do as a system administrator should be focused on protecting and

maintaining the systems integrity.
:K\

<

If the systems integrity is compromised, incorrect decisions could be made based on

invalid data.

<

If the system cannot be recovered after a disaster, your company could be out of
business.

+RZ

<

The system administrator must have a positive, professional attitude.

If the system administrator has less than this attitude, critical tasks may not be properly
completed (for example, backups may not be taken as scheduled and backup logs may
not be checked, which reduces the chances for a successful recovery).

<

System administrators should maintain a my job is on the line attitude.

This attitude helps to ensure that administrators focus on maintaining the integrity of
the system. The company may not survive if the system crashes and cannot be
recovered.

<

The system must be protected from internal and external sources.

One problem today is employees poking around in the network.

'R1RW%H$IUDLGWR$VNIRU+HOS
:K\

<

R/3 is so large and complex that one person cannot be expected to know everything.
If you are unsure which task to complete or how to complete it, you could make a
mistake and cause a larger problem.

<

Mistakes within the system can be expensive.

Certain things cannot be undone, and once set, are set forever.

<

The only way to learn is to ask.

There are no dumb questionsonly dumb reasons for not asking them.

+RZ

<

SAPNet R/3 notes

<

Various web sites and news groups

<

Consultants

Also see the section in this chapter that covers networking with other customers and
consultants.

System Administration Made Easy

15

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

1HWZRUNZLWK2WKHU&XVWRPHUVDQG&RQVXOWDQWV
:KDW

Get to know the R/3 Basis and system administrators in other companies.
:K\

<

Other customers may be able to provide solutions to your problems.

<

Customers who help each other reduce their consulting expenses.

<

The more people you know, the better your chances of finding someone to help you
solve a problem.

:KHQ:KHUHDQG+RZ

When you have the opportunity, meet:

<
<

Other SAP customers and consultants, especially those in your specialty area
Others using your operating system or database

Where to network:
<

Training classes

<

SAP events
Technical Education Conference (TechEd)
SAPPHIRE
Participate in user groups:
Americas SAP Users Group (ASUG)
Regional SAP users groups
Database user groups, such as those for Microsoft SQL Server, Informix, DB2, or
Oracle
Operating system user groups, such as those for UNIX (the various versions), NT, or
IBM (AIX, AS400, or OS390)

<

<

Participate in professional organizations

Participation means getting involved in the organization. The more you participate, the
more people you meet and get to know.
<

Whenever you attend an event, carry a stack of business cards.

Set the goal of collecting at least ten business cards, of people in your area of specialty.

<

Do not forget to ask the old-timers.

Decades ago, the mainframe community may have solved many of the issues and
problems you now face.

16

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

.HHS,W6KRUWDQG6LPSOH.,66
:K\

<

Complex tasks are more likely to fail as situations change.

A process with 27 steps has 27 chances to fail, because complex tasks are difficult to
create, debug, and maintain.

<

It is difficult to train people for complex tasks.

<

Explaining a complex task on the telephone increases the chance that what is said will
not be properly understood and an error will be made. If the error is severe, you may
have a disaster on your hands.

+RZ

<
<

Keep tasks as simple as possible.

Test

.HHS3URSHU'RFXPHQWDWLRQ
:KDW

Document processes, procedures, hardware changes, configuration changes, checks

performed, problems, errors, etc. If in doubt about what to document, write it all down.
:K\

<

As time passes, you will forget the details of a process or problem.

At some point, you may not remember anything about the process or problem. In an
extreme situation, which happens with short-term memory, you can quickly forget the
information in minutes.

<

If you violate the KISS principle, complete documentation becomes even more
important.

<

If the process is complex, complete documentation reduces the chance of errors.

<

If you are sick or unavailable, complete documentation can help someone else do the
job.

<

If changes need to be undone, you will know exactly what needs to be done to complete
this task.

<

Documentation helps train new people.

Employee turnover must be planned for. Proper documentation makes the training and
transition of new employees easier and faster.

System Administration Made Easy

17

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

:KHQ

Documentation must be changed when:

<

Documented items change.

Inaccurate documentation could be dangerous because it describes a process that should
not be followed.

<

Changes are made to the system.

<

Problems, such as hardware failures, error log entries, and security violations, occur.

Hot projects or emergencies tend to take precedence over writing documentation. Do

not postpone writing documentation, or the task may never get done. Record everything
that is done to the systemas it is being done.
+RZ

<

Record everything done to the system, as it is being done, so details are not forgotten.

<

Document items clearly and sufficiently so that, without assistance, a qualified person
can read what you have written and perform the task.

<

Re-read older documentation to see where improvements can be made. Obvious items
get fuzzy over time and are no longer obvious.

<

Use graphics, flowcharts, and screenshots to clarify documentation.

:KHUH

<

Keep a log (notebook) on each server and record everything that you do on the servers.

<

Keep a log for everything done remotely to any of the servers.

<

Keep a log for other related items.

8VH&KHFNOLVWV
:KDW

A checklist lists the steps required to complete a task. Each step requires an
acknowledgement of completion (a check) or an entry (date, time, size, etc.).
:K\

<

Checklists enforce a standardized process and reduce the chance that you will overlook
critical steps.
For example, if you were to use a checklist every time you drive a car, then you would
remember to turn off your headlights when you park your car, or you would not drive
off with your parking brake still set.

<

18

Checklists force you to document events, such as run times, which may later become
important.

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

:KHQ

Checklists are especially useful for tasks that are:

<

Complex or critical
If a step is missed or done incorrectly, the result could be serious (for example, inability
to restore the database).

<

Done for the first time

<

Done infrequently
It is difficult to remember how to do a complicated task that you do only once a year.

+RZ

See examples in Scheduled Tasks.

8VHWKH$SSURSULDWH7RROIRUWKH-RE
Sometimes a low-tech solution is best. Depending on the situation, a paper-and-pencil
solution may work better and be more cost effective than a computerized solution. Paper
and pencil still works during a power failure.

3HUIRUP3UHYHQWLYH0DLQWHQDQFH
:KDW

Preventive maintenance is the proactive monitoring and maintenance of the system.

:K\

<
<

It is less disruptive and stressful if you can plan a convenient time to do a task, rather
than have it develop into an emergency situation.
Fix a potential problem before it negatively impacts the system and company
operations.
An extreme situation is that the entire system is down until a particular task is
completed (for example, if the log file space goes down to zero (0), the database will
stop, and then R/3 also stops. Until sufficient file space is cleared, R/3 will not run and
certain business operations, such as shipping, may stop).

:KHQ

<

Checking for problems should be a part of your regular routine.

<

Scheduling tasks to fix a problem should be based on your situation, and when least
disruptive to your users.

+RZ

<

Monitor the various logs and event monitors

<
<

Obtain additional disk storage before you run out of room

Regularly clean the tape drive(s)

<

Check the database for consistency and integrity

System Administration Made Easy

19

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

'R1RW&KDQJH:KDW<RX'R1RW+DYH7R
:KDW

<

If the system works, leave it alone.

<

Do not change something just to upgrade to the latest version.

:K\

<

Risk
When something changes, there is a chance that something else may break.

<

Cost
Upgrading is expensive in terms of time, resources, and consulting, etc.

:KHQ

<

A business need exists.

<

Legal requirements call for an update.

This really is not an option. If you do not keep up you will not be complying with legal
requirements. The associated penalties can be expensive.

<

If the hardware or software release is no longer supported by the vendor.

<

The new release offers a specific functionality that offers added business value to your
company.

<

Fixing a major problem requires an upgrade.

A fix is unavailable in a patch or an advance release.

+RZ

<

If the change fails or causes problems, make certain you can recover to a before-thechange condition.

<

All changes must be regression tested to make sure that nothing else has been affected
by the change. In other words, everything still works as it is supposed to.
Regression testing of R/3 involves the functional team and users.

<

Stage the change and test it in the following order:

1. Test system (a Sandbox system)
2. Development system
3. Quality Assurance system
4. Production system
Even if your company does not have all the above-mentioned systems, the key is to
maintain the general order. For example, if your company does not have a test system,
test the change in the following order:
1. Development
2. Quality Assurance
3. Production

110

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

By the time you reach the production system, you should be comfortable that nothing
will break.

'R1RW0DNH6\VWHP&KDQJHV'XULQJ&ULWLFDO3HULRGV
:KDW

A critical period is when system disruptions could cause severe operational problems.
:K\

If a problem occurs during a critical period, the business maybe severely impacted.
Note the following sequence of events:
1. A system administrator changes a printer in Shipping at the end of the month.
2. R/3 cannot send output to the new printer.
3. The users cannot print shipping documents.
4. The company cannot ship their products.
5. Revenue for the month is reduced.
:KHQ

A critical period is any time where the users and the company may be severely impacted
by a system problem. These periods differ depending on the particular industry or
company. What is a critical period for one company may not be critical for another
company.
The following are real examples of critical periods:
<

At end of the month, when Sales and Shipping are booking and shipping as much as
they can, to maximize revenue for the month

<

At the beginning of the month, when Finance is closing the prior month

<

During the last month of the year, when Sales and Shipping are booking and shipping as
much as they can, to maximize the revenue for the year

<

During the beginning of the year, when Finance is closing the books for the prior year
and getting ready for the financial audit

+RZ

<

Always coordinate potentially disruptive system events with the users.

Different user groups in the company, such as Finance and Order Entry, may have
different quiet periods that need to be coordinated.

<

Plan all potentially disruptive systems-related activities during quiet periods when a
problem will have minimal user impact.

System Administration Made Easy

111

Chapter 1: R/3 System Administration Basics

R/3 System Guidelines

'R1RW$OORZ'LUHFW'DWDEDVH$FFHVV
:KDW

Direct database access means allowing a user to run a query or update directly to the
database without going through R/3.
:K\

<

By not going through R/3, there is the risk of corrupting the database.

<

Directly updating the database could put the database out of sync with the R/3 buffers.

+RZ

<

<

When R/3 writes to the database, it could be writing to many different tables.
If a user writes directly to the tables, missing a single table may corrupt the database by
putting the tables out of sync with each other.
With direct database access, a user could accidentally execute an update or delete, rather
than a read.

.HHSDOO1RQ6$3$FWLYLW\2IIWKH56HUYHUV
:KDW
< Do not allow users to directly access (telnet, remote access, etc.) the R/3 server(s).
< Do not use the R/3 server as a general file server.
< Do not run programs that are not directly related to R/3 on an R/3 server.
:K\

<

Security
Not allowing users to have access to the R/3 server reduces the chance of files from
being accidentally deleted or changed.
No access also means that user cannot look at confidential or sensitive information.

<

Performance
Using the production R/3 sever as a file server creates resource contention, where
performance is a primary concern. Programs running on the R/3 servers will contend
for the same resources that R/3 is using, which affects the performance of R/3.

+RZ

Use other servers to perform functions unrelated to R/3.

112

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

Corollaries to Murphys Law

0LQLPL]H6LQJOH3RLQWVRI)DLOXUH
:KDW

A single-point failure is when the failure of a single component, task, or activity causes the
system to fail or creates a critical event.
:K\

Each place where a single-point failure could occur increases the chances of a system failure
or other critical event.
For example, if:
<

You only have one tape drive and it fails, you cannot back up your database.

<

You rely on utility line power, and do not have a UPS, the server will crash during a
power failure and possibly corrupt the database.

<

You are the only one who can complete a task, and you are on vacation, the task will not
be completed until you return (or you will be on call while on vacation).

To guard against a single-point failure, consider the following options:

<
<

Systems configured with a built-in backup

Redundant equipment, such as dual power supplies

<

On-hand spares

<

Sufficient personnel

<

On-call consultants

<

Cross-training

<

Outsourcing

&RUROODULHVWR0XUSK\V/DZ
Murphys Law states: Whatever can go wrong will go wrong.
The following are some corollaries to Murphys Law:
<

Without telling you, someone will change something in the infrastructure and crash the
system.

<

When the power fails, you find out that the battery in your UPS is dead.

<

If you have only one tape drive, it will fail.

<

The one thing that you did not test is where the problem is.

<

Someone will need a network jumper cable, and will remove it from your server.

<

When disaster strikes, you will be out of town or unavailable .

<

Disaster will strike at the worst time.

<

Problems always happen at 2:00 AM.

<

Problems come in clusters.

System Administration Made Easy

113

Chapter 1: R/3 System Administration Basics

Special Definitions

<

The latest full backup tape will be bad.

<

The one time you did not check the backup log will be the time when the backup fails.

<
<

You will need a tape from the backup that failed.

The computer room will be destroyedalong with all your backup tapes.

<

What you did not write down, and forgot, is what you need to know.

<

User transparent, is not.

<

The Peter Principle will strike.

<

A shortcut is the longest distance between two points.

<

When you need to send an alpha page, a link in the e-mail system will fail.

<

When a disaster strikes, and you need to be found, you will be out of the pager or cell
phone coverage area.

<

When a disaster strikes, and you need to be contacted, the battery in your pager or cell
phone will be dead.

6SHFLDO'HILQLWLRQV
There are terms used in this guidebook that have very specific meanings. To prevent
confusion, they are defined below:

'DWDEDVHVHUYHU
This is where R/3 and the database resides.
The system clock of the database server is the master clock for the R/3 system.

$SSOLFDWLRQVHUYHU
This is where R/3 application runs.
On a two-tiered system, this would be combined on the database server. Application
servers can be dedicated to online users, batch processing or a mix.

,QVWDQFH
An installation of R/3 on a server.
The two types of instances are central, and dialog. More than one instance could exist on a
physical server.

6\VWHP
The complete R/3 installation for a System ID (SID), for example PRD.
A system logically consists of the R/3 central instance and dialog instances for the SID. This
physically consists of the database server and application servers for that SID.

114

Release 4.6A/B

Chapter 1: R/3 System Administration Basics

Special Definitions

Three-tiered R/3 Configuration

Layers

Physical Devices

R/3 Instance

What Runs on Each

Layer

Presentation

Desktop PCmany

N/A

SAP GUI

Application

Application Server

Dialog

R/3

Central

Database: SQL
Server, DB2,
Informix, ADABAS,
Oracle

N/A many
Database

Database server
only one

A two-tiered configuration combines the application and database layers on a single server.

System Administration Made Easy

115

Chapter 1: R/3 System Administration Basics

Special Definitions

116

Release 4.6A/B