SAP Workload Analysis - Chapter 4 Expensive SQL Statement

SQL Statement tuning is a small part of database tuning, and is performed by many different people: R/3 System administrators, database administrators, ABAP developers, certified technical consultants.

Definition and consequences of expensive SQL statements

From user’s point of view:

Lengthy response time of transaction using the statement

Lengthy response times result if the database needs a long time to return the requested data to R/3 needs a long time to return the next screen to the user.

From the system’s point of view:

Many data blocks are scanned to find the selected records.

Monitors for detecting and analyzing expensive SQL statements

What to detect:

1. Reports or transactions where DATABASE REQUEST TIME is a large fraction of response time
2. SQL statements with a HIGH NUMBER OF BUFFER GETS.

For each expensive SQL statement find out:

1. TABLE NAME
2. WHERE CLAUSE
3. INDEXES USED
4. Name of the REPORT OR TRANSACTION containing the statement.

For each expensive SQL statement:

To find out the name of the report or transaction that uses the SQL statement, use the:

Work process Overview (transaction SM50)

Transaction Profile (transaction ST03N)

To find out the names of the tables accessed, use:

SQL trace – ST05

Shared SQL Area – ST04 -> Detail analysis menu -> SQL request

Work process Overview

Database process monitor – ST04 -> Oracle session

To find out the indexes involved , use the EXPLAIN function in:

SQL trace

Shared SQL Area

Database Process Monitor

Performance monitoring methods other than those based on checking statistics have drawbacks. The methods described here are all based on checking statistics.

The screen shows an example where the database request time makes up more than 95% of the overall response time.

The excessively large request time is likely to be due to expensive SQL statements. If so, an SQL trace (Transaction ST05) would be useful. Alternatively, the large request time may indicate a problem with the database server.

Depending on the workload caused by the expensive statements, other transactions may also be affected. These transactions show a large wait time and possibly also a large database request time.

Detection Roadmap – 1

1. In ST03N, go to the Transaction  profile – Sorted by Response time total.

a. Programs where CPU time > 40% (Response time – wait time)

i  Detailed analysis using ABAP trace (SE30)

b. Programs where database request time > 40% (response time – wait time)

i. SQL trace

a. Detailed analysis of SQL statement

This detection roadmap shows the procedure for the using the transaction profile, accessed through the workload monitor – ST03N.

Large database request times often indicate expensive SQL statement. Study the underlying SQL statement in detail using the SQL trace – ST05.

In the process overview, look for work processes with database actions such as sequential read, direct read, update, insert, delete and commit.

The amount of time that a work process is occupied by a report is indicated if greater than one second. If work processes are occupied for a long time by reports, the report name occurs repeatedly in the process overview, as well as the table accessed by the report. In this example, ZZSELECT is listed repeatedly in conjunction with table ZLIPS.

If work processes are occupied for a long time by reports, check for expensive SQL statements using Database process monitor – ST04; ORACLE session, and check for exclusive lock waits using the database lock monitor – DB01.

To check for expensive SQL statements and other database problems, use the database monitor. There is a database monitor for every database system.

Important statistics displayed in the monitor include:

• Reads (logical reads)
• Physical reads
• Data buffer size and quality
• Shared pool size and quality
• Ratio of user calls to recursive calls
• Ratio of reads to user calls

ST04 ; ORACLE session:

The following information is displayed

Client process (column Clnt proc)

In this column, the number before the colon is the PID of the related R/3 work process. Use the PID to identify the related R/3 work process in the work process overview – sM50.

Client system (column clnt system)

This column identifies the application server on which the related R/3 work process is running.

Status

SQL statements currently being executed on the database are marked active. Use the filter option to show only the active statements.

To find out the text of the full SQL statement, position the cursor on the relevant row and double click. From the subsequent screen, you can execute an EXPLAIN.

Database locks are set by, for example, the SQL commands select for update and update. Exclusive lock waits can suddenly reduce system performance. To detect exclusive lock waits, use the Database lock monitor – DB01.

If an exclusive lock wait occurs:

Monitor the program which is holding the lock, using for ex, the database process monitor – ST04; oracle session. Is the program executing expensive SQL statements after setting  a database lock? As rule of thumb, all expensive SQL statements must be executed before setting the first lock.

Find out the user holding the lock so it can be released. If this is not possible, delete the lock so that other users can work. This will roll back the transaction of the lock holder. The transaction may need to be repeated. For ex, the seller may need to take the order a second time.

Database locks are generally released at the end of a dialog step or by an explicit commit.

Detection Road map -2

1. Work process overview – SM50 and SM66
   1. Work process in status running.

1. i.    Action/reason: “Dir.read”, “Seq.read”, “Insert”, “Update”,”delete”, “commit”
   1. Database lock monitor – DB01
      1. Wait situations due to database locks (Excl. lock waits”)?
         1. i.    Analyse lock holder
   2. Database process monitor – ST04; Oracle session
      1. Detailed analysis: SQL statement
   3. SQL Trace – ST05
      1. Identify  and analyse the SQL statement in detail.

The SQL statement specifies a set of records in tables that it tries to locate. To find these records, the database must scan the corresponding data blocks.

All blocks that are not yet in the database buffer must be read on the disk. Logical reads or buffer that are read from disk.

A statement is efficient, if the optimizer can use an index that limits the number of blocks that must be scanned, thus reducing the number of buffer gets.

A statement is expensive if many blocks must be read to find the required records.

To access the shared SQL area – ST04

Buffer gets : This column refers to the total number of buffers accessed by the statement. To find statements with a highest database load, sort the display using this column.

Bgets/row: This column refers to the average number of buffers accessed per record retrieved. Find statements with a high number of buffer gets per record. These can normally be tuned.

Executions: This column refers to the number of times the SQL statement was executed.

The program to which the SQL statement belongs can be identified using either:

The Where-used list option in the ABAP dictionary – SE12

The system wide work process overview – SM66 in conjunction with the database process monitor – ST04; ORACLE session

ORACLE only: To display the last call point of SQL statement in an ABAP program from within the shared cursor cache, choose Go to-> Display call point in ABAP program.

Your goal is to identify SQL statements which can be tuned. To display the actual statement being executed, go to shared SQL area – Shared cursor cache by calling transaction ST04, choosing Detail analysis menu and making selection appropriate for your platform. In the Shared SQL area, double click on appropriate now.

Statements generated by an ABAP program are displayed in upper case and quotation marks. For example : SELECT “MANDT”, “VBELN”,”POSNR” FROM “LIPS” WHERE …….

Statements not generated by an ABAP program cannot be tuned in R/3. These include:

Statements not generated by an ABAP program cannot be tuned in R/3. These include:

Statements are displayed in upper case without quotation marks. They stem, for ex, from check report RSORATDB, or from SAPDBA (options such as –check, -next). If such statements generate the highest database load, schedule the DBA tool to be executed less frequently. Ex: SELECT SEGMENT_NAME, …. FROM DBA_SEGMENTS.

Statements  selecting from R/3 basis tables such as DDNTT, DDNTF, D010L, D010INF and ATAB. These statements are displayed in upper case. If such statements generate the highest database load, there may be problems with the r/3 buffers. Check the buffer for swaps.

Ex: SELECT TABNAME, TABFORM, REFNAME FROM DDNTT WHERE……

Recursive statements (with oracle): These statements are displayed in lower case. Example: select file #, block#,ts# from seg$ where type#=3

The database interface generates SQL statements that are transferred to the database, which processes the statements and responds by sending data records to the database interface. If you activate SQL trace – ST05, record of the SQL statements, the response time of the database, and the number of records is written to the SQL trace file.

One trace file is written for each R/3 instance on an application server. Therefore, you cannot run more than one SQL trace at the same time in the same R/3 instance.

A large amount of data is written to the trace file. The standard size of the SQL trace file, which is 800 KB, is too low and should be increased to 16 MB (using parameter rstr/max_diskspace = 16 384 000).

Note: the network time contributes to the response time. Therefore, network problems between the application server and the database server are detected by an SQL trace.

In R/3 transaction ST05, allows you to activate and view SQL, enqueue, RFC, and buffer traces.

If the SQL trace was activated, to view the trace results, choose list trace. A screen is displayed like the one shown above, indicating the:

Time and duration of the respective database operation

Table accessed

SQL statement used

The lines with FETCH are part of the SQL statement in the previous row. For each FETCH, the number of records transferred between application and database servers as a result of the SQL statement are indicated in Column Rec.

To find out which fields and indexes exist for the table accessed, choose DDIC info.

To find out which index has been used  by the database optimizer for the SQL, choose Explain SQL.

The where-used list helps you to find expensive ABAP statements for a specific table. You may, for ex, learn that a specific table is associated with performance problems by looking at the work process overview – SM50, statistical records monitor – STAD, or SQL trace – ST05.

If a table is used in many programs, the where used list may not be useful.

To obtain where used list:

Call the ABAP dictionary with SE12

Enter the name of table

Choose utilities -> where used list.

To view the program lines of a specific program displayed, double click the program name.

In the exercise that follows, use all of the analysis tools discussed in this unit to find expensive SQL statements.

You can only detect expensive SQL statements using the work process overview during the running of the transaction using the SQL statement.

Detailed analysis and tuning

Distinguish between two types of expensive SQL statements:

Type I : the statement scans many data blocks in the database and is expensive because many records are transferred to the ABAP program. Database performance is optional.

Type II: The statement scans many data blocks in the database but transfers only few records to the ABAP program. Database performance is not optimal – For example, due to an inefficient search strategy.

Analyzing the two types of SQL statements using SQL traces – ST05 reveals:

For type I: Average duration of < 5 ms per record or < 100 ms per FETCH. Data are transferred with optimal performance.

For type II: FETCH duration is more than 500 ms.

If you look at the Shared SQL area – sT04; detail analysis menu; SQL request for the two types of SQL statements, you find:

For type I, bufgets per record < 5. This is the optimal relation between the number of records processed and the number of data blocks scanned.

For type II, bufgets per record > 5. this non-optimal relation between the number of records processed and the number of data blocks scanned is caused by an inefficient search strategy.

A poorly qualified SQL statement is one which does not use an index correctly to access data. To identify poorly qualified SQL statements, in the Shared SQL area – sT04; detail analysis menu, look  for expensive statements with a high number of bufgets per record.

In general, using indexes is recommended because they make data access more efficient.

Statements are regarded as poorly qualified if:

No appropriate index is associated with the table being accessed.

An incorrect index is being used.

An index is being used but a full table scan is more effective (For ex, for small tables or where a large number of records are retrieved)

Note: do not change the standard R/3 index design unless this is recommended in an SAP note.

To find out whether an SQL statement uses an index to access the database, use the EXPLAIN function on the SQL statement. EXPLAIN can be accessed from any of the following:

SQL trace – ST05

Database process monitor – ST04;oracle session

Shared SQL area – ST04;Detailed analysis menu.

After choosing explain, to find out the index structure or the structure of the table and all associated indexes, double click on the index or table name. This also reveals information about the statistics used by the cost-based optimizer, such as when the statistics were last refreshed.

For example, a statement is expensive if an index is missing, thus making it necessary to use to full table scan.

Even an index range scan can be expensive if the index is not selective or not  utilized properly.

Using explain function tells you which techniques are used by the database when executing an SQL statement. For ex:

When using an index range scan , the database retrieves a number of records using an index to limit the results before going to the data pages. This may not make access more efficient, for example, if only non-selective columns are evaluated by the index, or if the wrong index is used.

When using an index unique scan, the database retrieves a single row from an index. This access method is very efficient.

When using full table scan, the database retrieves all rows from the table to build the set of results. This is normally inefficient, unless, for ex, table is small or the application genuinely needs all the rows in the table.

When using concatenation, the database makes a union of a set of rows retrieved for the query. For OR / IN statements, concatenation normally makes access more efficient.

When using a sort, the database sorts the data before returning it.

When the database uses an index to retrieve data, explain tells you the index name. this helps you to recognize whether the database is choosing the wrong index.

SAP Workload Analysis - Chapter 3 Database Locks and R/3 Enqueue

In the work process overview – SM50, you can see that session B is not responding during a direct read for table NRIV. R/3 work process 405 has sent a SELECT SINGLE for table NRIV to the database and is now waiting for the database to return the requested data.

In monitor for database locks  – DB01, you can see why there is no response to the database request. Session B, which is run by WP 405, tries to create a lock on table NRIV, which is already locked by the R/3 work process 494. In the work process overview, you can see that work process 494 is processing session A.

To resolve the lock situation, session A must either release the lock or be cancelled.

The waiting session B causes SAP work process 405 to be blocked, which may cause wait situations for other users.

Situations like the one described are typically not caused by break points, but by lengthy processing of ABAP statements or SQL statements after they set a database lock. The lock on the database is released after the dialog step of session A is completed, and triggers a COMMIT or ROLLBACK.

Using R/3 enqueues and database locks.

Use enqueues to:

Explicitly exclude concurrent dialog access to data, thus preventing logical inconsistencies

A program using only read access does not need to use enqueues: Isolation levels can be used to achieve read consistency if necessary.

Database locks:

Are used in some special cases during the update phase

Should not be used in a dialog program

Exception: number ranges (SELECT single for update)

Locking and performance

Enqueues and database locks on central objects can serialize running transactions.

Avoid serialization:

In general, perform locks only when necessary

Keep locking times as short as possible:

For example, use array operations instead of single record insert/updates

For example, pre-aggregate data to enable one update instead of many

For number ranges: Fewer requirements cause less serialization

For available-to-promise quantities (ATP): additional logic can help to reduce locking times, especially over dialog steps.

For many enqueues, use bundling in a local enqueue container.

Use these two screens to detect high CPU usage on the database server.

Screen A, the operating system monitor – ST06, indicates a CPU utilization of 90% for user processes.

Screen B, shows the top CPU processes (ST06; Detailed analysis menu -> Top CPU processes). This screen reveals that 85.2% of the 2 CPU’s available are being used by the database process with PID 142.

High CPU usage of database processes for long periods typically indicates expensive SQL statements.

The database process monitor – ST04; oracle session can be used to analyze high CPU usage on the database server caused by expensive SQL statements. The Database process monitor enables you to display:

Database processes and the associated client processes (typically R/3 work processes).

The SQL statement currently being processed. To reveal the statement, dbl click the oracle process name. This is useful for statements that run for at least several seconds – short-running statements that are not expensive disappear too fast.

Screen A, showing the database process monitor, indicates that database process 296 is associated with the client process 494 on machine TWDFMX06.

After dbl clicking the line containing this oracle process, the database process monitor displays the expensive select on table ZLIPS: this statement is expensive because ZLIPS has many records and where clause is not supported by a suitable index. The EXPLAIN function for this SQL statement would indicate that a full table scan is being used.

Screen B, showing the work process overview – SM50 for application server TWDFMX06, identifies process 494 as an R/3 work process that is currently processing program ZZSELECT.

SAP Workload Analysis - Chapter 6 R3 Table Buffering

R/3 uses several buffers that are local to the application server and hold primarily run-time data:

R/3 repository buffers

Table buffers

Program buffers

R/3 GUI buffers

R/3 roll and paging buffers

R/3 Calendar buffers

Why table buffers?

By specifying that a table is to be buffered, you can reduce the database accesses and thus improve performance.

The difference in the time required for local R/3 buffer accesses and that required for database accesses is significant and affects:

Database server load (CPU usage, size of database buffer required)

Dispatch time for R/3 dialog steps (avoids blocking R/3 work process)

Table buffering types

There are three types of table buffering:

Full buffering (“resident buffering”) : 100% of a table’s content is loaded into the buffer on the first access to any data from the table.

Generic buffering: a number of generic key fields (first n key fields) is specified when setting this option for a table. When accessing any data, all data records whose first n key fields are the same as those in the data accessed are loaded into the buffer.

A typical case of generic buffering is client-independent buffering, where the client name is the first key field. If you specify resident buffering for a client – dependent table, the ABAP dictionary automatically uses generic buffering with one key field.

Single record buffering (“partial buffering”): only single records are read from the database and loaded into the buffer.

All three table buffering types can be seen as special variants of generic buffering:

For full buffering, n = 0

For generic buffering, 0

For single record buffering, n = all key fields.

Buffer Synchronization

Two things happen when a buffered table is updated:

The update is executed on the database table.

The buffer of the local R/3 instance on application server A is either updated or contents are marked as invalid and reloaded on the next access.

An R/3 system landscape consisting of more than one R/3 instance:  one R/3 instance on application server A and one R/3 instance on application server B.

The buffer of the non-local R/3 instance (on application server B) is not updated immediately.

The updating statement is executed by the R/3 database interface (DBIF), which inserts a record into the table DDLOG indicating the change to, for example, table T001

There are two profile parameters which control synchronization between buffers and the database:

Rdisp/bufrefmode

Possible values of this parameter are:

-       sendoff, exeauto: used for a central system – an R/3 system with one R/3 instance.

-       Sendon,. Exeauto: used for a distributed system.

Rdisp/bufreftime

-       used to indicate the time interval in seconds.

A non-local R/3 instance (such as application server B in the diagram) performs synchronization every one or two minutes (depending on how the relevant profile parameter is set). That is , the instance reads database table DDLOG to check whether the tables in the instance buffer have been changed in another instance. If there have been changes, the instance invalidates some or all of the buffered tables that are affected by the changes.

In time period between synchronizations, users read the old data. After data is invalidated, on the next access to that data, the data is updated from the database.

Fully buffered tables:               Any change invalidates the buffered table.

Generally buffered tables:       Changes in work area mode invalidate data with the

same generic field keys.

Single record buffered tables                          Changes in work area mode invalidate one buffered record.

In the work area mode, only one line of a table (the work area) is used to transfer data. This occurs, for occurs, for ex, when using the ABAP command: UPDATE (where was defined using command tables ).

Changes not made in work area mode invalidate the whole table. This occurs, for ex, when using the ABAP command: UPDATE where =

Transaction SE13 (Technical settings -> change) allows you to select the type of buffering (or no buffering) for a specific table. The most important question is whether a table should be buffered at all.

A table should only be buffered if the table is read frequently and if it is acceptable from an application or business point of view that changes to the data in the table are not immediately visible on all other R/3 instances.

In addition to full, partial, and general buffering, another buffering type, “installation-dependent”, is sometimes used that enables a table to be initially not buffered, but later set to one of the above buffering types in the running system. This buffering type is used if the table can be buffered from an application point of view, but for ex, the size of the table and the amount of main memory (hence the space for buffering) vary with the R/3 installation.

Normally, the programmer has set a buffering type, which can be revealed in the access profile for the table.

SQL statements by-passing the buffer

SQL statements that cannot be satisfied from the buffer, bypass the buffer and access the database.

Statements that bypass any type of buffering should be avoided when programming with the buffered tables in order to optimize performance. An exception is maintenance transactions on buffered tables, which should use an explicit SELECT…..BYPASSING BUFFER to ensure the retrieval of the most-up-to-date data directly from the database.

Which tables should be buffered?

This slide shows some of the criteria that must be met in addition to the technical criteria, in order to make a table eligible for buffering.

The following rule of thumb can be also used to determine tables that are eligible for buffering:

For a table size of less than 1 MB, there should be no more than 1 % changes per read, and there should be at least 300 sequential reads/day.

For a table size of between 1 and 5 MB, there should be no more than 0.1% changes per read and there should be at least 1000 sequential reads/day.

Monitoring R/3 table buffering

Roadmap 1

This roadmap shows you how to leads you to find problems with table buffering problems:

1) Display the Workload Monitor (Transaction ST03) for task types Dialog and Update

2) For both respective task types, choose Transaction profile and sort according to response time

3) For the programs or transactions that have a large response time, look at the adjacent columns to find out whether they have a lengthy CPU time or a lengthy database time.

4) For transactions with database time > 40% (response time – wait time):

Analyze single records by Viewing statistical records using Transaction STAD.

5) To analyze statistical records with a lengthy database time, double-click the appropriate line.

6) To find out whether a buffer reload occurred in the corresponding dialog step, choose ‘%_and

check for the note Tables were saved in the table buffer.

7) If this note occurs for many statistical records, it indicates frequent buffer reloads.

The table buffer should be analyzed using the Table Call Statistics monitor (Transaction ST10).

To call transaction Table Call Statistics, use Transaction ST10  or, from the R/3 initial screen choose:

Tools -> Adminsitration -> Monitor -> Performance -> Setup/buffers -> Calls.

This roadmap helps you to decide which tables should be buffered.

1) Cll Transaction ST10, Select all tables since startup,  and this server. Then choose Show

Statistics. The screen Performance analysis:Table call statistics is displayed, and contains a list

of tables and the related statistics. To sort the list by the figures in a particular column, place the

cursor anywhere in the column and choose Sort.

2) Sort the list by ,Buffer size (bytes) .

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

3) Choose Next view and sort the list by Buffer size [bytes].

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

4) Sort the list by column Rows affected under DB activity

For the tables at the top of the list, consider the buffering rules and decide whether these tables

should be unbuffered.

5) Sort the list by column Total under ABAP processor requests.

For the unbuffered tables at the top of the list, consider the buffering rules and decide whether

these tables should be buffered.

SAP Central User Administration (CUA)

The procedure for Central user administration configuration in a landscape:
1) Create Logical systems to all clients for the landscape using BD54 or SALE ascomfortable.
2) Attach Logical system to clients using Same.
3) Create RFC connection to relevant systems with the same name as logical system name .
If you Logical system name is SIDCLNT100 for dev then create RFC connection to DEV with same name SIDCLNT100.
4) Let us suppose you Central system: DEVCLNT100Child system: QUACLNT200
5) Create user CUA_DEV_100 in devclnt100 system
4. Create user CUA_QUA_200 in quaclnt200 system.
Create RFC’s to child systems from central and central to child.
5) Now logon to central system and execute tcode scua to configure cua.
Enter the name of the distribution model: CUA
Press create
Enter ALL Child system RFC’s
Save your entries now result screen will appear
If you expand the nodes for
the individual systems, you normally see the following messages for
each system: .ALE distribution model was saved,. .Central User
Administration activated,. and .Text comparison was started.. If
problem messages are displayed here, follow the procedure in SAP
Note 333441:
6) Setting the Parameters for Field Distribution Enter Tcode SCUM in central system following screen will appearNow maintain your filed distribution and save it.You can use transaction SUCOMP to administer company address data.You can use transaction SCUG in the central system to perform thesynchronization activities between the central system and the childsystems by selecting your child system on the initial screen of transactionSCUG and then choosing Synchronize Company Addresses in the Central System
After you have synchronized the company addresses, you can transfer theusers from the newly connected child systems to central administration.
This is done, as with the synchronization of the company addresses, using
transaction SCUG in the central system. To do this, on the initial screen of
transaction SCUG, select your child system and choose the Copy Users to
the Central System button.
Use
You can use the report RSCCUSND from the central system of Central User Administration (CUA) to synchronize the master data of selected users with a child system of the CUA. The report sends the master data (including role and profile assignments) to a child system of the CUA.
If master data exists in the child system for the user sent, it is overwritten.
Procedure…
1. Start report RSCCUSND (for example, using transaction SA38).
2. In the Receiving System field, specify the child system to which you want to send the user data.
3. You can use the fields User and User Group to restrict the number of users.
4. Specify the data that you want to distribute under Distribution Options.
5. Choose Execute.

Oracle SAP Administration

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