1.

From the R/3 main screen, choose: Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity

Alternatively, use transaction code ST04.

Sort by the column Buffer Gets. Check for statements that are executed very often with a
low number of Bufgets/record. These statements should be analyzed.

Sorts (Oracle)
This section shows the total number of sort operations along with the number of sort operations
performed in memory or on disk.

Sort operations take place if you use ORDER BY, GROUP BY or SORT MERGE JOIN SQL
statements. Sorting is also done during index creation. Sorting can be a very expensive process
and should be avoided whenever possible. It is generally better for performance if sorting is done
in memory than on disk.

See also:

Monitoring Sorting (Oracle)

SORT_AREA_SIZE (Oracle)

Time Statistics (Oracle)

An Oracle shadow process either runs actively on the PC (it uses CPU time) or else it waits. Wait
situations can be divided into cases where the Oracle process is waiting because there is
currently nothing for it to do ('idle waits') or where the Oracle process wants to run but first has to
wait for a resource that is not yet available ('busy waits'). 'Total waits time' describes the sum of
'idle wait time' and 'busy waits time'.

Sessions busy is defined as (CPU time + busy wait time) / (CPU time + total wait time). CPU
usage is defined as CPU time / Elapsed time. Time/ User call is defined as (CPU time + busy wait
time) / User calls.

Note that the three ratios show mean values since database startup. If you want to determine the
actual load at its peak, you should use the monitor's Reset -function.

See also:

Table Scans/Table Fetch (Oracle)

This section of the monitor shows how database data is accessed.

A full table scan occurs when Oracle must read all data blocks of a table from disk. When the
amount of data being read is small (short tables), this type of access is preferable. When the
amount of data being read is large (long tables), index access may be preferable.

When data from a table is accessed via an index, Oracle performs the actual lookup using the
rowID of the block holding the data. Access via this kind of index is normally very fast.

If a data record does not fit in one Oracle data block (whose size is determined by
db_block_size ( DB_BLOCK_SIZE (Oracle))), it must be continued in another block (data
chaining).

See also:
Table Scans: Problem Analysis (Oracle)

Monitoring Table Access Methods (Oracle)

Redo Log Buffer (Oracle)

This buffer (memory area in the SGA) holds information about changes made to data and objects
in the database. The Oracle background process LGWR writes entries from the redo log buffer to
the on-line redo log files on the disk.

Allocation fault rate shows the ratio of times Oracle attempted to find space available space in the
redo log buffer and was unsuccessful. When this happens, the user process must wait until space
in the buffer is free.

See also:

Monitoring the Redo Log Buffer (Oracle)

LOG_BUFFER (Oracle)

Calls (Oracle)
This section of the monitor shows the type and number of database accesses made on behalf of
Oracle processes. The value for rollbacks indicates the number of times an Oracle process failed
to complete the commit of an operation.

By monitoring database accesses, you can control the system load, separated by both user and
internal operations.

See also:

Monitoring Calls (Oracle)

Data Buffer (Oracle)

Data buffers have the following functions:

Table: Data buffer and their functions

Buffer Function
Data buffer holds Oracle blocks in shared memory (System Global
Area or SGA)
Data buffer quality measures the number of times that a data block requested
cache hit ratio (CHR) by an Oracle process is found to be already in memory.
Physical reads and Information is also provided on the number of physical
physical writes input/output (I/O) operations performed on behalf of
Oracle
Busy waits the number of times a process had to wait to acquire a
data buffer in a compatible state

See also:

Monitoring the Data Buffer (Oracle)

Buffer Busy Waits (Oracle)

DB_BLOCK_BUFFERS (Oracle)

Shared Pool (Oracle)

The shared pool (shared memory area in the SGA) is used by Oracle to hold several key memory
structures. Most important among these are the data dictionary cache and the shared SQL area.

The data dictionary cache contains information on Oracle objects e.g.

• naming

• definition

• access

It is regularly referenced by Oracle itself, as well as some application programs and database
users.

The shared SQL area, also known as a "shared cursor cache", is a memory area which contains
the parsed representation of SQL statements. Since a certain amount of system overhead is
needed to parse an SQL statement, the ability to reuse statements already in memory can add a
significant performance advantage.

See also:

Detailed Analysis (Oracle)

If the Alert Monitor indicates that the database has potential performance problems, you can
analyze the database in more detail.
Use the analysis functions available from the main screen of the Database Monitor Database
Performance Analysis ( SAP/Oracle Database Monitor: Main Screen).

All these functions provide numeric information on the database. A lot of the information can also
be displayed graphically. You can access the most important analysis functions by Detail analysis
menu. You will find a list below of some of the diverse analysis options - these are options which,
from SAP’s experience, are frequently used by customers.

Not all the analyses offered by the monitors are included in the list. Functions
that you do not normally need are not listed. These functions are mainly used by
the SAP Service & Support to analyze your R/3 and database system.

Table: Analysis options

Analysis For detailed information, see...

File activity statistics File System Requests (Oracle)
Overview of wait situations Wait Events (Oracle)
Wait situations in the data buffer (buffer Buffer Busy Waits (Oracle)
busy waits)
Data dictionary cache statistics Dictionary Buffer (Oracle)
Performance statistics per application server SAP Client (Oracle)
Resource consumption per Oracle shadow Oracle Sessions
process
Resource consumption by SQL statements Monitoring the Shared SQL Area (Oracle)
Exclusive lockwaits Exclusive Lockwaits (Oracle)
ALERT file Database Message Log (Oracle)
Oracle statistics tables Display V$ Tables (Oracle)
Overview of database performance Historical Database Performance Statistics
(Oracle)
Monitoring datasets State on Disk (Oracle)
Changes to init.ora parameters Parameter Changes (Oracle)
Consistency checks Consistency Checks
Missing indexes Missing Indexes
Type of table scan Table Scans: Problem Analysis (Oracle)
Checking tablespaces Checking for Full Tablespaces (Oracle)
Monitoring storage space Storage Management Errors (Oracle)
Free space analysis Checking for Freespace Problems (Oracle)
Displaying storage parameters Checking Storage Parameters (Oracle)
Extent analysis Extent Analysis (Oracle)
MAXEXTENTS values Problems with Maximum Number of Extents
(Oracle)
Display of Oracle table statistics for the cost- Display of Oracle table statistics
based optimizer
File System Requests (Oracle)
To display the File System Requests:

2. From the R/3 main screen, choose: Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity

Alternatively, use transaction code ST04.

3. Choose Detail analysis menu → Filesystem requests.

This screen displays statistics on physical accesses to database files. The display
includes duration for block reads and writes measured in milliseconds. To display these
time values, the init<SID>.ora parameter timed_statistics ( TIMED_STATISTICS
(Oracle)) must be set to true .

You can minimize the time needed for reading from or writing to a data file:

1. Identify the frequently used data files

2. Ensure that frequently used files are on separate disks so that I/O requests for objects do
not directly compete with each other.

Data file activity has an important effect on performance if your database is very
large and is used intensively.

Wait Events (Oracle)

'Idle wait' situations are:

• 'SQL*Net message from client' (the process is waiting for an SQL statement from the
client, for example, the R/3 work process),

• 'rdbms ipc message' (the process is waiting for a statement from the RDBMS),

• 'dispatcher timer', 'virtual circuit status', 'pmon timer', 'smon timer', 'WMON goes to sleep',
'Null event'.

'Busy wait' situations are:

• Wait situation for physical I/O: 'db file sequential read', 'db file parallel write', 'log file
sequential read', etc.:
 • ‘enqueue': wait situations due to exclusive database locks that can be examined using
the 'Exclusive Lockwaits' screen.

• 'buffer busy waits': wait situations in the Oracle buffers: you can find details on this on the
screen under 'Buffer busy waits'.

• 'Log file switch (archiving needed)': problems with the log switch or with checkpointing.
Look in the database message log for entries such as 'Cannot allocate log, archival
required' or 'All online logs needed archiving'.

• 'SQL*Net more data to client' and 'SQL*Net more data from client': The Oracle process is
waiting because data cannot be transferred quickly enough from, for example, the client.
This wait situation indicates problems with the SQL*Net-Installation or with the network.

SAP Client (Oracle)

You can analyze the workload of the database for each application server in the R/3
System. This helps you find out which application servers put the highest workload on the
database.

The fields on the statistics screen contain the following information:

Table: Information on the statistics screen

Field Information
Current Open Cursors Number of open cursors or context areas occupied on the
application server by user processes
User calls Number of database queries from users
Recursive calls Number of internal data dictionary queries
User commits Number of user transactions performed
User rollbacks Number of user transactions terminated
Parse count Number of "parsed" SQL statements
Database block gets Number of logical read operations required to call the current
version of the required data
Consistent gets Number of logical read operations required to call a
consistent version of the required data
Physical reads/writes Number of physical read and write operations performed in
the database
Redo blocks written Number of blocks written by the log writer in the redo log
Long table scans, rows gotten Number of full table scans of tables larger than four blocks
and number of data records read sequentially
Table fetch by row ID Number of table data records accessed directly
Table fetch by continued row Number of chained data records that were read
Table Scans: Problem Analysis (Oracle)
The Table Scans entry that appears in the Database Alert Monitor and the Database
Monitor shows the number of sequential read operations on tables per day. If the number of
sequential read operations per day is very high, you should perform further analyses. Sequential
data access is generally not very efficient, which is why you should try to minimize the number of
full table scans.

Causes

• Full table scans are often caused by missing table indexes. You can display tables
with missing indexes by choosing Database indexes in the Database Alert Monitor.

See also: Missing Indexes

• Incorrect coding of SELECT SQL statements may also result in too many full table scans.

To identify tables affected by sequential read operations:

1. From the R/3 main screen, choose Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity.

Alternatively, use transaction code ST04.

2. Choose Goto → Exceptions → Alert Monitor.

You reach the Database Alert Monitor.

3. Choose Table Scans long tables to display the applications servers and processes
responsible for the table scans.

If the processes belong to an Oracle user (for example, SYS), the table scans are actually
caused by the database. Processes belonging to the SAP user SAPR3 are important for
further analysis.

4. Log on to the application server that is causing the table scans.

5. Use the Process Monitor to identify the user and report causing the table scans.

From the R/3 main screen, choose Tools → Administration → Monitor → System
monitoring → Process overview.

Alternatively, use transaction code SM50 ( Work Process Load Monitor: Overview).

6. Find out which tables are used by this report.

There are two ways of doing this:

 - Start the report with an activated SQL trace

- Analyze the program.

7. Compare theses tables with those that appear in the list of tables with missing indexes.
Choose Database indexes in the Alert Monitor.

See also: Missing Indexes

If none of these tables have indexes missing, the table scans are probably caused by an
SQL statement in the report that has not been optimized.