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//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//saptrace/usertrace
LOG_ARCHIVE_DEST /oracle//saparch/SAPSID_
BACKGROUND_DUMP_DEST /oracle//saptrace/background
AUDIT_FILE_DEST /oracle//rdbms/audit
CONTROL_FILES /oracle//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 (see Figure 1-5).
Figure 1-5. The Oracle/SAP file architecture
Note that $ORACLE_HOME is set to the same value as /oracle/, and all of the Oracle database software is located directly beneath this directory. For example, the Oracle executables are always located in /oracle//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 master tnsnames.ora and sqlnet.ora files.
/sapmnt/
This directory stores system-wide files for SAP, including executables, global files, and profiles.
/usr/sap/
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 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
