# Top SQL (Physical Reads)

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:

- SQL Text : Shows the complete SQL text.
- Tables Referenced by this Query : Lists tables referenced by this query as well as various optimizer statistics.
- Top SQL (Buffer Gets) : Presents SQL sorted by Buffer Gets.

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:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

SQL Text

# SQL Text

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:

- SQL Text

Avg. Trans. Length in Seconds

# Avg. Trans. Length in Seconds

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:

- Response Time Per Trans

Transaction and Statement Execution Rates

# Transaction and Statement Execution Rates

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:

- Transaction Count

- Commit Count

- Rollback Count

- Execute Count

Avg Trans. Length Per User

# Avg Trans. Length Per User

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:

- Response Time Per Trans

User Transaction Rates (Insert/Update)

# User Transaction Rates (Insert/Update)

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:

- Transaction Count

- Commit Count

- Rollback Count

- Execute Count

Wait Events by Time

# Wait Events by Time

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:

- Wait Time

Wait Event Counts

# Wait Event Counts

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:

- Number Waits

Block Waits By Time

# Block Waits By Time

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 Blocks: Each segment has one segment header block. There are basically two types of segments, data and index.
- Data Blocks: Are used to store data (index or data).
- Free List Blocks: Are only used by objects that contain free list groups.

### User Action

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:

- Wait Time

Block Wait Counts

# Block Wait Counts

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 Blocks: Each segment has one segment header block. There are basically two types of segments, data and index.
- Data Blocks: Are used to store data (index or data).
- Free List Blocks: Are only used by objects that contain free list groups.

### User Action

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.

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: 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.

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: 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:

- Total Waits/Sec

Top SQL (Buffer Gets)

# Top SQL (Buffer Gets)

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.

To help further diagnose a potential problem, a number of drilldown charts are available including:

- SQL Text : Shows the complete SQL text.
- Tables Referenced by this Query : Lists tables referenced by this query as well as various optimizer statistics.
- Top SQL (Physical Reads) : Presents SQL sorted by Physical Reads.

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:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Average Cost of I/O

# Average Cost of I/O

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:

- Average time/Read

- Average time/Write

File Read Operations

# File Read Operations

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:

- Physical Reads/Sec

- Physical Block Reads/Sec

File Write Operations

# File Write Operations

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:

- Physical Writes/Sec

- Physical Block Writes/Sec

DB File Scattered Read

# DB File Scattered Read

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)

Latch Sleeps

# Latch Sleeps

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:

- Sleeps/Sec

- Slept Once

- Slept Twice

- Slept Three Times

- Slept Four Times

Latch Get/Miss Rates

# Latch Get/Miss Rates

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:

- Misses/Sec

- Immediate Misses/Sec

- Gets/Sec

- Immediate Gets/Sec

Latch Contention (>1% potential problem)

# Latch Contention (>1% potential problem)

This chart shows the contention ration for a latch. Contention for a latch may affect performance if either of these conditions is true:

- If the ratio of MISSES to GETS exceeds 1%.
- If the ratio of IMMEDIATE_MISSES to the sum of IMMEDIATE_GETS and IMMEDIATE_MISSES exceeds 1%.

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.

#### Reducing Latch Contention

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.

#### Reducing Contention for the Redo Allocation Latch

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.

#### Reducing Contention for Redo Copy Latches

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.

#### Reducing Contention for the LRU Latch

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:

- The maximum number of latches is twice the number of CPUs in the system. That is, the value of DB_BLOCK_LRU_LATCHES can range from 1 to twice the number of CPUs.
- A latch should have no less than 50 buffers in its set; for small buffer caches there is no added value if you select a larger number of sets. The size of the buffer cache determines a maximum boundary condition on the number of sets.
- Do not create multiple latches when Oracle runs in single process mode. Oracle automatically uses only one LRU latch in single process mode.
- If the workload on the instance is large, then you should have a higher number of latches. For example, if you have 32 CPUs in your system, then choose a number between half the number of CPUs (16) and actual number of CPUs (32) in your system.

This chart includes the following data items:

- Miss/Get Ratio

- Immediate Miss Ratio

Free Buffer Scans

# Free Buffer Scans

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:

- Avg Free Buffer Scans

Free Buffer Statistics

# Free Buffer Statistics

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:

- Free Buff Inspected/Sec

- Free Buff Requested/Sec

- Dirty Buff Inspected/Sec

Parse Statistics

# Parse Statistics

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:

- Is the application spending too much time opening and closing cursors?
- Ensure the application is using bind variables
- If applications open/re-parse the same statement,set SESSION_CACHED_CURSORS to the number of cursors used by the session
- Check that compiler flags RELEASE_CURSORS = NO and HOLD_CURSORS = yes
- Check programs for re-parsing statements before execute instead of using bind variables

This chart includes the following data items:

- Parses/Sec

- Hard Parses/Sec

- Executes/Sec

Cursor Cache Hit %

# Cursor Cache Hit %

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:

- Cursor Cache Hits

Buffer Pinned Counts

# Buffer Pinned Counts

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:

- Buffer pinned : This statistic measures the number of times a buffer was already pinned by a client when a client checks to determine if the buffer it wants is already pinned.
- Buffer not pinned : This statistic measures the number of times the buffer was not pinned by the client when a client checks to determine if the buffer it wants is already pinned.

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:

- Buffer is pinned/Sec

- Buffer is not pinned/Sec

Session Waits or CPU?

# Session Waits or CPU?

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:

- % Wait Time

- % CPU Time

Buffer Cache Hit %

# Buffer Cache Hit %

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:

- Buffer Cache Hit %

Call Rates

# Call Rates

User Calls and Recursive Call Rates Per Second

This chart includes the following data items:

- User Calls/Sec

- Recursive Calls/Sec

Recursive Call to User Call Ratio

# Recursive Call to User Call Ratio

Percentage of recursive calls to user calls

This chart includes the following data items:

- Recursive Calls/User Calls

I/O Rates per Sec

# I/O Rates per Sec

Database I/O per second

This chart includes the following data items:

- Physical Reads/Sec

- Physical Writes/Sec

- Logical Reads/Sec

- Block Changes/Sec

- Consistent Changes/Sec

- Redo Size/Sec

Rows Retrieved via Table Scan %

# Rows Retrieved via Table Scan %

Percentage of rows returned using table scan rather than index access

This chart includes the following data items:

- Full TableScan Rows ratio

Table Scan Rates

# Table Scan Rates

Per second rates for various classes of table scans

This chart includes the following data items:

- Table Scans(Long)/Sec

- Table Scans(Short)/Sec

- Rows Gotten Per Table Scan

- Table Scan Rows/Sec

Network Bytes Per Second

# Network Bytes Per Second

Number of bytes sent and/or received via network per second

This chart includes the following data items:

- Network Bytes/Sec

Blocks Per Table Scan

# Blocks Per Table Scan

Number of total blocks gotten per number of tablescans

This chart includes the following data items:

- Blocks Per Table Scan

Average Redo Log Write Size

# Average Redo Log Write Size

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:

- Average Redo Write Size

Redo Log Statistics

# Redo Log Statistics

Redo log activity statistics

This chart includes the following data items:

- Redo Entries/Sec

- Redo Log Space Req/Sec

- Redo Synch Writes/Sec

- Redo Blocks Written/Sec

- Redo Writes/Sec

Instance-Wide CPU Breakdown

# Instance-Wide CPU Breakdown

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:

- % Parse CPU Time

- % Recursive CPU Time

- % Other CPU Time

Memory Sort %

# Memory Sort %

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:

- Memory Sort %

Memory Sort Ratio

# Memory Sort Ratio

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:

- Disk Sorts/Sec

- Memory Sorts/Sec

Sort Area Sizes

# Sort Area Sizes

Initialization parameters pertaining to sorts

This chart includes the following data items:

- SORT_AREA_SIZE

- SORT_AREA_RETAINED_SIZE

Sorts and Scans

# Sorts and Scans

Sort and Tablescan statistics

This chart includes the following data items:

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

- Short Table Scans/Sec

- Long Table Scans/Sec

Rows per Sort

# Rows per Sort

Rows per sort metric

This chart includes the following data items:

- Rows/Sort

Max Sort Allocation

# Max Sort Allocation

Maximum number of blocks allocated to sorts

This chart includes the following data items:

- Maximum Sort Allocation

DBWR Free Block Statistics

# DBWR Free Block Statistics

Statistics related to the DBWR processing of free blocks

This chart includes the following data items:

- DBWR Make Free Requests

- DBWR Free Buffers Found

DBWR Scan Statistics

# DBWR Scan Statistics

Statistics describing the DBWR scans of the LRU list

This chart includes the following data items:

- DBWR LRU Scans

- DBWR Summed Scan Depth

- DBWR Buffers Scanned

DBWR Checkpoints

# DBWR Checkpoints

Number of times the DBWR was asked to mark a checkpoint

This chart includes the following data items:

- DBWR Checkpoints

Buffer Pool

# Buffer Pool

Number of blocks in the SGA on a per file basis

This chart includes the following data items:

- Block Count

- Distinct Block Count

Cursor Instance Parameters

# Cursor Instance Parameters

Initialization parameters pertaining to cursors

This chart includes the following data items:

- SESSION_CACHED_CURSORS

- OPEN_CURSORS

- CURSOR_SPACE_FOR_TIME

DB Blocks in the SGA

# DB Blocks in the SGA

Number of database blocks in the SGA

This chart includes the following data items:

- DB_BLOCK_BUFFERS

Redo Log Buffer Size

# Redo Log Buffer Size

Size in bytes of the redo log buffer

This chart includes the following data items:

- LOG_BUFFER

LRU Latch Count

# LRU Latch Count

Number of LRU latches

This chart includes the following data items:

- DB_BLOCK_LRU_LATCHES

Buffer Pool Parameters

# Buffer Pool Parameters

Initialization parameters pertaining to the buffer pools

This chart includes the following data items:

- BUFFER_POOL_KEEP

- BUFFER_POOL_RECYCLE

Datafile Count per Tablespace

# Datafile Count per Tablespace

#### Description

This chart shows the number of datafiles for each tablespace.

This chart includes the following data items:

- Datafile Count

Status per Tablespace

# Status per Tablespace

#### Description

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:

- Status

Block Counts per Tablespace

# Block Counts per Tablespace

#### Description

This chart shows, for each tablespace, the size in blocks for:

- The total size
- The total amount of free space
- The total amount of space currently being used by all users
- The total amount of used space

This chart includes the following data items:

- Total Blocks

- Free Blocks

- Total Quota Blocks

- Used Blocks

Free Space (%) per Tablespace

# Free Space (%) per Tablespace

#### Description

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.

#### User Action

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:

- Free Space (%)

Free Space (kbytes) per Tablespace

# Free Space (kbytes) per Tablespace

#### Description

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.

#### User Action

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:

- Free Space (kbytes)

Number of Free Extents per Tablespace

# Number of Free Extents per Tablespace

#### Description

This chart shows the number of free extents for each tablespace.

This chart includes the following data items:

- Free Extents

Data Dictionary Miss %

# Data Dictionary Miss %

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 Data Dictionary Miss chart shows the ratio of misses to gets. The chart will immediately indicate whether or not an exorbitant amount of dictionary cache misses exists.

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:

- Miss %

Data Dictionary Hit/Miss Rates

# Data Dictionary Hit/Miss Rates

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 Dictionary Cache Hit Ratio chart shows the cache-gets in one color and cache-misses in another color. The chart will immediately indicate whether or not an exorbitant amount of dictionary cache misses exists.

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:

- Gets/Sec

- Misses/Sec

Data Dictionary per Cache Entry Counts

# Data Dictionary per Cache Entry Counts

Per cache counts

This chart includes the following data items:

- Entries in Cache

- Valid Entries

Data Dictionary Per Cache Miss Rates

# Data Dictionary Per Cache Miss Rates

Number of cache misses per second per cache

This chart includes the following data items:

- Entries in Cache

- Misses/Sec

Library Cache Hit %

# Library Cache Hit %

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:

- Library Cache Hit %

Rollback No Wait %

# Rollback No Wait %

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:

- Rollback NoWait %

Per User Wait Events by Time

# Per User Wait Events by Time

This chart breaks down wait events on a per user basis.

This chart includes the following data items:

- Wait Time

Per User Wait Events by Count

# Per User Wait Events by Count

Number of waits for each event by user

This chart includes the following data items:

- Number Waits

- Number Timeouts

User Parse and Execute Totals

# User Parse and Execute Totals

Summed total of all parse and executes for each user

This chart includes the following data items:

- Parse Count

- Execute Count

User Parse and Execute Rates

# User Parse and Execute Rates

Per second rates

This chart includes the following data items:

- Parse Count (Hard)/Sec

- Parse Count (Total)/Sec

- Executes/Sec

User Total CPU

# User Total CPU

CPU usage by user

This chart includes the following data items:

- Total CPU Time %

User CPU Breakdown

# User CPU Breakdown

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:

- Parse CPU %

- Recursive CPU %

- Other CPU %

User I/O Rates

# User I/O Rates

Block and I/O rates per user

This chart includes the following data items:

- Block Gets/Sec

- Consistent Gets/Sec

- Physical Reads/Sec

- Block Changes/Sec

- Consistent Changes/Sec

User Sort Rates

# User Sort Rates

Sort statistics per user per second

This chart includes the following data items:

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

User Disk to Memory Sort Ratios

# User Disk to Memory Sort Ratios

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:

- Disk/Memory Sorts Ratio

User Sorts to Rows Sorted

# User Sorts to Rows Sorted

Number of rows per sort

This chart includes the following data items:

- Disk Sorts/Sort Rows Ratio

User UGA Memory Usage

# User UGA Memory Usage

Peak UGA (per user) memory use

This chart includes the following data items:

- UGA Memory

User Elapsed Parse Time

# User Elapsed Parse Time

Elapsed time for all parses for this user this sample period

This chart includes the following data items:

- Parse Elapsed Time

User Avg Wait for Parse

# User Avg Wait for Parse

Average time spent waiting for each parse

This chart includes the following data items:

- Avg. Wait Time per Parse

Rollback Segment No Wait Ratio (>99%)

# Rollback Segment No Wait Ratio (>99%)

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:

- Waits Logical Reads ratio

Rollback Segment Hit %

# Rollback Segment Hit %

Percentage of hits when requesting rollback segment headers

This chart includes the following data items:

- Rollback NoWait %

Rollback Segment Access Rates

# Rollback Segment Access Rates

Rollback segment access rates

This chart includes the following data items:

- Header Gets/Sec

- Header Waits/Sec

- Shrinks/Sec

- Wraps/Sec

- Extends/Sec

Rollback Segment Status

# Rollback Segment Status

Status and current number of transactions outstanding

This chart includes the following data items:

- Status

- Active Transactions

- Writes

- Extents

- Size

- OptSize

- HWMSize

- AveShrink

- AveActive

Tablespace (Segment) Fragmentation

# Tablespace (Segment) Fragmentation

Lists all segments that may be fragmented

Users with Tablescans of Large Tables (>5 Blocks)

# Users with Tablescans of Large Tables (>5 Blocks)

Lists all users and the number of large table scans per second

This chart includes the following data items:

- Long Tables/Sec

Users with Tablescans of Small Tables (<5 Blocks)

# Users with Tablescans of Small Tables (<5 Blocks)

Lists all users and the number of small table scans per second

This chart includes the following data items:

- Short Tables/Sec

Tablescans on Tables with Chained or Migrated Rows

# Tablescans on Tables with Chained or Migrated Rows

Lists per user tablescans on tables with chained or migrated rows

This chart includes the following data items:

- Fetch Continued Rows/Sec

Tablescans That Bypass the Buffer Cache (Direct to Disk)

# Tablescans That Bypass the Buffer Cache (Direct to Disk)

Lists per user tablescans that bypass the buffer cache

This chart includes the following data items:

- Direct Reads/Sec

User Tablescan Rates

# User Tablescan Rates

Various per user tablescan statistics

This chart includes the following data items:

- Direct Reads/Sec

SGA Free Memory

# SGA Free Memory

Bytes available in the SGA

This chart includes the following data items:

- Free Memory Size

SGA Request Failure and Miss Rates

# SGA Request Failure and Miss Rates

Number of times a request to the library cache failed or resulted in a miss

This chart includes the following data items:

- Rsvd List Request Misses

- Rsvd List Request Failures

SGA Breakdown

# SGA Breakdown

Sizes of components of the SGA, reported in Megabytes.

This chart includes the following data items:

- Free Memory Size

- Shared Pool Size

- Shared Pool Reserved Size

- Java Pool Size

- DB Block Buffers Size

- Log Buffer Size

- Fixed SGA Size

SGA Hit %

# SGA Hit %

Reloads/request percentage and shared pool reserved list miss/request percentage

This chart includes the following data items:

- Reserved List Alloc HitRatio

Lock Manager

# Lock Manager

Lock Manager top level chart

This chart includes the following data items:

- Session Id

- Session Serial Number

- Process Id

- Lock Type

- Mode Held

- Mode Requested

- Object Name

- ROWID

- Object Owner

- Object Type

- Resource ID1

- Resource ID2

Database Size

# Database Size

Size of database in megabytes

This chart includes the following data items:

- Database Size

Redo Log Buffer Size

# Redo Log Buffer Size

Maximum size of the redo log buffer

This chart includes the following data items:

- Max Log Buffer Size

Object Counts

# Object Counts

Number of schemas, users, tables, etc.

This chart includes the following data items:

- Number of Tablespaces

- Number of Schemas

- Number of Datafiles

- Number of Users

Session Counts

# Session Counts

Counts of total sessions, active, inactive, etc.

This chart includes the following data items:

- Session Count

Concurrent Session Count

# Concurrent Session Count

Current count of number of concurrent sessions

Concurrent Transaction Count

# Concurrent Transaction Count

Count of number of concurrent transactions

This chart includes the following data items:

- Concurrent Transactions

Current Operations Breakdown

# Current Operations Breakdown

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:

- Selects

- Updates

- Inserts

- Deletes

Response Time Overview

# Response Time Overview

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 .

Elapsed Time per Execute

# 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:

- Response Time Per Execute

User Elapsed Time per Execute

# User Elapsed Time per Execute

Average elapsed time per statement execution per user

This chart includes the following data items:

- Response Time Per Execute

Wait or CPU Bound?

# Wait or CPU Bound?

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:

- % Wait Time

- % CPU Time

Program CPU Breakdown

# Program CPU Breakdown

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:

- Parse CPU %

- Recursive CPU %

- Other CPU %

Wait Analysis Overview

# Wait Analysis Overview

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 .

CPU Overview

# CPU Overview

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.

I/O at a Glance

# I/O at a Glance

A group chart that shows the high level instance wide I/O statistics as well as the most heavily or costly accessed database files.

Top Session

# Top Session

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:

- Session Name

- OS Username

- Sort Statistic

- Status

- Machine

- Terminal

- Program

- Module

- Action

- Serial #

- SPID

- Physical Reads(%)

- Commit Count

- Rollback Count

- Execute Count

- Parse Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time

- Parse CPU

- Recursive CPU

- Block Gets

- Consistent Gets

- Physical Reads

- Block Changes

- Consistent Changes

- Disk Sorts

- Memory Sorts

- Sort Rows

- Parse Count (Hard)

- Parse Count Total

- Parse Elapsed Time

- UGA Memory

- Logon Time

- Logical Reads(%)

Avg Trans. Length Per Session

# Avg Trans. Length Per Session

Average elapsed time per transaction per session

This chart includes the following data items:

- Response Time per Trans

Session Transaction Rates (Insert/Update)

# Session Transaction Rates (Insert/Update)

Actual values of commits, rollbacks, executes, etc. for the sample period

This chart includes the following data items:

- Transaction Count

- Commit Count

- Rollback Count

- Execute Count

Elapsed Time per Execute per Session

# Elapsed Time per Execute per Session

Average elapsed time per statement execution per session

This chart includes the following data items:

- Response Time Per Execute

DB File Sequential Read Analysis

# DB File Sequential Read Analysis

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)

Latch Analysis

# Latch Analysis

This chart provides a comprehensive overview of Latch activity. Latch contention, latch sleeps, and overall latch statistics are presented for further investigation.

User Elapsed Time Components

# User Elapsed Time Components

CPU and wait components of elapsed time

This chart includes the following data items:

- % Wait Time

- % CPU Time

User CPU Analysis

# User CPU Analysis

Further investigation of CPU usage by users

Session Buffer Busy Wait

# Session Buffer Busy Wait

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:

- Filename

- Block#

- Wait

Sort Statistics At A Glance

# Sort Statistics At A Glance

Sort statistics group chart

SQL Sorted by Module, Action, Phys Reads

# SQL Sorted by Module, Action, Phys Reads

SQL statements of applications that use the DBMS_APPLICATION_INFO package

This chart includes the following data items:

- SQL Text

- Physical Reads

- Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

SQL Sorted by Module, Action, Buffer Gets

# SQL Sorted by Module, Action, Buffer Gets

SQL statements of applications that use the DBMS_APPLICATION_INFO package

This chart includes the following data items:

- SQL Text

- Physical Reads

- Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Application Module Activity

# Application Module Activity

List of current modules and the count of sessions using that module

This chart includes the following data items:

- Session Count

Sessions Waiting

# Sessions Waiting

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:

- Session Count

Parallel Query

# Parallel Query

Parallel query chart

Cursor Overview Chart

# Cursor Overview 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.

Per Host CPU Breakdown

# Per Host CPU Breakdown

CPU time broken down into parse, recursive and other

This chart includes the following data items:

- Parse CPU %

- Recursive CPU %

- Other CPU %

Tablespace Overview

# Tablespace Overview

Tablespace statistics, status, percent free space, free bytes, etc.

Redo Analysis

# Redo Analysis

This chart is intended to show different statistics that indicate the overall health of the Redo Log and the LGWR activity.

Timed Statistics

# Timed Statistics

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:

- TIMED_STATISTICS

SGA Overview

# SGA Overview

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.

- Parses: If an application makes a parse call for a SQL statement and the parsed representation of the statement does not already exist in a shared SQL area in the library cache, Oracle parses the statement and allocates a shared SQL area. You may be able to reduce library cache misses on parse calls by ensuring that SQL statements can share a shared SQL area whenever possible.
- Pins or Executes: If an application makes an execute call for a SQL statement and the shared SQL area containing the parsed representation of the statement has been de-allocated from the library cache to make room for another statement, Oracle implicitly reparses the statement, allocates a new shared SQL area for it, and executes it.

Host Total CPU Time

# Host Total CPU Time

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:

- Total CPU Time %

Program Total CPU Time

# Program Total CPU Time

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:

- Total CPU Time %

Summed Dirty Queue Length

# Summed Dirty Queue Length

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:

- Summed Dirty Queue Length

- Write Requests

DBWR Efficiency Statistics

# DBWR Efficiency Statistics

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:

- Avg Dirty Queue Length

- Dirty Buffers per Free Req

DBWR Analysis

# DBWR Analysis

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.

Database Health

# Database Health

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.

Redo Size per Second

# Redo Size per Second

Amount of redo generated per second in bytes

This chart includes the following data items:

- Redo Size/Sec

Blocks Per I/O

# Blocks Per I/O

Average number of blocks read/write to/from each file per I/O operation

This chart includes the following data items:

- Physical Blocks/Reads

- Physical Blocks/Writes

I/O Time

# I/O Time

This chart shows the average amount of time a I/O operation takes for the particular file.

This chart includes the following data items:

- Read Time

- Write Time

Tables Referenced by this Query

# Tables Referenced by this Query

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:

- Last Analyzed

- Rows

- Chained Rows Percent

Soft Parse %

# Soft Parse %

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:

- Soft Parse %

Top Sessions by Hard Parse Count

# Top Sessions by Hard Parse Count

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:

- Session Name

- OS Username

- Sort Statistic

- Status

- Machine

- Terminal

- Program

- Module

- Action

- Serial #

- SPID

- Physical Reads(%)

- Commit Count

- Rollback Count

- Execute Count

- Parse Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time

- Parse CPU

- Recursive CPU

- Block Gets

- Consistent Gets

- Physical Reads

- Block Changes

- Consistent Changes

- Disk Sorts

- Memory Sorts

- Sort Rows

- Parse Count (Hard)

- Parse Count Total

- Parse Elapsed Time

- UGA Memory

- Logon Time

- Logical Reads(%)

Top Sessions by Rows Sorted

# Top Sessions by Rows Sorted

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:

- Session Name

- OS Username

- Sort Statistic

- Status

- Machine

- Terminal

- Program

- Module

- Action

- Serial #

- SPID

- Physical Reads(%)

- Commit Count

- Rollback Count

- Execute Count

- Parse Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time

- Parse CPU

- Recursive CPU

- Block Gets

- Consistent Gets

- Physical Reads

- Block Changes

- Consistent Changes

- Disk Sorts

- Memory Sorts

- Sort Rows

- Parse Count (Hard)

- Parse Count Total

- Parse Elapsed Time

- UGA Memory

- Logon Time

- Logical Reads(%)

Top Sessions by Physical Reads

# Top Sessions by Physical Reads

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:

- Session Name

- OS Username

- Sort Statistic

- Status

- Machine

- Terminal

- Program

- Module

- Action

- Serial #

- SPID

- Physical Reads(%)

- Commit Count

- Rollback Count

- Execute Count

- Parse Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time

- Parse CPU

- Recursive CPU

- Block Gets

- Consistent Gets

- Physical Reads

- Block Changes

- Consistent Changes

- Disk Sorts

- Memory Sorts

- Sort Rows

- Parse Count (Hard)

- Parse Count Total

- Parse Elapsed Time

- UGA Memory

- Logon Time

- Logical Reads(%)

All SQL in the Cache that Access this Table

# All SQL in the Cache that Access this Table

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

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Open Cursors for this Session

# Open Cursors for this Session

This chart shows all of the current cursors (SQL statements) that this session has open. The statistics shown in Top Sessions chart will include statistics from all these queries, as well previous cursors that may have been executed and closed.

This chart includes the following data items:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Library Cache Eating SQL Statements

# Library Cache Eating SQL Statements

This chart lists SQL statements that are same within the first 50 characters. Statements that are the same except for literals that are used in the "WHERE" clause could potentially be rewritten to use bind variables. Re-parsing of basically the same SQL statement wastes time and resources. If your library cache hit rate is low, the queries listed here may be your largest offenders.

This chart includes the following data items:

- Count

Details of Similar SQL statements

# Details of Similar SQL statements

This chart allows you to view the text and statistics of all statements that match the first 50 characters of a chosen query string. From the information shown on this screen the user should be able to fully identify the query and decide whether it is a valid candidate to be rewritten to help avoid hard parses and library cache aging.

This chart includes the following data items:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Redo Allocation Retries

# Redo Allocation Retries

This chart shows the number of times that redo allocation failed.

When LGWR writes redo entries from the redo log buffer to a redo log file or disk, user processes can then copy new entries over the entries in memory that have been written to disk. LGWR normally writes fast enough to ensure that space is always available in the buffer for new entries, even when access to the redo log is heavy.

The value of REDO BUFFER ALLOCATION RETRIES should be near zero. If this value increments consistently, processes have had to wait for space in the buffer. The wait may be caused by the log buffer being too small or by checkpointing. Increase the size of the redo log buffer, if necessary, by changing the value of the initialization parameter LOG_BUFFER. The value of this parameter, expressed in bytes, must be a multiple of DB_BLOCK_SIZE. Alternatively, improve the checkpointing or archiving process.

This chart includes the following data items:

- Redo Allocation Retries

Buffer and Library Cache Hit %

# Buffer and Library Cache Hit %

This chart gives a high level view of the efficiency of the buffer cache and the library cache. Drilldowns are available for both metrics. In both cases cache utilization should be near %95.

This chart includes the following data items:

- Buffer Cache Hit %

- Library Cache Hit %

User Session Details

# User Session Details

For a selected USER detailed information, similiar to information found in the Top Sessions chart is displayed.

This chart includes the following data items:

- Parse Count

- Execute Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time %

- Parse CPU %

- Recursive CPU %

- Other CPU %

- Block Gets/Sec

- Consistent Gets/Sec

- Physical Reads/Sec

- Disk Read Ratio

- Block Changes/Sec

- Consistent Changes/Sec

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

- Disk/Memory Sorts Ratio

- Disk Sorts/Sort Rows Ratio

- Parse Count (Hard)/Sec

- Parse Count (Total)/Sec

- Parse Elapsed Time

- UGA Memory

- Avg. Wait Time per Parse

- Executes/Sec

- Serial#

Program Session Details

# Program Session Details

For a selected program detailed information, similiar to information found in the Top Sessions chart is displayed.

This chart includes the following data items:

- Parse Count

- Execute Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time %

- Parse CPU %

- Recursive CPU %

- Other CPU %

- Block Gets/Sec

- Consistent Gets/Sec

- Physical Reads/Sec

- Disk Read Ratio

- Block Changes/Sec

- Consistent Changes/Sec

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

- Disk/Memory Sorts Ratio

- Disk Sorts/Sort Rows Ratio

- Parse Count (Hard)/Sec

- Parse Count (Total)/Sec

- Parse Elapsed Time

- UGA Memory

- Avg. Wait Time per Parse

- Executes/Sec

- Serial#

Machine Session Details

# Machine Session Details

For a selected machine name detailed information, similiar to information found in the Top Sessions chart is displayed.

This chart includes the following data items:

- Parse Count

- Execute Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time %

- Parse CPU %

- Recursive CPU %

- Other CPU %

- Block Gets/Sec

- Consistent Gets/Sec

- Physical Reads/Sec

- Disk Read Ratio

- Block Changes/Sec

- Consistent Changes/Sec

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

- Disk/Memory Sorts Ratio

- Disk Sorts/Sort Rows Ratio

- Parse Count (Hard)/Sec

- Parse Count (Total)/Sec

- Parse Elapsed Time

- UGA Memory

- Avg. Wait Time per Parse

- Executes/Sec

- Serial#

SQL Hard Parse Analysis

# SQL Hard Parse Analysis

The Top Sessions by Hard Parse Count chart will show you which sessions are incurring the most hard parses.

Hard parses happen when the server parses a query and cannot find an exact match for the query in the library cache. Hard parses can be avoided by sharing SQL statements efficiently. The use of bind variables instead of literals in queries is one method to increase sharing.

This chart, by showing you which sessions are incurring the most hard parses, may lead you to the application or programs that are the best candidates for SQL rewrites.

The Library Cache Eating SQL Chart will show you which statements are similar in the first 'n' characters and how many versions of that statement segment are in the cache. Hard parses can also be forced by aging of SQL statements out of the cache due to an insufficient size of the shared pool area. The shared pool sizes allows you to see your current shared pool allocation and potentially increase it.

SQL 'Other' CPU Analysis

# SQL 'Other' CPU Analysis

This group of charts helps investigate areas that might be consuming CPU time. The moving of data between buffers and disk consumes lots of CPU time. The Top SQL by Buffer Gets shows SQL statements that require a lot of buffers from the cache. This processing takes time. Similarly, Top Sessions by Physical Reads shows sessions that are forcing I/O, which in turn results in CPU processing within the buffer cache.

Open SQL Cursors Sorted by Physical Reads

# Open SQL Cursors Sorted by Physical Reads

This chart shows the cursors the session currently has open. If the session opens and closes cursors frequently, you may only see the current SQL statement. The SQL statements are ordered by the number of physical reads they have performed.

This chart includes the following data items:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Open SQL Cursors Sorted by Parse Calls

# Open SQL Cursors Sorted by Parse Calls

This chart shows the cursors the session currently has open. If the session opens and closes cursors frequently, you may only see the current SQL statement. The SQL statements are ordered by the number of times they have been parsed.

This chart includes the following data items:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

Sessions Waiting for this Event

# Sessions Waiting for this Event

This chart will allow you to see the sessions that are stuck waiting on the particular event. All the standard drilldowns are available to dig further into any of the sessions.

This chart includes the following data items:

- Parse Count

- Execute Count

- Session Cursor Cache Hits

- Session Cursor Cache Count

- Total CPU Time %

- Parse CPU %

- Recursive CPU %

- Other CPU %

- Block Gets/Sec

- Consistent Gets/Sec

- Physical Reads/Sec

- Disk Read Ratio

- Block Changes/Sec

- Consistent Changes/Sec

- Disk Sorts/Sec

- Memory Sorts/Sec

- Sort Rows/Sec

- Disk/Memory Sorts Ratio

- Disk Sorts/Sort Rows Ratio

- Parse Count (Hard)/Sec

- Parse Count (Total)/Sec

- Parse Elapsed Time

- UGA Memory

- Avg. Wait Time per Parse

- Executes/Sec

- Serial#

SQL Statements Waiting for this Event

# SQL Statements Waiting for this Event

This list shows the SQL statements that are currently waiting on this particular event. From this list, you may be able to determine which ojbects are in contention and look to reorganize your application, rewrite the SQL, or reorganize the underlying objects.

This chart includes the following data items:

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

MTS Load

# MTS Load

This chart provides an overall picture of how busy the average dispatcher and server processes are. Also, it provides an indicator current proximity to server process limit, and peak server percentage.

This chart includes the following data items:

- Servers Busy %

- Dispatchers Busy %

- % Current Servers of Max

- % Peak Servers of Max

Server Types and Counts

# Server Types and Counts

This chart displays the current number of server, and dispatcher processes.

This chart includes the following data items:

- Dedicated Servers

- Current Shared Servers

- Dispatchers

MTS Server Start/Stops

# MTS Server Start/Stops

This charts shows a how often servers are being started and stopped. The values are normalized to a per second value, such that they can be valid over a range of sample frequencies.

This chart includes the following data items:

- Servers Started/Sec

- Servers Terminated/Sec

Dispatcher Contention

# Dispatcher Contention

This shows chart shows how busy the average dispatcher is for the various connection types currently configured on the system. Also reported is the amount of time the average request waits in the queue for this dispatcher class.

This chart includes the following data items:

- Busy Rate

- Avg Wait

Dispatcher Statistics

# Dispatcher Statistics

This chart shows the various statistics available for each dispatcher.

This chart includes the following data items:

- Status

- Accept

- Messages/sec

- Bytes/sec

- Owned

- Idle

- Busy

- % Busy

- % Idle

- Avg Wait Per Response

Shared Server Statistics

# Shared Server Statistics

This chart shows the various statistics available for each shared server process.

This chart includes the following data items:

- Status

- Requests/Sec

- Idle

- Busy

- % Busy

- Circuit Name

MTS at a Glance

# MTS at a Glance

Group chart of interesting MTS statistics

Blocking/Waiting Locks Chart

# Blocking/Waiting Locks Chart

Statistics for blocking/waiting locks

This chart includes the following data items:

- Session Id

- Session Serial Number

- Process Id

- Lock Type

- Mode Held

- Mode Requested

- Object Name

- ROWID

- Object Owner

- Object Type

- Resource ID1

- Resource ID2

User Type Locks Chart

# User Type Locks Chart

Statistics for user type locks

This chart includes the following data items:

- Session Id

- Session Serial Number

- Process Id

- Lock Type

- Mode Held

- Mode Requested

- Object Name

- ROWID

- Object Owner

- Object Type

- Resource ID1

- Resource ID2

I/O Rates per Trans

# I/O Rates per Trans

Database I/O per transaction

This chart includes the following data items:

- Physical Reads/Trans

- Physical Writes/Trans

- Logical Reads/Trans

- Phy Reads Direct/Trans

Table Scan per Trans

# Table Scan per Trans

Various classes of table scans per transaction

This chart includes the following data items:

- Table Scans(Long)/Trans

- Table Scans(Short)/trans

- Rows Gotten Per Table Scan

- Table Scan Rows/Trans

Network Bytes per Trans

# Network Bytes per Trans

Number of bytes sent/received via the network per transaction

This chart includes the following data items:

- Network Bytes/Trans

Segments Currently Being Waited On

# Segments Currently Being Waited On

This chart is a drilldown from a higher level chart that lists wait events. For wait events that are waiting for a read or a write to a specific block within a file, this chart will identify the segment that contains the block.

This chart includes the following data items:

- Segment Name

- Block Id

Wait Event File and Block Counts

# Wait Event File and Block Counts

This chart lists the number of files and blocks individual sessions are waiting on. This chart is a drilldown from a higher level chart that lists wait events. For the particular wait event that was chosen, you will see the individual waits and their file and block counts. Most of the write waits are related to DBWR performance.

This chart includes the following data items:

- Files

- Blocks

Cache Buffers Chains Analysis

# Cache Buffers Chains Analysis

There is high contention via the cache buffers chains latch for these blocks in the buffer cache. The segment to which these blocks belong should be identified. You should determine why these particular blocks are in demand and try to reduce the contention on them.

Throughput Rates

# Throughput Rates

This chart gives you a high level view of the transaction rates, both successful and unsuccessful. It also provides insight into how often users are logging in to the system. If the logon rate is high, then perhaps a very inefficient application is doing a connect, query, disconnect for each piece of information.

This chart includes the following data items:

- Logons/Sec

- Commits/Sec

- Rollbacks/Sec

- User Calls/Sec

- Recursive Calls/Sec

- Enqueue Waits/Sec

Gets and Changes Rates

# Gets and Changes Rates

Block and consistent get and change rates

This chart includes the following data items:

- Consistent Gets/Sec

- Consistent Changes/Sec

- Block Gets/Sec

- Block Changes/Sec

Instance Efficiency

# Instance Efficiency

Statistics that show database efficiency

Instance Activity

# Instance Activity

Statistics that show activity in the database

Database Health (Work in Progress)

# Database Health (Work in Progress)

Statistics to determine database health

Hit Ratios

# Hit Ratios

Various hit ratios

This chart includes the following data items:

- Buffer Cache Hit %

- Library Cache Hit %

- Redo No Wait %

- Memory Sort %

- Soft Parse %

- Latch %

Top 5 Sessions

# Top 5 Sessions

Top 5 Sessions ordered by % Physical Reads

This chart includes the following data items:

- Session Name

- Physical Reads(%)

- Logical Reads(%)

- Physical Reads

- Total CPU Time

- Parse Count (Hard)

Top 5 Waits by Time

# Top 5 Waits by Time

Top 5 wait events ordered by time waited, count

This chart includes the following data items:

- Wait Time

- Number Waits

Session Counts

# Session Counts

Active and inactive session counts

Latch Hit %

# Latch Hit %

How often latches are granted without waiting

This chart includes the following data items:

- Latch %

Redo Alloc No Wait %

# Redo Alloc No Wait %

How often redo entries are allocated without having to wait

This chart includes the following data items:

- Redo No Wait %

Current SQL

# Current SQL

This is the SQL statement the session is executing currently or the statement that was last executed.

This chart includes the following data items:

- SID

- SQL Text

- Module

- Action

- Physical Reads

- % Physical Reads

- Buffer Gets

- % Buffer Gets

- Executions/Sec

- Parse Calls/Sec

- Physical Reads/Sec

- Buffer Gets/Sec

- Rows Processed/Sec

- Total Shareable Memory

- Total Persistent Memory

- Runtime Memory

AQ Statistics

# AQ Statistics

Oracle Advanced Queuing keeps statistics about the current state of the queuing system as well as time-interval statistics in the dynamic table GV$AQ. Statistics about the current state of the queuing system include the numbers of ready, waiting, and expired messages. This chart displays the number of messages in each state (ready, waiting, and expired)

This chart includes the following data items:

- Waiting

- Ready

- Expired

AQ Wait Times

# AQ Wait Times

Oracle Advanced Queuing keeps statistics about the current state of the queuing system as well as time-interval statistics in the dynamic table GV$AQ. Statistics about the current state of the queuing system include the numbers of ready, waiting, and expired messages. This chart displays the average wait time of waiting messages and the total wait time of waiting messages.

This chart includes the following data items:

- Total Wait Time

- Avg Wait Time

Parallel Server Ping

# Parallel Server Ping

Totol Ping for an OPS database

Parallel Server Instance Ping

# Parallel Server Instance Ping

Ping Count by Instance

Parallel Server Ping By File

# Parallel Server Ping By File

Ping Count by File

File Ping By Instance

# File Ping By Instance

Ping Count by instance for a file

Parallel Server Ping By Block Class

# Parallel Server Ping By Block Class

Ping Count by Class

Parallel Server Ping By Object

# Parallel Server Ping By Object

Ping count by Object

Object Ping By Instance

# Object Ping By Instance

how each instance contribute to a object

Maximum Ping By Block

# Maximum Ping By Block

most frequently pinged block

Maximum Ping By Block for a object

# Maximum Ping By Block for a object

most frequently pinged block for a object

Global Cache Timeouts

# Global Cache Timeouts

showing timeouts and waits

Global Cache CR Timeouts By Instance

# Global Cache CR Timeouts By Instance

Request for a consistent read block and timed out.

Global Cache Convert Timeouts By Instance

# Global Cache Convert Timeouts By Instance

High contention or I/O workload on the disk

Global Cache Freelist Waits By Instance

# Global Cache Freelist Waits By Instance

usage of releasable locks

Global Cache CR Request

# Global Cache CR Request

cr requests

Global Cache CR Request By Instance

# Global Cache CR Request By Instance

cr requests

Global Cache Lock Convert

# Global Cache Lock Convert

cr convert

Global Cache Lock Convert By Instance

# Global Cache Lock Convert By Instance

cr convert by instance

OPS System Event

# OPS System Event

System Waits

Library Cache Lock

# Library Cache Lock

library cache locks

Library Cache Lock by Instance

# Library Cache Lock by Instance

library cache locks by instance

Row Cache Lock Chart

# Row Cache Lock Chart

row cache

Row Cahce Lock Chart by Instance

# Row Cahce Lock Chart by Instance

Row cache by instance

Per Trans. Sorts and Scans

# Per Trans. Sorts and Scans

Sort and Tablescan statistics

This chart includes the following data items:

- Disk Sorts/Trans

- Memory Sorts/Trans

- Sort Rows/Trans

- Short Table Scans/Trans

- Long Table Scans/Trans

Per Trans. Memory Sort Ratio

# Per Trans. Memory Sort Ratio

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:

- Disk Sorts/Trans

- Memory Sorts/Trans

Per Trans. Throughput Rates

# Per Trans. Throughput Rates

This chart gives you a high level view of the transaction rates, both successful and unsuccessful. It also provides insight into how often users are logging in to the system. If the logon rate is high, then perhaps a very inefficient application is doing an attach, query, detach for each piece of information.

This chart includes the following data items:

- Logons/Trans

- Commits/Trans

- Rollbacks/Trans

- User Calls/Trans

- Recursive Calls/Trans

- Enqueue Waits/Trans

Per Trans. Call Rates

# Per Trans. Call Rates

Instance-wide statistics in various call categories

This chart includes the following data items:

- User Calls/Trans

- Recursive Calls/Trans

Per Trans. Buffer Pinned Counts

# Per Trans. Buffer Pinned Counts

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:

- Buffer pinned : This statistic measures the number of times a buffer was already pinned by a client when a client checks to determine if the buffer it wants is already pinned.
- Buffer not pinned : This statistic measures the number of times the buffer was not pinned by the client when a client checks to determine if the buffer it wants is already pinned.

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:

- Buffer is pinned/Trans

- Buffer is not pinned/Trans

Per Trans. Parse Statistics

# Per Trans. Parse Statistics

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:

- Is the application spending too much time opening and closing cursors?
- Ensure the application is using bind variables
- If applications open/re-parse the same statement,set SESSION_CACHED_CURSORS to the number of cursors used by the session
- Check that compiler flags RELEASE_CURSORS = NO and HOLD_CURSORS = yes
- Check programs for re-parsing statements before execute instead of using bind variables

This chart includes the following data items:

- Parses/Trans

- Hard Parses/Trans

- Executes/Trans

Per Trans. Free Buffer Statistics

# Per Trans. Free Buffer Statistics

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:

- Free Buff Inspected/Trans

- Free Buff Requested/Trans

- Dirty Buff Inspected/Trans

Per Trans. Gets and Changes Rates

# Per Trans. Gets and Changes Rates

Block and consistent get and change rates

This chart includes the following data items:

- Consistent Gets/Trans

- Consistent Changes/Trans

- Block Gets/Trans

- Block Changes/Trans

html/DBACB0.htm
Kill Session

# Kill Session

Kill the selected session

html/DBACB1.htm
Turn On Timed Statistics

# Turn On Timed Statistics

Enable the tracking of elapsed time and CPU time metrics

html/DBACB2.htm
Analyze Table (FULL)

# Analyze Table (FULL)

Analyze Table to get statistic information.

html/DBACB3.htm
Analyze Table (Estimate 10%)

# Analyze Table (Estimate 10%)

Analyze Table by sampling 10% of the data to get statistic information.

html/DBACB4.htm
Analyze Table (Estimate 25%)

# Analyze Table (Estimate 25%)

Analyze Table by sampling 25% of the data to get statistic information.

html/DBACB5.htm
Turn SQL Trace On

# Turn SQL Trace On

Turn SQL TRACE ON for this session

html/DBACB6.htm
Turn SQL Trace Off

# Turn SQL Trace Off

Turn SQL TRACE OFF for this session

html/DBACB7.htm
SQL Analyze

# SQL Analyze

SQL Analyze - SQL tuning tool

html/DBACB8.htm
Instance Manager

# Instance Manager

Instance Manager - tool to modify init.ora parameters

Instance Response Time

# Instance Response Time

Response time calculated across all update and insert transactions

This class includes the following charts:

- Avg. Trans. Length in Seconds

- Transaction and Statement Execution Rates

- Elapsed Time per Execute

- Wait or CPU Bound?

Instance Response Time Default Chart
Instance Response Time Default Chart

Response time calculated across all update and insert transactions

% Wait Time

## % Wait Time

#### Description

This data item represents the percentage of time spent waiting, instance-wide, for resources or objects during this sample period.

#### Data Source

DeltaTotalWait / (DeltaTotalWait + DeltaCpuTime)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session' between sample end and start

#### User Action

Investigate further into which specific wait events are responsible for the bulk of the wait time. Individual wait events may identify unique problems within the database. Diagnosis will be tailored where appropriate through drilldowns specific to individual wait events.

% CPU Time

## % CPU Time

#### Description

This data item represents the percentage of time, instance-wide, spent executing instructions by the CPU during this sample period.

#### Data Source

DeltaCpuTime / (DeltaTotalWait + DeltaCpuTime)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session' between sample end and start

#### User Action

When CPU is the largest contributor to total reponse time, it needs to be broken down to properly understand the problem further. Basically, CPU Time is broken down into the following categories:

- Parse CPU time: Amount of CPU used for parsing SQL statements.
- Recursive CPU: Amount of CPU used for parsing row cache statements such as lookups in the data dictionary, executing triggers, PL/SQL, etc.
- Other CPU: Amount of CPU used for tasks such as looking up buffers, fetching rows or index keys, etc.

Response Time Per Trans

## Response Time Per Trans

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per transaction during this sample period.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaCommits + DeltaRollbacks)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session'' between sample end and start
- DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start
- DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.

Transaction Count

## Transaction Count

#### Description

This data item represents the total number of commits and rollbacks performed during this sample period.

#### Data Source

DeltaCommits + DeltaRollbacks
where:

- DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start
- DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.

Commit Count

## Commit Count

#### Description

This data item represents the number of user commits performed during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits
where:

- DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.

Rollback Count

## Rollback Count

#### Description

This data item represents the number of times users manually issue the ROLLBACK statement or an error occurs during a user's transactions during the sample period.

#### Data Source

DeltaRollbacks
where:

- DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

This statistic shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.

Response Time Per Execute

## Response Time Per Execute

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per SQL statement execution. This statistic may be more valid than response time per transaction as it shows accurate values even for read-only access.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaUserCalls + DeltaRecursiveCalls)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session'' between sample end and start
- DeltaUserCalls: difference of 'select value from v$sysstat where name='user calls'' between sample end and start
- DeltaRecursiveCalls: difference of 'select value from v$sysstat where name='recursive calls'' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements during the sample period. This statistic is an indication of the number of SQL statements that are being processed per sample period.

#### Data Source

DeltaUserCalls + DeltaRecursiveCalls
where:

- DeltaUserCalls: difference of 'select value from v$sysstat where name='user calls'' between sample end and start
- DeltaRecursiveCalls: difference of 'select value from v$sysstat where name='recursive calls'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the execution rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually a drop in execution rates, and an increase in response time may be indicators of problems. Depending upon the application, execution loads may vary widely across different times of the day.

User Response Time

# User Response Time

Response time broken down by individual users

This class includes the following charts:

- Avg Trans. Length Per User

- User Transaction Rates (Insert/Update)

- User Elapsed Time per Execute

- User Elapsed Time Components

User Response Time Default Chart
User Response Time Default Chart

Response time broken down by individual users

% Wait Time

## % Wait Time

#### Description

This data item represents the percentage of time spent waiting by this session for resources or objects during this sample period.

#### Data Source

DeltaTotalWait / (DeltaTotalWait + DeltaCpuTime)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Investigate further into which specific wait events are responsible for the bulk of the wait time. Individual wait events may identify unique problems within the database. Diagnosis will be tailored where appropriate through drilldowns specific to individual wait events.

% CPU Time

## % CPU Time

#### Description

This data item represents the percentage of time this session spent executing instructions by the CPU during this sample period.

#### Data Source

DeltaCpuTime / (DeltaTotalWait + DeltaCpuTime)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start

#### User Action

When CPU is the largest contributor to total reponse time, it needs to be broken down to properly understand the problem further. Basically, CPU Time is broken down into the following categories:

- Parse CPU time: Amount of CPU used for parsing SQL statements.
- Recursive CPU: Amount of CPU used for parsing row cache statements such as lookups in the data dictionary, executing triggers, PL/SQL, etc.
- Other CPU: Amount of CPU used for tasks such as looking up buffers, fetching rows or index keys, etc.

Response Time Per Trans

## Response Time Per Trans

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per transaction during this sample period.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaCommits + DeltaRollbacks)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
- DeltaCommits: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user commits' and n.statistic#=s.statistic#' between sample end and start
- DeltaRollbacks: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user rollbacks' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.

Transaction Count

## Transaction Count

#### Description

This data item represents the total number of commits and rollbacks performed by this session during this sample period.

#### Data Source

DeltaCommits + DeltaRollbacks
where:

- DeltaCommits: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user commits' and n.statistic#=s.statistic#' between sample end and start
- DeltaRollbacks: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user rollbacks' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.

Commit Count

## Commit Count

#### Description

This data item represents the number of user commits performed by this session during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits
where:

- DeltaCommits: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user commits' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.

Rollback Count

## Rollback Count

#### Description

This data item represents the number of times this session manually issued a ROLLBACK statement or an error occurs during a session's transaction during the sample period.

#### Data Source

DeltaRollbacks
where:

- DeltaRollbacks: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user rollbacks' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.

Response Time Per Execute

## Response Time Per Execute

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per SQL statement execution. This statistic may be more valid than response time per transaction as it shows accurate values even for read-only access.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaUserCalls + DeltaRecursiveCalls)
where:

- DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
- DeltaCpuTime: difference of 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
- DeltaUserCalls: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#' between sample end and start
- DeltaRecursiveCalls: difference of 'select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) in this session that executed SQL statements during the sample period. This statistic is an indication of the number of SQL statements that are being processed per sample period.

#### Data Source

DeltaUserCalls + DeltaRecursiveCalls
where:

- DeltaUserCalls: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#' between sample end and start
- DeltaRecursiveCalls: difference of 'select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the execution rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually a drop in execution rates, and an increase in response time may be indicators of problems. Depending upon the application, execution loads may vary widely across different times of the day.

Instance Wait Events

# Instance Wait Events

Time spent waiting for individual events within the database

This class includes the following charts:

- Wait Events by Time

- Wait Event Counts

- Top 5 Waits by Time

Instance Wait Events Default Chart
Instance Wait Events Default Chart

Time spent waiting for individual events within the database

Wait Time

## Wait Time

#### Description

This data item represents the amount of time, in seconds, spent waiting for the event during the last sample period.

#### Data Source

DeltaTimeWaited
where:

- DeltaTimeWaited: difference of 'select time_waited from v$system_event' between sample end and start

#### User Action

Time spent waiting is time that could have been spent processing. Attacking the wait event with the largest wait time will probably produce the largest gain. Drilldowns are available to charts that are tailored to help diagnose and improve the performance of individual wait events.

Number Waits

## Number Waits

#### Description

This data item represents the number of waits for each event during the last sample period. The number of waits is not as important as the amount of time spent waiting. The wait count for an event will be updated even if the request for the event completed immediately.

#### Data Source

DeltaWaitCounts
where:

- DeltaWaitCounts: difference of 'select total_waits from v$system_event' between sample end and start

#### User Action

Number Timeouts

## Number Timeouts

#### Description

This data item represents the number of timeouts for each event during the last sample period.

#### Data Source

DeltaWaitTimeOuts
where:

- DeltaWaitTimeOuts: difference of 'select total_timeouts from v$system_event' between sample end and start

#### User Action

Instance Block Waits Being Waited For and the Wait Duration

# Instance Block Waits Being Waited For and the Wait Duration

Time spent waiting for individual events within the database

This class includes the following charts:

- Block Waits By Time

- Block Wait Counts

Instance Block Waits Being Waited For and the Wait Duration Default Chart
Instance Block Waits Being Waited For and the Wait Duration Default Chart

Time spent waiting for individual events within the database

Wait Time

## Wait Time

#### Description

This data item represents time spent waiting for the specific class of block during sample period.

#### Data Source

DeltaWait
where:

- DeltaWait: difference of 'select time from v$waitstat' between sample end and start

#### User Action

Total Waits/Sec

## Total Waits/Sec

#### Description

This data item represents the number of times the specific class of block was waited for per second during the sample period.

#### Data Source

DeltaWait / Seconds
where:

- DeltaWait: difference of 'select count from v$waitstat' between sample end and start
- Seconds: number of seconds in sample period

#### User Action

AQ Statistics

# AQ Statistics

AQ Queue statistics

This class includes the following charts:

- AQ Statistics

- AQ Wait Times

AQ Statistics Default Chart
AQ Statistics Default Chart

AQ Queue statistics

Queue Table Name

## Queue Table Name

Queue Table Name

Waiting

## Waiting

the number of messages in the state 'WAITING'

Ready

## Ready

the number of messages in state 'READY'

Expired

## Expired

the number of messages in state 'EXPIRED'

Total Wait Time

## Total Wait Time

the number of seconds for which messages in the queue have been waiting in state 'READY'

Avg Wait Time

## Avg Wait Time

the average number of seconds a message in state 'READY' has been waiting to be dequeued

Top SQL

# Top SQL

Top N SQL statements ordered by a particular resource

This class includes the following charts:

- Top SQL (Physical Reads)

- Top SQL (Buffer Gets)

Top SQL Default Chart
Top SQL Default Chart

Top N SQL statements ordered by a particular resource

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

File Statistics

# File Statistics

This class breaks down I/O activity on a per file basis

This class includes the following charts:

Average Cost of I/O

File Write Operations

File Read Operations

Blocks Per I/O

I/O Time

File Statistics Default Chart
File Statistics Default Chart

This class breaks down I/O activity on a per file basis

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads from this datafile per second during the sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select phyrds from v$filestat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Writes/Sec

## Physical Writes/Sec

#### Description

This data item represents the number of physical writes to this datafile per second during the sample period.

#### Data Source

DeltaPhysicalWrites / Seconds
where:

DeltaPhysicalWrites: difference in 'select phywrts from v$filestat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Block Reads/Sec

## Physical Block Reads/Sec

#### Description

This data item represents the number of physical blocks read from this datafile per second during the sample period.

#### Data Source

DeltaPhysicalBlockReads / Seconds
where:

DeltaPhysicalBlockReads: difference in 'select phyblkrd from v$filestat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Block Writes/Sec

## Physical Block Writes/Sec

#### Description

This data item represents the number of physical blocks written to this datafile per second during the sample period.

#### Data Source

DeltaPhysicalBlockWrites / Seconds
where:

DeltaPhysicalBlockWrites: difference in 'select phyblkwrt from v$filestat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Read Time

## Read Time

#### Description

This data item represents the time spent doing reads from this datafile during the sample period. This value will always be 0 unless the TIMED_STATISTICS parameter is TRUE.

#### Data Source

DeltaReadTime
where:

DeltaReadTime: difference in 'select readtim from v$filestat' between sample end and start

#### User Action

Write Time

## Write Time

#### Description

This data item represents the time spent doing writes to this datafile during the sample period. This value will always be 0 unless the TIMED_STATISTICS parameter is TRUE.

#### Data Source

DeltaWriteTime
where:

DeltaWriteTime: difference in 'select writetim from v$filestat' between sample end and start

#### User Action

Average time/Read

## Average time/Read

#### Description

This data item represents the average time spent performing a read from this datafile during the sample period. This value will always be 0 unless the TIMED_STATISTICS parameter is TRUE.

#### Data Source

DeltaReadTime / DeltaPhysicalReads
where:

DeltaReadTime: difference in 'select readtim from v$filestat' between sample end and start
DeltaPhysicalReads: difference in 'select phyrds from v$filestat' between sample end and start

#### User Action

Average time/Write

## Average time/Write

#### Description

This data item represents the average time spent performing a write to this datafile during the sample period. This value will always be 0 unless the TIMED_STATISTICS parameter is TRUE.

#### Data Source

DeltaWriteTime / DeltaPhysicalWrites
where:

DeltaWriteTime: difference in 'select writetim from v$filestat' between sample end and start
DeltaPhysicalWrites: difference in 'select phywrts from v$filestat' between sample end and start

#### User Action

Physical Blocks/Reads

## Physical Blocks/Reads

#### Description

This data item represents the number of blocks read per read from this datafile during the sample period. A value close to 1 denotes the fact that single block reads are occurring.

#### Data Source

DeltaPhysicalBlockReads / DeltaPhysicalReads
where:

DeltaPhysicalBlockReads: difference in 'select phyblkrd from v$filestat' between sample end and start
DeltaPhysicalReads: difference in 'select phyrds from v$filestat' between sample end and start

#### User Action

Physical Blocks/Writes

## Physical Blocks/Writes

#### Description

This data item represents the number of blocks written per write to this datafile during the sample period. A value close to 1 denotes the fact that single block writes are occurring.

#### Data Source

DeltaPhysicalBlockWrites / DeltaPhysicalWrites
where:

DeltaPhysicalBlocksReads: difference in 'select phyblkwrt from v$filestat' between sample end and start
DeltaPhysicalWrites: difference in 'select phywrts from v$filestat' between sample end and start

#### User Action

Latches

# Latches

Latch statistics - only latches with sleeps,spins,waiters,misses > 0 shown

This class includes the following charts:

Latch Sleeps

Latch Get/Miss Rates

Latch Contention (>1% potential problem)

Latches Default Chart
Latches Default Chart

Latch statistics - only latches with sleeps,spins,waiters,misses > 0 shown

Gets/Sec

## Gets/Sec

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of successful willing-to-wait requests for the latch per second during this sample period.

#### Data Source

DeltaGets / Seconds
where:

DeltaGets: difference in 'select gets from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Spin Gets/Sec

## Spin Gets/Sec

#### Description

If a process is not able to obtain a latch right away, it must wait for the latch. This causes a slowdown to occur and results in additional CPU usage, until a latch is available. The CPU usage is a consequence of the "spinning" of the process. "Spinning" means that the process continues to look for the availability of that latch after fixed intervals of time, during which it sleeps. It continues to spin until a latch is available.

This data item represents the number of times per second during this sample period where an attempt to obtain a specific latch failed on the first attempt but succeeded after a spin.

#### Data Source

DeltaSpinGets / Seconds
where:

DeltaSpinGets: difference in 'select spin_gets from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Misses/Sec

## Misses/Sec

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times an initial willing-to-wait request for the latch was unsuccessful per second during this sample period.

#### Data Source

DeltaMisses / Seconds
where:

DeltaMisses: difference in 'select misses from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Sleeps/Sec

## Sleeps/Sec

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times per second during this sample period where a process waited for the requested latch after an initial willing-to-wait request.

#### Data Source

DeltaMisses / Seconds
where:

DeltaMisses: difference in 'select misses from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Waiters Woken/Sec

## Waiters Woken/Sec

#### Description

This data item represents the number of times this latch's wait was awakened per second during this sample period.

#### Data Source

DeltaWaitersWoken / Seconds
where:

DeltaWaitersWoken: difference in 'select waiters_woken from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Waiters Holding/Sec

## Waiters Holding/Sec

#### Description

This data item represents the number of times this latch waited while holding a different latch per second during this sample period

#### Data Source

DeltaWaitersWoken / Seconds
where:

DeltaWaitersWoken: difference in 'select waiters_woken from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Immediate Gets/Sec

## Immediate Gets/Sec

#### Description

If the latch requested with an immediate request and that latch is not available, the requesting process does not wait, but continues processing.

This data item represents the number of successful immediate requests for this latch per second for this sample period.

#### Data Source

DeltaImmediateGets / Seconds
where:

DeltaImmediateGets: difference in 'select immediate_gets from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Immediate Misses/Sec

## Immediate Misses/Sec

#### Description

If the latch requested with an immediate request and that latch is not available, the requesting process does not wait, but continues processing.

This data item represents the number of unsuccessful immediate requests for this latch per second for this sample period.

#### Data Source

DeltaImmediateMisses / Seconds
where:

DeltaImmediateMisses: difference in 'select immediate_misses from v$latch' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Miss/Get Ratio

## Miss/Get Ratio

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the percentage of times during this sample period an attempt a willing-to-wait request for this latch failed on first try.

#### Data Source

(DeltaMisses / DeltaGets) * 100
where:

DeltaMisses: difference in 'select misses from v$latch' between sample end and start
DeltaGets: difference in 'select gets from v$latch' between sample end and start

#### User Action

Immediate Miss Ratio

## Immediate Miss Ratio

#### Description

If the latch requested with an immediate request and that latch is not available, the requesting process does not wait, but continues processing.

This data item represents the percentage of times during this sample period an immediate request for this latch failed on first try.

#### Data Source

(DeltaImmediateMisses / (DeltaImmediateGets + DeltaImmediateMisses)) * 100
where:

DeltaImmediateMisses: difference in 'select immediate_misses from v$latch' between sample end and start
DeltaImmediateGets: difference in 'select immediate_gets from v$latch' between sample end and start

#### User Action

Level#

## Level#

#### Description

A latch is a type of a lock that can be very quickly aquired and freed. Latches are typically used to prevent more than one process from executing the same piece of code at a given time. Latches have an associated level that is used to prevent deadlocks. Once a process acquires a latch at a certain level it cannot subsequently acquire a latch at a level that is equal to or less than that level (unless it acquires it nowait).

This data item represents the latch level.

#### Data Source

select level# from v$latch

#### User Action

Slept Once

## Slept Once

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times during this sample period where a process waited 1 time for the requested latch after an initial willing-to-wait request.

#### Data Source

select sleep1 from v$latch

#### User Action

Slept Twice

## Slept Twice

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times during this sample period where a process waited 2 times for the requested latch after an initial willing-to-wait request.

#### Data Source

select sleep2 from v$latch

#### User Action

Slept Three Times

## Slept Three Times

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times during this sample period where a process waited 3 times for the requested latch after an initial willing-to-wait request.

#### Data Source

select sleep3 from v$latch

#### User Action

Slept Four Times

## Slept Four Times

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the number of times during this sample period where a process waited 4 times for the requested latch after an initial willing-to-wait request.

#### Data Source

select sleep4 from v$latch

#### User Action

Instance Statistics

# Instance Statistics

Instance-wide statistics

This class includes the following charts:

Hit Ratios

Latch Hit %

Cursor Cache Hit %

Buffer Cache Hit %

Library Cache Hit %

Recursive Call to User Call Ratio

Redo Alloc No Wait %

Soft Parse %

Instance-Wide CPU Breakdown

Buffer and Library Cache Hit %

Memory Sort %

Rows per Sort

Max Sort Allocation

Instance Statistics Default Chart
Instance Statistics Default Chart

Instance-wide statistics

Cursor Cache Hits

## Cursor Cache Hits

#### Description

This data item represents the percentage of times a parse call found a cursor in the session cursor cache.

#### Data Source

(DeltaCursorHits / (DeltaParseCount)) * 100
where:

DeltaCursorHits: difference in 'select value from v$sysstat where name='parse count (total)'' between sample end and start
DeltaParseCount: difference in 'select value from v$sysstat where name='session cursor cache hits'' between sample end and start

#### User Action

If this statistic is a relatively low percentage of the total parse call count for the session, consider setting SESSION_CACHED_CURSORS to a larger value, provided it does not have a negative impact on Operating System paging and swapping activity.
Buffer Cache Hit %

## Buffer Cache Hit %

#### Description

This data item represents the data block buffer cache efficiency, as measured by the percentage of times the data block requested by the query is 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.

#### Data Source

((DeltaLogicalGets - (DeltaPhysicalReads - DeltaPhysicalReadsDirect)) / DeltaLogicalGets) * 100
where:

DeltaLogicalGets: difference in 'select value from v$sysstat where name='session logical reads'' between sample end and start
DeltaPhysicalReads: difference in 'select value from v$sysstat where name='physical reads'' between sample end and start
DeltaPhysicalReadsDirect: difference in 'select value from v$sysstat where name='physical reads direct'' between sample end and start (Oracle 8.i)

#### User Action

The DB_BLOCK_BUFFERS initialization parameter determines the number of database buffers available in the buffer cache. It is one of the primary parameters which contribute to the total memory requirements of the SGA on the instance. The DB_BLOCK_BUFFERS parameter, together with the DB_BLOCK_SIZE parameter, controls the total size of the buffer cache. Since DB_BLOCK_SIZE can only be specified when the database is first created, normally the size of the buffer cache size is controlled using the DB_BLOCK_BUFFERS parameter.

Consider increasing the DB_BLOCK_BUFFERS initialization parameter to increase the size of the buffer cache. This increase allows the Oracle Server to keep more information in memory, thus reducing the number of I/O operations required to do an equivalent amount of work using the current cache size.
Recursive Calls/User Calls

## Recursive Calls/User Calls

#### Description

This data item represents the percentage of recursive calls to user calls.

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

#### Data Source

DeltaRecursiveCalls / DeltaUserCalls
where:

DeltaRecursiveCalls: difference in 'select value from v$sysstat where name='recursive calls'' between sample end and start
DeltaUserCalls: difference in 'select value from v$sysstat where name='user calls'' between sample end and start

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents or, if you are using Oracle 8.I, considering taking advantage of locally managed tablespaces.
Soft Parse %

## Soft Parse %

#### Description

A hard parse occurs when a SQL statement has to be loaded into the shared pool. In this case, the Oracle Server has to allocate memory in the shared pool and parse the statement. A soft parse is recorded when the Oracle Server checks the shared pool for a SQL statement and finds a version of the statement that it can reuse.

This data item represents the percentage of parse requests where the cursor was already in the cursor cache; in other words, the percentage of soft parses.

#### Data Source

((DeltaParseCountTotal - DeltaParseCountHard) / DeltaParseCountTotal) * 100
where:

DeltaParseCountTotal: difference in 'select value from v$sysstat where name='parse count (total)'' between sample end and start
DeltaParseCountHard: difference in 'select value from v$sysstat where name='parse count (hard)'' between sample end and start

#### User Action

% Parse CPU Time

## % Parse CPU Time

#### Description

This data item represents the percentage of CPU time spent parsing SQL statements. Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaTotalTime) * 100
where:

DeltaParseTime: difference in 'select value from v$sysstat where name='parse time cpu'' between sample end and start
DeltaTotalTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between sample end and start

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
% Recursive CPU Time

## % Recursive CPU Time

#### Description

This data item represents the percentage of time spent performing recursive calls.

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

#### Data Source

(DeltaRecursiveTime / DeltaTotalTime) * 100
where:

DeltaRecursiveTime: difference in 'select value from v$sysstat where name='recursive cpu usage'' between sample end and start
DeltaTotalTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between sample end and start

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents or, if you are using Oracle 8.I, considering taking advantage of locally managed tablespaces.
% Other CPU Time

## % Other CPU Time

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "Other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaTotalTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaTotalTime) * 100
where:

DeltaTotalTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between sample end and start
DeltaParseTime: difference in 'select value from v$sysstat where name='parse time cpu'' between sample end and start
DeltaRecursiveTime: difference in 'select value from v$sysstat where name='recursive cpu usage'' between sample end and start

#### User Action

It may be possible to reduce "Other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Library Cache Hit %

## Library Cache Hit %

#### Description

This data item represents the library cache efficiency, as measured by the percentage of times the fully parsed or compiled representation of PL/SQL blocks and SQL statements are already in memory.

The shared pool is an area in the SGA that contains the library cache of shared SQL requests, the dictionary cache and the other cache structures that are specific to a particular instance configuration.

The shared pool mechanism can greatly reduce system resource consumption in at least three ways:

Parse time is avoided if the SQL statement is already in the shared pool.
Application memory overhead is reduced, since all applications utilize the same pool of shared SQL statements and dictionary resources.
I/O resources are saved, since dictionary elements which are in the shared pool do not require access.

If the shared pool is too small, users will consume additional resources to complete a database operation. For library cache access, the overhead is primarily the additional CPU resources required to re-parse the SQL statement.

#### Data Source

(DeltaPinHits / DeltaPins) * 100
where:

DeltaPinHits: difference in 'select sum(pinhits) from v$librarycache' between sample end and start
DeltaPins: difference in 'select sum(pins) from v$librarycache' between sample end and start

#### User Action

The SHARED_POOL_SIZE initialization parameter controls the total size of the shared pool. Consider increasing the SHARED_POOL_SIZE to decrease the frequency in which SQL requests are being flushed from the shared pool to make room for new requests.

To take advantage of the additional memory available for shared SQL areas, you may also need to increase the number of cursors permitted per session. You can increase this limit by increasing the value of the initialization parameter OPEN_CURSORS.

Also, examine SQL statements which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Memory Sort %

## Memory Sort %

#### Description

This data item 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.

#### Data Source

(DeltaMemorySorts / (DeltaDiskSorts + DeltaMemorySorts)) * 100
where:

DeltaMemorySorts: difference in 'select value from v$sysstat where name='sorts (memory)'' between sample end and start
DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (disk)'' between sample end and start

#### User Action

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.
Rows/Sort

## Rows/Sort

#### Description

This data item represents the average number of rows per sort during this sample period.

#### Data Source

(DeltaSortRows / (DeltaDiskSorts + DeltaMemorySorts)) * 100
where:

DeltaSortRows: difference in 'select value from v$sysstat where name='sorts (rows)'' between sample end and start
DeltaMemorySorts: difference in 'select value from v$sysstat where name='sorts (memory)'' between sample end and start
DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (disk)'' between sample end and start

#### User Action

Maximum Sort Allocation

## Maximum Sort Allocation

#### Description

This data item represents the maximum amount of space, in blocks, allocated to all sorts.

#### Data Source

select sum(max_used_blocks) from v$sort_segment

#### User Action

Redo No Wait %

## Redo No Wait %

#### Description

Redo log entries contain a record of changes that have been made to the database block buffers. The log writer (LGWR) process writes redo log entries from the log buffer to a redo log file. The log buffer should be sized so that space is available in the log buffer for new entries, even when access to the redo log is heavy. When the log buffer is undersized, user process will be delayed as they wait for the LGWR to free space in the redo log buffer.

This data item represents the redo log buffer efficiency, as measured by the percentage of times users did not have to wait for the log writer to free space in the redo log buffer.

#### Data Source

((DeltaRedoEntries - DeltaRedoLogSpaceRequests) / DeltaRedoEntries) * 100
where:

DeltaRedoEntries: difference in 'select value from v$sysstat where name='redo entries'' between sample end and start
DeltaRedoLogSpaceRequests: difference in 'select value from v$sysstat where name='redo log space requests'' between sample end and start

#### User Action

The LOG_BUFFER initialization parameter determines the amount of memory that is used when buffering redo entries to the redo log file.

Consider increasing the LOG_BUFFER initialization parameter to increase the size of the redo log buffer should waiting be a problem. Redo log entries contain a record of the changes that have been made to the database block buffers. The log writer process (LGWR) writes redo log entries from the log buffer to a redo log. The redo log buffer should be sized so space is available in the log buffer for new entries, even when a ccess to the redo log is heavy.
Latch %

## Latch %

#### Description

If the latch is requested with a willing-to-wait request and that latch is not available, the requesting process waits a short time and requests the latch again. The process continues waiting and requesting until the latch is available.

This data item represents the percentage of times during this sample period an attempt a willing-to-wait request for this latch failed on first try.

#### Data Source

(DeltaMisses / DeltaGets) * 100
where:

DeltaMisses: difference in 'select misses from v$latch' between sample end and start
DeltaGets: difference in 'select gets from v$latch' between sample end and start

#### User Action

Active Sessions

## Active Sessions

#### Description

This data item represents the number of active sessions.

#### Data Source

select count(*) from v$session where status = 'ACTIVE'

#### User Action

Inactive Sessions

## Inactive Sessions

#### Description

This data item represents the number of inactive sessions.

#### Data Source

TotalSessions - ActiveSessions
where:

TotalSessions: select count(*) from v$session
ActiveSessions: select count(*) from v$session where status = 'ACTIVE'

#### User Action

Instance I/O Statistics Data

# Instance I/O Statistics Data

I/O statistics that are summarized for the entire instance

This class includes the following charts:

I/O Rates per Sec

Free Buffer Scans

Rows Retrieved via Table Scan %

Table Scan Rates

Network Bytes Per Second

Blocks Per Table Scan

Summed Dirty Queue Length

DBWR Efficiency Statistics

I/O Rates per Trans

Table Scan per Trans

Network Bytes per Trans

Instance I/O Statistics Data Default Chart
Instance I/O Statistics Data Default Chart

I/O statistics that are summarized for the entire instance

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Writes/Sec

## Physical Writes/Sec

#### Description

This data item represents the number of disk writes per second during the sample period.

#### Data Source

DeltaWrites / Seconds
where:

DeltaWrites: difference in 'select value from v$sysstat where name='physical writes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Logical Reads/Sec

## Logical Reads/Sec

#### Description

This data item represents the number of logical reads per second during the sample period.

#### Data Source

DeltaReads / Seconds
where:

DeltaReads: difference in 'select value from v$sysstat where name='session logical reads'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Blocks Per Table Scan

## Blocks Per Table Scan

Blocks_gotten / (short_scans + long_scans)

Avg Free Buffer Scans

## Avg Free Buffer Scans

Average number of buffers scanned when looking for a free buffer

Full TableScan Rows ratio

## Full TableScan Rows ratio

Row scan / (row scan + rowid scan)

Table Scans(Long)/Sec

## Table Scans(Long)/Sec

#### Description

This data item represents the number of long table scans per second during sample period. A table is considered 'long' if the table is not cached and if its high-water mark is greater than 5 blocks.

#### Data Source

DeltaScans / Seconds
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (long tables)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Table Scans(Short)/Sec

## Table Scans(Short)/Sec

#### Description

This data item represents the number of short table scans per second during sample period. A table is considered 'short' if the table is cached or if its high-water mark is less than 5 blocks.

#### Data Source

DeltaScans / Seconds
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (short tables)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Rows Gotten Per Table Scan

## Rows Gotten Per Table Scan

(Rowid scan) / (row scan + rowid scan)

Table Scan Rows/Sec

## Table Scan Rows/Sec

#### Description

During scanning operations, each row is retrieved sequentialy by the Oracle Server. This data item represents the number of rows scanned per second during this sample period.

#### Data Source

select s.value from v$sysstat s, v$statname n where n.name='table scan rows gotten' and n.statistic#=s.statistic#

#### User Action

Network Bytes/Sec

## Network Bytes/Sec

All network read/write per second

Summed Dirty Queue Length

## Summed Dirty Queue Length

#### Description

This item represents 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.

#### Data Source

select s.value from v$sysstat s, v$statname n where n.name='summed dirty queue length' and n.statistic#=s.statistic#

#### User Action

If many dirty buffers exist, then possibly the DBWn process(es) cannot keep up. Increase the buffer cache size or tune the DBWn process.
Write Requests

## Write Requests

Number of I/O requests generated by the DBWR process

Avg Dirty Queue Length

## Avg Dirty Queue Length

Average number of dirty blocks left on the LRU list per write request

Dirty Buffers per Free Req

## Dirty Buffers per Free Req

Number of dirty buffers found per free request

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of changes, per second during sample period, that were made to all blocks in the SGA as a result of an update or delete operation. This value is a rough indication of total database work as it indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select value from v$sysstat where name='db block changes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times, per second during sample period, a user prcoess applied rollback entries to perform a consistent read on a block.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select value from v$sysstat where name='consistent changes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Trans

## Physical Reads/Trans

#### Description

This data item represents the number of disk reads per transaction during the sample period.

#### Data Source

DeltaReads / Transactions
where:

DeltaReads: difference in 'select value from v$sysstat where name='physical reads'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Physical Writes/Trans

## Physical Writes/Trans

#### Description

This data item represents the number of disk writes per transaction during the sample period.

#### Data Source

DeltaWrites / Transactions
where:

DeltaWrites: difference in 'select value from v$sysstat where name='physical writes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Logical Reads/Trans

## Logical Reads/Trans

#### Description

This data item represents the number of logical reads per transaction during the sample period.

#### Data Source

DeltaReads / Transactions
where:

DeltaReads: difference in 'select value from v$sysstat where name='session logical reads'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Table Scans(Long)/Trans

## Table Scans(Long)/Trans

#### Description

This data item represents the number of long table scans per transaction during sample period. A table is considered 'long' if the table is not cached and if its high-water mark is greater than 5 blocks.

#### Data Source

DeltaScans / Transactions
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (long tables)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Table Scans(Short)/trans

## Table Scans(Short)/trans

#### Description

This data item represents the number of short table scans per transaction during sample period. A table is considered 'short' if the table is cached or if its high-water mark is less than 5 blocks.

#### Data Source

DeltaScans / Transactions
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (short tables)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Table Scan Rows/Trans

## Table Scan Rows/Trans

Table scans per transaction

Block Changes/Trans

## Block Changes/Trans

#### Description

This data item represents the number of changes, per transaction during sample period, that were made to all blocks in the SGA as a result of an update or delete operation. This value is a rough indication of total database work as it indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Transactions
where:

DeltaBlockChanges: difference in 'select value from v$sysstat where name='db block changes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Consistent Changes/Trans

## Consistent Changes/Trans

#### Description

This data item represents the number of times, per transaction during sample period, a user prcoess applied rollback entries to perform a consistent read on a block.

#### Data Source

DeltaConsistentChanges / Transactions
where:

DeltaConsistentChanges: difference in 'select value from v$sysstat where name='consistent changes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Network Bytes/Trans

## Network Bytes/Trans

All network read/write per transaction

Phy Reads Direct/Sec

## Phy Reads Direct/Sec

Data blocks direct read from disk per second

Phy Reads Direct/Trans

## Phy Reads Direct/Trans

Data blocks direct read from disk per transaction

Redo Size/Sec

## Redo Size/Sec

#### Description

This data item represents the amount of redo, in bytes generated per second during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

#### Data Source

DeltaRedoSize / Seconds
where:

DeltaRedoSize: difference in 'select value from v$sysstat where name='redo size'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Statistics

# Redo Statistics

Statistics pertaining to the handling of changed data blocks

This class includes the following charts:

Redo Log Statistics

Average Redo Log Write Size

Redo Size per Second

Redo Allocation Retries

Redo Statistics Default Chart
Redo Statistics Default Chart

Statistics pertaining to the handling of changed data blocks

Average Redo Write Size

## Average Redo Write Size

#### Description

This data item represents the average number of redo blocks written to disk per redo write operation during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

The log writer processes (LGWR) is responsible for redo log buffer management; that is, writing the redo log buffer to a redo log file on disk.

#### Data Source

DeltaRedoBlocksWritten / DeltaRedoWrites
where:

DeltaRedoBlocksWritten: difference in 'select value from v$sysstat where name='redo blocks written'' between end and start of sample period
DeltaRedoWrites: difference in 'select value from v$sysstat where name='redo writes'' between end and start of sample period

#### User Action

Redo Entries/Sec

## Redo Entries/Sec

#### Description

This data item represents the average number of redo entries copied into the redo log buffer per second during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

#### Data Source

DeltaRedoEntries / Seconds
where:

DeltaRedoEntries: difference in 'select value from v$sysstat where name='redo entries'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Log Space Req/Sec

## Redo Log Space Req/Sec

#### Description

This data item represents the number of times per second when the active redo log file became full and the Oracle Server had to wait for disk space to be allocated for the redo log entries. This space is created by performing a log switch.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

The log writer processes (LGWR) is responsible for redo log buffer management; that is, writing the redo log buffer to a redo log file on disk.

Small log files in relation to the size of the SGA or the commit rate of the workload can cause problems. When the log switch occurs, the Oracle Server must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for the database writer process (DBWR) to write dirty buffers to disk before continuing. This can decrease throughput.

#### Data Source

DeltaRedoLogSpaceRequests / Seconds
where:

DeltaRedoLogSpaceRequests: difference in 'select value from v$sysstat where name='redo log space requests'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Synch Writes/Sec

## Redo Synch Writes/Sec

#### Description

This data item represents the number of times a change was written out to disk, per second during this sample period, as a result of a COMMIT. When a user issues a COMMIT statement, the log writer process (LGWR) puts a commit record in the redo log buffer and writes it to disk immediately, along with the transaction's redo entries.

#### Data Source

DeltaRedoLogSpaceRequests / Seconds
where:

DeltaRedoLogSpaceRequests: difference in 'select value from v$sysstat where name='redo log space requests'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Blocks Written/Sec

## Redo Blocks Written/Sec

#### Description

This data item represents the average number of blocks written to the redo log files per second during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

The log writer processes (LGWR) is responsible for redo log buffer management; that is, writing the redo log buffer to a redo log file on disk.

#### Data Source

DeltaBlocksWritten / Seconds
where:

DeltaBlocksWritten: difference in 'select value from v$sysstat where name='redo blocks written'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Writes/Sec

## Redo Writes/Sec

#### Description

This data item represents the number redo write operations per second during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

The log writer processes (LGWR) is responsible for redo log buffer management; that is, writing the redo log buffer to a redo log file on disk.

#### Data Source

DeltaRedoWrites / Seconds
where:

DeltaRedoWrites: difference in 'select value from v$sysstat where name='redo writes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Size/Sec

## Redo Size/Sec

#### Description

This data item represents the amount of redo, in bytes generated per second during this sample period.

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

#### Data Source

DeltaRedoSize / Seconds
where:

DeltaRedoSize: difference in 'select value from v$sysstat where name='redo size'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Allocation Retries

## Redo Allocation Retries

#### Description

This data item represents number of times processes need to wait for redo allocation.

#### Data Source

select value from v$sysstat where name='redo buffer allocation retries'

#### User Action

SQL

# SQL

SQL statement use and misuse

SQL Default Chart
SQL Default Chart

SQL statement use and misuse

Sessions Waiting for this Event

# Sessions Waiting for this Event

Session statistics for sessions waiting for a particular event

This class includes the following charts:

Sessions Waiting for this Event

Sessions Waiting for this Event Default Chart
Sessions Waiting for this Event Default Chart

Session statistics for sessions waiting for a particular event

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts going to disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Serial#

## Serial#

Session serial number

DBWR Statistics

# DBWR Statistics

Statistics that show the health of the Database Writer process

This class includes the following charts:

DBWR Free Block Statistics

DBWR Scan Statistics

DBWR Checkpoints

DBWR Statistics Default Chart
DBWR Statistics Default Chart

Statistics that show the health of the Database Writer process

DBWR Make Free Requests

## DBWR Make Free Requests

#### Description

This data item represents the number of times DBWn was requested to make free buffers per second during this sample period.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaMakeFreeRequests / Seconds
where:

DeltaMakeFreeRequests: difference in 'select value from v$sysstat where name='DBWR make free requests'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Starting with Oracle 8.0, the DB_WRITER_PROCESSES parameter provides a means of alleviating I/O bottlenecks at the DBWn process. The DB_WRITER_PROCESSES parameter specifies the number of DBWn (DBW0 through DBW9) processes to start for an instance. Each is a completely separate process that performs both the "gather" phase as well as the "write" phase. Each additional DBWn process writes buffers from its own private portion of the database buffer cache. Thus, from a throughout standpoint, multiple DBWn process should be capable of delivering more I/O than one DBWn process with multiple I/O slaves. However, using the DB_WRITER_PROCESSES parameter is only beneficial on multiprocessor machines.

Another way is to start DBWn I/O slave processes to spread the load of writing database buffers across multiple slave processes, with a single master DBWn process doing the data "gathering" and multiple slaves processes doing the writing. Since I/O slaves do not write serially, even when there is only one CPU, it can be useful to have multiple I/O slaves on single CPU systems.

In general, DBWR_IO_SLAVES or DB_WRITER_PROCESSES should not be used unless there is clear evidence of a database writer bottleneck.
DBWR Free Buffers Found

## DBWR Free Buffers Found

#### Description

This data item represents the number of buffers, per second during this sample period, that DBWn found to be clean when requested to make free buffers.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaFreeBuffers / Seconds
where:

DeltaFreeBuffers: difference in 'select value from v$sysstat where name='DBWR free buffers found'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DBWR LRU Scans

## DBWR LRU Scans

#### Description

This data item represents the number of times, per second during this sample period, that DBWn scanned LRU queue looking for buffers to write. This value also includes times when the scan is to fill a batch being written for another purpose such as a checkpoint.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaLRUScans / Seconds
where:

DeltaLRUScans: difference in 'select value from v$sysstat where name='DBWR lru scans'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DBWR Summed Scan Depth

## DBWR Summed Scan Depth

#### Description

This data item represents the summed scan depth, per second during this sample period, for every time DBWn scanned the LRU for dirty blocks.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaSumScanDepth / Seconds
where:

DeltaSumScanDepth: difference in 'select value from v$sysstat where name='DBWR summed scan dept'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DBWR Buffers Scanned

## DBWR Buffers Scanned

#### Description

This data item represents the number of buffers (clean and dirty), per second during this sample period, that were examined by DBWn when DBWn scanned the LRU for dirty blocks.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaSumScanDepth / Seconds
where:

DeltaSumScanDepth: difference in 'select value from v$sysstat where name='DBWR buffers scanned'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DBWR Checkpoints

## DBWR Checkpoints

#### Description

This data item represents the number of times, per second during this sample period, DBWn was asked to scan the cache and write all blocks marked for a checkpoint.

The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.

When a buffer in the database buffer cache is modified, it is marked "dirty". The primary job of the DBWn process is to keep the buffer cache "clean" by writing dirty buffers to disk. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.

When the Oracle Server process cannot find a clean reusable buffer after scanning a threshold of buffers, it signals DBWn to write. When this request to make free buffers is received, DBWn writes the least recently used (LRU) buffers to disk. By writing the least recently used dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that may be useful soon.

In addition, DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo log from which crash or instance recovery would need to begin.

#### Data Source

DeltaCheckpoints / Seconds
where:

DeltaCheckpoints: difference in 'select value from v$sysstat where name='DBWR checkpoints'' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Buffer Pool

# Buffer Pool

Number of blocks currently within the SGA

This class includes the following charts:

Buffer Pool

Buffer Pool Default Chart
Buffer Pool Default Chart

Number of blocks currently within the SGA

Block Count

## Block Count

Number of blocks

Distinct Block Count

## Distinct Block Count

Number of blocks with different file# or block#

Initialization Parameters

# Initialization Parameters

Initialization parameters for the instance

This class includes the following charts:

Cursor Instance Parameters

DB Blocks in the SGA

Redo Log Buffer Size

LRU Latch Count

Buffer Pool Parameters

Timed Statistics

Sort Area Sizes

Initialization Parameters Default Chart
Initialization Parameters Default Chart

Initialization parameters for the instance

DB_BLOCK_BUFFERS

## DB_BLOCK_BUFFERS

#### Description

DB_BLOCK_BUFFERS specifies the number of database buffers available in the buffer cache. It is one of the primary parameters which contribute to the total memory requirements of the SGA on the instance.

The DB_BLOCK_BUFFERS parameter, together with the DB_BLOCK_SIZE parameter, determines the total size of the buffer cache. Effective use of the buffer cache can greatly reduce the I/O load on the database. Since DB_BLOCK_SIZE can be specified only when the database is first created, use DB_BLOCK_BUFFERS to control the size of the buffer cache.

This parameter affects the probability that a data block will be pinged when Parallel Server is enabled: the more buffers, the more chance of pings.

#### Data Source

select value from v$parameter where name='db_block_buffers'

#### User Action

BUFFER_POOL_KEEP

## BUFFER_POOL_KEEP

#### Description

BUFFER_POOL_KEEP is used to define the KEEP buffer pool. The KEEP buffer pool is used to maintain objects in the buffer cache. Two attributes are specified for the KEEP pool: the number of buffers in the buffer pool and the number of LRU latches allocated to the buffer pool.

The goal of the KEEP buffer pool is to retain objects in memory, thus avoiding I/O operations. The size of the KEEP buffer pool therefore depends on the objects that you wish to keep in the buffer cache. You can compute an approximate size for the KEEP buffer pool by adding together the sizes of all objects dedicated to this pool.

A good candidate for a segment to put into the KEEP pool is a segment that is smaller than 10% of the size of the DEFAULT buffer pool and has incurred at least 1% of the total I/Os in the system.

#### Data Source

select value from v$parameter where name='buffer_pool_keep'

#### User Action

DB_BLOCK_LRU_LATCHES

## DB_BLOCK_LRU_LATCHES

#### Description

DB_BLOCK_LRU_LATCHES specifies the upper bound of the number of LRU latch sets. Set this parameter to a value equal to the desired number of LRU latch sets. The Oracle Server decides whether to use this value or reduce it based on a number of internal checks. If the parameter is not set, Oracle calculates a value for the number of sets. The value calculated by the Oracle Server is usually adequate. Increase this only if misses are higher than 3% in V$LATCH.

#### Data Source

select value from v$parameter where name='db_block_lru_latches'

#### User Action

BUFFER_POOL_RECYCLE

## BUFFER_POOL_RECYCLE

#### Description

BUFFER_POOL_RECYCLE is used to define the RECYCLE buffer pool. The RECYCLE buffer pool is used to prevent objects from consuming unnecessary space in the cache. Two attributes are specified for the RECYCLE pool: the number of buffers in the buffer pool and the number of LRU latches allocated to the buffer pool.

The goal of the RECYCLE buffer pool is to eliminate blocks from memory as soon as they are no longer needed. If an application accesses the blocks of a very large object in a random fashion, there is little chance of reusing a block stored in the buffer pool before it is aged out. This is true regardless of the size of the buffer pool. Because of this, the object's blocks should not be cached; those cache buffers can be allocated to other objects.

However, be careful not to discard blocks from memory too quickly. If the buffer pool is too small, blocks may age out of the cache before the transaction or SQL statement has completed evaluation.

A good candidate for a segment to put into the RECYCLE buffer pool is a segment that is at least twice the size of the DEFAULT buffer pool and has incurred at least a few percent of the total I/Os in the system.

#### Data Source

select value from v$parameter where name='buffer_pool_recycle'

#### User Action

LOG_BUFFER

## LOG_BUFFER

#### Description

LOG_BUFFER specifies the size, in bytes, of the redo log buffer. The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER or DROP operations. Redo entries are used for database recovery, if necessary.

In general, larger LOG_BUFFER values reduce redo log file I/O, particularly if transactions are long or numerous.

#### Data Source

select value from v$parameter where name='log_buffer'

#### User Action

CURSOR_SPACE_FOR_TIME

## CURSOR_SPACE_FOR_TIME

#### Description

CURSOR_SPACE_FOR_TIME specifies whether a shared SQL area can be deallocated from the library cache to make room for a new SQL satement.

If this parameter is false, a shared SQL area can be deallocated from the library cache regardless of whether application cursors associated with its SQL statement are open. In this case, the Oracle Server must verify that a shared SQL area containing the statement is in the library cache.

If this parameter is true, a shared SQL area can be deallocated only when all application cursors associated with its statement are closed. In this case, the Oracle Server need not verify that a shared SQL area is in the cache, becaue the shared SQL area can never be deallocated while an application cursor associated with it is open.

Setting the value of this parameter to true saves the Oracle Server a small amount of time and may slightly improve the performance of execution calls.

However, it should not be set to true if you have found library cache misses on execution calls. Such library cache misses indicate that the shared pool is not large enough to hold the shared SQL areas of all concurrently open cursors. If the value is true and the shared pool has no space for a new SQL statement, the statement cannot be parsed and the Oracle Server returns an error saying that there is no more shared memory. If the value is false and there is no space for a new statement, the Oracle Server deallocates an existing shared SQL area. Although deallocating a shared SQL area results in a library cache miss later, it is preferable to an error halting the application because a SQL statement could not be parsed.

Furthermore, do not set CURSOR_SPACE_FOR_TIME to true if the amount of memory available to each user for private SQL area is scarce. This value also prevents the deallocation of private SQL areas associated with open cursors. If the private SQL areas for all concurrently open cursors fills the user's available memroy so that there is no space to allocate a private SQL area for a new SQL statement, the statement cannot be parsed and the Oracle Server returns an error indicating there is not enough memory.

#### Data Source

select value from v$parameter where name='cursor_space_for_time'

#### User Action

SESSION_CACHED_CURSORS

## SESSION_CACHED_CURSORS

#### Description

If an application repeatedly issues parse calls on the same set of SQL statements, 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.

The Oracle Server uses the shared SQL area to determine whether more than three parse requests have been issued on a given statement. If so, the Oracle Server 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 will then find the cursor in the session cursor cache.

To enable caching of session cursors, use SESSION_CACHED_CURSORS to specify the maximum number of session cursors kept in the cache. An Least Recently Used (LRU) algorithm removes entries in the session cursor cache to make room for new entries when needed.

To determine whether the session cursor cache is sufficiently large for your instance, you can examine the session statistic "session cursor cache hits" in the V$SESSTAT view. This statistic counts the number of times a parse call found a cursor in the session cursor cache. 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.

#### Data Source

select value from v$parameter where name='session_cached_cursors'

#### User Action

OPEN_CURSORS

## OPEN_CURSORS

#### Description

OPEN_CURSORS defines the maximum number of open cursors a session can have at once. If a session reaches this limit, a MAX OPEN CURSORS EXCEEDED error message is returned.

OPEN_CURSORS also determines the size of the PL/SQL cursor cache for the instance. PL/SQL keeps a cache of open cursors that were executed from within PL/SQL. If the cursor is still in the cache the next time the users say to execute it, then it can be directly used. Otherwise, it must be reparsed, etc. The size of the PL/SQL cursor cache is equal to OPEN_CURSORS minus the number of cursors the user has opened directly.

#### Data Source

select value from v$parameter where name='open_cursors'

#### User Action

TIMED_STATISTICS

## TIMED_STATISTICS

#### Description

TIMED_STATISTICS enables the collection of timed statistics.

#### Data Source

select value from v$parameter where name='timed_statistics'

#### User Action

SORT_AREA_SIZE

## SORT_AREA_SIZE

#### Description

SORT_AREA_SIZE defines the size, in bytes, of memory that is available to a user process during sorting. It is allocated on a per user basis from available memory.

When a user performs a database operation which requires a sort, the information to be sorted is loaded into the user's PGA memory. When the total amount of data to be sorted is less than SORT_AREA_SIZE, the sort is performed completely in memory.

If the total amount of data exceeds SORT_AREA_SIZE, a disk sort is performed. Disk sorts process SORT_AREA_SIZE subsets of the data to be sorted in sort runs. Each sort run is written to disk as a temporary segment.

#### Data Source

select value from v$parameter where name='sort_area_size'

#### User Action

SORT_AREA_RETAINED_SIZE

## SORT_AREA_RETAINED_SIZE

#### Description

SORT_AREA_RETAINED_SIZE determines the size, in bytes, to which the Oracle Server will reduce the sort area memory allocation after the final sort run completes. The retained size parameter controls the size of the read buffer which is used to maintain a portion of the sorted information in memory. If a process needs to perform multiple, concurrent sorts, each sort is given a memory allocation of SORT_AREA_RETAINED_SIZE.

The Oracle Server uses an amount of memory determined by SORT_AREA_SIZE during sort processing. Once all the information has been sorted and the first fetch has completed, if the retained size is less than the sort area size, the Oracle Server merges all the sort runs into a single run and sort memory is reduced to the retained size.

#### Data Source

select value from v$parameter where name='sort_area_retained_size'

#### User Action

Tablespace

# Tablespace

Overview of free space in all tablespaces

This class includes the following charts:

Datafile Count per Tablespace

Status per Tablespace

Block Counts per Tablespace

Free Space (%) per Tablespace

Free Space (kbytes) per Tablespace

Number of Free Extents per Tablespace

Tablespace Default Chart
Tablespace Default Chart

Overview of free space in all tablespaces

Datafile Count

## Datafile Count

#### Description

This data item represents the number of datafiles in this tablespace.

#### Data Source

select count(*) from dba_data_files where tablespace_name='name'

#### User Action

Total Blocks

## Total Blocks

#### Description

This data item represents the total size, in blocks, of this tablespace.

#### Data Source

select sum(blocks) from dba_data_files where tablespace_name='name'

#### User Action

Free Blocks

## Free Blocks

#### Description

This data item represents the total amount of free space, in blocks, in this 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.

#### Data Source

select sum(blocks) from dba_free_space where tablespace_name='name'

#### User Action

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.
Free Space (kbytes)

## Free Space (kbytes)

#### Description

This data item represents the total amount of free space, in kilobytes, in this 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.

#### Data Source

select sum(bytes)/1024 from dba_free_space where tablespace_name='name'

#### User Action

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.
Free Space (%)

## Free Space (%)

#### Description

This data item represents the percentage of free space, in blocks, in this 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.

#### Data Source

(FreeBlocks / TotalBlocks) * 100
where:

FreeBlocks: select sum(blocks) from dba_free_space where tablespace_name='name'
TotalBlocks: select sum(blocks) from dba_data_files where tablespace_name='name'

#### User Action

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.
Total Quota Blocks

## Total Quota Blocks

#### Description

This data item represents the total number of blocks in this tablespace that are currently being used by all users.

#### Data Source

select sum(blocks) from dba_ts_quotas where tablespace_name='name'

#### User Action

Status

## Status

#### Description

This data item indicates this tablespace's status; for example, if the tablespace is online, offline or read-only.

#### Data Source

select status from dba_tablespaces where tablespace_name='name'

#### User Action

Free Extents

## Free Extents

#### Description

This data item represents the number of free extents in this tablespace.

#### Data Source

select count(*) from dba_free_space where tablespace_name='name'

#### User Action

Used Blocks

## Used Blocks

#### Description

This data item represents the total number of used blocks in this tablespace.

#### Data Source

(TotalBlocks - FreeBlocks)
where:

TotalBlocks: select sum(blocks) from dba_data_files where tablespace_name='name'
FreeBlocks: select sum(blocks) from dba_free_space where tablespace_name='name'

#### User Action

Data Dictionary

# Data Dictionary

Shows miss percentage of dictionary cache.

This class includes the following charts:

Data Dictionary Miss %

Data Dictionary Hit/Miss Rates

Data Dictionary Default Chart
Data Dictionary Default Chart

Shows miss percentage of dictionary cache.

Miss %

## Miss %

#### Description

This data item represents dictionary cache efficiency as measured by the percentage of requests against the dictionary data that were not already in memory. It is important to determine whether the misses on the data dictionary are actually affecting the performance of the Oracle Server.

The shared pool is an area in the SGA that contains the library cache of shared SQL requests, the dictionary cache and the other cache structures that are specific to a particular instance configuration.

Misses on the data dictionary cache are to be expected in some cases. Upon instance startup, the data dictionary cache contains no data, so any SQL statement issued is likely to result in cache misses. As more data is read into the cache, the likelihood of cache misses should decrease. Eventually the database should reach a "steady state" in which the most frequently used dictionary data is in the cache. At this point, very few cache misses should occur. To tune the cache, examine its activity only after your application has been running.

#### Data Source

(Misses / Gets) * 100
where:

Misses: select sum(getmisses) from v$rowcache
Gets: select sum(gets) from v$rowcache

#### User Action

If the percentage of misses exceeds 10% to 15%, consider increasing SHARED_POOL_SIZE to decrease the frequency in which dictionary data is being flushed from the shared pool to make room for new. To increase the memory available to the cache, increase the value of the initialization parameter SHARED_POOL_SIZE.
Gets/Sec

## Gets/Sec

#### Description

This data item represents the total number of requests for information from data dictionary objects per second for this sample period.

#### Data Source

DeltaGets / Seconds
where:

DeltaGets: difference in 'select sum(gets) from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Misses/Sec

## Misses/Sec

#### Description

This data item represents the total number of requests, per second for this sample period, for information from data dictionary objects that resulted in a cache miss.

#### Data Source

DeltaMisses / Seconds
where:

DeltaMisses: difference in 'select sum(getmisses) from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Data Dictionary Detail

# Data Dictionary Detail

Detailed data dictionary statistics

This class includes the following charts:

Data Dictionary per Cache Entry Counts

Data Dictionary Per Cache Miss Rates

Data Dictionary Detail Default Chart
Data Dictionary Detail Default Chart

Detailed data dictionary statistics

Entries in Cache

## Entries in Cache

#### Description

This data item represents the total number of entries in the data dictonary cache.

#### Data Source

select count from v$rowcache

#### User Action

Misses/Sec

## Misses/Sec

#### Description

This data item represents the total number of requests, per second for this sample period, for information from data dictionary objects that resulted in a cache miss.

#### Data Source

DeltaMisses / Seconds
where:

DeltaMisses: difference in 'select sum(getmisses) from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Valid Entries

## Valid Entries

#### Description

This data item represents the total number of entries in the data dictonary cache that contain valid data.

#### Data Source

select usage from v$rowcache

#### User Action

Gets/Sec

## Gets/Sec

#### Description

This data item represents the total number of requests for information from data dictionary objects per second for this sample period.

#### Data Source

DeltaGets / Seconds
where:

DeltaGets: difference in 'select sum(gets) from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Scans/Sec

## Scans/Sec

#### Description

This data item represents the number of scan requests per second during this sample period.

#### Data Source

DeltaScans / Seconds
where:

DeltaScans: difference in 'select scans from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

ScanMisses/Sec

## ScanMisses/Sec

#### Description

This data item represents the number of scan requests, per second during this sample period, that failed to find data in cache.

#### Data Source

DeltaScanMisses / Seconds
where:

DeltaScanMisses: difference in 'select scanmisses from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

ScanCompletes/Sec

## ScanCompletes/Sec

#### Description

This data item represents the number of times, per second during this sample period, the list was completely scanned.

#### Data Source

DeltaScanCompletes / Seconds
where:

DeltaScanCompletes: difference in 'select scancompletes from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Modifications/Sec

## Modifications/Sec

#### Description

This data item represents the number of inserts, updates and deletions per second for this sample period.

#### Data Source

DeltaModifications / Seconds
where:

DeltaModifications: difference in 'select modifications from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Flushes/Sec

## Flushes/Sec

#### Description

This data item represents the number of times data was flushed to disk per second for this sample period.

#### Data Source

DeltaFlushes / Seconds
where:

DeltaFlushes: difference in 'select flushes from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DLM_Requests/Sec

## DLM_Requests/Sec

#### Description

This data item represents the number of DLM requests per second for this sample period.

#### Data Source

DeltaRequests / Seconds
where:

DeltaRequests: difference in 'select dlm_requests from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DLM_Conflicts/Sec

## DLM_Conflicts/Sec

#### Description

This data item represents the number of DLM conflicts per second for this sample period.

#### Data Source

DeltaConflicts / Seconds
where:

DeltaConflicts: difference in 'select dlm_conflicts from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

DLM_Releases/Sec

## DLM_Releases/Sec

#### Description

This data item represents the number of DLM releases per second for this sample period.

#### Data Source

DeltaReleases / Seconds
where:

DeltaReleases: difference in 'select dlm_releases from v$rowcache' between sample end and start
Seconds: number of seconds in sample period

#### User Action

SQL from Wait Events

# SQL from Wait Events

SQL currently waiting on an event

This class includes the following charts:

SQL Statements Waiting for this Event

SQL from Wait Events Default Chart
SQL from Wait Events Default Chart

SQL currently waiting on an event

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

Rollback Statistics

# Rollback Statistics

Rollback segment header access statistics.

This class includes the following charts:

Rollback No Wait %

Rollback Statistics Default Chart
Rollback Statistics Default Chart

Rollback segment header access statistics.

Rollback NoWait %

## Rollback NoWait %

#### Description

Contention for rollback segments is reflected by contention for buffers that contain rollback segment blocks. This data item represents the percentage of times when there was no wait for accessing the rollback segment header. This value should be greater than 99%.

Rollback segments are portions of the database that record the actions of transactions in case a transaction is rolled back. Rollback segments are used to provide read consistency, support rollback transactions and recover a database.

Proper allocation of rollback segments make for optimal database performance. Using a sufficient number of rollback segments distributes rollback segment contention across many segments and improves performance.

#### Data Source

((DeltaGets - DeltaWaits) / DeltaGets) * 100
where:

DeltaGets: difference in 'select sum(gets) from v$rollstat' between sample end and start
DeltaWaits: difference in 'select sum(waits) from v$rollstat' between sample end and start

#### User Action

To reduce contention for buffers containing rollback segment blocks, create additional rollback segments. The general guidelines for choosing how many rollback segments to allocate is based on the number and type of concurrently active transactions on your database. Allocate one rollback segment for each 10 concurrent OLTP (online transaction processing) transactions and one rollback segment for each concurrent batch job.

In addition, when creating a rollback segment, keep extents within a rollback the same size by specifying STORAGE parameters where NEXT=INITIAL.

It is also recommended that you set the MINEXTENTS parameter value to 20. Because rollback segments are logically regarded as a circular queue of extents, they are required to have MINEXTENTS value of at least 2. The probability that a rollback segment will require a new extent allocation depends on how likely the next extents are to contain active undo. The more extents the rollback segment has, the less likely that a rollback segment will require an extent allocation that could be avoided. Administrators should create rollback segments with many extents. Naturally, there is a point of diminishing returns. There is a rapid decline of a rollback segment's probability of extending as the number of extents increases. Beyond 20 extents, the incremental decrease in the segment's probability of extending fails to justify the cost of the additional extent.
User Events

# User Events

The list of events being waited for by each active user

This class includes the following charts:

Per User Wait Events by Time

Per User Wait Events by Count

User Events Default Chart
User Events Default Chart

The list of events being waited for by each active user

Wait Time

## Wait Time

#### Description

This data item represents the amount of time, in seconds, that was spent waiting for this event during this sample period.

#### Data Source

DeltaWaitTime
where:

DeltaWaitTime: difference in 'select sum(time_waited) from v$session_event' between end and start of period

#### User Action

Number Waits

## Number Waits

#### Description

This data item represents the number of times this event was waited for during this sample period.

#### Data Source

DeltaWaits
where:

DeltaWaits: difference in 'select sum(total_waits) from v$session_event' between end and start of period

#### User Action

Number Timeouts

## Number Timeouts

#### Description

This data item represents the number of timeouts for this event for during this sample period.

#### Data Source

DeltaTimeouts
where:

DeltaTimeouts: difference in 'select sum(total_timeouts) from v$session_event' between end and start of period

#### User Action

User Buffer Busy

# User Buffer Busy

User Buffer Busy Default Chart
User Buffer Busy Default Chart

Block #

## Block #

wait type

## wait type

Session Id

## Session Id

Segment Name

## Segment Name

Owner

## Owner

User Level Statistics

# User Level Statistics

Users currently attached to the server and their statistics

This class includes the following charts:

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

User Level Statistics Default Chart
User Level Statistics Default Chart

Users currently attached to the server and their statistics

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaMemorySorts / Seconds
where:

DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Rollback Segment

# Rollback Segment

Rollback segment header access statistics

This class includes the following charts:

Rollback Segment No Wait Ratio (>99%)

Rollback Segment Hit %

Rollback Segment Access Rates

Rollback Segment Status

Rollback Segment Default Chart
Rollback Segment Default Chart

Rollback segment header access statistics

Header Gets/Sec

## Header Gets/Sec

#### Description

This data item represents the number of rollback segment header gets per second during this sample period.

#### Data Source

DeltaGets / Seconds
where:

DeltaGets: difference in 'select gets from v$rollstat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Header Waits/Sec

## Header Waits/Sec

#### Description

This data item represents the number of rollback segment header waits per second during this sample period.

#### Data Source

DeltaWaits / Seconds
where:

DeltaWaits: difference in 'select waits from v$rollstat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Rollback NoWait %

## Rollback NoWait %

#### Description

Rollback segments are portions of the database that record the actions of transactions in case a transaction is rolled back. Rollback segments are used to provide read consistency, support rollback transactions and recover a database.

Proper allocation of rollback segments make for optimal database performance. Using a sufficient number of rollback segments distributes rollback segment contention across many segments and improves performance.

Contention for rollback segments is reflected by contention for buffers that contain rollback segment blocks. This data item represents the percentage of times when there was no wait for accessing the rollback segment header. This value should be greater than 99%.

#### Data Source

((DeltaGets - DeltaWaits) / DeltaGets) * 100
where:

DeltaGets: difference in 'select sum(gets) from v$rollstat' between sample end and start
DeltaWaits: difference in 'select sum(waits) from v$rollstat' between sample end and start

#### User Action

To reduce contention for buffers containing rollback segment blocks, create additional rollback segments. The general guidelines for choosing how many rollback segments to allocate is based on the number and type of concurrently active transactions on your database. Allocate one rollback segment for each 10 concurrent OLTP (online transaction processing) transactions and one rollback segment for each concurrent batch job.

In addition, when creating a rollback segment, keep extents within a rollback the same size by specifying STORAGE parameters where NEXT=INITIAL.

It is also recommended that you set the MINEXTENTS parameter value to 20. Because rollback segments are logically regarded as a circular queue of extents, they are required to have MINEXTENTS value of at least 2. The probability that a rollback segment will require a new extent allocation depends on how likely the next extents are to contain active undo. The more extents the rollback segment has, the less likely that a rollback segment will require an extent allocation that could be avoided. Administrators should create rollback segments with many extents. Naturally, there is a point of diminishing returns. There is a rapid decline of a rollback segment's probability of extending as the number of extents increases. It has been determined that beyond 20 extents, the incremental decrease in the segment's probability of extending fails to justify the cost of the additional extent.
Active Transactions

## Active Transactions

#### Description

This data item represents the total number of active transactions.

#### Data Source

select xacts from v$rollstat

#### User Action

Shrinks/Sec

## Shrinks/Sec

#### Description

This data item represents the number of times, per second during this sample period, extents were freed from the rollback segment.

#### Data Source

DeltaShrinks / Seconds
where:

DeltaShrinks: difference in 'select shrinks from v$rollstat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

The OPTIMAL parameter specifies the optimal size for a rollback segment. The value for this parameter should be carefully chosen according to the kinds of transactions that the system runs to avoid frequent shrinks and extensions. For a system that executes long-running transactions or long queries, OPTIMAL should be large. OPTIMAL should be smaller for a system that mainly executes short transactions and short queries.

Assuming an instance has equally sized rollback segments with comparably sized extents, the OPTIMAL parameter for a given rollback segment should be set slightly higher than the average number of bytes in active extents in the rollback segment.

Furthermore, OPTIMAL should not be set to a value less than the number of bytes required for MINEXTENTS extents.

If the number of shrinks is greater than 1% of the total number of rollback segment uses (gets), shrinks may be happening too frequent. In this case, you may consider increasing the OPTIMAL setting to reduce the time spent shrinking.
Wraps/Sec

## Wraps/Sec

#### Description

This data item represents the number of times, per second during this sample period, a transaction continued writing from one extent in a rollback segment to another existing extent.

#### Data Source

DeltaWraps / Seconds
where:

DeltaWraps: difference in 'select wraps from v$rollstat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Extends/Sec

## Extends/Sec

#### Description

This data item represents the number of times, per second during this sample period, extents were allocated from the rollback segment.

#### Data Source

DeltaExtents / Seconds
where:

DeltaExtents: difference in 'select extents from v$rollstat' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If the number of times the rollback segment extended is greater than 1% of the total number of rollback segment uses (gets), excessive allocations may be taking place. Excessive allocations can occur as a result of one of two problems:

The use of an extent size that is too small
The use of an OPTIMAL value that is too small

When the extent size is too small, the rollback segment should be recreated with a larger extent size. When the OPTIMAL value is too small, the rollback segment should be altered to use a larger OPTIMAL value.
Status

## Status

#### Description

This data item represents the status of the rollback segment. A rollback segment is always in one of several status. The state of the rollback segment determines whether it can be used in a transaction, as well as which administrative procedures a DBA can perform on it.

OFFLINE: Has not been aquired (brought ONLINE) by any instance
ONLINE: Has been acquired (brought ONLINE) b an instance; may contain data from active transactions
NEEDS RECOVERY: Contains data from uncommitted transactions that cannot be rolled back because the datafiles involved are inaccessiable, or because the rollback segment is corrupted
PARTLY AVAILABLE: Contains data from an in-doubt transaction; that is, an unresolved distributed transaction
INVALID: Has been dropped

#### Data Source

select status from v$rollstat

#### User Action

Waits Logical Reads ratio

## Waits Logical Reads ratio

#### Description

#### Data Source

((DeltaLogReads - DeltaWaits) / DeltaLogReads) * 100
where:

DeltaLogReads: difference of 'select s.value from v$sesstat s, v$statname n where n.name='session logical reads' and n.statistic#=s.statistic#' between sample end and start
DeltaWaits: difference in 'select waits from v$rollstat' between sample end and start

#### User Action

Size

## Size

#### Description

This data item represents the size, in bytes, of the rollback segment.

#### Data Source

select rssize from v$rollstat

#### User Action

Writes

## Writes

#### Description

This data item represents the number of bytes written to the rollback segment.

#### Data Source

select rssize from v$rollstat

#### User Action

OptSize

## OptSize

#### Description

This data item represents the OPTIMAL size, in bytes, of the rollback segment. The OPTIMAL parameter specifies the optimal size for a rollback segment. The value for this parameter should be carefully chosen according to the kinds of transactions that the system runs to avoid frequent shrinks and extensions. For a system that executes long-running transactions or long queries, OPTIMAL should be large. OPTIMAL should be smaller for a system that mainly executes short transactions and short queries.

Assuming an instance has equally sized rollback segments with comparably sized extents, the OPTIMAL parameter for a given rollback segment should be set slightly higher than the average number of bytes in active extents in the rollback segment.

Furthermore, OPTIMAL should not be set to a value less than the number of bytes required for MINEXTENTS extents.

If the number of shrinks is greater than 1% of the total number of rollback segment uses (gets), shrinks may be happening too frequent. In this case, you may consider increasing the OPTIMAL setting to reduce the time spent shrinking.

#### Data Source

select optsize from v$rollstat

#### User Action

HWMSize

## HWMSize

#### Description

This data item represents the most space, in bytes, ever allocated for the rollback segment.

#### Data Source

select hwmsize from v$rollstat

#### User Action

AveShrink

## AveShrink

#### Description

This data item represents the average size, in bytes, of the space Oracle truncated from the rollback segment.

#### Data Source

select aveshrink from v$rollstat

#### User Action

If the number of shrinks taking place is low and the average size shrunk is large, then OPTIMAL is set correctly.

If the number of shrinks taking place is high and the average size shrunk is small, then OPTIMAL is too small as too many shrinks are taking place. You should alter the rollback segment increasing the OPTIMAL setting.
AveActive

## AveActive

#### Description

This data item represents the average number of bytes in active extents in the rollback segment measured over time.

#### Data Source

select aveactive from v$rollstat

#### User Action

Extents

## Extents

#### Description

This data item represents the number of extents in the rollback segment.

#### Data Source

select extents from v$rollstat

#### User Action

Top Sessions

# Top Sessions

Summary information of top sessions as ordered by the selected sort statistic

This class includes the following charts:

Top Session

Top Sessions by Hard Parse Count

Top Sessions by Rows Sorted

Top Sessions by Physical Reads

Top 5 Sessions

Top Sessions Default Chart
Top Sessions Default Chart

Summary information of top sessions as ordered by the selected sort statistic

Session Name

## Session Name

#### Description

This data item represents either the Oracle username of the current session or the name of the background process.

#### Data Source

select NVL(s.username, b.name) from v$session s, v$bgprocess b

#### User Action

OS Username

## OS Username

#### Description

This data item represents the name of the operating system client user.

#### Data Source

select osuser from v$session

#### User Action

Sort Statistic

## Sort Statistic

#### Description

This data item contains the value for the sort statistic which was used to order the sessions for display.

#### Data Source

#### User Action

Status

## Status

#### Description

This data item represents the status of this session.

ACTIVE: currently executing SQL
INACTIVE: inactive
KILLED: marked to be killed
CACHED: temporary cached for use by Oracle*XA
SNIPED: session inactive, waiting on the client

#### Data Source

select status from v$session

#### User Action

Machine

## Machine

#### Description

This data item represents the operating system machine name.

#### Data Source

select machine from v$session

#### User Action

Terminal

## Terminal

#### Description

This data item represents the operating system terminal name.

#### Data Source

select terminal from v$session

#### User Action

Program

## Program

#### Description

This data item represents the name of the client program.

#### Data Source

select program from v$session

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$session

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$session

#### User Action

Serial #

## Serial #

#### Description

This data item represents the session serial number. This value is used to uniquely identify a session's objects. It guarantees that session-level commands are applied to the correct session objects if the session ends and another session begins with the same session ID.

#### Data Source

select serial# from v$session

#### User Action

SPID

## SPID

#### Description

This data item represents the Oracle process identifier.

#### Data Source

select p.spid from v$process p, v$session s where s.paddr = p.addr

#### User Action

Commit Count

## Commit Count

#### Description

This data item represents the number of user commits performed by this session during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits
where:

DeltaCommits: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user commits' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Rollback Count

## Rollback Count

#### Description

This data item represents the number of times this session manually issued a ROLLBACK statement or an error occurs during a session's transaction during the sample period.

#### Data Source

DeltaRollbacks
where:

DeltaRollbacks: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user rollbacks' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.
Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time

## Total CPU Time

#### Description

This data item represents the total amount of CPU time, in seconds, used by this session.

#### Data Source

DeltaTotalCpuTime
where:

DeltaTotalCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Parse CPU

## Parse CPU

#### Description

This data item represents the amount of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

DeltaParseTime
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU

## Recursive CPU

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the amount of this session's CPU time that is being used for recursive calls.

#### Data Source

DeltaRecursiveTime
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Block Gets

## Block Gets

#### Description

This data item represents the number of blocks obtained in CURRENT mode.

#### Data Source

DeltaBlockGets
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Consistent Gets

## Consistent Gets

#### Description

This data item represents the number of times a consistent read was requested for a block.

#### Data Source

DeltaConsistentGets
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of data blocks read from disk during this sample period.

#### Data Source

DeltaPhysicalReads
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes

## Block Changes

number of changes that were made to all blocks in the SGA that were part of an update or delete operation

Consistent Changes

## Consistent Changes

The number of times a database block has applied rollback entries to perform a consistent read on the block

Disk Sorts

## Disk Sorts

Number of sorts with disk writes

Memory Sorts

## Memory Sorts

Number of sorts with no disk writes

Sort Rows

## Sort Rows

The total number of rows sorted

Parse Count (Hard)

## Parse Count (Hard)

The total number of parse calls (real parses).

Parse Count Total

## Parse Count Total

Total number of parse calls (hard and soft).

Parse Elapsed Time

## Parse Elapsed Time

Total elapsed time for parsing, in seconds

UGA Memory

## UGA Memory

Current UGA size for the session

Logon Time

## Logon Time

#### Description

This data item represents the time of logon by this session.

#### Data Source

select logon from v$session s

#### User Action

Physical Reads(%)

## Physical Reads(%)

#### Description

This data item represents the percentage of total physical reads that were attributed to this session during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

Logical Reads(%)

## Logical Reads(%)

#### Description

This data item represents the percentage of total buffer gets that were attributed to this session during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session logical reads' and n.statistic#=s.statistic#' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

Username Table Scans

# Username Table Scans

Table scan statistics by user

This class includes the following charts:

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

Username Table Scans Default Chart
Username Table Scans Default Chart

Table scan statistics by user

Long Tables/Sec

## Long Tables/Sec

#### Description

This data item represents the number of long table scans per second during this sample period. A table is considered 'long' if the table is not cached and if its high-water mark is greater than 5 blocks.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='table scans (long tables)' and n.statistic#=s.statistic#

#### User Action

Short Tables/Sec

## Short Tables/Sec

#### Description

This data item represents the number of short table scans per second during this sample period. A table scan is considered 'short' if the table is cached or if its high-water mark is less than 5 blocks.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='table scans (short tables)' and n.statistic#=s.statistic#

#### User Action

Rows Gotten/Sec

## Rows Gotten/Sec

#### Description

During scanning operations, each row is retrieved sequentialy by the Oracle Server. This data item represents the number of rows scanned per second during this sample period.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='table scan rows gotten' and n.statistic#=s.statistic#

#### User Action

Fetch Continued Rows/Sec

## Fetch Continued Rows/Sec

#### Description

In two circumstances the data for a row in a table may be too large to fit into a single data block. This results in row fragmentation.

In the first case, the row is too large to fit into one data block when it is first inserted. In this case, the Oracle Server stores the data for the row in a chain of data blocks reserved for that segment. Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG or LONG RAW. Row continuation in these cases is unavoidable without using a larger DB_BLOCK_SIZE.

In the second case, however, a row that originally fit into one data block is updated so that the overall row length increases and the block's free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit into a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row.

When a row is chained or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row.

This data item represents the number of chained row retrievals per second during the sample period.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='table fetch continued row' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Blocks Gotten/Sec

## Blocks Gotten/Sec

#### Description

During scanning operations, each row is retrieved sequentially by Oracle. This data item represents the number of blocks retrieved from the buffer cache per second during the sample period.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='table scan blocks gotten' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Cache Partitions/Sec

## Cache Partitions/Sec

#### Description

This data item represents the number of full table scans, per second during the sample period, on tables using the CACHE option. The CACHE option specifies that the blocks retrieved for the table are placed at the most recently used end of the LRU list in the buffer cache when a full scan is performed. This option is useful for small lookup tables that are accessed frequently.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='table scans (cache partitions)' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Direct Reads/Sec

## Direct Reads/Sec

#### Description

This data item represents the number of full tables scans, per second during the sample period, that were performed with direct read thus bypassing the buffer cache.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='table scans (direct reads)' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Rowid Ranges/Sec

## Rowid Ranges/Sec

#### Description

This data item represents the number of full tables scans with specified ROWID endpoints per second during the sample period,

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='table scans (rowid ranges)' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Shared Pool

# Shared Pool

Shows statistics about the shared pool

This class includes the following charts:

SGA Free Memory

SGA Request Failure and Miss Rates

SGA Breakdown

SGA Hit %

Shared Pool Default Chart
Shared Pool Default Chart

Shows statistics about the shared pool

Free Memory Size

## Free Memory Size

#### Description

This data item represents size, in megabytes, of available free memory in the shared pool.

#### Data Source

select bytes/1024/1024 from v$sgastat where name = 'free memory'

#### User Action

Rsvd List Request Misses

## Rsvd List Request Misses

#### Description

This data item represents the number of times the reserved list did not have a free piece of memory to statisfy the request and needed to begin flushing objects from the LRU list.

This value is only valid when the initialization parameter SHARED_POOL_RESERVED_SIZE is set to a valid value.

#### Data Source

select request_misses from v$shared_pool_reserved

#### User Action

Rsvd List Request Failures

## Rsvd List Request Failures

#### Description

This data item represents the number of times no memory was found to satisfy a shared pool request; that is, the number of times an ORA-4031 occurred.

#### Data Source

select request_failures from v$shared_pool_reserved

#### User Action

Request failures is a very clear indicator that the size of the shared pool is not sufficient.
Shared Pool Size

## Shared Pool Size

#### Description

The shared pool portion of the SGA contains three major areas: library cache, dictionary cache and various control structures. The total size of the shared pool is determined by the initialization parameter SHARED_POOL_SIZE.

This data item represents the size, in megabytes, of the shared pool.

If the shared pool is not large enough, users will consume additional resources to complete a database operation. For the library cache, the overhead will primarily be the additional CPU resources used to reparse the SQL statement. The overhead for the dictionary cache will show up as additional I/O, since dictionary references that have been displaced from the cache will need to be refetched from disk. The impact to user response times will vary depending on whether there is a bottlenect on the resource charged for the overhead.

If the shared pool is too large, memory resources are wasted that could be utilized elsewhere in the database environment. This can contribute to performance degradation in database environments where memory is already a scarce resource. In addition, the extra memory used for the shared pool will not be available for use by other processes on the system, nor could it be utilized for other caches, such as the buffer cache.

#### Data Source

select value from v$parameter where name='shared_pool_size'

#### User Action

Shared Pool Reserved Size

## Shared Pool Reserved Size

#### Description

The shared pool portion of the SGA contains three major areas: library cache, dictionary cache and various control structures.

This data item represents the size, in megabytes, of the shared pool space which is reserved for large contiguous requests for shared pool memory. This parameter, along with the SHARED_POOL_RESERVED_MIN_ALLOC parameter, can be used to avoid performance degradation in the shared pool from situations where pool fragmentation forces Oracle to search and free chunks of unused pool to compile the current request.

#### Data Source

select value from v$parameter where name='shared_pool_reserved_size'

#### User Action

Session UGA Size

## Session UGA Size

#### Description

This data item represents the current UGA size for a session.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='session uga memory' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Session UGA Max Memory

## Session UGA Max Memory

#### Description

This data item represents the peak UGA size for a session.

#### Data Source

select se.username,s.value from v$sesstat s, v$statname n, v$session se where n.name='session uga memory max' and n.statistic#=s.statistic# and s.sid=se.sid

#### User Action

Reserved List Alloc HitRatio

## Reserved List Alloc HitRatio

#### Description

This data item represents the shared pool reserved list hit ratio. This value gives an indication of how well the reserved list is operating and should be between 95 to 100 percent.

#### Data Source

((Requests - Misses) / Requests) * 100
where:

Requests: select requests from v$shared_pool_reserved
Misses: select request_misses from v$shared_pool_reserved

#### User Action

Java Pool Size

## Java Pool Size

#### Description

This data item represents the size, in megabytes, of the Java pool.

#### Data Source

select value from v$parameter where name='java_pool_size'

#### User Action

DB Block Buffers Size

## DB Block Buffers Size

#### Description

This data item represents the size, in megabytes, of the database block buffers.

#### Data Source

select sum(decode(name,'db_block_buffers',bytes)) from v$sgasta

#### User Action

Log Buffer Size

## Log Buffer Size

#### Description

This data item represents the size, in megabytes, of the log buffer.

#### Data Source

select sum(decode(name,'log_buffer',bytes)) from v$sgasta

#### User Action

Fixed SGA Size

## Fixed SGA Size

#### Description

This data item represents the size, in megabytes, of the fixed portion of the SGA.

#### Data Source

select sum(decode(name,'fixed_sga',bytes)) from v$sgasta

#### User Action

Instance Size Statistics

# Instance Size Statistics

Statistics that indicate the current size of the database and its objects

This class includes the following charts:

Database Size

Redo Log Buffer Size

Object Counts

Instance Size Statistics Default Chart
Instance Size Statistics Default Chart

Statistics that indicate the current size of the database and its objects

Database Size

## Database Size

#### Description

This data item represents the size, in megabytes, of the database.

#### Data Source

select sum(bytes)/(1024*1024) from sys.dba_data_files where status = 'AVAILABLE'

#### User Action

Number of Tablespaces

## Number of Tablespaces

#### Description

This data item represents the number of tablespaces in the database,

#### Data Source

select count(*) from sys.dba_tablespaces where status != 'OFFLINE'

#### User Action

Number of Schemas

## Number of Schemas

#### Description

This data item represents the number of schemas in the database,

#### Data Source

select count(*) from sys.user$ u where exists (select null from sys.obj$ o where o.owner# = u.user# and o.type# in (1,2,3,19,20,21,34,35,40,41))

#### User Action

Number of Datafiles

## Number of Datafiles

#### Description

This data item represents the number of datafiles in the database,

#### Data Source

select count(*) from sys.dba_data_files where status = 'AVAILABLE'

#### User Action

Number of Users

## Number of Users

#### Description

This data item represents the number of users in the database,

#### Data Source

select count(*) from sys.dba_users

#### User Action

Max Log Buffer Size

## Max Log Buffer Size

#### Description

This data item represents the maximum size, in megabytes, of the log buffer.

#### Data Source

select max(bytes)/(1024*1024) from v$log

#### User Action

Locks

# Locks

Locks currently held by the Oracle server and outstanding requests for a lock or latch

This class includes the following charts:

Lock Manager

User Type Locks Chart

Locks Default Chart
Locks Default Chart

Locks currently held by the Oracle server and outstanding requests for a lock or latch

Session Id

## Session Id

Session holding or acquiring the lock

Session Serial Number

## Session Serial Number

Session serial number of session holding or acquiring the lock

Lock Type

## Lock Type

#### Description

Enqueues are shared memory structures (locks) that serialize access to database resources. They can be associated with a session or transaction. Enqueue names are displayed in the LOCK_TYPE column of the DBA_LOCKS and DBA_LOCK_INTERNAL data dictionary views.

A resource uniquely identifies an object that can be locked by different sessions within an instance (local resource) or between instances (global resource). Each session that tries to lock the resource will have an enqueue on the resource. Note: The names of enqueues and their definitions may change from release to release.

The Oracle enqueues are:

BL, Buffer Cache Management
CF, Controlfile Transaction
CI, Cross-instance Call Invocation
CU, Bind Enqueue
DF, Datafile
DL, Direct Loader Index Creation
DM, Database Mount
DR, Distributed Recovery
DX, Distributed TX
FS, File Set
IN, Instance Number
IR, Instance Recovery
IS, Instance State
IV, Library Cache Invalidation
JQ, Job Queue
KK, Redo Log "Kick"
L[A-P], Library Cache Lock
MR, Media Recovery
N[A-Z], Library Cache Pin
PF, Password File
PI, Parallel Slaves
PR, Process Startup
PS, Parallel Slave Synchronization
Q[A-Z], Row Cache
RT, Redo Thread
SC, System Commit Number
SM, SMON
SQ, Sequence Number Enqueue
SR, Synchronized Replication
SS, Sort Segment
ST, Space Management Transaction
SV, Sequence Number Value
TA, Transaction Recovery
TM, DML Enqueue
TS, Temporary Segment (also TableSpace)
TT, Temporary Table
TX, Transaction
UL, User-defined Locks
UN, User Name
US, Undo Segment, Serialization
WL, Being Written Redo Log
XA, Instance Attribute Lock
XI, Instance Registration Lock

#### Data Source

LOCK_TYPE column from V$LOCK table.

#### User Action

Determine the cause for the lock contention and try to remove it. Although drastic, a session can be killed by selecting a session and using the kill session tool. This should be used as a last resort to remove the blocking lock if it has been determined that it won't be freed up any time soon.
Mode Held

## Mode Held

Lock mode in which the session holds the lock

Mode Requested

## Mode Requested

Lock mode in which the process requests the lock

Object Name

## Object Name

Name of the object being locked

ROWID

## ROWID

The current ROWID being locked

Object Owner

## Object Owner

User name of the owner of the object

Object Type

## Object Type

Type of object

Resource ID1

## Resource ID1

Lock identifier #1 (depends on type)

Resource ID2

## Resource ID2

Lock identifier #2 (depends on type)

Process Id

## Process Id

Operating System Process Id

Session Activity Counts

# Session Activity Counts

Counts of sessions that are active, waiting, logged on, etc.

This class includes the following charts:

Session Counts

Session Activity Counts Default Chart
Session Activity Counts Default Chart

Counts of sessions that are active, waiting, logged on, etc.

Session Count

## Session Count

#### Description

This data item represents the number of sessions currently marked with the associated status. The status of the session can be:

ACTIVE: currently executing SQL
INACTIVE: inactive
KILLED: marked to be killed
CACHED: temporary cached for use by Oracle*XA
SNIPED: session inactive, waiting on the client

#### Data Source

select status from v$session group by status

#### User Action

Transaction Statistics

# Transaction Statistics

Current number of transactions by action type at this instant

This class includes the following charts:

Concurrent Transaction Count

Current Operations Breakdown

Transaction Statistics Default Chart
Transaction Statistics Default Chart

Current number of transactions by action type at this instant

Concurrent Transactions

## Concurrent Transactions

#### Description

This data item represents the number of active sessions.

#### Data Source

select sum(decode(command,0,0,1)) from v$session where status = 'ACTIVE'

#### User Action

Selects

## Selects

#### Description

This data item represents the number of SELECT statements being performed at time of sampling.

#### Data Source

select sum(decode(command,3,1,0)) from v$session where status = 'ACTIVE'

#### User Action

Updates

## Updates

#### Description

This data item represents the number of UPDATE statements being performed at time of sampling.

#### Data Source

select sum(decode(command,6,1,0)) from v$session where status = 'ACTIVE'

#### User Action

Inserts

## Inserts

#### Description

This data item represents the number of INSERT statements being performed at time of sampling.

#### Data Source

select sum(decode(command,2,1,0)) from v$session where status = 'ACTIVE'

#### User Action

Deletes

## Deletes

#### Description

This data item represents the number of DELETE statements being performed at time of sampling.

#### Data Source

select sum(decode(command,7,1,0)) from v$session where status = 'ACTIVE'

#### User Action

Load

# Load

Load Container Class

Load Default Chart
Load Default Chart

Load Container Class

Circuit

# Circuit

Statistics of user connections to the database through dispatchers and servers

Circuit Default Chart
Circuit Default Chart

Statistics of user connections to the database through dispatchers and servers

Server

## Server

Name of shared server

Session

## Session

Session id.

Serial

## Serial

Session serial number

Status

## Status

Status of the circuit

Queue

## Queue

Queue the circuit is currently on

Message

## Message

Total number of messages that have gone through this circuit

Bytes

## Bytes

Total number of bytes that have gone through this circuit

Dispatcher

# Dispatcher

Dispatcher process statistics

This class includes the following charts:

Dispatcher Statistics

Dispatcher Default Chart
Dispatcher Default Chart

Dispatcher process statistics

Status

## Status

Dispatcher status

Accept

## Accept

Whether this dispatcher is accepting new connections

Messages/sec

## Messages/sec

Number of messages processed by this dispatcher

Bytes/sec

## Bytes/sec

Size in bytes of messages processed by this dispatcher

Owned

## Owned

Number of circuits owned by this dispatcher

Idle

## Idle

Time spent idle, in seconds

Busy

## Busy

Percentage of time spent busy this sample period

% Busy

## % Busy

Busy/(busy+idle)

% Idle

## % Idle

Idle/(busy+idle)

Avg Wait Per Response

## Avg Wait Per Response

Amount of time spent waiting for each response on the queue, in seconds

Dispatcher Contention

# Dispatcher Contention

Dispatcher contention statistics

This class includes the following charts:

Dispatcher Contention

Dispatcher Contention Default Chart
Dispatcher Contention Default Chart

Dispatcher contention statistics

Busy Rate

## Busy Rate

Busy/(busy+idle)*100

Avg Wait

## Avg Wait

Average wait per item in the queue

Shared Server

# Shared Server

Shared server processes statistics

This class includes the following charts:

Shared Server Statistics

Shared Server Default Chart
Shared Server Default Chart

Shared server processes statistics

Status

## Status

Server status

Requests/Sec

## Requests/Sec

Number of requests taken from the common queue per second

Idle

## Idle

Total idle time, in seconds

Busy

## Busy

Total busy time, in seconds

% Busy

## % Busy

Busy / (Idle+Busy) * 100

Circuit Name

## Circuit Name

Address of circuit currently being serviced

MTS Statistics

# MTS Statistics

Statistics of multi-threaded server

This class includes the following charts:

MTS Load

Server Types and Counts

MTS Server Start/Stops

MTS Statistics Default Chart
MTS Statistics Default Chart

Statistics of multi-threaded server

Dedicated Servers

## Dedicated Servers

Number of dedicated servers

Current Shared Servers

## Current Shared Servers

Number of shared servers

Dispatchers

## Dispatchers

Number of dispatchers

Servers Min

## Servers Min

Minimum number of shared servers allowed

Servers High Watermark

## Servers High Watermark

The highest number of servers running at one time since the instance started

Max Servers

## Max Servers

Maximum number of shared server processes allowed to be running simultaneously

Servers Started/Sec

## Servers Started/Sec

Number of shared server processes that Oracle started

Servers Terminated/Sec

## Servers Terminated/Sec

Number of shared server processes that Oracle terminated

Servers Busy %

## Servers Busy %

Average load across all servers

Dispatchers Busy %

## Dispatchers Busy %

Average load across all dispatchers

% Current Servers of Max

## % Current Servers of Max

(Current shared servers/max servers * 100) how close is the current count to the maximum number of servers

% Peak Servers of Max

## % Peak Servers of Max

High watermark/max servers * 100 how close has the high watermark come to servers limit

Parallel Server Block Ping

# Parallel Server Block Ping

Total max block ping for all instances

Parallel Server Block Ping Default Chart
Parallel Server Block Ping Default Chart

Total max block ping for all instances

Block Pings

## Block Pings

Sum of max block pings.

Parallel Server Block Ping by Tablespace

# Parallel Server Block Ping by Tablespace

Block ping by tablespace statistics.

Parallel Server Block Ping by Tablespace Default Chart
Parallel Server Block Ping by Tablespace Default Chart

Block ping by tablespace statistics.

Block Pings

## Block Pings

Max block ping for each tablespace

Parallel Server Block Ping by Instance

# Parallel Server Block Ping by Instance

Max block ping for each instance

Parallel Server Block Ping by Instance Default Chart
Parallel Server Block Ping by Instance Default Chart

Max block ping for each instance

Block Pings

## Block Pings

Max block ping for each instance

Parallel Server File I/O Rate

# Parallel Server File I/O Rate

File read/write statistics for all instances

Parallel Server File I/O Rate Default Chart
Parallel Server File I/O Rate Default Chart

File read/write statistics for all instances

Physical Reads/Sec

## Physical Reads/Sec

Number of physical reads / second

Physical Writes/Sec

## Physical Writes/Sec

Number of times DBWR is required to write

Parallel Server File I/O Rate by Object

# Parallel Server File I/O Rate by Object

File read/write statistics for each datafile

Parallel Server File I/O Rate by Object Default Chart
Parallel Server File I/O Rate by Object Default Chart

File read/write statistics for each datafile

Physical Reads/Sec

## Physical Reads/Sec

Number of physical reads / second

Physical Writes/Sec

## Physical Writes/Sec

Number of times DBWR is required to write

Parallel Server File I/O Rate by Instance

# Parallel Server File I/O Rate by Instance

File read/write statistics for each instance

Parallel Server File I/O Rate by Instance Default Chart
Parallel Server File I/O Rate by Instance Default Chart

File read/write statistics for each instance

Physical Reads/Sec

## Physical Reads/Sec

Number of physical reads / second

Physical Writes/Sec

## Physical Writes/Sec

Number of times DBWR is required to write

Parallel Server Lock Activity

# Parallel Server Lock Activity

Displays the DLM lock operation activity of all instances

Parallel Server Lock Activity Default Chart
Parallel Server Lock Activity Default Chart

Displays the DLM lock operation activity of all instances

From:

## From:

PCM lock initial state: NULL; S; X; SSX

To:

## To:

PCM lock initial state: NULL; S; X; SSX

Sum

## Sum

Number of times the lock operation executed

Parallel Server Sessions

# Parallel Server Sessions

Current session statistics

Parallel Server Sessions Default Chart
Parallel Server Sessions Default Chart

Current session statistics

Session Serial Number

## Session Serial Number

Session serial number

PID

## PID

Oracle process identifier

Status

## Status

Status of the session

Username

## Username

Oracle username

Lock Wait

## Lock Wait

Address of lock this session is waiting for

Command

## Command

Command in progress (last statement parsed)

Parallel Server Users

# Parallel Server Users

Number of users for all instances.

Parallel Server Users Default Chart
Parallel Server Users Default Chart

Number of users for all instances.

Logged On

## Logged On

Number of users that have logged on to OPS server

Active

## Active

Number of active users

Parallel Server Users Per Instance

# Parallel Server Users Per Instance

Number of users for each instance

Parallel Server Users Per Instance Default Chart
Parallel Server Users Per Instance Default Chart

Number of users for each instance

Logged On

## Logged On

Number of users that have logged on for each instance

Active

## Active

Number of active users for each instance

Redo Latch

# Redo Latch

Redo latch statistics

Redo Latch Default Chart
Redo Latch Default Chart

Redo latch statistics

Redo no wait %

## Redo no wait %

Redo allocation hit %

## Redo allocation hit %

Immediate missing ratio

## Immediate missing ratio

SQL Text

# SQL Text

The full SQL text

This class includes the following charts:

SQL Text

SQL Text Default Chart
SQL Text Default Chart

The full SQL text

SQL Text

## SQL Text

#### Description

This data item represents the complete SQL text.

#### Data Source

select piece, sql_text from v$sqltext_with_newlines order by piece ASC

#### User Action

Parallel Server Instance

# Parallel Server Instance

Parallel Server instance statistics

Parallel Server Instance Default Chart
Parallel Server Instance Default Chart

Parallel Server instance statistics

Instance Number

## Instance Number

Instance number used for instance registration

Host Name

## Host Name

Name of the host machine

PARALLEL

## PARALLEL

YES/NO in parallel server mode

Thread#

## Thread#

Redo thread opened by the instance

User

# User

Usernames

User Default Chart
User Default Chart

Usernames

User Number

## User Number

User number

Overview of Performance

# Overview of Performance

Performance overview charts

Overview of Performance Default Chart
Overview of Performance Default Chart

Performance overview charts

Sessions

# Sessions

Summary information of top sessions as measured by the selected sort statistic

Sessions Default Chart
Sessions Default Chart

Summary information of top sessions as measured by the selected sort statistic

Session Name

## Session Name

#### Description

This data item represents either the Oracle username of the current session or the name of the background process.

#### Data Source

select NVL(s.username, b.name) from v$session s, v$bgprocess b

#### User Action

OS Username

## OS Username

#### Description

This data item represents the name of the operating system client user.

#### Data Source

select osuser from v$session

#### User Action

Sort Statistic

## Sort Statistic

#### Description

This data item contains the value for the sort statistic which was used to order the sessions for display.

#### Data Source

select value from v$sesstat where statistic#=:1

#### User Action

Status

## Status

#### Description

This data item represents the status of this session.

ACTIVE: currently executing SQL
INACTIVE: inactive
KILLED: marked to be killed
CACHED: temporary cached for use by Oracle*XA
SNIPED: session inactive, waiting on the client

#### Data Source

select status from v$session

#### User Action

Machine

## Machine

#### Description

This data item represents the operating system machine name.

#### Data Source

select machine from v$session

#### User Action

Terminal

## Terminal

#### Description

This data item represents the operating system terminal name.

#### Data Source

select terminal from v$session

#### User Action

Program

## Program

#### Description

This data item represents the name of the client program.

#### Data Source

select program from v$session

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$session

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$session

#### User Action

Serial #

## Serial #

#### Description

This data item represents the session serial number. This value is used to uniquely identify a session's objects. It guarantees that session-level commands are applied to the correct session objects if the session ends and another session begins with the same session ID.

#### Data Source

select serial# from v$session

#### User Action

SPID

## SPID

#### Description

This data item represents the Oracle process identifier.

#### Data Source

select p.spid from v$process p, v$session s where s.paddr = p.addr

#### User Action

Commit Count

## Commit Count

#### Description

This data item represents the number of user commits performed by this session during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits
where:

DeltaCommits: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user commits' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Rollback Count

## Rollback Count

#### Description

This data item represents the number of times this session manually issued a ROLLBACK statement or an error occurs during a session's transaction during the sample period.

#### Data Source

DeltaRollbacks
where:

DeltaRollbacks: difference of 'select s.value from v$sesstat s, v$statname n where n.name='user rollbacks' and n.statistic#=s.statistic#' between sample end and start

#### User Action

This statistic shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.
Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time

## Total CPU Time

#### Description

This data item represents the total amount of CPU time, in seconds, used by this session.

#### Data Source

DeltaTotalCpuTime
where:

DeltaTotalCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Parse CPU

## Parse CPU

#### Description

This data item represents the amount of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

DeltaParseTime
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU

## Recursive CPU

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

DeltaRecursiveTime
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Block Gets

## Block Gets

#### Description

This data item represents the number of blocks obtained in CURRENT mode.

#### Data Source

DeltaBlockGets
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Consistent Gets

## Consistent Gets

#### Description

This data item represents the number of times a consistent read was requested for a block.

#### Data Source

DeltaConsistentGets
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of data blocks read from disk during this sample period.

#### Data Source

DeltaPhysicalReads
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes

## Block Changes

Number of changes that were made to all blocks in the SGA that were part of an update or delete operation

Consistent Changes

## Consistent Changes

Number of times a database block has applied rollback entries to perform a consistent read on the block

Disk Sorts

## Disk Sorts

Number of sorts with disk writes

Memory Sorts

## Memory Sorts

Number of sorts with no disk writes

Sort Rows

## Sort Rows

Total number of rows sorted

Parse Count (Hard)

## Parse Count (Hard)

Total number of parse calls (real parses)

Parse Count Total

## Parse Count Total

Total number of parse calls (hard and soft).

Parse Elapsed Time

## Parse Elapsed Time

Total elapsed time for parsing, in seconds

UGA Memory

## UGA Memory

Current UGA size for the session

Logon Time

## Logon Time

#### Description

This data item represents the time of logon by this session.

#### Data Source

select logon from v$session s

#### User Action

Session Logical Reads

## Session Logical Reads

#### Description

This data item represents the total number of logical reads this session has made.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session logical reads' and n.statistic#=s.statistic#

#### User Action

User Session Response Time

# User Session Response Time

Response time broken down by individual users, then session

This class includes the following charts:

Avg Trans. Length Per Session

Session Transaction Rates (Insert/Update)

Elapsed Time per Execute per Session

Session Waits or CPU?

User Session Response Time Default Chart
User Session Response Time Default Chart

Response time broken down by individual users, then session

% Wait Time

## % Wait Time

#### Description

This data item represents the percentage of time spent waiting, instance-wide, for resources or objects.

TotalWait / (TotalWait + CpuTime)
where:

TotalWait: sum of time waited for all wait events in v$system_event
CpuTime: select value from v$sysstat where name='CPU used by this session'

#### User Action

Investigate further into which specific wait events are responsible for the bulk of the wait time. Individual wait events may identify unique problems within the database. Diagnosis will be tailored where appropriate through drilldowns specific to individual wait events.
% CPU Time

## % CPU Time

#### Description

This data item represents the percentage of time, instance-wide, spent executing instructions by the CPU.

#### Data Source

CpuTime / (TotalWait + CpuTime)
where:

CpuTime: select value from v$sysstat where name='CPU used by this session'
TotalWait: sum of time waited for all wait events in v$system_event

#### User Action

When CPU is the largest contributor to total reponse time, it needs to be broken down to properly understand the problem further. Basically, CPU Time is broken down into 3 categories:

Parse CPU time: Amount of CPU used for parsing SQL statements.
Recursive CPU: Amount of CPU used for parsing row cache statements such as lookups in the data dictionary, executing triggers, PL/SQL, etc.
Other CPU: Amount of CPU used for tasks such as looking up buffers, fetching rows or index keys, etc.
Response Time per Trans

## Response Time per Trans

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per transaction.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaCommits + DeltaRollbacks)
where:

DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session'' between sample end and start
DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start
DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.
Transaction Count

## Transaction Count

#### Description

This data item represents the total number of commits and rollbacks performed during this sample period.

#### Data Source

DeltaCommits + DeltaRollbacks
where:

DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start
DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Commit Count

## Commit Count

#### Description

This data item represents the number of user commits performed during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits
where:

DeltaCommits: difference of 'select value from v$sysstat where name='user commits'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Rollback Count

## Rollback Count

#### Description

This data item represents the number of times users manually issue the ROLLBACK statement or an error occurs during a user's transactions during the sample period.

#### Data Source

DeltaRollbacks
where:

DeltaRollbacks: difference of 'select value from v$sysstat where name='user rollbacks'' between sample end and start

#### User Action

This statistic shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.
Response Time Per Execute

## Response Time Per Execute

#### Description

Using only statistics available within the database, this data item gives the best approximation of response time, in seconds, per SQL statement execution. This statistic may be more valid than response time per transaction as it shows accurate values even for read-only access.

#### Data Source

(DeltaTotalWait + DeltaCpuTime) / (DeltaUserCalls + DeltaRecursiveCalls)
where:

DeltaTotalWait: difference of 'sum of time waited for all wait events in v$system_event' between sample end and start
DeltaCpuTime: difference of 'select value from v$sysstat where name='CPU used by this session'' between sample end and start
DeltaUserCalls: difference of 'select value from v$sysstat where name='user calls'' between sample end and start
DeltaRecursiveCalls: difference of 'select value from v$sysstat where name='recursive calls'' between sample end and start

#### User Action

Investigate further into which component, waits or CPU, is responsible for the majority of the response time and continue diagnosis.
Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements during the sample period. This statistic is an indication of the number of SQL statements that are being processed per sample period.

#### Data Source

DeltaUserCalls + DeltaRecursiveCalls
where:

DeltaUserCalls: difference of 'select value from v$sysstat where name='user calls'' between sample end and start
DeltaRecursiveCalls: difference of 'select value from v$sysstat where name='recursive calls'' between sample end and start

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the execution rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually a drop in execution rates, and an increase in response time may be indicators of problems. Depending upon the application, execution loads may vary widely across different times of the day.
Session Buffer Busy

# Session Buffer Busy

Show session wait on file and block#

This class includes the following charts:

Session Buffer Busy Wait

Session Buffer Busy Default Chart
Session Buffer Busy Default Chart

Show session wait on file and block#

Filename

## Filename

Data file name

Block#

## Block#

Block number

Wait

## Wait

Type of wait

Segment Name

## Segment Name

Name of the segment that contains the block being waited on

Owner

## Owner

Owner of segment

Response Time

# Response Time

Classes that display response time and its breakdown

Response Time Default Chart
Response Time Default Chart

Classes that display response time and its breakdown

Wait Events

# Wait Events

Classes related to wait events and their diagnosis

Wait Events Default Chart
Wait Events Default Chart

Classes related to wait events and their diagnosis

User Statistics

# User Statistics

Classes that break down statistics by user

User Statistics Default Chart
User Statistics Default Chart

Classes that break down statistics by user

Database Instance

# Database Instance

Statistics that are database wide (v$systat in origin)

Database Instance Default Chart
Database Instance Default Chart

Statistics that are database wide (v$systat in origin)

I/O

# I/O

I/O classes

I/O Default Chart
I/O Default Chart

I/O classes

Memory

# Memory

SGA utilization, various cache statistics, etc.

Memory Default Chart
Memory Default Chart

SGA utilization, various cache statistics, etc.

Background Processes

# Background Processes

Redo log, DBWR, and other statistics related to background processes

Background Processes Default Chart
Background Processes Default Chart

Redo log, DBWR, and other statistics related to background processes

Storage

# Storage

Tablespace and other storage-related information

Storage Default Chart
Storage Default Chart

Tablespace and other storage-related information

SQL Sorted by Module, Action

# SQL Sorted by Module, Action

SQL for applications that utilize the DBMS_APPLICATION_INFO package

This class includes the following charts:

SQL Sorted by Module, Action, Phys Reads

SQL Sorted by Module, Action, Buffer Gets

SQL Sorted by Module, Action Default Chart
SQL Sorted by Module, Action Default Chart

SQL for applications that utilize the DBMS_APPLICATION_INFO package

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads performed by this statement during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache during this sample period.

#### Data Source

DeltaBufferGets
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Application Monitoring

# Application Monitoring

Classes of data that report on applications using the DBMS_APPLICATION_INFO package

This class includes the following charts:

Application Module Activity

Application Monitoring Default Chart
Application Monitoring Default Chart

Classes of data that report on applications using the DBMS_APPLICATION_INFO package

Session Count

## Session Count

#### Description

This data item represents the number of sessions that are currently executing under a particular module.

#### Data Source

select count(module) from v$session where module_hash != 0
SQL statement Count

## SQL statement Count

The count of SQL statements in the cache that have this module set

Sessions Waiting on Events

# Sessions Waiting on Events

Count of sessions currently waiting for particular events

This class includes the following charts:

Sessions Waiting

Sessions Waiting on Events Default Chart
Sessions Waiting on Events Default Chart

Count of sessions currently waiting for particular events

Session Count

## Session Count

#### Description

This data item represents the number of sessions currently waiting on this event.

#### Data Source

select count(*) from v$session_wait where wait_time = 0
MTS

# MTS

Multi-Threaded Server Classes

MTS Default Chart
MTS Default Chart

Multi-Threaded Server Classes

OPS

# OPS

Oracle Parallel Server Classes

OPS Default Chart
OPS Default Chart

Oracle Parallel Server Classes

Host Level Statistics

# Host Level Statistics

Hosts (nodes) currently attached to the server and their statistics

This class includes the following charts:

Per Host CPU Breakdown

Host Total CPU Time

Host Level Statistics Default Chart
Host Level Statistics Default Chart

Hosts (nodes) currently attached to the server and their statistics

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of hard parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Program Level Statistics

# Program Level Statistics

Programs currently attached to the server and their statistics

This class includes the following charts:

Program CPU Breakdown

Program Total CPU Time

Program Level Statistics Default Chart
Program Level Statistics Default Chart

Programs currently attached to the server and their statistics

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parallel Query

# Parallel Query

Parallel Query activity

Parallel Query Default Chart
Parallel Query Default Chart

Parallel Query activity

Process ID

## Process ID

Oracle process identifier

SPID

## SPID

Operating system process identifier

Instance ID

## Instance ID

Instance ID

Server Group

## Server Group

The logical group of servers to which this parallel server process belongs

Server Set

## Server Set

The logical set of servers to which this parallel server process belongs

Degree

## Degree

Degree of parallelism being used by the server set

Requested Degree

## Requested Degree

Degree of parallelism that was requested by the user

Wait Event

## Wait Event

Event name this session is waiting for

Tables That Can't Extend

# Tables That Can't Extend

Tables that cannot extend because next_extent is larger than available space

Tables That Can't Extend Default Chart
Tables That Can't Extend Default Chart

Tables that cannot extend because next_extent is larger than available space

Tablespace name

## Tablespace name

Tablespace name

Owner

## Owner

Owner of the table

Next extend

## Next extend

Next extend

Largest Free Space (bytes)

## Largest Free Space (bytes)

Size of the largest free chunk in the tablespace

Session Statistics By Host

# Session Statistics By Host

Session statistics for host

This class includes the following charts:

Machine Session Details

Session Statistics By Host Default Chart
Session Statistics By Host Default Chart

Session statistics for host

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Serial#

## Serial#

Session serial number

Session Statistics By Program

# Session Statistics By Program

Session statistics for program

This class includes the following charts:

Program Session Details

Session Statistics By Program Default Chart
Session Statistics By Program Default Chart

Session statistics for program

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Serial#

## Serial#

Session serial number

Session Statistics By User

# Session Statistics By User

Session statistics for user

This class includes the following charts:

User Session Details

Session Statistics By User Default Chart
Session Statistics By User Default Chart

Session statistics for user

Parse Count

## Parse Count

#### Description

This data item represents the total number of parse calls (hard and soft) for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#

#### User Action

Execute Count

## Execute Count

#### Description

This data item represents the total number of calls (user and recursive) that executed SQL statements for this session.

#### Data Source

UserCalls + RecursiveCalls
where:

UserCalls: select s.value from v$sesstat s, v$statname n where n.name='user calls' and n.statistic#=s.statistic#
RecursiveCalls: select s.value from v$sesstat s, v$statname n where n.name='recursive calls' and n.statistic#=s.statistic#

#### User Action

Session Cursor Cache Hits

## Session Cursor Cache Hits

#### Description

This data item represents the number of hits in the session cursor cache during this sample period.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache hits' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Session Cursor Cache Count

## Session Cursor Cache Count

#### Description

This data item represents the total number of cursors cached during this sample period. This value is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheHits
where:

DeltaCursorCacheHits: difference in 'select s.value from v$sesstat s, v$statname n where n.name='session cursor cache count' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

Total CPU Time %

## Total CPU Time %

#### Description

This data item represents the percentage of CPU time being used by this session.

#### Data Source

(DeltaCpuTime / DeltaTotalCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period
DeltaTotalCpuTime: difference in 'select value from v$sysstat where name='CPU used by this session'' between end and start of sample period

#### User Action

Parse CPU %

## Parse CPU %

#### Description

This data item represents the percentage of this session's CPU time that is being used for parsing (hard and soft). Parse time CPU can be a strong indication that an application has not been well tuned. High parse time CPU usually indicates that the application may be spending too much time opening and closing cursors or is not using bind variables.

#### Data Source

(DeltaParseTime / DeltaCpuTime) * 100
where:

DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If excessive parsing is taking place, examine SQL statements. Look for statements that can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Recursive CPU %

## Recursive CPU %

#### Description

Sometimes, to execute a SQL statement issued by a user, the Oracle Server must issue additional statements. Such statements are called recursive calls or recursive SQL statements. For example, if you insert a row into a table that does not have enough space to hold that row, the Oracle Server makes recursive calls to allocate the space dynamically if dictionary managed tablespaces are being used. Recursive calls are also generated:

when data dictionary information is not available in the data dictionary cache and must be retrieved from disk
in the firing of database triggers
in the execution of DDL statements
in the execution of SQL statements within stored procedures, functions, packages and anonymous PL/SQL blocks
in the enforcement of referential integrity constraints

This data item represents the percentage of this session's CPU time that is being used for recursive calls.

#### Data Source

(DeltaRecursiveTime / DeltaCpuTime) * 100
where:

DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between end and start of sample period
DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between end and start of sample period

#### User Action

If the Oracle Server appears to be making excessive recursive calls while your application is running, determine what activity is causing these recursive calls. If you determine that the recursive calls are caused by dynamic extension, either reduce the frequency of extension by allocating larger extents, or, if you are using Oracle 8i, consider taking advantage of locally managed tablespaces.
Other CPU %

## Other CPU %

#### Description

This data item represents the percentage of time spent looking for buffers, fetching rows or index keys, etc. Generally, "other" CPU should represent the highest percentage of CPU time out of the total CPU time used.

#### Data Source

((DeltaCpuTime - (DeltaParseTime + DeltaRecursiveTime)) / DeltaCpuTime) * 100
where:

DeltaCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='CPU used by this session' and n.statistic#=s.statistic#' between sample end and start
DeltaParseTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaRecursiveTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='recursive cpu usage' and n.statistic#=s.statistic#' between sample end and start

#### User Action

It may be possible to reduce "other" CPU time by investigating SQL statements that have a high number of buffer_gets and/or a high number of physical reads.
Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of blocks obtained in CURRENT mode per second during this sample period.

#### Data Source

DeltaBlockGets / Seconds
where:

DeltaBlockGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db blocks gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during this sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent gets' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of data blocks read from disk per second during this sample period.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Read Ratio

## Disk Read Ratio

#### Description

This data item represents the percentage of reads that were directly read from disk, bypassing the buffer cache, during this sample period. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

#### Data Source

DeltaDirectReads / DeltaPhysicalReads
where:

DeltaDirectReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads direct' and n.statistic#=s.statistic#' between sample end and start
DeltaPhysicalReads: difference in 'select s.value from v$sesstat s, v$statname n where n.name='physical reads' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. These are changes that are generating redo log entries and hence will be permanent changes to the database if the transaction is committed.

This statistic is a rough indication of the total database work. This statistic indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='db block changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times changes were made to blocks in the SGA as part of an update or delete. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select s.value from v$sesstat s, v$statname n where n.name='consistent changes' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts to disk as opposed to being performed in memory per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory as opposed to on disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (rows)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Disk/Memory Sorts Ratio

## Disk/Memory Sorts Ratio

#### Description

This data item represents the percentage of sorts performed on disk as opposed to in memory for this sample period.

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.

#### Data Source

DeltaDiskSorts / DeltaMemorySorts
where:

DeltaDiskSorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (disk)' and n.statistic#=s.statistic#' between sample end and start
DeltaMemorySorts: difference in 'select s.value from v$sesstat s, v$statname n where n.name='sorts (memory)' and n.statistic#=s.statistic#' between sample end and start

#### User Action

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.
Disk Sorts/Sort Rows Ratio

## Disk Sorts/Sort Rows Ratio

Percentage of sorts performed to disk

Parse Count (Hard)/Sec

## Parse Count (Hard)/Sec

#### Description

This data item represents the number of parses per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (hard)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Parse Count (Total)/Sec

## Parse Count (Total)/Sec

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseCount / Second
where:

DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Elapsed Time

## Parse Elapsed Time

#### Description

This data item represents the number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParseElapsedTime
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start

#### User Action

UGA Memory

## UGA Memory

#### Description

This data item represents the current UGA size for this session.

#### Data Source

select s.value from v$sesstat s, v$statname n where n.name='session uga memory' and n.statistic#=s.statistic#' between sample end and start

#### User Action

Avg. Wait Time per Parse

## Avg. Wait Time per Parse

#### Description

This data item represents the average time waited per parse, in seconds, during this sample period.

#### Data Source

((DeltaParseElapsedTime - DeltaParseCpuTime) / Seconds) / DeltaParseCount
where:

DeltaParseElapsedTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time elapsed' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCpuTime: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse time cpu' and n.statistic#=s.statistic#' between sample end and start
DeltaParseCount: difference in 'select s.value from v$sesstat s, v$statname n where n.name='parse count (total)' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select s.value from v$sesstat s, v$statname n where n.name='execute count' and n.statistic#=s.statistic#' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Serial#

## Serial#

Session serial number

SQL View Usage

# SQL View Usage

SQL view usage

SQL View Usage Default Chart
SQL View Usage Default Chart

SQL view usage

Text

## Text

#### Description

This data item represents the text for the view.

#### Data Source

select text from dba_views

#### User Action

SQL Table Usage

# SQL Table Usage

Lists tables being used by a SQL statement

This class includes the following charts:

Tables Referenced by this Query

SQL Table Usage Default Chart
SQL Table Usage Default Chart

Lists tables being used by a SQL statement

Last Analyzed

## Last Analyzed

#### Description

This data item represents the date of the most recent time this table was analyzed.

#### Data Source

select analyzetime from sys.tab$

#### User Action

Because the cost-based optimizer relies on statistics, it is important to ensure these statistics are valid. If the size and the data distribution of tables change frequently, these statistics should be generated regularly to ensure their accuracy. Cost-based optimizer statistics can be generated using the ANALYZE command or with the DBMS_STATS package.

When you generate statistics for a table, if the dictionary already contains statistics for the analyzed object, Oracle updates the existing statistics. Oracle also invalidates any currently parsed SQL statement that access the analyzed object.

The next time such a statement executes, the optimizer automatically chooses a new execution plan based on the new statistics.
Rows

## Rows

#### Description

This data item represents the number of rows returned during the generation of cost-based optimizer statistics.

Because the cost-based optimizer relies on statistics, it is important to ensure these statistics are valid. If the size and the data distribution of tables change frequently, these statistics should be generated regularly to ensure their accuracy. Cost-based optimizer statistics can be generated using the ANALYZE command or with the DBMS_STATS package.

Because of the time and space required for computing statistics, in many cases it is possible to use estimation rather than computation.

#### Data Source

select rowcnt from sys.tab$

#### User Action

Chained Rows Percent

## Chained Rows Percent

#### Description

This data item represents the percentage of rows that are chained or migrated.

#### Data Source

select (chncnt/rowcnt)*100 from sys.tab$

#### User Action

In two circumstances, the data for a row in a table may be too large to fit into a single data block. This results in row fragmentation.

In the first case, the row is too large to fit into one data block when it is first inserted. In this case, the Oracle Server stores the data for the row in a chain of data blocks reserved for that segment. Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG or LONG RAW. Row chaining in these cases is unavoidable without using a larger DB_BLOCK_SIZE.

In the second case, however, a row that originally fit into one data block is updated so that the overall row length increases and the block's free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit into a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row.

When a row is continued or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row. You can identify migrated and chained rows by using the analyze list chained rows command. This command collects information about each migrated and chained row and placed this information into a specified output table; for example, CHAINED_ROWS. The collected information includes the head rowid of any migrated and chained row. Once this has been identified, the following steps can be used to focus your efforts on reducing migrated and chained rows instead of rebuilding the entire table:

Disable foreign key constraints and triggers as appropriate
Create an intermediate table with the same columns as the existing table to hold the migrated and chained rows:
create table intermediate as select * from existing where rowid in (select head_rowid from chained_rows where table_name=’existing’);
Delete the migrated and chained rows from the existing table:
delete from existing where rowid in
(select head_rowid from chained_rows where table_name=’existing’);
Insert the rows of the intermediate table into the existing table:
insert into existing select * from intermediate;
Reenable dependencies as appropriate

Correcting row fragmentation is more expensive than proper prevention. Often, row migration problems can be minimized by correctly setting the table’s pctfree value. Setting pctfree high can waste some space but will more or less guarantee no row migration, while being too conservative may result in excessive row migration and reduced performance. Oracle recommends erring on the side of setting pctfree high rather than low, because in most cases this probably will be only a difference of about 5%. For tables that don’t have varying width columns and/or don’t get updated, this parameter can be safely ignored or set to a low value.

If the percentage of chained and/or migrated rows is greater than 5% and the maximum row length is less than the database block size then consider increasing the current pctfree setting to reduce the potential for rows which would have to be migrated in the future.
SQL that Access the Table

# SQL that Access the Table

SQL statements that access the table

This class includes the following charts:

All SQL in the Cache that Access this Table

SQL that Access the Table Default Chart
SQL that Access the Table Default Chart

SQL statements that access the table

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

SQL From Session

# SQL From Session

SQL statement that the current session is executing

This class includes the following charts:

Open Cursors for this Session

Open SQL Cursors Sorted by Physical Reads

Open SQL Cursors Sorted by Parse Calls

SQL From Session Default Chart
SQL From Session Default Chart

SQL statement that the current session is executing

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads/greatest(executions,1) from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets/greatest(executions,1) from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads/greatest(executions,1) from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets/greatest(executions,1) from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

Similar SQL Statements

# Similar SQL Statements

This class lists SQL statements found in the cache that are the same for the first 50 characters

This class includes the following charts:

Library Cache Eating SQL Statements

Similar SQL Statements Default Chart
Similar SQL Statements Default Chart

This class lists SQL statements found in the cache that are the same for the first 50 characters

Count

## Count

#### Description

This data item represents the times a similiar SQL fragment was found in the shared SQL area.

#### Data Source

select count(*) from v$sql
group by substr(sql_text,1,50) having count(*) > 5

#### User Action

Examine SQL statements which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Detailed Similar SQL

# Detailed Similar SQL

SQL statements that appear to be the same

This class includes the following charts:

Details of Similar SQL statements

Detailed Similar SQL Default Chart
Detailed Similar SQL Default Chart

SQL statements that appear to be the same

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads/greatest(executions,1) from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets/greatest(executions,1) from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads/greatest(executions,1) from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets/greatest(executions,1) from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds:number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

Instance Statistics Per Sec

# Instance Statistics Per Sec

Statistics that are summarized for the entire instance per second

This class includes the following charts:

Gets and Changes Rates

Free Buffer Statistics

Parse Statistics

Buffer Pinned Counts

Call Rates

Memory Sort Ratio

Sorts and Scans

Throughput Rates

Instance Statistics Per Sec Default Chart
Instance Statistics Per Sec Default Chart

Statistics that are summarized for the entire instance per second

Free Buff Inspected/Sec

## Free Buff Inspected/Sec

#### Description

This data item represents the number of buffers skipped over from the end of the LRU queue to find a reusable buffer per second during this sample period. The difference between this statistic and 'dirty buffers inspected' is the number of buffers that could not be used because they were busy, needed to be written after rapid aging out, or they have a user, a waiter, or are being read/written.

#### Data Source

DeltaFreeBuffersInspected / Seconds
where:

DeltaFreeBuffersInspected: difference in 'select value from v$sysstat where name='free buffer inspected'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Free Buff Requested/Sec

## Free Buff Requested/Sec

#### Description

This data item represents the count of the number of times, per second during this sample period, a reusable buffer or a free buffer was requested to create or load a block.

#### Data Source

DeltaFreeBuffersRequested / Seconds
where:

DeltaFreeBuffersRequested: difference in 'select value from v$sysstat where name='free buffer requested'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Dirty Buff Inspected/Sec

## Dirty Buff Inspected/Sec

#### Description

This data item represents the the number of dirty buffers found, per second during this sample period, by the foreground while the foreground was looking for a buffer to reuse.

#### Data Source

DeltaFreeBuffersRequested / Seconds
where:

DeltaFreeBuffersRequested: difference in 'select value from v$sysstat where name='dirty buffers inspected'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Parses/Sec

## Parses/Sec

#### Description

This data item represents the total number of parse calls (hard and soft) per second during this sample period.

#### Data Source

DeltaParses / Seconds
where:

DeltaParses: difference in 'select value from v$sysstat where name='parse count (total)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Hard Parses/Sec

## Hard Parses/Sec

#### Description

This data item represents the number of hard parses per second during this sample period.

#### Data Source

DeltaParses / Seconds
where:

DeltaParses: difference in 'select value from v$sysstat where name='parse count (hard)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Executes/Sec

## Executes/Sec

#### Description

This data item represents the number of statement executions (user and recursive) per second during this sample period.

#### Data Source

DeltaExecutes / Seconds
where:

DeltaExecutes: difference in 'select value from v$sysstat where name='execute count'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Cursor Cache Count/Sec

## Cursor Cache Count/Sec

#### Description

This data item represents the total number of cursors cached per second during this sample period. This is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheCount / Seconds
where:

DeltaCursorCacheCount: difference in 'select value from v$sysstat where name='session cursor cache count'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Cursor Cache Hits/Sec

## Cursor Cache Hits/Sec

#### Description

This data item represents the count of the number of hits in the session cursor cache per second during the sample period. A hit means the SQL statement did not have to be reparsed. By subtracting this value from 'parse count (total)' you can determine the real number of parses that happened.

#### Data Source

DeltaCursorCacheHits / Seconds
where:

DeltaCursorCacheHits: difference in 'select value from v$sysstat where name='session cursor cache hits'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Consistent Gets/Sec

## Consistent Gets/Sec

#### Description

This data item represents the number of times a consistent read was requested for a block per second during the sample period.

#### Data Source

DeltaConsistentGets / Seconds
where:

DeltaConsistentGets: difference in 'select value from v$sysstat where name='consistent gets'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Buffer is pinned/Sec

## Buffer is pinned/Sec

#### Description

This data item represents the number of times, per second during the sample period, a buffer was already pinned by a client when a client checked to determine if the desired buffer was already pinned.

#### Data Source

DeltaPinned / Seconds
where:

DeltaPinned: difference in 'select value from v$sysstat where name='buffer is pinned count'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Buffer is not pinned/Sec

## Buffer is not pinned/Sec

#### Description

This data item represents the number of times, per second during the sample period, the buffer was not pinned by the client when a client checks to determine if the buffer it wants is already pinned.

#### Data Source

DeltaNotPinned / Seconds
where:

DeltaNotPinned: difference in 'select value from v$sysstat where name='buffer is not pinned count'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

User Calls/Sec

## User Calls/Sec

#### Description

This data item represents the number of logins, parses, or execute calls per second during the sample period,

#### Data Source

DeltaUserCalls / Seconds
where:

DeltaUserCalls: difference in 'select value from v$sysstat where name='user calls'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Recursive Calls/Sec

## Recursive Calls/Sec

#### Description

This data item represents the number of calls, per second during the sample period, that resulted in a change to an internal table.

#### Data Source

DeltaRecursiveCalls / Seconds
where:

DeltaRecursiveCalls: difference in 'select value from v$sysstat where name='recursive calls'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Logons/Sec

## Logons/Sec

#### Description

This data item represents the number of logons per second during the sample period.

#### Data Source

DeltaLogons / Seconds
where:

DeltaLogons: difference in 'select value from v$sysstat where name='logons cumulative'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Disk Sorts/Sec

## Disk Sorts/Sec

#### Description

This data item represents the number of sorts going to disk per second for this sample period.

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.

#### Data Source

DeltaDiskSorts / Seconds
where:

DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (disk)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

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.
Memory Sorts/Sec

## Memory Sorts/Sec

#### Description

This data item represents the number of sorts performed in memory, as opposed to on disk, per second for this sample period.

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.

#### Data Source

DeltaMemorySorts / Seconds
where:

DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (memory)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

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.
Sort Rows/Sec

## Sort Rows/Sec

#### Description

This data item represents the average number of rows sorted per second during this sample period.

#### Data Source

DeltaSortRows / Seconds
where:

DeltaSortRows: difference in 'select value from v$sysstat where name='sorts (rows)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Enqueue Waits/Sec

## Enqueue Waits/Sec

#### Description

This data item represents the number of waits, per second during this sample period, that happened during an enqueue convert or get because the enqueue could not be granted right away.

#### Data Source

DeltaWaits / Seconds
where:

DeltaWaits: difference in 'select value from v$sysstat where name='enqueue waits'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Block Gets/Sec

## Block Gets/Sec

#### Description

This data item represents the number of requests for blocks per second during sample period.

#### Data Source

DeltaGets / Seconds
where:

DeltaGets: difference in 'select value from v$sysstat where name='db block gets'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Block Changes/Sec

## Block Changes/Sec

#### Description

This data item represents the number of changes, per second during sample period, that were made to all blocks in the SGA as a result of an update or delete operation. This value is a rough indication of total database work as it indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Seconds
where:

DeltaBlockChanges: difference in 'select value from v$sysstat where name='db block changes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Consistent Changes/Sec

## Consistent Changes/Sec

#### Description

This data item represents the number of times, per second during sample period, a user prcoess applied rollback entries to perform a consistent read on a block.

#### Data Source

DeltaConsistentChanges / Seconds
where:

DeltaConsistentChanges: difference in 'select value from v$sysstat where name='consistent changes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Rollbacks/Sec

## Rollbacks/Sec

#### Description

This data item represents the number of times, per second during the sample period, that users manually issue the ROLLBACK statement or an error occured during a user's transactions.

#### Data Source

DeltaRollbacks / Seconds
where:

DeltaRollbacks: difference in 'select value from v$sysstat where name='user rollbacks'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

This value shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.
Commits/Sec

## Commits/Sec

#### Description

This data item represents the number of user commits performed, per second during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits / Seconds
where:

DeltaCommits: difference in 'select value from v$sysstat where name='user commits'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Long Table Scans/Sec

## Long Table Scans/Sec

#### Description

This data item represents the number of long table scans per second during sample period. A table is considered 'long' if the table is not cached and if its high-water mark is greater than 5 blocks.

#### Data Source

DeltaScans / Seconds
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (long tables)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Short Table Scans/Sec

## Short Table Scans/Sec

#### Description

This data item represents the number of short table scans per second during sample period. A table is considered 'short' if the table is cached or if its high-water mark is less than 5 blocks.

#### Data Source

DeltaScans / Seconds
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (short tables)'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Redo Size/Sec

## Redo Size/Sec

#### Description

This data item represents the amount of redo, in bytes, generated per second during this sample period.

#### Data Source

DeltaRedo / Seconds
where:

DeltaRedo: difference in 'select value from v$sysstat where name='redo size'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of disk reads per second during the sample period.

#### Data Source

DeltaReads / Seconds
where:

DeltaReads: difference in 'select value from v$sysstat where name='physical reads'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Physical Writes/Sec

## Physical Writes/Sec

#### Description

This data item represents the number of disk writes per second during the sample period.

#### Data Source

DeltaWrites / Seconds
where:

DeltaWrites: difference in 'select value from v$sysstat where name='physical writes'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Session Logical Reads/Sec

## Session Logical Reads/Sec

#### Description

This data item represents the number of logical reads per second during the sample period.

#### Data Source

DeltaReads / Seconds
where:

DeltaReads: difference in 'select value from v$sysstat where name='session logical reads'' between end and start of sample period
Seconds: number of seconds in sample period

#### User Action

Instance Statistics Per Transaction

# Instance Statistics Per Transaction

Statistics that are summarized for the entire instance per transaction

This class includes the following charts:

Per Trans. Gets and Changes Rates

Per Trans. Free Buffer Statistics

Per Trans. Parse Statistics

Per Trans. Buffer Pinned Counts

Per Trans. Call Rates

Per Trans. Memory Sort Ratio

Per Trans. Sorts and Scans

Per Trans. Throughput Rates

Instance Statistics Per Transaction Default Chart
Instance Statistics Per Transaction Default Chart

Statistics that are summarized for the entire instance per transaction

Free Buff Inspected/Trans

## Free Buff Inspected/Trans

#### Description

This data item represents the number of buffers skipped over from the end of the LRU queue to find a reusable buffer per transaction during this sample period. The difference between this statistic and 'dirty buffers inspected' is the number of buffers that could not be used because they were busy, needed to be written after rapid aging out, or they have a user, a waiter, or are being read/written.

#### Data Source

DeltaFreeBuffersInspected / Transactions
where:

DeltaFreeBuffersInspected: difference in 'select value from v$sysstat where name='free buffer inspected'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Free Buff Requested/Trans

## Free Buff Requested/Trans

#### Description

This data item represents the count of the number of times, per transaction during this sample period, a reusable buffer or a free buffer was requested to create or load a block.

#### Data Source

DeltaFreeBuffersRequested / Transactions
where:

DeltaFreeBuffersRequested: difference in 'select value from v$sysstat where name='free buffer requested'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Dirty Buff Inspected/Trans

## Dirty Buff Inspected/Trans

#### Description

This data item represents the the number of dirty buffers found, per transaction during this sample period, by the foreground while the foreground was looking for a buffer to reuse.

#### Data Source

DeltaFreeBuffersRequested / Transactions
where:

DeltaFreeBuffersRequested: difference in 'select value from v$sysstat where name='dirty buffers inspected'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Parses/Trans

## Parses/Trans

#### Description

This data item represents the total number of parse calls (hard and soft) per transaction during this sample period.

#### Data Source

DeltaParses / Transactions
where:

DeltaParses: difference in 'select value from v$sysstat where name='parse count (total)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Hard Parses/Trans

## Hard Parses/Trans

#### Description

This data item represents the number of hard parses per transaction during this sample period.

#### Data Source

DeltaParses / Transactions
where:

DeltaParses: difference in 'select value from v$sysstat where name='parse count (hard)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

If there appears to be excessive time spent parsing, evaluate SQL statements to determine which can be modified to optimize shared SQL pool memory use and avoid unnecessary statement reparsing. This type of problem is commonly caused when similar SQL statements are written which differ in space, case, or some combination of the two. You may also consider using bind variables rather than explicitly specified constants in your statements whenever possible.
Executes/Trans

## Executes/Trans

#### Description

This data item represents the number of statement executions (user and recursive) per transaction during this sample period.

#### Data Source

DeltaExecutes / Transactions
where:

DeltaExecutes: difference in 'select value from v$sysstat where name='execute count'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Cursor Cache Count/Trans

## Cursor Cache Count/Trans

#### Description

This data item represents the total number of cursors cached per transaction during this sample period. This is only incremented if SESSION_CACHED_CURSORS is greater than 0.

#### Data Source

DeltaCursorCacheCount / Transactions
where:

DeltaCursorCacheCount: difference in 'select value from v$sysstat where name='session cursor cache count'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Cursor Cache Hits/Trans

## Cursor Cache Hits/Trans

#### Description

This data item represents the count of the number of hits in the session cursor cache per transaction during the sample period. A hit means the SQL statement did not have to be reparsed. By subtracting this value from 'parse count (total)' one can determine the real number of parses that happened.

#### Data Source

DeltaCursorCacheHits / Transactions
where:

DeltaCursorCacheHits: difference in 'select value from v$sysstat where name='session cursor cache hits'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Consistent Gets/Trans

## Consistent Gets/Trans

#### Description

This data item represents the number of times a consistent read was requested for a block per transaction during the sample period.

#### Data Source

DeltaConsistentGets / Transactions
where:

DeltaConsistentGets: difference in 'select value from v$sysstat where name='consistent gets'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Buffer is pinned/Trans

## Buffer is pinned/Trans

#### Description

This data item represents the number of times, per transaction during the sample period, a buffer was already pinned by a client when a client checked to determine if the desired buffer was already pinned.

#### Data Source

DeltaPinned / Transactions
where:

DeltaPinned: difference in 'select value from v$sysstat where name='buffer is pinned count'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Buffer is not pinned/Trans

## Buffer is not pinned/Trans

#### Description

This data item represents the number of times, per transaction during the sample period, the buffer was not pinned by the client when a client checks to determine if the buffer it wants is already pinned.

#### Data Source

DeltaNotPinned / Transactions
where:

DeltaNotPinned: difference in 'select value from v$sysstat where name='buffer is not pinned count'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

User Calls/Trans

## User Calls/Trans

#### Description

This data item represents the number of logins, parses, or execute calls per transaction during the sample period,

#### Data Source

DeltaUserCalls / Transactions
where:

DeltaUserCalls: difference in 'select value from v$sysstat where name='user calls'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Recursive Calls/Trans

## Recursive Calls/Trans

#### Description

This data item represents the number of calls, per transaction during the sample period, that resulted in a change to an internal table.

#### Data Source

DeltaRecursiveCalls / Transactions
where:

DeltaRecursiveCalls: difference in 'select value from v$sysstat where name='recursive calls'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Logons/Trans

## Logons/Trans

#### Description

This data item represents the number of logons per transaction during the sample period.

#### Data Source

DeltaLogons / Transactions
where:

DeltaLogons: difference in 'select value from v$sysstat where name='logons cumulative'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Disk Sorts/Trans

## Disk Sorts/Trans

#### Description

This data item represents the number of sorts going to disk per transactions for this sample period.

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.

#### Data Source

DeltaDiskSorts / Transactions
where:

DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (disk)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

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.
Memory Sorts/Trans

## Memory Sorts/Trans

#### Description

This data item represents the number of sorts performed in memory, as opposed to on disk, per transaction for this sample period.

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.

#### Data Source

DeltaMemorySorts / Transactions
where:

DeltaDiskSorts: difference in 'select value from v$sysstat where name='sorts (memory)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

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.
Sort Rows/Trans

## Sort Rows/Trans

#### Description

This data item represents the average number of rows sorted per transaction during this sample period.

#### Data Source

DeltaSortRows / Transactions
where:

DeltaSortRows: difference in 'select value from v$sysstat where name='sorts (rows)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Enqueue Waits/Trans

## Enqueue Waits/Trans

#### Description

This data item represents the number of waits, per transaction during this sample period, that happened during an enqueue convert or get because the enqueue could not be granted right away.

#### Data Source

DeltaWaits / Transactions
where:

DeltaWaits: difference in 'select value from v$sysstat where name='enqueue waits'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Block Gets/Trans

## Block Gets/Trans

#### Description

This data item represents the number of requests for blocks per transactions during sample period.

#### Data Source

DeltaGets / Transactions
where:

DeltaGets: difference in 'select value from v$sysstat where name='db block gets'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Block Changes/Trans

## Block Changes/Trans

#### Description

This data item represents the number of changes, per transaction during sample period, that were made to all blocks in the SGA as a result of an update or delete operation. This value is a rough indication of total database work as it indicates the rate at which buffers are being dirtied.

#### Data Source

DeltaBlockChanges / Transactions
where:

DeltaBlockChanges: difference in 'select value from v$sysstat where name='db block changes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Consistent Changes/Trans

## Consistent Changes/Trans

#### Description

This data item represents the number of times, per transaction during sample period, a user prcoess applied rollback entries to perform a consistent read on a block.

#### Data Source

DeltaConsistentChanges / Transactions
where:

DeltaConsistentChanges: difference in 'select value from v$sysstat where name='consistent changes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Rollbacks/Trans

## Rollbacks/Trans

#### Description

This data item represents the number of times, per transaction during the sample period, that users manually issue the ROLLBACK statement or an error occured during a user's transactions.

#### Data Source

DeltaRollbacks / Transactions
where:

DeltaRollbacks: difference in 'select value from v$sysstat where name='user rollbacks'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

This value shows how often users are issuing the ROLLBACK statement or encountering errors in their transactions. Further investigation should be made to determine if the rollbacks are part of some faulty application logic or due to errors occuring through database access.
Commits/Trans

## Commits/Trans

#### Description

This data item represents the number of user commits performed, per transaction during the sample period. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

#### Data Source

DeltaCommits / Transactions
where:

DeltaCommits: difference in 'select value from v$sysstat where name='user commits'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

This statistic is an indication of how much work is being accomplished within the database. A spike in the transaction rate may not necessarily be bad. If response times stay close to normal, it means your system can handle the added load. Actually, a drop in transaction rates and an increase in response time may be indicators of problems. Depending upon the application, transaction loads may vary widely across different times of the day.
Long Table Scans/Trans

## Long Table Scans/Trans

#### Description

This data item represents the number of long table scans per transaction during sample period. A table is considered 'long' if the table is not cached and if its high-water mark is greater than 5 blocks.

#### Data Source

DeltaScans / Transactions
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (long tables)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Short Table Scans/Trans

## Short Table Scans/Trans

#### Description

This data item represents the number of short table scans per transaction during sample period. A table is considered 'short' if the table is cached or if its high-water mark is less than 5 blocks.

#### Data Source

DeltaScans / Transactions
where:

DeltaScans: difference in 'select value from v$sysstat where name='table scans (short tables)'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Redo Size/Trans

## Redo Size/Trans

#### Description

This data item represents the amount of redo, in bytes, generated per transaction during this sample period.

#### Data Source

DeltaRedo / Transactions
where:

DeltaRedo: difference in 'select value from v$sysstat where name='redo size'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Physical Reads/Trans

## Physical Reads/Trans

#### Description

This data item represents the number of disk reads per transaction during the sample period.

#### Data Source

DeltaReads / Transactions
where:

DeltaReads: difference in 'select value from v$sysstat where name='physical reads'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Physical Writes/Trans

## Physical Writes/Trans

#### Description

This data item represents the number of disk writes per transaction during the sample period.

#### Data Source

DeltaWrites / Transactions
where:

DeltaWrites: difference in 'select value from v$sysstat where name='physical writes'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Session Logical Reads/Trans

## Session Logical Reads/Trans

#### Description

This data item represents the number of logical reads per transaction during the sample period.

#### Data Source

DeltaReads / Transactions
where:

DeltaReads: difference in 'select value from v$sysstat where name='session logical reads'' between end and start of sample period
Transactions: number of transactions in sample period

#### User Action

Longest Running Transactions

# Longest Running Transactions

Current running transactions, sorted by duration

Longest Running Transactions Default Chart
Longest Running Transactions Default Chart

Current running transactions, sorted by duration

SQL

## SQL

#### Description

This data item represents the current SQL.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Logical I/O

## Logical I/O

#### Description

This data item represents the logical I/O per second since the transaction started.

#### Data Source

select log_io from v$transaction

#### User Action

Physical I/O

## Physical I/O

#### Description

This data item represents the physical I/O per second since the transaction started.

#### Data Source

select phy_io from v$transaction

#### User Action

Consistent Gets

## Consistent Gets

#### Description

This data item represents the consistent gets per second since the transaction started.

#### Data Source

select cr_get from v$transaction

#### User Action

Consistent Changes

## Consistent Changes

#### Description

This data item represents the consistent changes per second since the transaction started.

#### Data Source

select cr_change from v$transaction

#### User Action

Duration of Trans

## Duration of Trans

#### Description

This data item represents the duration, in seconds, since the transaction started.

#### Data Source

select (sysdate - to_date(START_TIME,'mm/dd/yy hh24:mi:ss')) * 86400 from v$transaction

#### User Action

Segments Being Waited On

# Segments Being Waited On

Segments that are currently being waited on by sessions

This class includes the following charts:

Segments Currently Being Waited On

Segments Being Waited On Default Chart
Segments Being Waited On Default Chart

Segments that are currently being waited on by sessions

Segment Name

## Segment Name

#### Description

This data item represents the name of the segment containing the block that is being waited on.

#### Data Source

select segment_name from sys.dba_extents where file_id = p1 and p2 between block_id and block_id+blocks-1
where:

p1: is the file number of a database file
p2: is block id within the file

#### User Action

None
Block Id

## Block Id

#### Description

This data item represent the block number within a file of the extent being waited on.

#### Data Source

select p2 from v$session_wait

#### User Action

This block id, in conjunction with the file id can be used to figure out the segment and object that is being waited on. If the same segment is waited on repeatedly, you have identified a bottleneck.
Filename

## Filename

#### Description

This data item represents the name of the database file containing the block that the current wait event is waiting on.

#### Data Source

select p1 from v$session_wait

#### User Action

This identifies the file that is causing the wait. If the same file is causing the wait repeatedly, you have identfied the bottleneck. You should investigate further how to best spread the I/O or the applications access to objects within this file.
Segment Owner

## Segment Owner

#### Description

This data item represents the name of the owner of the segment containing the block that is being waited on.

#### Data Source

select owner from sys.dba_extents where file_id = p1 and p2 between block_id and block_id+blocks-1
where:

p1: is the file number of a database file
p2: is block id within the file

#### User Action

Tablespace Name

## Tablespace Name

#### Description

This data item represents the name of the tablespace that contains the block being waited on.

#### Data Source

select tablespace_name from sys.dba_extents where file_id = p1 and p2 between block_id and block_id+blocks-1
where:

p1: is the file number of a database file
p2: is block id within the file

#### User Action

Parallel Read/Write Waits

# Parallel Read/Write Waits

Count of files and blocks being waited for

This class includes the following charts:

Wait Event File and Block Counts

Parallel Read/Write Waits Default Chart
Parallel Read/Write Waits Default Chart

Count of files and blocks being waited for

Files

## Files

#### Description

This data item represents the number of files being read or written to.

#### Data Source

select p1 from v$session_wait

#### User Action

Blocks

## Blocks

#### Description

This data item represents the number of files being read or written to.

#### Data Source

select p2 from v$session_wait

#### User Action

Cache Buffer Chain - Hot Blocks

# Cache Buffer Chain - Hot Blocks

File and block id's of high contention blocks within the database

Cache Buffer Chain - Hot Blocks Default Chart
Cache Buffer Chain - Hot Blocks Default Chart

File and block id's of high contention blocks within the database

Block Id

## Block Id

Block Id that is under contention

Blocking Locks

# Blocking Locks

Locks currently held by the Oracle server and outstanding requests for a lock or latch

This class includes the following charts:

Blocking/Waiting Locks Chart

Blocking Locks Default Chart
Blocking Locks Default Chart

Locks currently held by the Oracle server and outstanding requests for a lock or latch

Session Id

## Session Id

Session holding or acquiring the lock

Session Serial Number

## Session Serial Number

Session serial number of session holding or acquiring the lock

Lock Type

## Lock Type

#### Description

Enqueues are shared memory structures (locks) that serialize access to database resources. They can be associated with a session or transaction. Enqueue names are displayed in the LOCK_TYPE column of the DBA_LOCKS and DBA_LOCK_INTERNAL data dictionary views.

A resource uniquely identifies an object that can be locked by different sessions within an instance (local resource) or between instances (global resource). Each session that tries to lock the resource will have an enqueue on the resource.

Note: The names of enqueues and their definitions may change from release to release.

The Oracle enqueues are:

BL, Buffer Cache Management
CF, Controlfile Transaction
CI, Cross-instance Call Invocation
CU, Bind Enqueue
DF, Datafile
DL, Direct Loader Index Creation
DM, Database Mount
DR, Distributed Recovery
DX, Distributed TX
FS, File Set
IN, Instance Number
IR, Instance Recovery
IS, Instance State
IV, Library Cache Invalidation
JQ, Job Queue
KK, Redo Log "Kick"
L[A-P], Library Cache Lock
MR, Media Recovery
N[A-Z], Library Cache Pin
PF, Password File
PI, Parallel Slaves
PR, Process Startup
PS, Parallel Slave Synchronization
Q[A-Z], Row Cache
RT, Redo Thread
SC, System Commit Number
SM, SMON
SQ, Sequence Number Enqueue
SR, Synchronized Replication
SS, Sort Segment
ST, Space Management Transaction
SV, Sequence Number Value
TA, Transaction Recovery
TM, DML Enqueue
TS, Temporary Segment (also TableSpace)
TT, Temporary Table
TX, Transaction
UL, User-defined Locks
UN, User Name
US, Undo Segment, Serialization
WL, Being Written Redo Log
XA, Instance Attribute Lock
XI, Instance Registration Lock

#### Data Source

LOCK_TYPE column from V$LOCK table.

#### User Action

Determine the cause for the lock contention and try to remove it. Although drastic, a session can be killed by selecting a session and using the kill session tool. This should be used as a last resort to remove the blocking lock if it has been determined that it won't be freed up any time soon.
Mode Held

## Mode Held

Lock mode in which the session holds the lock

Mode Requested

## Mode Requested

Lock mode in which the process requests the lock

Object Name

## Object Name

Name of the object being locked

ROWID

## ROWID

The current ROWID being locked

Object Owner

## Object Owner

User name of the owner of the object

Object Type

## Object Type

Type of object

Resource ID1

## Resource ID1

Lock identifier #1 (depends on type)

Resource ID2

## Resource ID2

Lock identifier #2 (depends on type)

Process Id

## Process Id

Operating system process id

Current SQL

# Current SQL

The current SQL statement for a session

This class includes the following charts:

Current SQL

Current SQL Default Chart
Current SQL Default Chart

The current SQL statement for a session

SQL Text

## SQL Text

#### Description

This data item contains the first eighty characters of the SQL text for the current cursor.

#### Data Source

select sql_text from v$sqlarea

#### User Action

Physical Reads

## Physical Reads

#### Description

This data item represents the number of physical reads. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

select disk_reads from v$sqlarea

#### User Action

Buffer Gets

## Buffer Gets

#### Description

This data item represents the number of read requests that were satisfied by buffers in the cache. In other words, its value is the total number of blocks read by all executions of this statement.

#### Data Source

select buffer_gets from v$sqlarea

#### User Action

Executions/Sec

## Executions/Sec

#### Description

This data item represents the number of times this statement was executed per second during this sample period.

#### Data Source

DeltaExecutions / Seconds
where:

DeltaExecutions: difference in 'select executions from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Parse Calls/Sec

## Parse Calls/Sec

#### Description

This data item represents the total number of times this statement was parsed per second during this sample period.

#### Data Source

DeltaParseCalls / Seconds
where:

DeltaParseCalls: difference in 'select parse_calls from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Physical Reads/Sec

## Physical Reads/Sec

#### Description

This data item represents the number of physical reads performed by this statement per second during the sample period. In other words, its value is the number of read requests that were not satisfied by buffers in the cache and resulted in access to datafiles on disk.

#### Data Source

DeltaPhysicalReads / Seconds
where:

DeltaPhysicalReads: difference in 'select disk_reads from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Buffer Gets/Sec

## Buffer Gets/Sec

#### Description

This data item represents the number of read requests for this statement that were satisfied by buffers in the cache per second during this sample period.

#### Data Source

DeltaBufferGets / Seconds
where:

DeltaBufferGets: difference in 'select buffer_gets from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Rows Processed/Sec

## Rows Processed/Sec

#### Description

This data item represents the total number of rows processed to complete this statement per second during the sample period.

#### Data Source

DeltaRowsProcessed / Seconds
where:

DeltaRowsProcessed: difference in 'select rows_processed from v$sqlarea' between sample end and start
Seconds: number of seconds in sample period

#### User Action

Total Shareable Memory

## Total Shareable Memory

#### Description

This data item represents the sum of all shareable memory, in bytes, used by this statement.

#### Data Source

select sharable_mem from v$sqlarea

#### User Action

Total Persistent Memory

## Total Persistent Memory

#### Description

This data item represents the sum of all persistent memory, in bytes, used by this statement.

#### Data Source

select persistent_mem from v$sqlarea

#### User Action

Runtime Memory

## Runtime Memory

#### Description

This data item represents the sum of all memory, in bytes, currently in use by this statement.

#### Data Source

select runtime_mem from v$sqlarea

#### User Action

Module

## Module

#### Description

This data item represents the name of the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_MODULE.

#### Data Source

select module from v$sqlarea

#### User Action

Action

## Action

#### Description

This data item represents the name of the action being performed by the application module that first executed this statement. This name can be optionally set by using DMBS_APPLICATION_INFO.SET_ACTION.

#### Data Source

select action from v$sqlarea

#### User Action

% Physical Reads

## % Physical Reads

#### Description

This data item represents the percentage of total physical reads that were attributed to this statement during the sample period.

#### Data Source

DeltaPhysicalReads / DeltaTotalReads
where:

DeltaPhysicalReads: difference in 'select sum(disk_reads) from v$sql' between sample end and start
DeltaTotalReads: difference of 'select value from v$sysstat where name='physical reads' between sample end and start

#### User Action

% Buffer Gets

## % Buffer Gets

#### Description

This data item represents the percentage of total buffer gets that were attributed to this statement during the sample period.

#### Data Source

DeltaBufferGets / DeltaTotalGets
where:

DeltaBufferGets: difference in 'select sum(buffer_gets) from v$sql' between sample end and start
DeltaTotalGets: difference of 'select value from v$sysstat where name='session logical reads' between sample end and start

#### User Action

SID

## SID

#### Description

This data item represents the session identifier.

#### Data Source

select sid from v$session

#### User Action

OPS Stat

# OPS Stat

Instance wide statistic for an OPS database

OPS Stat Default Chart
OPS Stat Default Chart

Instance wide statistic for an OPS database

Total Pings/Sec

## Total Pings/Sec

Total number of OPS pings for all instances per second

CR Timeout/Sec

## CR Timeout/Sec

Global Cache CR Timeout for all instances per second

Convert Timeout/Sec

## Convert Timeout/Sec

Global Cache Convert Timeouts for all instances per second

Freelist Waits/Sec

## Freelist Waits/Sec

Global Cache Freelist Waits for all instances per second

Avarage CR Request

## Avarage CR Request

avarage CR request time in msec

BSP utilization

## BSP utilization

avarage serve time in msec

Avarage Convert time

## Avarage Convert time

avarage convert time in msec

Avarage get time

## Avarage get time

avarage get time in msec

OPS Stats By Instance

# OPS Stats By Instance

Instance wide statistic for an OPS database

OPS Stats By Instance Default Chart
OPS Stats By Instance Default Chart

Instance wide statistic for an OPS database

Total Pings/Sec

## Total Pings/Sec

Total number of OPS pings for an instances per second

CR Timeout/Sec

## CR Timeout/Sec

Global Cache CR Timeout for an instances per second

Convert Timeouts/Sec

## Convert Timeouts/Sec

Global Cache Convert Timeouts for an instances per second

Freelist Waits/Sec

## Freelist Waits/Sec

Global Cache Freelist Waits for an instances per second

Avarage CR Request

## Avarage CR Request

avarage CR request time in msec

BSP utilization

## BSP utilization

avarage serve time in msec

Avarage Convert time

## Avarage Convert time

avarage convert time in msec

Avarage get time

## Avarage get time

avarage get time in msec

Ping Ratio

## Ping Ratio

ratio of 'DBWR cross instance writes' to 'physical writes'

OPS Ping By File

# OPS Ping By File

Ping by File

OPS Ping By File Default Chart
OPS Ping By File Default Chart

Ping by File

Pings/Sec

## Pings/Sec

Ping count per second for this file

OPS Ping By File Drill

# OPS Ping By File Drill

Invisible

OPS Ping By File Drill Default Chart
OPS Ping By File Drill Default Chart

Invisible

Pings/Sec

## Pings/Sec

Ping count per second for this file

File Ping By Instance

# File Ping By Instance

Invisible

File Ping By Instance Default Chart
File Ping By Instance Default Chart

Invisible

Pings/Sec

## Pings/Sec

Ping count per second for this file of

OPS Ping By Block Class

# OPS Ping By Block Class

How pings are distributed over blocks of different classes

OPS Ping By Block Class Default Chart
OPS Ping By Block Class Default Chart

How pings are distributed over blocks of different classes

Pings/Sec

## Pings/Sec

Ping count per second for this file

Percentage

## Percentage

Ping count percentage

OPS Ping By Block Class Drill

# OPS Ping By Block Class Drill

Invisible

OPS Ping By Block Class Drill Default Chart
OPS Ping By Block Class Drill Default Chart

Invisible

Pings/Sec

## Pings/Sec

Ping count per second for this file

Percentage

## Percentage

Ping count percentage

OPS Ping By Object

# OPS Ping By Object

How pings are distributed over objects.

OPS Ping By Object Default Chart
OPS Ping By Object Default Chart

How pings are distributed over objects.

Ping/Sec

## Ping/Sec

Ping count per second for this object

Type

## Type

Type of database Object

OPS Ping By Object Drill

# OPS Ping By Object Drill

Invisible

OPS Ping By Object Drill Default Chart
OPS Ping By Object Drill Default Chart

Invisible

Ping/Sec

## Ping/Sec

Ping count per second for this object

Type

## Type

Type of database Object

OPS Object Ping By Instance Drill

# OPS Object Ping By Instance Drill

Invisible

OPS Object Ping By Instance Drill Default Chart
OPS Object Ping By Instance Drill Default Chart

Invisible

Ping/Sec

## Ping/Sec

Ping count per second for this object

OPS Maximum Ping By Block

# OPS Maximum Ping By Block

maximum pinged block#

OPS Maximum Ping By Block Default Chart
OPS Maximum Ping By Block Default Chart

maximum pinged block#

Name

## Name

name of the object

Type

## Type

Type of the object

File#

## File#

file number

Block#

## Block#

block number

Ping/Sec

## Ping/Sec

Ping count per second for this object

OPS Maximum Ping By Block for Object

# OPS Maximum Ping By Block for Object

invisible

OPS Maximum Ping By Block for Object Default Chart
OPS Maximum Ping By Block for Object Default Chart

invisible

Ping/Sec

## Ping/Sec

Ping count per second for this object

OPS System Waits

# OPS System Waits

System waits

OPS System Waits Default Chart
OPS System Waits Default Chart

System waits

Wait Time

## Wait Time

wait time for this event

Wait Percentage

## Wait Percentage

percentage of the wait

OPS Library Cache Lock

# OPS Library Cache Lock

Library cache

OPS Library Cache Lock Default Chart
OPS Library Cache Lock Default Chart

Library cache

dlm lock requests

## dlm lock requests

dlm lock requests

dlm pin requests

## dlm pin requests

dlm pin requests

dlm invalidations

## dlm invalidations

dlm invalidation

OPS Library Cache Lock By Instance

# OPS Library Cache Lock By Instance

Library cache by Istance

OPS Library Cache Lock By Instance Default Chart
OPS Library Cache Lock By Instance Default Chart

Library cache by Istance

dlm lock requests

## dlm lock requests

dlm lock requests

dlm pin requests

## dlm pin requests

dlm pin requests

dlm invalidations

## dlm invalidations

dlm invalidation

OPS Row Cache Lock

# OPS Row Cache Lock

Row cach

OPS Row Cache Lock Default Chart
OPS Row Cache Lock Default Chart

Row cach

dlm requests

## dlm requests

dlm request

dlm conflicts

## dlm conflicts

dlm conflocts

conflict %

## conflict %

dlm conflicts percentage

OPS Row Cache Lock By Instance

# OPS Row Cache Lock By Instance

Row cach by instance

OPS Row Cache Lock By Instance Default Chart
OPS Row Cache Lock By Instance Default Chart

Row cach by instance

dlm requests

## dlm requests

dlm request

dlm conflicts

## dlm conflicts

dlm conflocts

conflict %

## conflict %

dlm conflicts percentage