Performance Overview 
This is the main screen in the SAP/Oracle Database Monitor. It gives you an overview of the performance of your Oracle database.
You start the database monitor from the DBA Cockpit by choosing . You see an overview of database performance.
You can right-click a field and choose:
Help for more information on the meaning of the field
Details to see the values for each instance if you are running an Oracle Real Application Cluster (RAC)
If you are running RAC, you choose in DB Instances whether to display overview information for one RAC instance or for the total of all RAC instances.
Note
The appearance of a yellow or red light indicates that the difference in percent for the value of at least one instance from the average of all instances exceeds a certain limit. The limit values are maintained in table ST04N_LIM.
The fields are grouped as follows:
General information, data source is V$INSTANCE
Field |
Description |
|---|---|
DB instance |
Name of the current database instance This is the SAP-SID in non-RAC environments. |
DB node |
Host name of the selected DB node This is the database server in non-RAC environments. |
DB release |
Release of the current database |
Day, time |
Current day and time |
Start up at |
Date and time when the current database instance started |
Sec. since start |
Seconds since start of the current database instance |
Sec. btw. snaps. |
Seconds between snapshots |
Data buffer
Field |
Description |
|---|---|
Size |
Size of the data buffer in KB
|
Quality |
Data buffer quality, calculated as follows: 100% – ((physicalreads – physicalreads_direct – physicalreads_directlob) / (sess_logicalreads – physicalreads_direct – physicalreads_directlob)) Non-RAC or RAC detail: data buffer quality of the current instance RAC total: average of quality for all instance-related data buffer Data source: V$SYSSTAT |
Size default pool |
Size of the default buffer pool in KB, calculated as follows:
Data source: V$PARAMETER |
Size keep pool |
Size of the keep buffer pool in KB, calculated as follows:
Data source: V$PARAMETER |
Size others |
Sum of the sizes of all other buffer pools in KB, calculated as follows:
Data source: V$PARAMETER |
Logical reads |
Number of logical read operations
|
Physical reads |
Number of physical read operations
|
Physical writes |
Number of physical write operations
|
Buffer busy waits |
Number of buffer busy wait situations
|
Buffer wait times (s) |
Sum of buffer busy wait times
|
Shared pool
Field |
Description |
|---|---|
Size (kB) |
Shared pool size in KB
|
DD-cache quality (%) |
Data dictionary cache quality as percentage, calculated as follows: 100% – (totalget_misses / totalgets)
|
SQL area getratio (%) |
Ratio of gethits to gets as a percentage, calculated as follows: sum (gethits) / sum (gets) x 100
|
SQL area pinratio (%) |
Ratio of pinhits to pins as a percentage, calculated as follows: sum (pinhits) / sum (pins) x 100
|
SQLA Reloads/pins (%) |
Ratio of reloads to pins as a percentage, calculated as follows: sum (reloads) / sum (pins) x 100
|
Log buffer
Field |
Description |
|---|---|
Size (kB) |
Size of the redo log buffer in KB
|
Entries |
Number of redo log buffer entries
|
Allocation retries |
Number of redo buffer allocation retries
|
Alloc fault rate (%) |
Redo buffer allocation retries as a percentage of redo entries
|
Redo log wait (s) |
Redo log wait in seconds
|
Log files (in use) |
Number of active log files
|
Calls
Field |
Description |
|---|---|
User calls |
Number of user calls
|
User commits |
Number of user commits
|
User rollbacks |
Number of user rollbacks
|
Time Statistics
Field |
Description |
|---|---|
Busy wait time (s) |
Busy wait time in seconds, calculated as the sum of the time waited for all non-idle events.
|
CPU time session (s) |
CPU time session in seconds, calculated as sum of CPU time used by this session
|
Time/User call (ms) |
Time for each user call in milliseconds, calculated as follows: (busy wait time + CPU time) / user calls
|
Sessions busy (%) |
Busy sessions as a percentage, calculated as follows: (busy wait time + CPU time) / total wait time
|
CPU usage (%) |
CPU usage as a percentage, calculated as follows: CPU time / (elapsed time x CPU count)
|
Number of CPUs |
Number of CPUs
|
Redo Logging
Field |
Description |
|---|---|
Redo writes |
Number of redo log writes
|
OS blocks written |
Number of operating system redo blocks written
|
Latching time (s) |
Redo writer latching time in seconds Non-RAC or RAC detail: redo writer latching time for the current instance RAC total: total latching time for all instances Data source: V$SYSSTAT |
Redo write time (s) |
Redo write time in seconds
|
MB written |
Number of MB written
|
Table scans and fetches
Field |
Description |
|---|---|
Short table scans |
Number of short table scans
|
Long table scans |
Number of long table scans
|
Table fetch by rowid |
Number of table fetches by row ID
|
Fetch by contin. row |
Number of fetches by continued row
|
Sorts
Field |
Description |
|---|---|
Sorts (memory) |
Number of sorts in memory
|
Sorts (disk) |
Number of sorts in disk
|
Sorts (rows) |
Number of sorted rows
|
WA exec. optim. mode |
Number of work area executions in optimal mode
|
WA exec. one pass m. |
Number of work area executions in one-pass mode
|
WA exec. multipass m. |
Number of work area executions below the one-pass memory requirement
|
Instance Efficiency
Field |
Description |
|---|---|
Soft parse ratio |
Soft parse ratio is calculated as follows: 1 – (parse count hard / parse count total) This shows whether there are many hard parses on the system. The ratio should be compared to the raw statistics to ensure accuracy. For example a soft parse ratio of 0.2 typically indicates a high hard parse rate. However, if the total number of parses is low, you can disregard the ratio.
|
In-memory sort ratio |
In-memory sort ratio is calculated as follows: sorts in memory / (sorts in memory + sorts on disk) This shows the proportion of sorts that are performed in memory. Optimally, in an operational online transaction processing (OLTP) system, most sorts are small and can be performed solely as in-memory sorts.
|
Parse to exec. ratio |
Parse to execute ratio is calculated as follows: 1 – (parse count total / execute count) In an operational environment, optimally a SQL statement should be parsed once and executed many times. Therefore an ideal value is close to 1.
|
Parse CPU to total |
Parse-CPU-to-total ratio is calculated as follows: 1 – (parse time CPU / CPU used by this session) This shows how much of the total CPU time used was spent on activities other than parsing. When this ratio is low, the system is performing too many parses.
|
PTime CPU / PT elps |
Parse time CPU / parse time elapsed ratio is calculated as follows: parse time CPU / parse time elapsed This can often indicate latch contention. The ratio indicates whether the time spent parsing is allocated to CPU cycles (that is, productive work) or whether the time spent parsing was not spent on CPU cycles. Time spent parsing not on CPU cycles usually indicates that the time was spent sleeping due to latch contention.
|