This chart shows SQL statements performing the most physical reads.
Improving SQL performance is usually the most effective way for improving application performance. In identifying statements with the most potential to improve performance you should probably consider the statements in the highest I/O demands. In other words, consider statements with the highest number of read requests that resulted in access to datafiles on disk.
Another factor worth considering is the frequency at which the statement is executed. A statement with the a high I/O level may only be executed once a day, far less than another statement with a lower I/O level that is executed many thousand times a day.
There are numerous reasons why a query would results in excessive disk reads; for example, a full table scan is being performed.
To help further diagnose the cause of the I/O there are number of drilldown charts available, including:
Further investigation on how to best tune a particular SQL statement can be done by selecting any one of SQL statements listed and using the SQL Analyze tool.
This chart includes the following data items:
This chart displays the full SQL text, which is truncated in some of the TOP SQL charts.
The SQL shown in some of the TOP SQL charts is a truncated value, because the truncated value is all that is available from V$SQLAREA. To get the full SQL text, the
V$SQLTEXT_WITH_NEWLINES must be queried to piece together the segments of the query.
For performance, this chart only displays when it is needed to display the full SQL text.
This chart includes the following data items:
This chart shows the user our best estimate of overall response time using statistics
that are available from the database. Response time is defined here as overall
wait time plus overall CPU time consumed by all sessions within the database, divided
by the number of commits plus rollbacks to give a per-transaction value. The per-transaction value may display as 0 if the database is being accessed in a read-only mode or if TIMED_STATISTICS is not set to TRUE.
When monitoring a read-only database, a better measure of response time might
be based on a per-execute basis, the average length of time per SQL statement execution. To
view this statistic, look at the Elapsed time per execute chart.
Further investigation into the individiual parts of response time, CPU and Wait can be found via
a drilldown to Wait or CPU Bound .
This chart includes the following data items:
This chart shows the number of transactions that were committed and rolled back during the sample period, as well as SQL execution counts. This is a good throughput overview.
This chart includes the following data items:
This chart shows a breakdown of per transaction response time on a per user basis.
CPU and Wait times are summed across all sessions for each user. This chart will be helpful for monitoring response time for applications that segregrate functionality through different users.
This chart includes the following data items:
This chart shows throughput or load statistics on a per user basis. The statistics are
summed across all sessions for the user.
This chart includes the following data items:
This chart is a list of events across the instance, sorted by the summation of wait time for
each event type.
This list will allow the user to quickly identify which event the instance is waiting for the most. Each event type is affected by different parameters and conditions. Further drilldown is accomplished by selecting the particular wait event of interest. Some of the wait events have specific drilldown charts to help diagnose the reason for the wait.
There are also generic drilldowns, available for all wait events. To determine how many sessions are currently waiting for a specific event, use the
Sessions Waiting for this Event Chart. Similarly to view the SQL statements that are currently waiting for the event, use the SQL Statements waiting for this event Chart. This will lead you quickly to the SQL statements that are experiencing the wait and help you determine the impact this wait is having on the application.
This chart includes the following data items:
This chart shows the number of waits instance-wide that occurred during the sample period. Only events with a non-zero count will be displayed. Along with the count of waits, the number of timeouts is also displayed.
The count of waits is not as important as the actual time spent waiting. A session may request a resource and issue a wait, yet have the request immediately granted. The wait count will be incremented, although no wait time actually occurred.
This chart includes the following data items:
This chart is related to the buffer busy event. Determining the types of blocks (buffers) the database is waiting on will dictate the possible solutions to reducing the contention on those blocks. The three types of blocks we are interested in are Segment Headers Blocks, Data Blocks and Free List Blocks.
This section briefly describes the three block types.
Segment Header Block waits:
Problem: Possibly not enough transaction free lists due to a high number of inserts for the table, and therefore access to the transaction free list becomes a bottleneck.
Solution: Add more free list groups. It is also possible to add more free list groups to get around any limitations of a small block size constraining the number of free lists, even in exclusive mode.
Problem: High Water Mark (HWM) for the table may be constantly increased since the table is growing and running out of blocks for new inserts on the free list. The default value for bumping up the HWM is 5, which may be too low on a busy system or for the average insert size.
Solution: The HWM value can be increased up to 255 through the init.ora parameter _BUMP_HIGHWATER_MARK_COUNT. Note: this parameter will determine how many blocks to allocate per free list when bumping up the HWM. Therefore, this can grow the table very large if the number of free lists is also high. For example, if we have 100 free lists and set _BUMP_HIGHWATER_MARK_COUNT=100, this means that 10000 blocks (potentially) are added to the extent.
Problem: Extent sizes are too small, therefore the table is constantly growing. As a rule, it is better to have a small number of very large extents than to have a large number of small extents.
Solution: Increase the size of each extent.
Data Blocks: Are used to store data (index or data).
Problem: Multiple sessions could be reading the same block from disk (this could happen for each block class). Only one session will do the read and the other sessions will be waiting for the block to end up in the buffer cache. The other sessions will be waiting on the buffer busy wait event.
Solution: The buffer cache may be too small to keep the current working set in memory. Increasing the buffer cache (db_block_buffers) can help, or using buffer pools to reduce the number of buffers an object can occupy in the buffer cache (for example, limit the number of buffers a randomly-accessed large table or a history table can occupy in the buffer cache.)
Problem: Multiple sessions are trying to access the same row in a block. This could be because there are too many rows per block (lots of small rows in a large data block).
Solution: Reduce the number of rows per block (pctfree/pctuse settings need to be changed). This is a space for time optimization. The table will use more space but the wait time for buffer busy waits will decrease.
Problem: Multiple sessions trying to insert into the same block. The reason it is the same block is that there is only one free list (or not enough free lists). There is only one head of the free list.
Solution: Adding multiple free lists to the object will increase the number of head of free lists. This distributes the contention point over the free lists, thereby reducing the number of buffer busy waits.
Freelist Blocks: Add more freelists. In case of Parallel Server make sure that each instance has its own freelist group(s).
Undo Header Blocks : Add more rollback segments (when running in Exclusive mode). Set
transactions per rollback segment to 1 (Exclusive mode).
Undo Blocks : Consider making rollback segments larger in Exclusive mode or increase number of
PCM locks (GC_ROLLBACK_LOCKS) in Parallel Server Mode only. This chart includes the following data items:
This chart is related to the buffer busy event. Determining the types of blocks (buffers) the database is waiting on will dictate the possible solutions to reducing the contention on those blocks. The three types of blocks we are interested in are Segment Headers Blocks,
Data Blocks and Free List Blocks.
This section briefly describes the three block types.
Segment Header Block waits:
Problem: Possibly not enough transaction free lists due to a high number of inserts for the table, and therefore access to the transaction free list becomes a bottleneck.
Solution: Add more free list groups. It is also possible to add more free list groups to get around any limitations of a small block size constraining the number of free lists even in exclusive mode.
Problem: High Water Mark (HWM) for the table may be constantly increased since the table is growing and running our of blocks for new inserts on the free list. The default value for bumping up the HWM is 5, which may be too low on a busy system or for the average insert size.
Solution: The HWM value can be increased up to 255 through the init.ora parameter _BUMP_HIGHWATER_MARK_COUNT. Note: this parameter will determine how many blocks to allocate per free list when bumping up the HWM. Therefore, this can grow the table very large if the number of free lists is also high. For example, if we have 100 free lists and set _BUMP_HIGHWATER_MARK_COUNT=100, this means that 10000 blocks (potentially) are added to the extent.
Data Blocks: Are used to store data (index or data).
Problem: multiple sessions could be reading the same block from disk (this could happen for each block class). Only one session will do the read and the other sessions will be waiting for the block to end up in the buffer cache. The other sessions will be waiting on the buffer busy wait event.
Solution: It could be that the buffer cache is too small to keep the current working set in memory. Increasing the buffer cache (db_block_buffers) can help or using buffer pools to reduce the number of buffers an object can occupy in the buffer cache (for example, limit the number of buffers a randomly-accessed large table or a history table can occupy in the buffer cache).
Problem: Multiple sessions are trying to access the same row in a block. This could be because there are too many rows per block (lots of small rows in a large data block).
Solution: Reduce the number of rows per block (pctfree/pctuse settings need to be changed). This is a space for time optimization. The table will use more space, but the wait time for buffer busy waits will decrease.
Problem: Multiple sessions trying to insert into the same block. The reason it is the same block is that there is only one free list (or not enough free lists). There is only one head of the free list.
Solution: Adding multiple free lists to the object will increase the number of head of free lists. This distributes the contention point over the free lists, thereby reducing the number of buffer busy waits.
Problem: High Water Mark for the table may be constantly increased since the table is growing and running our of blocks for new inserts on the free list. The default value for bumping up the HWM is 5, which may be too low on a busy system or for the average insert size.
Solution: The HWM value can be increased up to 255 through the init.ora parameter _BUMP_HIGHWATER_MARK_COUNT. Note: this parameter will determine how many blocks to allocate per free list when bumping up the HWM. Therefore, this can grow the table very large if the number of free lists is also high. For example, if we have 100 free lists and set _BUMP_HIGHWATER_MARK_COUNT=100, this means that 10000 blocks (potentially) are added to the extent.
Data Blocks: Are used to store data (index or data).
Problem: Multiple sessions could be reading the same block from disk (this could happen for each block class). Only one session will do the read and the other sessions will be waiting for the block to end up in the buffer cache. The other sessions will be waiting on the buffer busy wait event.
Solution: It could be that the buffer cache is too small to keep the current working set in memory. Increasing the buffer cache (db_block_buffers) can help or using buffer pools to reduce the number of buffers an object can occupy in the buffer cache (for example, limit the number of buffers a randomly-accessed large table or a history table can occupy in the buffer cache).
Problem: Multiple sessions are going after the same row in a block. This could be because there are too many rows per block (lots of small rows in a large data block).
Solution: Reduce the number of rows per block (pctfree/pctuse settings need to be changed). This is a space for time optimization. The table will use more space, but the wait time for buffer busy waits will decrease.
Problem: Multiple sessions trying to insert into the same block. The reason it is the same block is that there is only one free list (or not enough free lists). There is only one head of the free list.
Solution: Adding multiple free lists to the object will increase the number of head of free lists. This distributes the contention point over the free lists, thereby reducing the number of buffer busy waits.
Freelist Blocks: Add more freelists. In case of Parallel Server make sure that each instance has its own freelist group(s).
Undo Header Blocks : Add more rollback segments (when running in Exclusive mode). Set
transactions per rollback segment to 1 (Exclusive mode).
Undo Blocks : Consider making rollback segments larger in Exclusive mode or increase number of PCM locks (GC_ROLLBACK_LOCKS) in Parallel Server Mode only. This chart includes the following data items:
This chart shows SQL statements performing the most buffer gets.
Improving SQL performance is usually the most effective way for improving application
performance. In identifying statements with the most potential to improve performance,
you may want to consider the statements with the highest buffer gets. Buffer gets, or
logical reads, is one of the contributors to CPU time, as it requires locating and
retrieving buffers from the cache.
Another factor worth considering is the frequency at which the statement is executed. A
statement with the a high number of buffer gets may only be executed once a day, far
less than another statement with a lower number of buffer gets that is executed many
thousand times a day.
There are numerous reasons why a query would result in excessive buffer gets; for example,
a full table scan is being performed.
Further investigation on how to best tune a particular SQL statement can be done by selecting any one of
SQL statements listed and using the SQL Analyze tool.
Tuning these statements will result in less CPU time for the application. Execution
count is also important when determining which SQL statement should be tuned first.
The statement with the highest buffer get count may be executed once a day, far less
often than another statement in the list. Tuning the SQL statement with the highest count may not produce as much of an improvement for the application or system in this case as tuning the statement that is executed much more frequently.
This chart will identify the SQL statements that are performing the most buffer gets.
There could be many reasons why a query is performing these buffer gets, with full table scans being a common culprit. To help further diagnose the cause of the problem there are number of drilldown charts available. The SQL shown on this
chart is limited to a fixed number of characters. To see the full SQL text, use the
SQL Text . To see which tables this query references and to check on
the validity statistics used by the optimizer, use the Tables Referenced
by this Query Chart. To see SQL sorted by Physical Reads, use the
Top SQL (Physical Reads) Chart.
Further investigation on how to best tune a particular SQL statement can be done by selecting any one of SQL statements listed and using the SQL Analyze tool.
This chart includes the following data items:
This chart ranks the database files from worst to first in term of average cost of I/O.
Cost of I/O is readtime/physical reads. This chart shows that a given file may be a candidate for striping, or that the stripe width, or the total number of disks involved in the striping should be increased.
If the average cost per I/O is high, this may indicate the need to increase the stripe width or the total number of disks involved in striping. Also, look at the total number of I/O’s per transaction, I/O Rates per trans , then at how many concurrent transactions are running. For example: If each transaction requires 2 reads plus 1 write and expectation is to perform 1000 transactions per second, this calculation requires that the system actually process 3000 I/O’s per second. Therefore, if one disk can perform 50-100 I/Os per second, at least 60 disks will be needed (3000/50). Now if the requirement doubles from 1000 transactions per second to 2000, it will be necessary to double the number of disks.
This chart includes the following data items:
This chart lists the data files of the database and displays the number of physical reads per second and the number of block reads per second. This chart should quickly point out files that are hot spots within the database.
This chart includes the following data items:
This chart lists the data files of the database and displays the number of physical writes per second and the number of blocks written per second. This chart should quickly point out files that are hot spots within the database.
This chart includes the following data items:
This chart shows which files are having full table scans, range scans, or single block reads performed against them. Files that are having single block reads (and the objects within them) are possible candidates for index selection.
The number of blocks that is read in a single I/O operation is determined by the init.ora
parameter db_file_multi_block_read_count.
When the number of physical reads is close to the number of physical block reads for a file (that is, when the result of dividing the number of physical reads by the number of physical block reads is close to 1), then single block reads are occurring on that file. If the resulting value is not close to 1, then full table scans or range scans are being performed on that file.
For files that are experiencing single block reads, look at the objects within the file to determine whether an index may be appropriate for those objects.
To reduce the cost of db file scattered read, check the file placement on each disk,the number
of disks, and the stripe size per disk (this should be 2 * db_file_multi_block_read_count)
This chart helps identify the latch with the highest sleep count. Sleep count is the number of times the latch was not gotten via a spin and was forced to sleep.
With a high number of latch free waits, it is important to determine which latch is being requested. When the bottleneck is a single latch, increasing the spin count can help. In this case, it is ‘cheaper’ to spin the CPU more than to pay the cost to have a process sleep. Also, identifying the latch with the highest sleeps will point to the bottleneck in the application/database. If through further analysis you can remove this bottleneck, you will increase throughput rates.
Latches are used to synchronize access to various resources in the the database. Tuning each individual latch requires futher investigation into the individual latch.
This chart includes the following data items:
This chart shows the get and miss rates for all latches. The values here are the
actual rates. Contention for these latches is calculated and displayed in the
Latch Contention (>1% potential problem) Chart.
This chart includes the following data items:
This chart shows the contention ration for a latch.
Contention for a latch may affect performance if either of these conditions is true:
If either of these conditions is true for a latch, then try to reduce contention for that latch. These contention thresholds are appropriate for most operating systems, though some computers with many CPUs may be able to tolerate more contention without performance reduction.
Most cases of latch contention occur when two or more Oracle processes concurrently attempt to obtain the same latch. Latch contention rarely occurs on single-CPU computers, where only a single process
can be active at once.
To reduce contention for the redo allocation latch, you should minimize the time that any single process holds the latch. To reduce this time, reduce copying on the redo allocation latch. Decreasing the value of
the LOG_SMALL_ENTRY_MAX_SIZE initialization parameter reduces the number and size of redo entries copied on the redo allocation latch.
On multiple-CPU computers, multiple redo copy latches allow multiple processes to copy entries to the redo log buffer concurrently. The default value of LOG_SIMULTANEOUS_COPIES is the number of CPUs available to your Oracle instance.
If you observe contention for redo copy latches, then add more latches by increasing the value of LOG_SIMULTANEOUS_COPIES. Consider having twice as many redo copy latches as CPUs available to your
Oracle instance.
The LRU (least recently used) latch controls the replacement of buffers in the buffer cache. For symmetric multiprocessor (SMP) systems, Oracle automatically sets the number of LRU latches to a value
equal to one half the number of CPUs on the system. For non-SMP systems, one LRU latch is sufficient.
Contention for the LRU latch can impede performance on SMP machines with a large number of CPUs. You can detect LRU latch contention by querying V$LATCH, V$SESSION_EVENT, and
V$SYSTEM_EVENT. To avoid contention, consider bypassing the buffer cache or redesigning the application.
You can specify the number of LRU latches on your system with the initialization parameter DB_BLOCK_LRU_LATCHES. This parameter sets the maximum value for the desired number of LRU latches. Each
LRU latch controls a set of buffers; Oracle balances allocation of replacement buffers among the sets.
To select the appropriate value for DB_BLOCK_LRU_LATCHES, consider the following:
This chart includes the following data items:
This chart displays the average number of buffers scanned to find a free buffer.
If your system must scan too many buffers in the foreground to find a free buffer, then it wastes CPU resources.
To alleviate this problem, tune the DBWn process(es) to write more frequently. You can also increase the size of the buffer cache to enable the database writer process(es) to keep up. On average, you would expect to see 1 or 2 buffers scanned. If more than this number are being scanned, then increase the size of the buffer cache or tune the DBWn process(es).
This chart includes the following data items:
This chart delves into the details surrounding the "free buffer waits" event.
Free buffer waits may be caused by the session scanning at the end of the LRU (Least Recently Used) list for a free buffer. If the dirty list is full, then a foreground process must wait for the dirty buffers to be written to disk. Or, free buffer waits can be caused by a session that scans too many buffers (db_block_max_scan_count). In Oracle7, it is more likely that the dirty buffer list is full than anything else, so increasing db_block_write_batch should be sufficient.
The formula 1 + (free buffers inspected /free buffers requested) will calculate the average
number of buffers that a session is scanning at the end of a LRU to find a free buffer.
If this number is close to 1, it means a session can find a buffer on average very quickly.
If the number is very large it normally means that a lot of Consistent Read (CR) buffers are
sitting at the end of the LRU.
If the average number of free buffers scanned is too large, the db_block_max_scan_count parameter may be too high or you may want to increase the db_block_write_batch parameter.
This chart includes the following data items:
This chart shows total parse count, hard parse count and execution counts. By comparing SQL statement parse counts to execution counts, we can get a picture of how often SQL
statements are being reparsed. A lot of the tuning in this area is probably best done in the application, through more efficient use of cursors, bind variables, and the like.
The following should be checked if parse counts are high:
This chart includes the following data items:
This chart indicates the hit ratio for session cached cursors.
The hit ratio counts the number of times a parse call found a cursor in the session cursor cache.
If an application repeatedly issues parse calls on the same set of SQL statements, then the reopening of the session cursors can affect system performance. Session cursors can be stored in a session cursor
cache. This feature can be particularly useful for applications designed using Oracle Forms, because switching from one form to another closes all session cursors associated with the first form.
Oracle uses the shared SQL area to determine whether more than three parse requests have been issued on a given statement. If so, Oracle assumes the session cursor associated with the statement should be cached and moves the cursor into the session cursor cache. Subsequent requests to parse that SQL statement by the same session then find the cursor in the session cursor cache.
To enable caching of session cursors, you must set the initialization parameter SESSION_CACHED_CURSORS. The value of this parameter is a positive integer specifying the maximum number of session cursors
kept in the cache. An LRU (Least Recently Used) algorithm removes entries in the session cursor cache to make room for new entries when needed.
If this statistic is a relatively low percentage of the total parse call count for the session, you should consider setting SESSION_CACHED_CURSORS to a larger value (provided it does not have a negative impact on Operating System paging and swapping activity).
This chart includes the following data items:
This chart displays some key statistics in monitoring the buffer cache pinning activity.
Oracle relies on database buffers in the SGA to store the most recently used blocks of
database data read from disk. The set of database buffers in an instance is the database
buffer cache. The buffer cache is organized in two lists: the dirty list and the LRU list.
The dirty list contains modified buffers that have not been written to disk.
The LRU list contains free buffers, pinned buffers and dirty buffers.
The DBWR manages the database buffer cache so that user processes can always find free buffers.
This chart displays these key statistics in monitoring buffer cache pinning activity:
These statistics are not incremented when a client performs such a check before releasing it, because the client does not intend to use the buffer in this case.
These statistics provide a measure of how often a long consistent read pin on a buffer is beneficial. If the client is able to reuse the pinned buffer many times, then it indicates that it is useful to have the buffer
pinned.
This chart includes the following data items:
This chart shows response time in the database broken down into two components, wait time and CPU time.
From the percentages shown, the user should be able to quickly determine which component is consuming
the largest portion of elapsed time. Further diagnosis of either component can be accomplished
by selecting either wait time or CPU time and drilling down to charts tailored to the particular
component
This chart includes the following data items:
Oracle relies on database buffers in the SGA to store the most recently used blocks of
database data read from disk. The set of database buffers in an instance is the database
buffer cache. The buffer cache is organized in two lists: the dirty list and the LRU list.
The dirty list contains modified buffers that have not been written to disk.
The LRU list contains free buffers, pinned buffers and dirty buffers.
The DBWR manages the database buffer cache so that user processes can always find free buffers. The buffer
cache efficiency, as measured by the hit ratio, records the percentage of times the data
block requested by a specific query is already in memory. Because the most recently (and
often the most frequently) used data is kept in memory, effective use of the buffer cache
can greatly reduce the I/O load on the database.
If the buffer cache is too small,
frequently accessed data will be flushed from the buffer cache too quickly which forces
the information to be re-fetched from disk. Since disk access is much slower than memory
access, application performance will suffer. In addition, the extra burden imposed on the
I/O subsystem could introduce a bottleneck at one or more devices which would further degrade
performance.
This chart includes the following data items:
User Calls and Recursive Call Rates Per Second
This chart includes the following data items:
Percentage of recursive calls to user calls
This chart includes the following data items:
Database I/O per second
This chart includes the following data items:
Percentage of rows returned using table scan rather than index access
This chart includes the following data items:
Per second rates for various classes of table scans
This chart includes the following data items:
Number of bytes sent and/or received via network per second
This chart includes the following data items:
Number of total blocks gotten per number of tablescans
This chart includes the following data items:
This chart gives an indication of the average I/O size being requested.
If this is small, it is generally due to either small transactions or high
concurrency causing frequent redo_synch_writes. This chart includes the following data items:
Redo log activity statistics
This chart includes the following data items:
This chart displays information about the amount of time your CPU spends parsing SQL statements.
When Oracle executes a SQL statement, it parses it to determine whether the syntax and its contents are correct. This process can consume significant overhead. Once parsed, Oracle does not parse the statement again unless the
parsing information is aged from the memory cache and is no longer available. Ineffective memory sharing among SQL statements can result in reparsing.
This chart helps you detect the general response time on parsing. The more your application is parsing, the more contention exists,
and the more time your system spends waiting. If parse time CPU represents a large percentage of the CPU time,
then time is being spent parsing instead of executing statements. If this is the case, then it is likely that either the
application is using literal SQL and not sharing it, or the shared pool is poorly configured. If Other is
the greatest percentage, look for SQL statements that are performing the most buffer gets and physical reads.
This chart includes the following data items:
This chart represents the sort efficiency, as measured by the percentage of
times sorts were performed in memory as opposed to going to disk.
For best performance, most sorts should occur in memory, because sorts to disks are
expensive to perform. If the sort area is too small, extra sort runs will be
required during the sort operation. This increases CPU and I/O resource consumption.
If excessive sorts are taking place on disk, consider increasing the SORT_AREA_SIZE
initialization parameter to increase the size of the sort area. A larger sort area will
allow the Oracle Server to keep sorts in memory, reducing the number of I/O operations
required to do an equivalent amount of work using the current sort area size.
This chart includes the following data items:
This chart represents the sort efficiency, as measured by the percentage of
times sorts were performed in memory as opposed to going to disk.
For best performance, most sorts should occur in memory, because sorts to disks are
expensive to perform. If the sort area is too small, extra sort runs will be
required during the sort operation. This increases CPU and I/O resource consumption.
If excessive sorts are taking place on disk, consider increasing the SORT_AREA_SIZE
initialization parameter to increase the size of the sort area. A larger sort area will
allow the Oracle Server to keep sorts in memory, reducing the number of I/O operations
required to do an equivalent amount of work using the current sort area size.
This chart includes the following data items:
Initialization parameters pertaining to sorts
This chart includes the following data items:
Sort and Tablescan statistics
This chart includes the following data items:
Rows per sort metric
This chart includes the following data items:
Maximum number of blocks allocated to sorts
This chart includes the following data items:
Statistics related to the DBWR processing of free blocks
This chart includes the following data items:
Statistics describing the DBWR scans of the LRU list
This chart includes the following data items:
Number of times the DBWR was asked to mark a checkpoint
This chart includes the following data items:
Number of blocks in the SGA on a per file basis
This chart includes the following data items:
Initialization parameters pertaining to cursors
This chart includes the following data items:
Number of database blocks in the SGA
This chart includes the following data items:
Size in bytes of the redo log buffer
This chart includes the following data items:
Number of LRU latches
This chart includes the following data items:
Initialization parameters pertaining to the buffer pools
This chart includes the following data items:
This chart shows the number of datafiles for each tablespace.
This chart includes the following data items:
This chart shows the tablespace status, for example, whether the tablespace is online,
offline or read-only, for each tablespace.
This chart includes the following data items:
This chart shows, for each tablespace, the size in blocks for: This chart includes the following data items:
This chart shows the percentage of free space, in blocks, per tablespace. As
segments within a tablespace grow, the free space within that tablespace decreases. Should
free space become insufficient, the creation of new segments or the extension of existing
segments will fail.
If free space is insufficient, increase the size of the tablespace by enabling automatic
extension for one of its datafiles, manually resizing one of its datafiles, or adding a
new datafile.
This chart includes the following data items:
This chart shows the total amount of free space, in kilobytes, for each tablespace. As
segments within a tablespace grow, the free space within that tablespace decreases. Should
free space become insufficient, the creation of new segments or the extension of existing
segments will fail.
If free space is insufficient, increase the size of the tablespace by enabling automatic
extension for one of its datafiles, manually resizing one of its datafiles, or adding a
new datafile.
This chart includes the following data items:
This chart shows the number of free extents for each tablespace.
This chart includes the following data items:
The Data Dictionary Cache is the part of the shared pool used to hold definitions of dictionary objects in memory.
Examples of dictionary objects are privileges, users, tables, columns, constraints,
indexes, etc. The data dictionary cache is sized indirectly when specifying the
SHARED_POOL_SIZE init.ora parameter. The dictionary is tuned automatically by Oracle.
When Oracle is first started and objects are being accessed for the first time,
a miss occurs because a disk read has been required to access the information.
Ideally from then on, there will be no more misses because the dictionary information
will be placed in memory. Unfortunately this is not always the case.
The ratio of all get misses to gets should be between 7-10%. If the percentage is
outside the desired range, lower it by increasing the value of the SHARED_POOL_SIZE
init.ora parameter. Then shut down the database and restart it for the new
SHARED_POOL_SIZE to take effect.
This chart includes the following data items:
The Data Dictionary Cache is the part of the shared pool used to hold definitions of dictionary objects in memory.
Examples of dictionary objects are privileges, users, tables, columns, constraints,
indexes, etc. The data dictionary cache is sized indirectly when specifying the
SHARED_POOL_SIZE init.ora parameter. The dictionary is tuned automatically by Oracle.
When Oracle is first started and objects are being accessed for the first time,
a miss occurs because a disk read has been required to access the information.
Ideally from then on, there will be no more misses because the dictionary information
will be placed in memory. Unfortunately this is not always the case.
The ratio of all get misses to gets should be between 7-10%. If the percentage is
outside the desired range, lower it by increasing the value of the SHARED_POOL_SIZE
init.ora parameter. Then shut down the database and restart it for the new
SHARED_POOL_SIZE to take effect.
This chart includes the following data items:
Per cache counts
This chart includes the following data items:
Number of cache misses per second per cache
This chart includes the following data items:
This chart shows the percentage of parse requests that find the cursor already present in the
cache. A complete description of the meaning of this metric can be found in the description of
the item in the chart.
Drilldowns from this chart will help you determine the reasons for the low hit percentage.
This chart includes the following data items:
Contention for rollback segments is reflected by contention for buffers that contain
rollback segment blocks. This chart represents the percentage of times when there was no wait for accessing the rollback segment header.
This value should be greater than 99%.
This chart includes the following data items:
This chart breaks down wait events on a per user basis.
This chart includes the following data items:
Number of waits for each event by user
This chart includes the following data items:
Summed total of all parse and executes for each user
This chart includes the following data items:
Per second rates
This chart includes the following data items:
CPU usage by user
This chart includes the following data items:
This chart displays information about CPU usage per user, broken down into subcomponents.
When Oracle executes a SQL statement, it parses it to determine whether the syntax and its contents are correct. This process can consume significant overhead. Once parsed, Oracle does not parse the statement again unless the
parsing information is aged from the memory cache and is no longer available. Ineffective memory sharing among SQL statements can result in reparsing.
This chart helps you detect the general response time on parsing. The more your application is parsing, the more contention exists,
and the more time your system spends waiting. If parse time CPU represents a large percentage of the CPU time,
then time is being spent parsing instead of executing statements. If this is the case, then it is likely that either the
application is using literal SQL and not sharing it, or the shared pool is poorly configured. If Other is
the greatest percentage, look for SQL statements that are performing the most buffer gets and physical reads.
This chart includes the following data items:
Block and I/O rates per user
This chart includes the following data items:
Sort statistics per user per second
This chart includes the following data items:
This chart represents the sort efficiency, as measured by the percentage of
times sorts were performed on disk as opposed to in memory.
For best performance, most sorts should occur in memory as sorts to disks are
expensive to perform. If the sort area is too small, extra sort runs will be
required during the sort operation. This increases CPU and I/O resource consumption.
If excessive sorts are taking place on disk, consider increasing the SORT_AREA_SIZE
initialization parameter to increase the size of the sort area. A larger sort area will
allow the Oracle Server to keep sorts in memory, reducing the number of I/O operations
required to do an equivalent amount of work using the current sort area size.
This chart includes the following data items:
Number of rows per sort
This chart includes the following data items:
Peak UGA (per user) memory use
This chart includes the following data items:
Elapsed time for all parses for this user this sample period
This chart includes the following data items:
Average time spent waiting for each parse
This chart includes the following data items:
Contention for rollback segments is reflected by contention for buffers that contain
rollback segment blocks. This chart represents the percentage of times when there was
no wait for accessing the rollback segment header. This value should be greater than 99%.
This chart includes the following data items:
Percentage of hits when requesting rollback segment headers
This chart includes the following data items:
Rollback segment access rates
This chart includes the following data items:
Status and current number of transactions outstanding
This chart includes the following data items:
Lists all segments that may be fragmented
Lists all users and the number of large table scans per second
This chart includes the following data items:
Lists all users and the number of small table scans per second
This chart includes the following data items:
Lists per user tablescans on tables with chained or migrated rows
This chart includes the following data items:
Lists per user tablescans that bypass the buffer cache
This chart includes the following data items:
Various per user tablescan statistics
This chart includes the following data items:
Bytes available in the SGA
This chart includes the following data items:
Number of times a request to the library cache failed or resulted in a miss
This chart includes the following data items:
Sizes of components of the SGA, reported in Megabytes.
This chart includes the following data items:
Reloads/request percentage and shared pool reserved list miss/request percentage
This chart includes the following data items:
Lock Manager top level chart
This chart includes the following data items:
Size of database in megabytes
This chart includes the following data items:
Maximum size of the redo log buffer
This chart includes the following data items:
Number of schemas, users, tables, etc.
This chart includes the following data items:
Counts of total sessions, active, inactive, etc.
This chart includes the following data items:
Current count of number of concurrent sessions
Count of number of concurrent transactions
This chart includes the following data items:
This chart displays a breakdown of the types of SQL statements currently being executed.
Only statements marked as active at the time of the sample will show up in the data reported.
So the results of this chart may be misleading. The values reported are valid for just the
instant in time that the query was performed,
This chart includes the following data items:
This chart shows the average elapsed time for a SQL statement to be executed as well as the breakdown
of the elapsed time into wait and cpu time components. For these charts to be valid the
TIMED_STATISTICS parameter must be set to TRUE. TIMED_STATISTICS can be enabled through a tool
available on each of the charts. The two charts shown here are
Wait or CPU Bound and Elapsed time per execute .
This shows the user our best estimate of overall response time, from statistics
that are available in the database. Response time is defined here as overall
wait time plus overall CPU time consumed by all sessions within the database, divided
by the number of executes to give a per-execute value. The per-execute value is shown
such that we can accurately report on read-only access as well as transactional access. For
per transaction response time, see the Avg. Trans. Length in Seconds
chart.
Further investigation into the individual parts of response time, CPU and Wait, can be done via a drilldown to
Wait or CPU Bound .
This chart includes the following data items:
Average elapsed time per statement execution per user
This chart includes the following data items:
This chart shows response time in the database broken down into two components, wait time and CPU time.
From the percentages shown, the user should be able to quickly determine which component is consuming
the largest portion of elapsed time. Further diagnosis of either component can be accomplished
by selecting either wait time or CPU time and drilling down to charts tailored to the particular
component
This chart includes the following data items:
This chart shows CPU usage broken down into its components, catagorized by each program attached to
the database. The program name is taken from the V$SESSION table and the statistics that are used
to calculate these values are aggregated for all sessions that were started by users executing
the named program.
When Oracle executes a SQL statement, it parses it to determine whether the syntax and its contents are correct.
This process can consume significant overhead. Once parsed, Oracle does not parse the statement again unless the
parsing information is aged from the memory cache and is no longer available. Ineffective memory sharing among SQL statements can result in reparsing.
Now you can detect the general response time on parsing. The more your application is parsing, the more contention exists,
and the more time your system spends waiting. If parse time CPU represents a large percentage of the CPU time,
then time is being spent parsing instead of executing statements. If this is the case, then it is likely that the
application is using literal SQL and not sharing it, or the shared pool is poorly configured. If Other is
the greatest percentage, look for SQL statements that are performing the most buffer gets and physical reads.
This chart includes the following data items:
This chart is a group chart that shows summary information about Wait Events. With a chart showing the number of sessions that
are currently waiting for specific events Sessions Waiting for this Event And a chart showing the top 5 wait events
that have finished waiting during this sample Wait Events by Time .
This chart depicts where CPU time is being spent within the database. It contains CPU breakdowns for
the database as a whole as well as individual programs, users, and remote nodes. From these charts, you should be able to quickly determine where and how your CPU is being consumed.
When Oracle executes a SQL statement, it parses it to determine whether the syntax and its contents are correct.
This process can consume significant overhead. Once parsed, Oracle does not parse the statement again unless the
parsing information is aged from the memory cache and is no longer available. Ineffective memory sharing among SQL statements can result in reparsing.
Now you can detect the general response time on parsing. The more your application is parsing, the more contention exists,
and the more time your system spends waiting. If parse time CPU represents a large percentage of the CPU time,
then time is being spent parsing instead of executing statements. If this is the case, then it is likely that the
application is using literal SQL and not sharing it, or the shared pool is poorly configured. If Other is
the greatest percentage, look for SQL statements that are performing the most buffer gets and physical reads.
A group chart that shows the high level instance wide I/O statistics as well as the
most heavily or costly accessed database files.
Sessions are displayed in descending order based upon the delta value of the statistic chosen as
the sort statistic.
This chart can be used to create a customized Top Session view. All of the available statistics
and identifiers for sessions are shown in a large table by default. By using the Set Options
button in the toolbar the chart can be customized to show only the items of interest and the sort
criteria can be changed. Customized charts can then be saved, named and accessed directly by name.
This chart includes the following data items:
Average elapsed time per transaction per session
This chart includes the following data items:
Actual values of commits, rollbacks, executes, etc. for the sample period
This chart includes the following data items:
Average elapsed time per statement execution per session
This chart includes the following data items:
The db file scattered read event usually indicates full table scans or range scans.
The number of blocks that is read in a single I/O operation is determined by the init.ora
parameter db_file_multi_read_count. This chart will show the files that are having scans
performed on them. If phyrds is close to physical block reads, then single block reads are
occurring. If that is not the case then full scans or range scans are not happening on that
particular file. This chart will show which files are having single block reads and identify
those files and the objects within them as possible candidates for index selection.
If physical reads/physical blocks read is close to 1, then single block reads are occurring, and scans are not occurring on the file and the. Check the objects that reside in the file. And look to see if an index may be appropriate for those objects.
To reduce the cost of db file scattered read, check the file placement on each disk, the number of disks, and the stripe size per disk (this should be 2 * db_file_mutli_block_read_count)
This chart provides a comprehensive overview of Latch activity. Latch contention,
latch sleeps, and overall latch statistics are presented for further investigation.
CPU and wait components of elapsed time
This chart includes the following data items:
Further investigation of CPU usage by users
This chart is related to the buffer busy event. This chart will show which blocks in which
files and why the current session is waiting on them. The block could be being read
by another session or being modified by another session. From this we can figured out
what type of contention the session is having on specific files and the blocks within
those files.
This chart includes the following data items:
Sort statistics group chart
SQL statements of applications that use the DBMS_APPLICATION_INFO package
This chart includes the following data items:
SQL statements of applications that use the DBMS_APPLICATION_INFO package
This chart includes the following data items:
List of current modules and the count of sessions using that module
This chart includes the following data items:
A list of events across the instance sorted by the number of sessions currently
waiting to the particular event type. This list will allow the user to quickly identify
which event the instance is waiting for the most as a whole. Each event type is affected
by different parameters and conditions. Further drilldown is accomplished by selecting the particular
wait event of interest. Some of the wait events have specific drilldown charts to help diagnose
the reason for the wait.
There are also generic drilldowns, available for all wait events. To determine the individual
sessions that are currently waiting for a specific event use the Sessions Waiting for this Event Chart.
Similarly to view the SQL statements that are currently waiting for the event, use the
SQL Statements waiting for this event Chart. This will lead you quickly to
the SQL statements that are experiencing the wait and help you determine the impact this wait
is having on the application.
This chart includes the following data items:
Parallel query chart
This chart contains statistics pertaining to the use and size of the session cursor cache.
This cache is enabled via SESSION_CURSOR_CACHE parameter.
CPU time broken down into parse, recursive and other
This chart includes the following data items:
Tablespace statistics, status, percent free space, free bytes, etc.
This chart is intended to show different statistics that indicate the overall health of the
Redo Log and the LGWR activity.
Most of the charts and statistics displayed or gathered for CP analyis require that the initialization parameter
timed_statisics be set to TRUE. This enables the database to gather CPU and elapsed time information
on operations within the server. The overhead encurred by turning on this statistic's timing is very low.
The benefits gained by being able to accurately track resource and elapsed time consumption far outweigh the associated
cost. If the value show in the chart is currently "FALSE" you can dynamically turn on timed_statistics by using the associated
Turn On Timed Statistics Tool found in the tool pulldown associated with this chart. Tools, Drilldowns, Historical Collections
and other options are viewable with a right mouse button on any chart.
This chart includes the following data items:
This chart is intended to show different Shared Pool statistics that determine whether to increase or decrease the Shared Pool Size parameter to tune the Library Cache performance.
The library cache is one of the dynamic memory structures in the Shared Pool.
The library cache holds executable forms of SQL cursors, PL/SQL programs, and JAVA classes.
The library cache is limited in size and is controlled by an LRU algorithm such that objects are aged out of this cache if the shared pool runs out of room.
Library cache misses can occur on either the parse or the execute step in the processing of a SQL statement.
This chart shows the percentage of CPU Time used in the last sample period by sessions that originate on the listed
hosts. You should be able to quickly discover which remote nodes are responsible for the bulk of the CPU consumption within
the database. This chart will be especially useful for environments that dedicate middle tier servers to specific applications. This chart includes the following data items:
This chart shows the percentage of CPU Time used in the last sample period by the listed programs.
You should be able to quickly discover which programs are responsible for the bulk of the CPU consumption within
the database. This chart will be especially useful for environments that have unique image names for their various applications. This chart includes the following data items:
This chart shows the sum of dirty buffers found on the LRU buffer list and write requests during this sample period. Summed dirty queue length is the number of blocks that stay in the dirty queue after a write request is completed.
If many dirty buffers exist, then possibly the DBWn process(es) cannot keep up. Increase the buffer cache size or tune the DBWn process. This chart includes the following data items:
This chart shows if the DBWR is leaving dirty blocks in the LRU queue that are either being
found after each write completes or are found by shadow processes trying to load new blocks into
the cache. Values > 1 for both of these statics can point to I/O, cache sizing problems or an
insufficient number of DBWR processes. This chart includes the following data items:
Through the use of the charts displayed as a group here, you should be able to determine if the DBWR is
operating at a level that is adequate for the database. From within each of the specific charts, you can investigate further into individual statistics and
possible actions to correct problems.
This chart is the starting point for diagnosing performance problems with the database.
Each sub chart within the group chart has drilldowns that will lead you through further
analysis of the potential problem, denoted by the statistics shown on that chart.
Some of the drilldowns are context specific. If there is more than one item shown in a chart,
selecting the individual item of interest before using the right mouse button to drilldown will
provide the best context to the tool.
Amount of redo generated per second in bytes
This chart includes the following data items:
Average number of blocks read/write to/from each file per I/O operation
This chart includes the following data items:
This chart shows the average amount of time a I/O operation takes for the
particular file. This chart includes the following data items:
This chart will show you the tables that this query references.
If the query is large, it may not be readily apparent which tables it actually
accesses. If the query is performing lots of I/O, it could be doing a full
table scan against one of tables. If the cost based optimizer is in use, it could
be choosing a bad strategy based upon out of date statistics. Use the information
in this chart to decide if the table statistics are valid. If not, use one of the
analyze tool options to update the statistics for any of the tables. A high chained row
percentage may indicate that the average row in this table cannot fit into a data blcok.
This may be becuase of updates which increase the size of records, forcing them to be migrated
to other blocks, or the row size may just exceed the db_block_size. Use the Reorg wizard to
determine if tables with high row chain percentages should be reorganized. This chart includes the following data items:
Soft parses are parses that find the SQL statement in the cache already parsed and are
able to reuse the existing entry. Hard parses do not find the SQL statement in the cache
and consume processing cycles to complete the parse step. If the Soft Parse percentage is
low, you should look at the SQL statements in the cache. Using the Top SQL Chart you should
be able to determine if bind variables are being used or not. SQL statements must match exactly
for the SQL cache to be used efficiently. This chart includes the following data items:
This chart shows the sessions which are parsing SQL statements that do
not already reside in the cache. Most often, this is due to using literals and
not bind variables in SQL queries. The SQL statements in use by a session can be
found by drilling down to the Open Cursors for this Session chart. This chart includes the following data items:
This chart is the starting point for figuring out which sessions and then ultimately
which queries are performing the most sorting. From this chart, you can drill down to
open cursors for the session, and then sort those queries by row sorts to determine
which queries are causing the sorts. This chart includes the following data items:
This chart gives you a good idea of which sessions are responsible for the bulk
of the database read I/O. From this chart, you can drilldown to the open SQL for
the session which, when sorted by physical reads, will give you an idea of which queries are
responsible for the I/O. This chart includes the following data items:
This chart gives you a good idea of the impact a change to this table will
have on the rest of your application, whether it be through adding an index to
improve a query or via updating the table's internal statistics. This chart includes the following data items:
SQL Text
Avg. Trans. Length in Seconds
Transaction and Statement Execution Rates
Avg Trans. Length Per User
User Transaction Rates (Insert/Update)
Wait Events by Time
Wait Event Counts
Block Waits By Time
User Action
Block Wait Counts
User Action
Top SQL (Buffer Gets)
Average Cost of I/O
File Read Operations
File Write Operations
DB File Scattered Read
Latch Sleeps
Latch Get/Miss Rates
Latch Contention (>1% potential problem)
Reducing Latch Contention
Reducing Contention for the Redo Allocation Latch
Reducing Contention for Redo Copy Latches
Reducing Contention for the LRU Latch
Free Buffer Scans
Free Buffer Statistics
Parse Statistics
Cursor Cache Hit %
Buffer Pinned Counts
Session Waits or CPU?
Buffer Cache Hit %
Call Rates
Recursive Call to User Call Ratio
I/O Rates per Sec
Rows Retrieved via Table Scan %
Table Scan Rates
Network Bytes Per Second
Blocks Per Table Scan
Average Redo Log Write Size
Redo Log Statistics
Instance-Wide CPU Breakdown
Memory Sort %
Memory Sort Ratio
Sort Area Sizes
Sorts and Scans
Rows per Sort
Max Sort Allocation
DBWR Free Block Statistics
DBWR Scan Statistics
DBWR Checkpoints
Buffer Pool
Cursor Instance Parameters
DB Blocks in the SGA
Redo Log Buffer Size
LRU Latch Count
Buffer Pool Parameters
Datafile Count per Tablespace
Description
Status per Tablespace
Description
Block Counts per Tablespace
Description
Free Space (%) per Tablespace
Description
User Action
Free Space (kbytes) per Tablespace
Description
User Action
Number of Free Extents per Tablespace
Description
Data Dictionary Miss %
Data Dictionary Hit/Miss Rates
Data Dictionary per Cache Entry Counts
Data Dictionary Per Cache Miss Rates
Library Cache Hit %
Rollback No Wait %
Per User Wait Events by Time
Per User Wait Events by Count
User Parse and Execute Totals
User Parse and Execute Rates
User Total CPU
User CPU Breakdown
User I/O Rates
User Sort Rates
User Disk to Memory Sort Ratios
User Sorts to Rows Sorted
User UGA Memory Usage
User Elapsed Parse Time
User Avg Wait for Parse
Rollback Segment No Wait Ratio (>99%)
Rollback Segment Hit %
Rollback Segment Access Rates
Rollback Segment Status
Tablespace (Segment) Fragmentation
Users with Tablescans of Large Tables (>5 Blocks)
Users with Tablescans of Small Tables (<5 Blocks)
Tablescans on Tables with Chained or Migrated Rows
Tablescans That Bypass the Buffer Cache (Direct to Disk)
User Tablescan Rates
SGA Free Memory
SGA Request Failure and Miss Rates
SGA Breakdown
SGA Hit %
Lock Manager
Database Size
Redo Log Buffer Size
Object Counts
Session Counts
Concurrent Session Count
Concurrent Transaction Count
Current Operations Breakdown
Response Time Overview
Elapsed Time per Execute
User Elapsed Time per Execute
Wait or CPU Bound?
Program CPU Breakdown
Wait Analysis Overview
CPU Overview
I/O at a Glance
Top Session
Avg Trans. Length Per Session
Session Transaction Rates (Insert/Update)
Elapsed Time per Execute per Session
DB File Sequential Read Analysis
Latch Analysis
User Elapsed Time Components
User CPU Analysis
Session Buffer Busy Wait
Sort Statistics At A Glance
SQL Sorted by Module, Action, Phys Reads
SQL Sorted by Module, Action, Buffer Gets
Application Module Activity
Sessions Waiting
Parallel Query
Cursor Overview Chart
Per Host CPU Breakdown
Tablespace Overview
Redo Analysis
Timed Statistics
SGA Overview
Host Total CPU Time
Program Total CPU Time
Summed Dirty Queue Length
DBWR Efficiency Statistics
DBWR Analysis
Database Health
Redo Size per Second
Blocks Per I/O
I/O Time
Tables Referenced by this Query
Soft Parse %
Top Sessions by Hard Parse Count
Top Sessions by Rows Sorted
Top Sessions by Physical Reads
All SQL in the Cache that Access this Table