Professional Documents
Culture Documents
Oracle St04
Oracle St04
From the R/3 main screen, choose: Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity
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:
SORT_AREA_SIZE (Oracle)
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:
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)
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:
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:
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:
DB_BLOCK_BUFFERS (Oracle)
• 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:
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.
2. From the R/3 main screen, choose: Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity
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:
Data file activity has an important effect on performance if your database is very
large and is used intensively.
• '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'.
• 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.
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.
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.
• Incorrect coding of SELECT SQL statements may also result in too many full table scans.
1. From the R/3 main screen, choose Tools → Administration → Computing Center →
Management System → Control → Performance Menu → Database → Activity.
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.
From the R/3 main screen, choose Tools → Administration → Monitor → System
monitoring → Process overview.
Alternatively, use transaction code SM50 ( Work Process Load Monitor: Overview).
7. Compare theses tables with those that appear in the list of tables with missing indexes.
Choose Database indexes in the Alert Monitor.
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.