Oracle SAP Administration

By Donald K. Burleson
1st Edition November 1999
1-56592-696-X, Order Number: 696X
214 pages, $32.95

Chapter 1
Oracle and SAP
In this chapter:
Introduction to SAP
Oracle/SAP Naming Conventions
The Oracle Database Layer of SAP
Oracle/SAP Administrators and Tasks
Administering an Oracle/SAP system, and maximizing the performance of its
database, is a formidable job. You need to fully understand how both the SAP and
Oracle systems work in isolation, and you need to know how they work together. In
subsequent chapters of this book, I'll describe the specifics of that interaction. You'll
learn how to use the special Oracle/SAP utilities, how to deal with the limitations of
conventional Oracle functions, and how to place and reorganize files. Furthermore,
after reading this book, you'll know more about monitoring databases during
operation, tuning them, running backup and recovery, and performing special
operations for systems that use parallel technologies or that support unusually large
databases.
This chapter presents the fundamentals of the SAP architecture and describes how
Oracle fits into the SAP runtime system. It also explains fundamental Oracle/SAP
concepts -- the client/server model, special Oracle/SAP naming conventions,
administrator roles, and basic administrative operations. First, though, let's take a step
back and look at what SAP is.
Introduction to SAP
The SAP system is a collection of software that performs standard business functions
for corporations. The system has become very popular because it provides a complete
solution to standard business requirements such as manufacturing, accounting,
financial management, and human resources. It incorporates the concepts of enterprise
resource planning (ERP) and business process reengineering (BPR) into an integrated
solution for business applications.
SAP is a product developed and marketed by the German company SAP AG. SAP is a
German acronym for "Systemanalyse und Programmentwicklung," which can be
loosely translated into "Systems and Application Products." Founded in 1972 by IBM
application developers, SAP AG originally developed application products for the
European marketplace. For nearly two decades, the company grew slowly. Early
versions of its software were mainframe-based and appealed particularly to very large
European corporations. Within the United States, sales were mainly to the Fortune
500.
SAP's R/3 System
During the 1990s, companies of all sizes began to embrace the concept of ERP
systems and to gravitate toward prewritten business applications. With the
introduction of its client/server SAP R/3 system in 1992, SAP AG, which already had
a sizeable lead in the ERP market, unveiled a system that was attractive to medium-
and small-sized companies as well as to the large companies already using SAP
software. The SAP R/3 system runs on virtually any hardware/software platform and
can use many different database management systems. One SAP system might be
based on an IBM AS/400 running OS/400 using DB2; another might be based on a
Sun Solaris (a dialect of Unix) using the Oracle RDBMS; still another might be based
on an IBM PC running Windows NT using SQL Server. While SAP can be run with
many different database products, nearly 85% of SAP customers now choose Oracle
because of its dominance in the database marketplace. SAP software has become very
popular in the U.S., and the company is now the world's leading application package
vendor. SAP competes directly with Oracle Applications products and PeopleSoft
products in the ERP marketplace.
The SAP R/3 code is written in an interpretive language called ABAP. (ABAP is a
German acronym that, loosely translated, means "Advanced Business Application
Programming.") ABAP is very similar to COBOL in its syntax. Use of the ABAP
language allows SAP customers to extend the functionality of the base product, as
described in the next section.
SAP Application Products
The SAP R/3 application offers end users the ability to run their entire business from a
single application vendor. Some SAP customers choose to run their entire enterprise
from SAP, while others run SAP only for specific business processes, such as
manufacturing or finance. SAP is designed to allow customers to choose their own set
of business functions, and it is sold in many configurations--both as specific business
functions and as enterprise-wide solutions.
An SAP customer can choose whatever applications meet his site's specific business
requirements. In addition, the customer is free to customize his SAP installation,
adding new database entities as well as new functionality. For example, a company
may use an inventory method that is nonstandard but essential to the company's
efficiency; the basic SAP functionality can be modified to accommodate the specific
requirements of that inventory method. The result of all of this flexibility is that
virtually every SAP installation has its own specific configuration and set of
functions. However, there are costs associated with customizing SAP. An
organization that makes thousands of customizations to its SAP application may find
itself spending millions of dollars to upgrade SAP: when SAP is upgraded, every
customization must be identified in the ABAP code, and these changes must be
reapplied to the upgraded SAP software, increasing the cost of the upgrade.
SAP products are distributed as applications with functional modules inside each
application. Applications are generally focused on particular business functions. The
modules within each application perform specific business tasks such as capital
investment management, personnel administration, and quality management. The
major applications are financials, human resources, and logistics, described briefly in
the following sections.
In addition to basic business functions, SAP also offers products in the following
areas (see http://www.sap.com/products/ for details):
SAP Business Intelligence initiative
SAP Supply Chain Management initiative
SAP Customer Relationship Management initiative
SAP Electronic Commerce
SAP Human Resources
SAP Treasury
SAP Real Estate
SAP Environment, Health, & Safety
When an SAP application is purchased with Oracle, each of the modules is delivered
with a complete Oracle schema consisting of thousands of tables and indexes.
Because the end user may purchase one or more components of SAP, SAP delivers
the definition for many more Oracle tables and indexes than will be used by the
running application. It is not uncommon to see an SAP application where thousands of
tables and indexes are allocated but never used by SAP.
SAP has also branched out from traditional online transaction processing (OLTP)
products into data warehousing with its Business Information Warehouse (BIW) and
Supply Chain Optimization, Planning, and Execution (SCOPE) products.
Financials applications
The SAP Financials applications contain all of the functionality needed for enterprise-
wide financial management. The modules within the Financials applications include
the following:
Financial Accounting (FI)
Provides a complete financial accounting solution, including income
statements, balance sheets, journals, ledgers, and all areas of financial
accounting.
Enterprise Controlling (EC)
Assists in controller tasks.
Capital Investment Management (IM)
Assists finance organizations in their capital investments and tracking.
Controlling (CO)
Assists the controller organization.
Treasury (TR)
Assists with transactions related to the U.S. Treasury.
Human Resources applications
The SAP Human Resources (HR) applications are designed to provide a fully
functioning HR system. They include two primary modules:
Personnel Administration (PA)
Assists with all areas of personnel administration, including applicant
tracking and personnel history.
Personnel Development (PD)
Assists with training and educational status of employees.
These systems handle all of the mundane HR tasks, such as personnel and payroll, and
also a number of more esoteric HR functions, such as seminar and convention
management.
Logistics applications
The SAP Logistics applications include SAP's most popular modules. Logistics was
the first area of entry for SAP. This includes virtually every area of manufacturing,
from the initial acquisition of raw materials to the delivery of finished goods. The
modules in this area include the following products:
Materials Management (MM)
Manages raw materials, inventory, and all aspects of goods
manufacturing.
Production Planning (PP)
Offers sophisticated tools for planning large production environments.
General Logistics (LO)
Manages logistics for companies that require large-scale deployment of
goods and resources.
Sales and Distribution (SD)
Manages the inventory and distribution of finished goods.
Plant Maintenance (PM)
Manages the resources required for large manufacturing plants.
Quality Management (QM)
Captures and maintains quality control for manufacturing environments.
Project System (PS)
Assists with the scheduling of project tasks and interdependencies
between tasks.
The SAP R/3 System Architecture
All SAP R/3 applications are delivered in a three-tier client/server architecture, shown
in Figure 1-1.
Figure 1-1. The SAP three-tier client/server architecture

The three layers are:
Presentation layer
The PC-based GUI interface that is used by the end-user community.
Application layer
The SAP application servers that service requests for data and manage
the interface to the presentation layer.
Database layer
The actual DBMS that communicates with the application servers to
fulfill their requests for data.
A piece of "middleware" called BASIS links the application to the database and the
operating system. BASIS is most commonly associated with the GUI interface to SAP
(called SAPGUI), and the BASIS Administrator is an SAP professional who is
responsible for configuring the SAP environment, including the GUI screens and the
SAP application servers.
SAP end users log into their PCs using SAPGUI, and are connected to a specific
application server. This application server has pre-established connections with the
Oracle database, and it services all requests for data. As I mentioned earlier, the
access language for Oracle data is SAP ABAP. ABAP generates Oracle SQL
(Structured Query Language), which is then used to service the end user's request for
data. The communication between the application servers and the database, and
between the client and the application servers, is TCP/IP.
While SAP is available for many different hardware platforms and operating systems,
the majority of SAP systems use Unix-based servers for hosting SAP and the Oracle
database. For this reason, as mentioned in the Preface, this book assumes the use of
Unix in most examples.
The application server
While SAP uses the generic term application server to define a computer that receives
connections from SAP clients, the actual connections are managed by SAP dialog
servers.
A dialog instance is a software program that is running the SAP kernel (similar to an
Oracle instance), and it is the job of the dialog instance to execute the ABAP
programs and manage the requests for data and services. While there is generally a
one-to-one mapping between an application server and a dialog instance, it is possible
to have more than one dialog instance on an application server.
The central instance
The central instance is a concept that is unique to SAP. The central instance is a
combination of hardware and software. It contains a physical server (the application
server) and numerous software components, including a message server, a database
gateway (a pre-established connection between SAP and Oracle--or another database),
and various update, enqueue, dialog, and spool facility software. In most generic SAP
architectures, there are numerous application servers but only a single central
instance. However, in addition to managing the SAP interfaces, the central instance
can also serve as an application server.
Bear in mind that SAP is very flexible, and there are many different ways to configure
an SAP architecture to meet your business needs. However, most companies that
implement SAP wisely choose to alter their business practices to accommodate SAP.
By avoiding customization of its SAP application, a company can more easily
upgrade its SAP software.
TIP: In 1998 SAP AG announced that the company is planning a four-tiered
client/server architecture that will isolate the database from the SAP applications.
Under the four-tiered architecture, the database will be insulated from SAP by the use
of an active database cache called liveCache. This expanded memory cache will act as
a separate layer, further insulating the Oracle database from the SAP application and
allowing for the real-time manipulation of database objects.
Work processes
Any computer is capable of running one or more application servers. The main
purpose of a dialog instance is to intercept requests for work from the SAP clients and
to execute ABAP programs to service the requests for data. In addition, a dialog
instance contains a dispatcher task and a set of work processes (WPs). The WPs are
Unix tasks that can easily be identified by logging on to the Unix server and entering
the following command:
ps -ef|grep dw
All SAP WPs contain the string "dw" (an acronym for Dialog Work) in their process
names. The dispatcher on an SAP dialog receives requests from the SAP users
(see Figure 1-2). In cases where a computer is running more than one dialog instance,
there is one dispatcher for each dialog instance.
Figure 1-2. The SAP Dialog instance configuration

The WP is the task that is charged with executing the application's tasks. As such, a
WP consists of an ABAP language interpreter and processor, a task handler, and a
means of connecting to the Oracle database. SAP defines several types of work
processes, as follows:
Dialog (DIA)
Executes interactive dialogs
Batch (BTC)
Executes background tasks
Update (UPD)
Manages database updates
Enqueue (ENQ)
Manages resource locks
Spool (SPO)
Manages data formatting and printing
The WPs can be viewed from a variety of places via SAPGUI, the SAP management
tool. In SAPGUI, each screen has a name, and the SAPGUI screen called SM50
shows the currently executing WPs on a dialog instance (see Figure 1-3). SAPGUI has
more than 100 screens, but in this book I'll focus on the major database screens.
See Chapter 2, Oracle/SAP Utilities, for a discussion of SAPGUI and SAPDBA, the
primary SAP utilities.
Figure 1-3. SAPGUI transaction SM50 displaying SAP work processes

The SAP system administrator, commonly called the BASIS administrator, controls
the number of WPs that are defined to each application server. (See the "Oracle/SAP
Administrators and Tasks" section later in this chapter.) In addition, the BASIS
administrator can define "op modes" that control the number and type of WPs for each
application server. For example, the BASIS administrator might define a day mode
consisting of more dialog WPs for interactive sessions, and a night mode consisting of
more batch WPs for the evening batch processes. These op modes are automatically
switched by SAP according to the timetable specified by the BASIS administrator.
Oracle/SAP Naming Conventions
In order to maintain control over a vast set of applications, SAP has devised a
convention for naming common components. These conventions are more than
suggestions; in many cases, deviation from the naming conventions may cause some
management components of SAP (e.g., SAPDBA) to function improperly. Thus, it's
very important that all SAP systems follow these naming conventions.
One firm rule relates to the Oracle table and index names. Obviously, the SAP table
structures and table names cannot be changed without changing the ABAP programs
that access these tables, and SAP strongly urges customers not to alter the Oracle
entities without the express consent of SAP AG. However, the Oracle administrator
does have control over the naming of some Oracle entities (tablespaces and datafiles)
and their placement within the filesystems and disk devices. The main areas of
concern for the Oracle administrator are the Oracle SID name, the name and location
of the Oracle initialization file, and the names of the Oracle tablespaces and datafiles;
these objects are described in the following sections.
The Oracle SID in SAP
SAP mandates that the Oracle SID (System IDentifier), specified in Unix and some
other operating systems as ORACLE_SID, always begin with an uppercase "SA,"
followed by a single alphanumeric digit or a single uppercase alphabetic character.
Thus, the SID may have the values SA0-SA9 or SAA-SAZ. These are the only
allowable choices for Oracle database SIDs. Throughout this book, I've used the
notation sapsid to refer to the Oracle SID established for your own database.
The Oracle Initialization File (INIT.ORA) in SAP
Within an SAP system, the Oracle initialization file must exist with a specific name in
a specific directory; if it does not, the SAPGUI and SAPDBA utilities will not work
properly. Within both Oracle documentation and third-party books, the initialization
file is ususally referred to as INIT.ORA, and I've followed that convention in this
book. Note, however, that the actual name of this file in your system will
be INITsapsid.ORA, where sapsid is the Oracle SID for your database (described in
the previous section) and has the name you've specified for it. For example, if your
Oracle SID is SA9, your initialization file will have the name INITSA9.ORA. In SAP
systems, the intialization file must be located in the directory oracle/<sapsid>/dbs;
for example, oracle/SA9/dbs.
In addition to the basic initialization file, SAP allows configuration or subinitialization
files to be called from the INIT.ORA file. Most Oracle administrators find it more
convenient to place all of the Oracle initialization parameters in a single file; however,
sometimes it makes sense to segregate different types of parameters into several files.
For example, if your site is configured differently for transaction processing (during
the day) and for batch processing (at night), you might include common initialization
parameters in a single configuration (CONFIG.ORA) file but have
separate INIT.ORA files for day and night processing. You'd restart with the
appropriate INIT.ORA file for each time period. (This approach should not be
confused with BASIS op modes.)
Within the INIT.ORA file, you must follow the SAP conventions for parameters
summarized in Table 1-1.
Table 1-1: SAP Conventions for the INIT.ORA File
INIT.ORA Parameter Filesystem Destination
USER_DUMP_DEST /oracle/<sapsid>/saptrace/usertrace
LOG_ARCHIVE_DEST /oracle/<sapsid>/saparch/SAPSID_
BACKGROUND_DUMP_DEST /oracle/<sapsid>/saptrace/background
AUDIT_FILE_DEST /oracle/<sapsid>/rdbms/audit
CONTROL_FILES /oracle/<sapsid>/sapdata-nn/cntrl1.data1
Oracle Tablespaces in SAP
In an SAP system, Oracle tablespace names always begin with the string "PSAP" and
end with a "D" (data tablespace) or an "I" (index tablespace). Some of the common
SAP tablespaces are PSAPCLUD, PSAPLOADD, and PSAPDICD.
A standard SAP system contains only a handful of tablespaces. These tablespaces are
designed to contain all of the SAP tables, and are defined as a part of the default SAP
installation. Figure 1-4 shows the sample tablespace descriptions for an SAP
installation. Within an Oracle/SAP tablespace, many of the tablespaces will remain
small--for example, the metadata information in the DICT tablespace.
Figure 1-4. Standard SAP tablespaces

SAP has segregated the Oracle tables into tablespaces according to their functions. As
shown in Figure 1-4, each tablespace can be classified as a transaction tablespace, a
BASIS tablespace, or an SAP system tablespace. Note that the SAP application has a
system tablespace (called PSAPDICTD), just as the Oracle database has a system
tablespace. The following sections describe these tablespaces. SAP folks disregard the
leading PSAP in each tablespace and the ending "D" or "I" in each tablespace name.
Hence, the PSAPSTABD tablespace is commonly referred to as STAB.
Transaction tablespaces
Transaction tablespaces hold the application data for individual transactions. These
transaction tablespaces include the BTAB, STAB, and USER1 tablespaces:
BTAB
Holds the SAP transaction tables. These tables constitute the heart of
SAP, and the Oracle administrator may choose to migrate the largest and
most active tables into other tablespaces for improved data management.
STAB
Holds the SAP master data and transparent tables. These are normally
the master reference tables for the SAP application holding commonly
referenced application information.
USER1
Commonly defined to hold user customization tables that are not defined
with the SAP software.
In an operational SAP database, these tablespaces will experience the highest read-
write activity and will grow very large as your end users load SAP with their business
data. Thus, you'll need to monitor these tablespaces very closely, since they may fill
and cause the entire SAP application to stop. Many Oracle/SAP administrators run
scripts to identify the largest and most active tables in these tablespaces and move
these tables into separate tablespaces. These separate tablespaces are then segregated
by disk for better overall I/O management. Oracle administrators sometimes use file
striping for these tablespaces to balance the load across many disk devices, and
thereby improve throughput. I'll describe SAP tablespace monitoring in some detail
in Chapter 4, SAP Database Monitoring.
BASIS tablespaces
The BASIS tablespaces include BTABD, STABD, DICT, LOAD, PROT, and
SOURCE. SAP uses these Oracle tablespaces to store data that is used to perform
basic SAP system functions. For example:
PROT
Holds the output from ABAP reports while they are waiting to be
printed, and contains spool, converter, and log tables.
SOURCE and LOAD
Contain the ABAP source code for reports and screens. In an SAP
system, remember that ABAP is run in an interpretive mode, and the
source code is gathered from these tablespaces at runtime for
interpreting.
DICT
Contains the ABAP data dictionary, and consists of SAP metadata; in
this sense, the DICT tablespace is very similar to the traditional Oracle
SYSTEM tablespace.
System tablespaces
The most important SAP system tablespaces are POOL, CLU, and DOCU:
POOL
Used to store the SAP system pool tables. These are similar to the master
data tables found in the STAB (transaction) tablespaces, but SAP
considers them too small to require their own Oracle tables. The items
from the POOL tablespaces are generally buffered and loaded into the
memory of the dialog instance, so POOL is not heavily accessed except
at SAP startup time.
CLU
Contains SAP cluster tables. Unlike Oracle clusters, SAP cluster tables
are stored into Oracle tables with LONG RAW datatypes. The data
within the LONG RAW columns are used by SAP as subtables, and each
row within an SAP cluster table may contain data that is completely
unrelated to the next row in the table. These pseudo-tables present a
challenge to the Oracle administrator, especially when they must be
reorganized, because you can't use Oracle's CREATE TABLE AS
SELECT command with tables that contain LONG RAW columns.
Consequently, reorganizations of the CLU tables must be performed
with Oracle's slower Export/Import utilities. I'll discuss this topic
in Chapter 5, Table, Tablespace, and Index Reorganization.
DOCU
Contains the document tables, including the sapscript and sapfind tables.
This is a relatively small tablespace with fewer than 30 tables.
Oracle Files in SAP
In a typical Oracle configuration, you can map an Oracle tablespace to a single
datafile or to many datafiles. Because of the large size of many SAP installations, an
Oracle/SAP tablespace generally maps to many datafiles. In a production SAP
environment, many of these tables will never be used, while other tables will grow
very rapidly. Thus, in general, you should identify and segregate the highly active
tables into separate tablespaces. Chapter 4 includes a script you can use to identify the
SAP tables that are growing.
SAP is quite strict about the names for its default tablespaces, so you cannot change
these names, but you can add new tablespaces. When you segregate SAP tables into a
separate tablespace, however, you can name that tablespace anything you like.
Although SAP gives you complete freedom in tablespace naming, SAP AG suggests
that when a new tablespace contains a single table, the tablespace name be a
permutation of the table name. For example, the table named VBAP could be moved
into a tablespace with any of the following names: PSAPVBAPD, VBAPD, or VBAP.
An SAP purist would preface the tablespace name with PSAP and end the tablespace
with the letter "D." This is helpful in order to be consistent with the other SAP naming
conventions, and it can also be helpful when using SAPGUI to view tablespace
information.
Oracle system files
While many standard Oracle configurations generally follow Oracle's Optimal
Flexible Architecture (OFA) standard, SAP has changed this standard somewhat, in
an effort to create a "flat" file hierarchy (seeFigure 1-5).
Figure 1-5. The Oracle/SAP file architecture

Note that $ORACLE_HOME is set to the same value as /oracle/<sapsid>, and all of
the Oracle database software is located directly beneath this directory. For example,
the Oracle executables are always located in /oracle/<sapsid>/bin.
Oracle datafiles
Within SAP, Oracle database files are named somewhat differently from the way
they're named in traditional Oracle databases. The default SAP installation uses
datafile names in which the prefix matches the tablespace name. For the filename
suffix, rather than using a dbf suffix, SAP requires that datafiles contain
the datan suffix. In this way, the Oracle datafile called psappooli.data3, for example,
will be instantly recognizable as the third datafile for the POOL data indexes.
Oracle indexes
SAP also follows a standard for index naming. All Oracle index names default to
eight characters in length; they always begin with the table name, end with a number,
and use between one and three underscore characters in between. All indexes that end
with a zero represent the primary key indexes for the table, and all nonzero numbers
represent secondary indexes. For example, you will be able to tell that VBEP_ _ _0 is
the primary key index for the VBEP table, and that VLPMA_ _1 is the secondary
index for the VLPMA table. To properly display indexes within SAPGUI, all new
SAP indexes should begin with the table name and end with a unique numeric
character. Also, it is important that the index names be eight characters long, using a
variable number of underscore ( _ ) characters.
SAP Filesystems on Unix
In addition to the required Oracle filesystems, some SAP-specific filesystems are
found on most of the SAP application servers. These filesystems are used to hold
certain Unix files that are required for SAP to function in the Unix environment.
These include the SAP executable programs, SAP configuration files, and other SAP
system-related datafiles, as follows:
/usr/sap/trans
This directory contains the common transport directory, .sapconf, as well
as other SAP and Oracle configuration files. For distributed Oracle
systems, this directory may also contain the
mastertnsnames.ora and sqlnet.ora files.
/sapmnt/<sapsid>
This directory stores system-wide files for SAP, including executables,
global files, and profiles.
/usr/sap/<sapsid>
This directory stores instance-specific files for each SAP dialog instance.
The Oracle Database Layer of SAP
As you know, SAP is designed to work with many database management systems;
interfaces are available for Oracle, DB2, Informix, and several other database
products. Since SAP is database-independent, the SAP architecture requires the
database to be defined as a part of the initial SAP installation. Once defined, the SAP
programs (ABAP programs) will generate SQL that is compliant with the target
database product.
Native Oracle SQL is generated by the ABAP program at runtime, and the SQL is
then passed to Oracle for execution. The dynamic nature of ABAP SQL greatly
increases its flexibility, but it makes it very difficult for the Oracle administrator to
provide SQL tuning for Oracle. Because the SQL is generated from the ABAP at
runtime, there is no way to change the execution plan for SQL by adding hints as you
would in a traditional Oracle system. I'll discuss this limitations of SQL tuning, and
some strategies you can adopt to overcome it, in Chapter 6, SAP Tuning.
Viewing Connections to the Oracle Database
From Oracle's perspective, the SAP application looks just like any other application.
The SAP instance predefines a set of database connections that are created when the
SAP instance is started, and these connections are held for the life of the SAP
instance. In the example that follows (see Example 1-1), I've issued the following
Unix command to display the processes for the ORACLE_SID called SA9:
ps -ef|grep -i sa9
This command displays the Oracle background processes (arch, pmon, reco), as well
as all of the preestablished connections to SAP.
Example 1-1: The SAP Connections to the Oracle Database

sa9adm 94456 1 0 08:54:43 - 0:00 ora_arch_SA9
sa9adm 106746 1 0 08:54:47 - 0:00 ora_ckpt_SA9
sa9adm 71153 1 0 08:54:39 - 0:00 ora_pmon_SA9
sa9adm 15100 1 0 08:54:51 - 0:00 ora_reco_SA9
orasa9 72915 1 0 09:33:18 - 0:00 oracleSA9 (LOCAL=NO)
sa9adm 12118 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 24665 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 26179 30211 0 08:56:42 - 0:00 oracleSA9 T:I,,5
sa9adm 27494 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 29528 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 31300 30211 0 08:56:42 - 0:00 oracleSA9 T:I,,5
sa9adm 40034 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 52567 30211 0 08:57:35 - 0:00 oracleSA9 T:I,,5
sa9adm 73573 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 74088 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 74852 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5
sa9adm 82796 30211 0 08:58:06 - 0:00 oracleSA9 T:I,,5
sa9adm 93799 30211 0 08:58:05 - 0:00 oracleSA9 T:I,,5

Flow of Data from Oracle to SAP
One of the confounding aspects of the Oracle/SAP architecture is the many layers that
exist in an SAP environment. On its way to the SAPGUI client, Oracle data must be
read from disk into the local disk cache, transferred onto the database server Journal
File System (JFS) cache, then transferred into the Oracle buffer cache. Once the data
reaches Oracle, it is shipped to the application server, where it is cached again before
making the final trip to the SAPGUI client.
As you may know, memory buffers are used to save data from a prior disk read so that
they do not have to be reread the next time the data is required. In an Oracle/SAP
configuration, there are many layers of data buffers, and each buffer caches much of
the same data as its predecessor (see Figure 1-6). However, this redundant caching
does not mean that all of the extra data buffers are wasted. As data makes the trip
from the disk to the SAP client, the data cached in each buffer is successively refined.
For example, at the disk level, a physical I/O may result in an entire track of data
being stored on the disk array cache. As the data reaches Oracle, only a single
database block is cached. Once the data reaches the SAP application server, only
specific row information will be stored in the SAP buffer.
Figure 1-6. The path of data from Oracle to SAP clients


Oracle/SAP Administrators and Tasks
Who does what in an Oracle/SAP environment? If you are accustomed to traditional
Oracle environments (those not using SAP), you might find yourself confused by the
very different roles within an SAP environment. For example, many Oracle DBAs are
dismayed to learn that the Oracle software is installed by the BASIS administrator
when the SAP environment is first established, and that they do not have any direct
control over the installation process.
The next sections briefly describe the different roles you'll encounter when using
Oracle with SAP, as well as the functions for which each role is responsible.
SAP Functional Job Titles
In the Oracle/SAP technical arena, there are four major players:
The BASIS administrator (BA)
The Oracle administrator (DBA)
The system administrator (SA)
The network administrator (NA)
At many shops, these duties are shared--for example, the BA might also act as the
DBA--but there are some generalities in job descriptions for these roles.
BASIS administrator
The BASIS administrator (BA) is responsible for the installation and maintenance of
both SAP and Oracle. The BA is also responsible for the configuration of the SAP
topology, the configuration of the application servers and central instance that make
up the system, and the performance and tuning of the SAP application servers. In
addition, the BA is charged with many administrative tasks that are typically
performed by the DBA or SA in a generic Oracle database. For example, the BA is
responsible for creating SAP users, maintaining passwords, defining printers and
spools, and adjusting the number of work processes on each SAP dialog instance. A
successful BA must have an intimate knowledge of the SAP environment and must
act as a buffer between the end users and the DBA/SA staff.
Oracle administrator
The Oracle administrator (DBA) is responsible for ensuring that Oracle has been
correctly installed by the BASIS administrator and for applying Oracle-specific
maintenance patches.
TIP: Unlike administrators of traditional systems, the Oracle/SAP DBA generally
contacts SAP AG headquarters before applying any patches to the Oracle database.
In addition, the DBA must ensure that the SAP objects (tables and indexes) don't fully
consume their tablespaces. The DBA is also responsible for database monitoring,
performance and tuning, and periodic table and index reorganization.
System administrator
The system administrator (SA) is responsible for ensuring that the host servers are
properly installed and configured. The SA is also responsible for the monitoring and
performance tuning of all hardware devices. This can be a major undertaking because
many large SAP landscapes have dozens of application and database servers. At many
shops, the SA must develop an Oracle backup and recovery plan and must perform the
Oracle database backups. While the roles for backup and recovery are shared between
the SA and the DBA, in many SAP shops the SA works on the backup software (e.g.,
ADSM or Legato), while the DBA works with the Oracle component of backup and
recovery (e.g., Oracle Enterprise Backup Utility or Oracle Recovery Manager).
Network administrator
Because of all the connections between each layer of SAP, the network administrator
(NA) has an especially important role in the Oracle/SAP environment. The NA must
constantly monitor the network, looking for bottlenecks and ensuring the smooth flow
of data among all of the servers.
SAP Job Functions
The day-to-day tasks within SAP are also very different from those within
conventional Oracle databases. Because of the special characteristics of the SAP
architecture, many functional roles normally performed by the Oracle DBA shift to
other administrators.
Oracle software installation
The Oracle software is installed as a part of the SAP installation process, which is
performed by the BA.
SAP user administration
All SAP user administration and user security is performed by the BA. The rationale
for this assignment has to do with the way end users connect to the Oracle database.
In SAP, all end-user connections from the SAP application servers to the Oracle
database are done with Oracle SQL*Net connections. This means that there is no need
for any Unix userids. Also, the pre-established connections with Oracle are made with
a single user (schema owner) called SAP R/3, so there is no need for specific Oracle
userids.
SAP security administration
While this job is the primary responsibility of the BA, the SA and DBA play ancillary
roles. The BA is responsible for creating SAP users and maintaining their passwords.
The BA is also charged with all SAP application security.
The SA ensures the appropriate file permissions and controls the master SAP Unix
account <sapsid>adm. (For example, the SAP system SA9 would have a master Unix
account called sa9adm.) For Oracle, all SAP connections are done via the SAP
schema owner, SAP R/3, so there is no Oracle role security to maintain.
The DBA ensures SQL*Net security for the connections between the application
servers and the database server, and controls the password for the Oracle schema
owner, SAP R/3.
WARNING: A breach of security for the SAP R/3 Oracle user could be a major
disaster. Since the sapr3 user owns the entire Oracle/SAP schema, any or all of the
database entities could be deleted if the sapr3 password were exposed.
Backup and recovery
This function is generally split between the SA and the DBA. The DBA has overall
responsibility for the integrity of the Oracle database, including the online redo logs.
However, the SA is usually responsible for writing the backup scripts and ensuring
that the Oracle/SAP database is successfully transferred to tape. If recovery is
required, the DBA requests the disk media restore from the SA; from that point on,
the DBA is responsible for the database roll-forward activities.
Oracle maintenance
The installation of Oracle patches is performed by the DBA, but only after being
given the go-ahead by the SAP AG company representative. SAP is only certified for
specific releases of Oracle, and some Oracle patch upgrades could produce unwanted
results.
Printer management
This function is split between the BA and the SA. The SA must install and define the
printer, but it is the job of the BA to define the printer and a spool to the SAP system.
Problem resolution
This is the most confusing function within SAP. Because of the complex nature of
SAP, a response-time problem could be due to any number of factors -- database
problems, network problems, hardware resource problems, SAP software problems,
and many others. Thus, most SAP shops notify all of the administrators when a
response-time problem occurs, and all parties work in parallel to examine the
problem. The key to successful problem resolution within SAP is to ensure that all of
the members of the technical team have a close and trusting working relationship.
Back to: Oracle SAP Administration

oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies | Privacy Policy
2001, O'Reilly & Associates, Inc.