AWR_Instance Activity Stats一些指标的单位可以参考的东西

  • CPU used by this session - This is the amount of CPU time (in 10s of milliseconds) used by a session between when a user call started and ended. Some user calls can complete within 10 milliseconds and as a result, the start and end user-call time can be the same. In this case, 0 milliseconds are added to the statistic. A similar problem can exist in the reporting by the operating system, especially on systems that suffer from many context switches.
  • CPU used when call started - The CPU time used when the call is started.
  • CR blocks created - A buffer in the buffer cache was cloned. The most common reason for cloning is that the buffer is held in an incompatible mode.
  • Cached Commit SCN referenced - The number of times cached Commit SCN is referenced.
  • Commit SCN cached - The number of times Commit SCN is cached.
  • Current blocks converted for CR - A CURRENT buffer (shared or exclusive) is made CR before it can be used.
  • DBWR Flush object call found no dirty buffers - The DBWR did not find any dirty buffers for an object that was flushed from the cache.
  • DBWR Flush object cross instance calls - The number of times DBWR received a flush by object number cross instance call (from a remote instance). This includes both checkpoint and invalidate object.
  • DBWR buffers scanned - The total number of buffers looked at when scanning each LRU set for dirty buffers to clean. This count includes both dirty and clean buffers. Divide by DBWR LRU scans to find the average number of buffers scanned.
  • DBWR checkpoint buffers written - The number of buffers that were written for checkpoints.
  • DBWR checkpoints - Number of times the DBWR was asked to scan the cache and write all blocks marked for a checkpoint.
  • DBWR cross instance writes - The total number of blocks written for other instances so that they can access the buffers.
  • DBWR free buffers found - The number of buffers that DBWR found clean when it was requested to make free buffers. Divide by DBWR make free requests to find the average number of reusable buffers at the end of each LRU.
  • DBWR lru scans - The number of times that DBWR does a scan of the LRU queue looking for buffers to write. This includes times when the scan is to fill a batch being written for another purpose, such as a checkpoint. This statistic is always greater than or equal to DBWR make free requests.
  • DBWR make free requests - Number of messages received requesting DBWR to make some more free buffers for the LRU.
  • DBWR revisited being-written buffer - The number of times that DBWR tried to save a buffer for writing and found that it was already in the write batch. This statistic is a measure of the amount of "useless" work that DBWR had to do in trying to fill the batch. This can occur because many sources contribute to a write batch. If the same buffer from different sources is considered for adding to the write batch, then all but the first attempt will be "useless" since the buffer is already marked as being written.
  • DBWR skip hot writes - The number of times DBWR skipped writing "hot" buffers.
  • DBWR summed scan depth - The current scan depth (number of buffers examined by DBWR) is added to this statistic every time DBWR scans the LRU for dirty buffers. Divide by DBWR lru scans to find the average scan depth.
  • DBWR timeouts - The number of times that the DBWR has been idle since the last timeout. These are the times that the DBWR looked for buffers to idle write.
  • DBWR undo block writes - The number of transaction table blocks written by DBWR. It is an indication of how many "hot" buffers were written, leading to write complete waits.
  • DDL statements parallelized - The number of DDL statements that were parallelized.
  • DML statements parallelized - The number of DML statements that were parallelized.
  • PX local messages received - The number of local messages received for Parallel Executions.
  • PX local messages sent - The number of local messages sent for Parallel Executions.
  • PX remote messages received - The number of remote messages received for Parallel Executions.
  • PX remote messages sent - The number of remote messages sent for Parallel Executions.
  • SQL*Net roundtrips to/from client - Total number of Net8 messages sent to and received from the client.
  • SQL*Net roundtrips to/from dblink - Total number of Net8 messages sent over and received from a database link.
  • Unnecessary process cleanup for SCN batching - The total number of times that the process cleanup was performed unnecessarily because the session/process did not get the next batched SCN. The next batched SCN went to another session instead.
  • Background checkpoints completed - The number of checkpoints completed by the background. This statistic is incremented when the background successfully advances the thread checkpoint.
  • Background checkpoints started - The number of checkpoints started by the background. It can be larger than the number completed if a new checkpoint overrides an incomplete checkpoint. This only includes checkpoints of the thread, not individual file checkpoints for operations such as offline or begin backup. This statistic does not include the checkpoints performed in the foreground, such as ALTER SYSTEM CHECKPOINT LOCAL.
  • Bytes received via SQL*Net from client - The total number of bytes received from the client over Net8.
  • Bytes received via SQL*Net from dblink - The total number of bytes received from a database link over Net8.
  • Bytes sent via SQL*Net to client - The total number of bytes sent to the client from the foreground process(es).
  • Bytes sent via SQL*Net to dblink - The total number of bytes sent over a database link.
  • Calls to get snapshot SCN: kcmgss - The number of times a snap System Change Number (SCN) was allocated. The SCN is allocated at the start of a transaction.
  • Change write time - The elapsed time for redo write for changes made to CURRENT blocks in 10s of milliseconds.
  • Cleanouts and rollbacks - consistent read gets - The number of times CR gets require both block rollbacks, and block cleanouts.
  • Cleanouts only - consistent read gets - The number of times CR gets require only block cleanouts, no rollbacks.
  • Cluster key scan block gets - The number of blocks obtained in a cluster scan.
  • Cluster key scans - The number of cluster scans that were started.
  • Commit cleanout failures: block lost - The number of times a cleanout at commit was attempted and could not find the correct block due to forced write, replacement, or switch CURRENT.
  • Commit cleanout failures: buffer being written - The number of times a cleanout at commit was attempted but the buffer was currently being written.
  • Commit cleanout failures: callback failure - The number of times the cleanout callback function returns FALSE.
  • Commit cleanout failures: cannot pin - The total number of times a commit cleanout was performed but failed because the block could not be pinned.
  • Commit cleanout failures: hot backup in progress - The number of times cleanout at commit was attempted during hot backup. The image of the block needs to be logged before the buffer can be made dirty.
  • Commit cleanout failures: write disabled - The number of times that a cleanout at commit time was performed but the writes to the database had been temporarily disabled.
  • Commit cleanouts - The total number of times the cleanout block at commit time function was performed.
  • Commit cleanouts successfully completed - The number of times the cleanout block at commit time function successfully completed.
  • Consistent changes - The number of times a database block has applied rollback entries to perform a consistent read on the block. Workloads that produce a great deal of consistent changes can consume a great deal of resources.
  • Consistent gets - The number of times a consistent read was requested for a block. See also consistent changes above.
  • Cross instance CR read - The number of times this instance made a cross-instance call to write a particular block due to timeout on an instance lock get. The call allowed the block to be read CR rather than CURRENT.
  • Data blocks consistent reads - undo records applied - The number of undo records applied to CR rollback data blocks.
  • DB block changes - Closely related to consistent changes, this statistic counts the total number of changes that were made to all blocks in the SGA that were part of an update or delete operation. 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 total database work. This statistic indicates (possibly on a per-transaction level) the rate at which buffers are being dirtied.
  • DB block gets - This statistic tracks the number of blocks obtained in CURRENT mode.
  • Deferred (CURRENT) block cleanout applications - The number of times cleanout records are deferred, piggyback with changes, always current get.
  • Dirty buffers inspected - The number of dirty buffers found by the foreground while the foreground is looking for a buffer to reuse.
  • Enqueue conversions - The total number of enqueue converts.
  • Enqueue deadlocks - The total number of enqueue deadlocks between different sessions.
  • Enqueue releases - The total number of enqueue releases.
  • Enqueue requests - The total number of enqueue gets.
  • Enqueue timeouts - The total number of enqueue operations (get and convert) that timed out before they could complete.
  • Enqueue waits - The total number of waits that happened during an enqueue convert or get because the enqueue could not be granted right away.
  • Exchange deadlocks - The number of times that a process detected a potential deadlock when exchanging two buffers and raised an internal, restartable error. Index scans are currently the only operations, which perform exchanges.
  • Execute count - The total number of calls (user and recursive) that execute SQL statements.
  • Free buffer inspected - The number of buffers skipped over from the end of an LRU queue in order to find a reusable buffer. 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. For more information, see "dirty buffers inspected."
  • Free buffer requested - The count of the number of times a reusable buffer or a free buffer was requested to create or load a block.
  • Global cache defers - The number of times a ping request was deferred until later.
  • Global cache freelist waits - The number of pings for free lock elements (when all releasable locks are in use).
  • Global lock async converts - The total number of asynchronous global lock converts.
  • Global lock async gets - The total number of asynchronous global lock gets.
  • Global lock convert time - The total elapsed time of all synchronous (non-asynchronous) global lock converts in 10s of milliseconds.
  • Global lock get time - The total elapsed time of all synchronous (non-asynchronous) global lock gets in 10s of milliseconds.
  • Global lock releases - The total number of synchronous global lock releases.
  • Global lock sync converts - The total number of synchronous global lock converts.
  • Global lock sync gets - The total number of synchronous global lock gets.
  • Immediate (CR) block cleanout applications - The number of times cleanout records are applied immediately during CR gets.
  • Immediate (CURRENT) block cleanout applications - The number of times cleanout records are applied immediately during current gets.
  • Kcmccs called get current SCN - The number of times the kernel got the CURRENT SCN when there was a need to casually confirm the SCN.
  • Kcmgss read SCN without going to DLM - The number of times the kernel casually confirmed the SCN without going to the LM.
  • Kcmgss waited for batching - The number of times the kernel waited on a snapshot SCN.
  • Logons cumulative - The total number of logons since the instance started. This statistic is useful only in V$SYSSTAT. It gives an instance overview of all processes that logged on.
  • Logons current - The total number of current logons. This statistic is useful only in V$SYSSTAT.
  • Next SCNs gotten without going to DLM - The number of SCNs (System Change Numbers) obtained without going to the DLM.
  • No work - consistent read gets - The number of times CR gets require no block cleanouts nor rollbacks.
  • Opened cursors cumulative - The total number of opened cursors since the instance has started (in V$SYSSTAT). In V$SESSTAT, this statistic shows the total number of cursors opened since the start of the session.
  • Opened cursors current - The total number of current open cursors.
  • Opens of replaced files - The total number of files that needed to be reopened because they were no longer in the process file cache.
  • Opens requiring cache replacement - The total number of file opens that caused a current file to be closed in the process file cache.
  • Parse count (hard) - The total number of parse calls (real parses). A hard parse means allocating a workheap and other memory structures, and then building a parse tree. A hard parse is a very expensive operation in terms of memory use.
  • Parse count (total) - Total number of parse calls (hard and soft). A soft parse is a check to make sure that the permissions on the underlying object have not changed.
  • Parse time CPU - The total CPU time used for parsing (hard and soft) in 10s of milliseconds.
  • Parse time elapsed - The total elapsed time for parsing in 10s of milliseconds. By subtracting parse time CPU from this statistic, the total waiting time for parse resources is determined. For more information, see parse time CPU above.
  • Physical reads - The total number of data blocks read from disk. This equals the number of physical reads direct plus all reads into buffer cache.
  • Physical writes - The total number of data blocks written to disk. This equals the number of "physical writes direct" plus all writes from buffer cache.
  • Queries parallelized - The number of SELECT statements that got parallelized.
  • Recovery array read time - The elapsed time of I/O while doing recovery.
  • Recovery array reads - The number of reads performed during recovery.
  • Recovery blocks read - The number of blocks read during recovery.
  • Recursive calls - Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates a SQL statement. These internal SQL statements generate recursive calls.
  • Recursive CPU usage - The total CPU time used by non-user calls (recursive calls). Subtract this value from CPU used by this session to determine how much CPU time was used by the user calls.
  • Redo entries - This statistic increments each time redo entries are copied into the redo log buffer.
  • Redo entries linearized -The total number of entries of size <= REDO_ENTRY_PREBUILD_THRESHOLD. Building these entries increases CPU time, but may also increase concurrency on a multi-processor system.
  • Redo log space requests - The active log file is full and Oracle is waiting for disk space to be allocated for the redo log entries. Space is created by performing a log switch. 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, Oracle 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 DBWR to write dirty buffers to disk before continuing. Also, examine the log file space and log file space switch wait events in V$SESSION_WAIT.
  • Redo log space wait time - The total elapsed time of waiting for redo log space request in 10s of milliseconds.
  • Redo log switch interrupts - The number of times that another instance asked this instance to advance to the next log file.
  • Redo ordering marks - The number of times that an SCN had to be allocated to force a redo record to have a higher SCN than a record generated in another thread using the same block.
  • Redo size - The total amount of redo generated in bytes.
  • Redo synch time - The elapsed time of all redo sync write calls in 10s of milliseconds.
  • Redo synch writes - Usually, redo that is generated and copied into the log buffer need not be flushed out to disk immediately. The log buffer is a circular buffer that LGWR periodically flushes. Redo sync writes increments when changes being applied must be written out to disk due to a commit.
  • Redo wastage - Number of bytes wasted because redo blocks needed to be written before they are completely full. Early writing may be needed to commit transactions, to be able to write a database buffer or to switch logs.
  • Redo write time - The total elapsed time of the write from the redo log buffer to the current redo log file in 10s of milliseconds.
  • Redo writer latching time - The elapsed time need by LWGR to obtain and release each copy latch in 10s of milliseconds. This is only used if the initialization parameter LOG_SIMULTANEOUS_COPIES > 0. For more information, see "LOG_SIMULTANEOUS_COPIES".
  • Redo writes - Count of the total number of writes by LGWR to the redo log files.
  • Remote instance undo block writes - The number of times this instance wrote a dirty undo block so that another instance could read it.
  • Remote instance undo header writes - The number of times this instance wrote a dirty undo header block so that another instance could read it.
  • Remote instance undo requests - The number of times this instance requested undo from another instance so it could be read CR.
  • Rollback changes - undo records applied - The number of undo records applied to rollback (real) changes.
  • Rollbacks only - consistent read gets - The number of times CR gets require only block rollbacks, no block cleanouts.
  • Serializable aborts - The number of times an SQL statement in serializable isolation level had to abort.
  • Session connect time - The connect time for the session in 1/100 seconds. This value is useful only in V$SESSTAT. It is the wall clock time of when the logon to this session occurred.
  • Session cursor cache count - The total number of cursors cached. This is only incremented if SESSION_CACHED_CURSORS > 0. This statistic is the most useful in V$SESSTAT. If the value for this statistic in V$SESSTAT is close to the setting of the initialization parameter SESSION_CACHED_CURSORS, the value of the initialization parameter should be increased.
  • Session cursor cache hits -The count of the number of hits in the session cursor cache. A hit means that the SQL statement did not have to be reparsed. By subtracting this statistic from parse count (total) one can determine the real number of parses that happened.
  • Session logical reads - This statistic is basically DB block gets + consistent gets. For more information, see "DB block gets" and "consistent gets."
  • Session PGA memory - This statistic shows the current PGA size for a session. This statistic is useful only in V$SESSTAT; it has no meaning in V$SYSSTAT.
  • Session PGA memory max - This statistic shows the peak PGA size for a session. This statistic is useful only in V$SESSTAT; it has no meaning in V$SYSSTAT.
  • Session stored procedure space - This statistic shows the amount of memory that this session is using for stored procedures.
  • Session UGA memory - This statistic shows the current UGA size for a session. This statistic is useful only in V$SESSTAT; it has no meaning in V$SYSSTAT.
  • Session UGA memory max - This statistic shows the peak UGA size for a session. This statistic is useful only in V$SESSTAT; it has no meaning in V$SYSSTAT.
  • Sorts (disk) - If the number of disk writes is non-zero for a given sort operation, then this statistic is incremented. Sorts that require I/O to disk are quite resource intensive. Try increasing the size of the initialization parameter SORT_AREA_SIZE. For more information, see "SORT_AREA_SIZE".
  • Sorts (memory) - If the number of disk writes is zero, then the sort was performed completely in memory and this statistic is incremented. This is further indication of sorting activity in the application workload. You cannot do much better than memory sorts, except maybe no sorts at all. Sorting is usually caused by selection criteria specifications within table join SQL operations.
  • Sorts (rows) - The total number of rows sorted.
  • Summed dirty queue length - The sum of the dirty LRU queue length after every write request. Divide by writes requests to get the average queue length after write completion.
  • Table fetch by ROWID - When rows are fetched using a ROWID (usually recovered from an index), each row returned increments this counter. This statistic is an indication of row fetch operations being performed with the aid of an index. Because doing table scans usually indicates either non-optimal queries or tables without indexes, this statistic should increase as the above issues have been addressed in the application.
  • Table fetch continued row -When a row that spans more than one block is encountered during a fetch, this statistic is incremented. Retrieving rows that span more than one block increases the logical I/O by a factor that corresponds to the number of blocks than need to be accessed. Exporting and re-importing may eliminate this problem. Taking a closer look at the STORAGE parameters PCT_FREE and PCT_USED. This problem cannot be fixed if rows are larger than database blocks (for example, if the LONG datatype is used and the rows are extremely large).
  • Table scan blocks gotten - During scanning operations, each row is retrieved sequentially by Oracle. Each block encountered during the scan increments this statistic. This statistic informs you of the number of database blocks that you had to get from the buffer cache for the purpose of scanning. Compare the value of this parameter to the value of consistent gets to get a feeling for how much of the consistent read activity can be attributed to scanning. For more information, see "consistent gets".
  • Table scan rows gotten - This statistic is collected during a scan operation, but instead of counting the number of database blocks, it counts the rows being processed.
  • Table scans (cache partitions) - Count of range scans on tables that have the CACHE option enabled.
  • Table scans (direct read) - Count of table scans performed with direct read (bypassing the buffer cache).
  • Table scans (long tables) - Long (or conversely short) tables can be defined as tables that do not meet the short table criteria as described in table scans (short tables) below.
  • Table scans (rowid ranges) - Count of table scans with specified ROWID endpoints. This is performed for Parallel Query.
  • Table scans (short tables) - Long (or conversely short) tables can be defined by optimizer hints coming down into the row source access layer of Oracle. The table must have the CACHE option set.
  • Total file opens - The total number of file opens being performed by the instance. Each process needs a number of files (control file, log file, database file) in order to work against the database.
  • Transaction rollbacks - The number of transactions being successfully rolled back.
  • Transaction tables consistent read rollbacks - The number of times transaction tables are CR rolled back.
  • Transaction tables consistent reads -undo records applied - The number of undo records applied to CR rollback transaction tables.
  • User calls - Oracle allocates resources (Call State Objects) to keep track of relevant user call data structures every time you log in, parse or execute. When determining activity, the ratio of user calls to RPI calls, indicates how much internal work gets generated as a result of the type of requests the user is sending to Oracle.
  • User commits - 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.
  • User rollbacks - This statistic stores the number of times users manually issue the ROLLBACK statement or an error occurs during users' transactions.
  • Write requests - This statistic stores the number of times DBWR takes a batch of dirty buffers and writes them to disk.



l  CPU used when call started - The CPU time used when the call is started

l  CR blocks created- A buffer in the buffer cache was cloned. The most common reason for cloning is that the buffer is held in an incompatible mode.

l  Cached Commit SCN referenced- The number of times cached Commit SCN is referenced.

l  Commit SCN cached- The number of times Commit SCN is cached.

l  Current blocks converted for CR- A CURRENT buffer (shared or exclusive) is made CR before it can be used.

l  DBWR Flush object call found no dirty buffers- The DBWR did not find any dirty buffers for an object that was flushed from the cache.

l  DBWR Flush object cross instance calls- The number of times DBWR received a flush by object number cross instance call (from a remote instance). This includes both checkpoint and invalidate object.

l  DBWR buffers scanned- The total number of buffers looked at when scanning each LRU set for dirty buffers to clean. This count includes both dirty and clean buffers. Divide by DBWR LRU scans to find the average number of buffers scanned.

l  DBWR checkpoint buffers written- The number of buffers that were written for checkpoints.

l  DBWR checkpoints- Number of times the DBWR was asked to scan the cache and write all blocksmarked for a checkpoint.

l  DBWR cross instance writes- The total number of blocks written for other instances so that they can access the buffers.

l  DBWR free buffers found- The number of buffers that DBWR found clean when it was requested to make free buffers. Divide by DBWR make free requests to find the average number of reusable buffers at the end of each LRU.

l  DBWR lru scans- The number of times that DBWR does a scan of the LRU queue looking for buffers to write. This includes times when the scan is to fill a batch being written for another purpose, such as a checkpoint. This statistic is always greater than or equal to DBWR make free requests.

l  DBWR make free requests- Number of messages received requesting DBWR to make some more free buffers for the LRU.

l  DBWR revisited being-written buffer- The number of times that DBWR tried to save a buffer for writing and found that it was already in the write batch. This statistic is a measure of the amount of "useless" work that DBWR had to do in trying to fill the batch. This can occur because many sources contribute to a write batch. If thesame buffer from different sources is considered for adding to the write batch, then all but the first attempt will be "useless" since the buffer is alreadymarked as being written.

l  DBWR skip hot writes- The number of times DBWR skipped writing "hot" buffers.

l  DBWR summed scan depth- The current scan depth (number of buffers examined by DBWR) is added to this statistic every time DBWR scans the LRU for dirty buffers. Divide by DBWR lru scans to find the average scan depth.

l  DBWR timeouts- The number of times that the DBWR has been idle since the last timeout. These are the times that the DBWR looked for buffers to idle write.

l  DBWR undo block writes- The number of transaction table blocks written by DBWR. It is an indication of how many "hot" buffers were written, leading to write complete waits.

l  DDL statements parallelized- The number of DDL statements that were parallelized.

l  DML statements parallelized- The number of DML statements that were parallelized.

l  PX local messages received- The number of local messages received for Parallel Executions.

l  PX local messages sent- The number of local messages sent for Parallel Executions.

l  PX remote messages received- The number of remote messages received for Parallel Executions.

l  PX remote messages sent- The number of remote messages sent for Parallel Executions.

l  SQL*Net roundtrips to/from client- Total number of Net8 messages sent to and received from the client.

l  SQL*Net roundtrips to/from dblink - Total number of Net8 messages sent over and received from a database link.

l  Unnecessary process cleanup for SCN batching- The total number of times that the process cleanup was performed unnecessarily because the session/process did not get the next batched SCN. The next batched SCN went to another session instead.

l  Background checkpoints completed- The number of checkpoints completed by the background. This statistic is incremented when the background successfully advances the thread checkpoint.

l  Background checkpoints started- The number of checkpoints started by the background. It can be larger than the number completed if a new checkpoint overrides an incomplete checkpoint. This only includes checkpoints of the thread, not individual file checkpoints for operations such as offline or begin backup. This statistic does not include the checkpoints performed in the foreground, such as ALTER SYSTEM CHECKPOINT LOCAL.

l  Bytes received via SQL*Net from client- The total number of bytes received from the client over Net8.

l  Bytes received via SQL*Net from dblink- The total number of bytes received from a databaselink over Net8.

l  Bytes sent via SQL*Net to client- The total number of bytes sent to the client from the foreground process(es).

l  Bytes sent via SQL*Net to dblink- The total number of bytes sent over a databaselink.

l  Calls to get snapshot SCN: kcmgss- The number of times a snap System Change Number (SCN) was allocated. The SCN is allocated at the start of a transaction.

l  Change write time- The elapsed time for redo write for changes made to CURRENT blocks in 10s of milliseconds.

l  Cleanouts and rollbacks- consistent read gets - The number of times CR gets require both block rollbacks, and block cleanouts.

l  Cleanouts only- consistent read gets - The number of times CR gets require only block cleanouts, no rollbacks.

l  Cluster key scan block gets- The number of blocks obtained in a cluster scan.

l  Cluster key scans- The number of cluster scans that were started.

l  Commit cleanout failures: block lost- The number of times a cleanout at commit was attempted and could not find the correct block due to forced write, replacement, or switch CURRENT.

l  Commit cleanout failures: buffer being written- The number of times a cleanout at commit was attempted but the buffer was currently being written.

l  Commit cleanout failures: callback failure- The number of times the cleanout callback function returns FALSE.

l  Commit cleanout failures: cannot pin- The total number of times a commit cleanout was performed but failed because the block could not be pinned.

l  Commit cleanout failures: hot backup in progress- The number of times cleanout at commit was attempted during hot backup. The image of the block needs to be logged before the buffer can be made dirty.

l  Commit cleanout failures: write disabled- The number of times that a cleanout at commit time was performed but the writes to the database had been temporarily disabled.

l  Commit cleanouts- The total number of times the cleanout block at commit time function was performed.

l  Commit cleanouts successfully completed- The number of times the cleanout block at commit time function successfully completed.

l  Consistent changes- The number of times a database block has applied rollback entries to perform a consistent read on the block. Workloads that produce a great deal of consistent changes can consume a great deal of resources.

l  Consistent gets- The number of times a consistent read was requested for a block. See also consistent changes above.

l  Cross instance CR read- The number of times this instance made a cross-instance call to write a particular block due to timeout on an instance lock get. The call allowed the block to be read CR rather than CURRENT.

l  Data blocks consistent reads- undo records applied - The number of undo records applied to CR rollback data blocks.

DB block gets - This statistic tracks the number of blocks obtained in CURRENT mode.

Deferred (CURRENT) block cleanout applications- The number of times cleanout records are deferred, piggyback with changes, always current get.

Dirty buffers inspected - The number of dirty buffers found by the foreground while the foreground is looking for a buffer to reuse.

Enqueue conversions - The total number of enqueue converts.

Enqueue deadlocks - The total number of enqueue deadlocks between different sessions.

Enqueue releases - The total number of enqueue releases.

Enqueue requests - The total number of enqueue gets.

Enqueue timeouts - The total number of enqueue operations (get and convert) that timed out before they could complete.

Enqueue waits - The total number of waits that happened during an enqueue convert or get because the enqueue could not be granted right away.

Exchange deadlocks - The number of times that a process detected a potential deadlock when exchanging two buffers and raised an internal, restartable error. Index scans are currently the only operations, which perform exchanges.

Free buffer inspected - The number of buffers skipped over from the end of an LRU queue in order to find a reusable buffer. 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. For more information, see "dirty buffers inspected."

Free buffer requested - The count of the number of times a reusable buffer or a free buffer was requested to create or load a block.

Global cache defers - The number of times a ping request was deferred until later.

Global cache freelist waits - The number of pings for free lock elements (when all releasable locks are in use).

Global lock async converts - The total number of asynchronous global lock converts.

Global lock async gets - The total number of asynchronous global lock gets.

Global lock convert time - The total elapsed time of all synchronous (non-asynchronous) global lock converts in 10s of milliseconds.

Global lock get time - The total elapsed time of all synchronous (non-asynchronous) global lock gets in 10s of milliseconds.

Global lock releases - The total number of synchronous global lock releases.

Global lock sync converts - The total number of synchronous global lock converts.

Global lock sync gets - The total number of synchronous global lock gets.

Immediate (CR) block cleanout applications- The number of times cleanout records are applied immediately during CR gets.

Immediate (CURRENT) block cleanout applications- The number of times cleanout records are applied immediately during current gets.

Kcmccs called get current SCN- The number of times the kernel got the CURRENT SCN when there was a need to casually confirm the SCN.

Kcmgss read SCN without going to DLM- The number of times the kernel casually confirmed the SCN without going to the LM.

Kcmgss waited for batching - The number of times the kernel waited on a snapshot SCN.

Logons cumulative - The total number of logons since the instance started. This statistic is useful only in V$SYSSTAT. It gives an instance overview of all processes that logged on.

Next SCNs gotten without going to DLM- The number of SCNs (System Change Numbers) obtained without going to the DLM.

No work - consistent read gets- The number of times CR gets require no block cleanouts nor rollbacks.

Opened cursors cumulative - The total number of opened cursors since the instance has started (in V$SYSSTAT). In V$SESSTAT, this statistic shows the total number of cursors opened since the start of the session.

Opened cursors current - The total number of current open cursors.

Opens of replaced files - The total number of files that needed to be reopened because they were no longer in the process file cache.

Opens requiring cache replacement- The total number of file opens that caused a current file to be closed in the process file cache.

Parse time CPU - The total CPU time used for parsing (hard and soft) in 10s of milliseconds.

Parse time elapsed - The total elapsed time for parsing in 10s of milliseconds. By subtracting parse time CPU from this statistic, the total waiting time for parse resources is determined. For more information, see parse time CPU above.

Queries parallelized - The number of SELECT statements that got parallelized.

Recovery array read time - The elapsed time of I/O while doing recovery.

Recovery array reads - The number of reads performed during recovery.

Recovery blocks read - The number of blocks read during recovery.

Recursive calls - Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates a SQL statement. These internal SQL statements generate recursive calls.

Recursive CPU usage - The total CPU time used by non-user calls (recursive calls). Subtract this value from CPU used by this session to determine how much CPU time was used by the user calls.

Redo entries - This statistic increments each time redo entries are copied into the redo log buffer.

l   Redo entrieslinearized-The total number of entries of size <= REDO_ENTRY_PREBUILD_THRESHOLD. Building these entries increases CPU time, but may also increase concurren






名称

  

注释

CPU used by this session

统计CALL发起开始到结束的CPU时间片的数量,每个计数代表一个CPU周期,也就是10毫秒。不过如果有一个CALL不足一个CPU周期就执行完了,那么统计值的时候START TIMEEND TIME是相同的,这样会计算为0.这个计数基本上可以代表了ORACLE数据库消耗的CPU资源,不过计算的时候要注意单位是厘秒(cs),乘以10可以换算成毫秒。比如平均每秒这个指标值是782.1,表示ORACLE消耗了7821毫秒CPU时间,如果这个系统是一个16CPU的系统,那么这个指标可以说明ORACLE消耗了超过50%CPU资源。不过由于部分小的CALL可能由于消耗的时间小于10毫秒而没有计算进去,实际的使用率可能略高于通过这个值计算出来的。一般来说大多数CALL消耗的CPU都会大于10毫秒,所以这个值还是能够基本反映出ORACLECPU资源的开销

CR blocks created   

CURRENT块被克隆后用于创建CRconsistent read)块。被克隆的主要原因是BUFFER被非兼容的模式占用,如果单位时间内CR BLOCKS CREATED值比较高,说明数据库中对某些数据块的修改和访问比较频繁。如果这些访问集中在某些热块上,那么可能会形成较为严重的BUFFER BUSY WAITS,在RAC环境中,可能还会导致全局热块冲突,如果这个指标比较高,那么应该关注BUFFER BUSY WAITS以及CACHE BUFFER CHAINS闩锁等

current blocks converted for CR

一个CURRENTBUFFER在被使用前生成了CR

DBWR buffers scanned

当某些触发条件发生时,DBWR会在LRU链的冷端开始扫描脏块,组成DBWR BATCH,这个指标统计的是DBWRLRU上扫描的BUFFER的总数,包含脏块和干净的块,这个指标除以DBWR LRU SCANS这个指标就是每次扫描查找的数据块的数量。

DBWR checkpoint buffers written

CHECKPOINTSdbwr写入的的脏块数量,如果在单位时间里这个指标比较高,说明系统中数据块的变更较为频繁

DBWR free buffers found

DBWRLRU链中扫描BUFFER的时候发现的FREEBUFFER的数量,除以DBWR  MAKE FREE REQUESTS就是平均每次DBWR在收到DBWR MAKE FREE消息的时候扫描LRU链找到的FREE BUFFER的平均数,这个平均数一般会比较少

DBWR make free requests

DBWR收到的MAKE FREE 消息的数量,如果某个前台进程在查找一个空闲的BUFFER的时候无法找到的时候或者其他一些触发条件,会向DBWR发出MAKE FREE消息。如果在单位时间内这个值较高,说明DB CACHE可能存在不足的现象

DBWR summed scan depth

DBWR扫描LRU链查找脏块的时候,查找的BUFFER的数量,这个数越大说明LRU链尾部的赃块数量越少。从Oracle 8i开始,由于LRU链的算法发生了变化,因此如果LRU链尾部的热块比较多,也可能造成这个指标较大

DBWR timeout

DBWR IDLE超过一个特定值,该指标就会加1。如果该值较高,说明BUFFER CACHE中的数据变化较小,需要写入磁盘的脏块数量极少

DBWR transaction table writes

DBWR写入的回滚段头的数量,这个指标比较高说明有较多热块正在被写入,而大量用户进程在等待这些块写入完成

DBWR undo block writes

DBWR写入回滚段的数据块数量

DDL statements parallelized

DDL操作并发执行的计数

DML statements parallelized

DML操作并发执行的计数

background checkpoints completed

后台进程完成的CHECKPOINTS的数量。

background checkpoints started

后台进程启动的CHECKPOINTS数量,可能比上一个状态的值大一些。如果一个新的CHECKPOINT覆盖了一个未完成的CHECKPOINT或者CHECKPOINT还正在执行。这个状态只包含REDOCHECKPOINT,不包括其他类型的CHECKPOINT,比如OFFLINE文件或者BEGIN BACKUP或者ALTER SYSTEM CHECKPOINT LOCAL命令等

branch node splits

由于插入数据导致的索引枝节点分裂的数量,这个指标较高说明目前存在索引产生了较多的枝节点分裂,可能某张表上的某个索引字段变化十分频繁,这种频繁的变化可能对某个应用的性能有较大的影响

BUFFER DEADLOCK

DB CACHE死锁的数量计数,如果单位时间内该指标较高,可能DB CACHE存在性能问题,或者存在某些BUG

buffer is not pinned count

当访问一个BUFFER的时候,这个BUFFER已经释放的数量,只用于Oracle内部调试,并不说明性能问题

buffer is pinned count

当访问一个BUFFER的时候,该BUFFER已经被PIN住了,如果单位时间内这个指标比较高,说明可能存在热块

change write time

当前块的变化被写入REDO的时间,单位厘秒(cs,10毫秒),该指标一般不会太大,如果太大需要分析

commit cleanout failures: block lost

commit的时候准备做块清理操作的时候,发现不能找到正确的块的次数计数。

commit cleanout failures: buffer being written

OracleCOMMIT的时候,去清除BUFFER的时候,发现这个BUFFER 正在被其他会话写入的计数,如果改指标比较高,可能说明存在热块  

commit cleanout failures: callback failure

OracleCOMMIT的时候,做清除操作时调用CALLBACK函数返回FALSE的计数

commit cleanout failures: cannot pin

OracleCOMMIT的时候,做清除操作时无法PIN到这个BUFFER的计数,有可能在准备清理的时候该BUFFER又被其他会话PIN住了,如果该指标较高,可以查看DB CACHE相关的情况,包括DB CACHE的大小,命中率,相关闩锁的命中率,以及热块争用的情况

commit cleanout failures: hot backup in progress      

  

OracleCOMMIT的时候,做清除操作时发现正在做热备份的技术。此时在修改这个BUFFER前,这个BUFFER在被修改前,必须先被写入LOG BUFFER,以确保数据库恢复的时候不会产生块断裂

commit cleanout failures: write disabled

OracleCOMMIT的时候,做清除操作时发现数据库的写操作暂时被关闭了。这种情况出现的很少

  

commit cleanouts

在做COMMIT的时候做块清除工作的计数,无论成功与否计数器都会加1

commit cleanouts successfully completed

COMMIT时成功完成CLEANOUTS的计数。这个指标和上一个指标参考来看,两个指标应该较为接近(这个指标略低一些),如果这两个指标相差太大,需要分析DB CACHE是否存在过小的问题,或者应用中是否经常对大表进行大数据量的修改操作

consistent changes

数据块提交了UNDO信息成为CR块的计数,这个指标说明了系统中CR块产生的数量,这个指标越大,越要注意CACHE BUFFER CHAINS等闩锁的情况,以及热块对系统性能的影响

consistent gets

一致性读的计数,会话发出的对某个数据块进行一致性读的请求。这个指标不能和consistent changes混淆,一个CR块产生后,可能被多次consistent gets使用,因此这个指标要比前一个指标大的多。

data blocks consistent reads - undo records applied

UNDO中读取数据,形成CR READ。本计数器是记录从UNDO中获取UNDO记录的计数,如果这个指标的值较大,说明对于某些修改较为频繁的表的查询和其他操作也很频繁,有可能存在热点表和索引

deferred (CURRENT) block cleanout applications

做延迟块清除操作的计数。在提交的时候该数据块由于某些原因,某些数据块无法马上做块清除工作,这种情况下,这个数据块就会做延迟块清除,延迟块清除操作可能在下次该数据块被查询的时候进行,这种情况也导致了有时候我们会看到我们做SELECT操作的时候也会产生大量的REDO

dirty buffers inspected

当某个会话在LRU链的冷端开始查找空闲的数据块,查到一个脏块,这个指标就会被增加,如果在单位时间内该指标较大,说明LRU链的冷端存在较多的脏块。这种情况的出现有几种可能:

  

l          系统中的赃块数量十分巨大,而且DBWR的写入速度不足,从而导致DBWR无法尽快将这些脏块写入硬盘

  

l          部分BUFFER 特别热,并且被更改的频率特别高,从而造成LRU链的尾端存在大量这样的块

  

l          本系统是一个以DML为主的系统,数据块的变更十分频繁

  

碰到这种情况,可以关注一下dbwr的性能,并且关注一下DB  CACHE的命中率及cache buffer chains等闩锁的情况

enqueue waits

等待各种锁的计数

exchange deadlocks

当进行两个BUFFER交换的时候,发生内部死锁的计数。索引扫描是导致这种交换的唯一因素,如果改指标较高,可以检查是否存在十分热的索引(可以通过BUFFER BUSY WAITS分析来定位)

free buffer inspected

LRU队列的尾部扫描可重用的BUFFER的时候跳过的BUFFER的数量。

  

global cache freelist waits

ping一个buffer的时候由于所有的lock element都被使用而引起的等待。

global lock convert time

同步全局锁的转换时间(单位是10ms),这个指标较高说明全局锁冲突较为严重,需要检查cluster interconnect的性能

hot buffers moved to head of LRU

当一个热块到达LRU队列的尾部的时候,ORACLE自动会把这个块移动到LRU队列的头上,以便于使之能够继续被使用。每发生一次这样的操作,这个计数就加一,值得注意的是,从8i开始,LRU的算法发生了变化,通过引入TCH计数来确定热块,而不是通过将热块在LRU链上移动来保证热块不被过早的换出。如果热块存在于LRU链的尾部,扫描的时候发现了热块,会主动跳过,从而保证热块不被过早的重用

  

immediate (CURRENT) block cleanout applications

获取BUFFERGET BUFFER)后,立即进行记录清除操作的计数。

leaf node splits

INSERT发生后,导致索引叶节点分裂的次数,一般来说对于插入较为频繁的系统,这个指标一般会比较高,除非出现叶节点热块较为严重的现象,一般来所不需要特别关注该指标

logons current

当前登录数据库的计数

opened cursors current

当前的Open CURSORS的数量

opens of replaced files

文件由于不在打开文件缓冲中而重新打开的计数。每个Oracle会话都有一个文件打开缓冲区,保持部分打开的数据文件的句柄,以避免重复打开文件

parse count (hard)

硬分析的统计值,该值需要和parse count (total)对比来看硬分析的比例。

parse count (soft)

软分析的统计值

parse count (total)

发生的parse call的总数

parse time cpu

PARSE消耗的CPU的统计,单位是10毫秒

parse time elapsed

PASE的持续时间,单位是10毫秒。这个指标减去parse time cpu就是parse中等待的时间。如果parse time cpu占整个parse time elapsed的比例较低,说明parse中的等待时间过长,可能共享池存在性能问题,需要进行分析

physical reads direct

直接物理读的数量。读的时候不经过BUFFER。一般发生这种操作的情况有:排序操作、并行查询操作的SLAVE或者预读

physical writes direct

直接写的数量,不经过BUFFER,直接写入。一般发生这种操作的情况有:

  

l          直接装载操作,比如CREATE TABLE AS SELECT

  

l          并行DML操作

  

l          排序操作中的临时表空间写入

  

l          写入没有缓冲的LOB字段

physical writes non checkpoint

CHECKPOINT引起的物理写。物理写的发生情况包括CHECKPOINT或者无足够的空闲BUFFER可用,或者DBWR超时等,一般情况下这个指标会超过physical writes的一半以上,除非是CHECKPOINT十分频繁的系统。如果该指标占physical writes的比重比较少,应该进行分析

pinned buffers inspected

当一个用户进程扫描REPLACEMENT列表,寻找一个可重用的BUFFER的时候,发现一个冷块被PIN了或者有一个PIN请求的等待事件。这种情况很少发生,因为冷块很少会被PIN。如果平均每秒该指标值较大,需要进行分析

queries parallelized

并行查询执行的次数统计

recursive cpu usage

非用户调用的CUP时间

recovery array read time

recovery的时候产生的IO消耗的时间

recovery array reads

RECOVERY的时候产生的IO的次数

recovery blocks read

recovery的时候读取的数据块的数量

redo entries

当一个redo信息被拷贝到log buffer的时候这个计数增加

redo entries linearized

小于等于REDO_ENTRY_PREBUILD_THRESHOLDredo entries的数量,这些redo entries可以并发生成,不需要受闩锁的限制,但是会增加CPU的消耗,在多CPU的系统中,这个值会比较高

redo buffer allocation retries

当申请REDO BUFFER的时候,重试的次数。一般来说重试发生的原因是REDO WRITER还没完成或者日志切换正在进行。如果该指标较高,说明REDO  LOG产生的频率很高,LGWR无法及时刷新LOG  BUFFER,可以考虑加大LOG BUFFER的大小。LOG  BUFFER一般可以为几兆到几十兆,不过由于很多数据库版本中存在BUG,因此不建议将LOG BUFFER设置的过大,一般来说30-40M对于绝大多数系统来说都是足够的了

  

如果是由于等待日志切换,那么可能是存在的问题包括:

  

l          REDO  LOG文件过小

  

l          REDO  LOG IO性能不佳

  

l          数据文件的IO性能不佳导致DBWR写入较慢

  

l          DBWR的数量太少,导致DBWR的写入性能不足

redo log space requests

当前ACTIVE的日志文件满了,Oracle必须等待日志切换完成后才能分配REDO LOG磁盘空间,就会产生这个等待。如果SGA的大小和日志文件的大小不匹配,并且系统中的COMMIT十分频繁。当日志切换的时,DBWR需要把已经提交的脏块也写入磁盘,在这些脏块写入磁盘完成前,日志切换不能完成。在这种情况下,这个统计值会比较高。

  

如果这个统计值较高,建议检查以下几个方面:

  

l          REDO  LOG文件的IO性能是否存在问题,如果log file parallel write的平均耗时较大,说明REDO LOG的写性能出现了问题,建议将REDO LOG放到性能更好的磁盘上,或者将REDO LOG文件独立存放,避免IO冲突

  

l          LOG  BUFFER的大小是否过小

  

l          应用软件中的提交可能过于频繁,建议采用批量提交的方式,而不要每条记录都提交

redo log space wait time

Redo log space requests的等待时间(单位厘秒),这个指标需要和上一个指标一起看

  

redo size

生成的所有redo的大小,单位是字节

redo synch time

Redo synch调用消耗的时间,单位是10毫秒(厘秒)

redo sync writes

一般来说redo信息生成后,会被拷贝到log buffer中,并不需要马上被写入redo log文件,lgwr会周期性将这些数据写入redo log文件。不过如果事务提交了,那么这些redo 信息必须马上被写入REDO LOG文件,这个时侯redo sync writes计数器会增加

redo wastage

在把LOG BUFFER数据写入REDO LOG文件的时候计算的LOG BUFFER空闲的空间

redo writer latching time

LGWR获得每个COPY LATCH的时间(单位厘秒),如果该指标存在问题,需要检查REDO LOG文件的IO性能以及LOG BUFFER的大小是否足够,这个指标只有在LOG_SIMULTANEOUS_COPIES > 0的时候才有意义

redo writes

LGWRLOG BUFFER写入REDO LOG文件的计数

remote instance undo block writes

如果远程的实例需要读取某个UNDO BLOCK,需要这个实例先将这个脏的”UNDO BLOCK回写,这个计数器就会增加

remote instance undo header writes

和上一个指标类似,只是写入的是UNDO HEADER

remote instance undo requests

由于要做CR从远程的实例中请求UNDO的数量,如果这个指标较大,说明RAC中的某些数据块经常在实例间进行共享,某个实例修改过的数据也正在被其他实例使用,这种情况下需要留意CLUSTER INTERCONNECT的性能

rollback changes - undo records applied

当用户需要ROLLBACK的时候,提交的UNDO记录的数量,当事务需要回滚时,需要从UNDO中取出数据,并且提交到已被修改过的数据上,这个计数和系统中ROLLBACK的数量以及每次ROLLBACK的记录的数量有关

rollbacks only - consistent read gets

当用户需要进行CR READ的时候,提交的UNDO记录的数量,此时并没有BUFFER CLEAR操作发生。当进行一致性读的时候,也需要从UNDO中取出相关的数据,然后生成一个CR BLOCK,把这些数据提交到CR BLOCK上,这个时候这个指标就会增加。

  

rows fetched via callback

CALLBACK函数返回的记录数。该统计量仅仅用于内部DEBUG

session cursor cache count

会话CURSOR缓冲区的计数,只有当session_cached_cursors大于0的时候才有意义,如果这个值已经很接近甚至到达了参数中session_cached_cursors的值,那么说明这个参数可能需要加大

session cursor cache hits

这个指标也只有当session_cached_cursors大于0才有意义,会话直接从SESSION CURSOR CACHE中找到某个SQL的计数,这个值可以看出CURSOR CACHE产生的作用,可以将这个值和parse  count(total)进行比较

sorts (disk)

磁盘排序的数量,如果平均每秒该指标的值较高,需要检查一下PGA_AGGREGATE_TARGET参数是否设置过低,或者*_AREA_SIZE是否设置过小(PGA手工管理模式)。检查该指标的时候,同时应该查看一下TEMP表空间的相关文件的IO性能,如果TEMP表空间文件的IO性能不足,需要加大PGA的配置来减少硬盘排序

sorts (memory)

内存排序的统计

summed dirty queue length

每次写请求发生的时候,脏数据块链表的长度总和除以写请求的次数,这个统计值越大,说明系统中需要回写的脏块较多

switch current to new buffer

将当前BUFFER移动到另外一个新的BUFFER,原有的BUFFER成为一个CR BLOCK,这种操作的次数

table fetch by rowid

通过ROWID访问表,这种操作一般是通过索引访问,还有一种情况是SQL直接通过rowid去访问某个表。

table fetch continued row

如果访问某一行数据,需要访问多个BLOCK,这个计数器就会增加。产生这种情况的一个很主要的原因是行链和行迁移,如果某个表的PCT_FREE设置不合理,可能导致UPDATE的时候产生行迁移,这样就会增加这个计数

  

第二种可能性是某一行计数的长度相对BLOCK SIZE来说过大,这样一行数据被存储在多个BLOCK中的机会就较大,这种情况下应该将这种表存放于更大的BLOCK SIZE的表空间中

  

还有一种可能性就是系统中访问带LOB字段的访问较多,因为大的LOB字段一般来说采用独立的SEGMENT存放,因此访问这种数据也会增加这个统计值

total file opens

INSTANCE打开的文件的数量(包含数据文件、控制文件、REDO  LOG等)

transaction rollbacks

被成功回退的事务的总数

  

write clones created in background

如果当前的BUFFER正在被写入,那么后台进程或者前台进程克隆一个新的BUFFER,使原来BUFFER的写入可以继续进行

  

enqueue conversions

表或者行锁的转换统计

enqueue deadlocks

死锁统计

enqueue releases

锁释放统计

enqueue requests   

锁申请统计

enqueue timeouts

锁申请超时统计

enqueue waits

锁等待统计

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30126024/viewspace-2102295/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/30126024/viewspace-2102295/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值