Oracle服务器监控指标和分析

Oracle关键计数器含义

l
CPU used by this session：所有session的cpu占用量，不包括后台进程。这项统计的单位是百分之x秒.完全调用一次不超过10ms

l
db block changes：那部分造成SGA中数据块变化的insert,update或delete操作数这项统计可以大概看出整体数据库状态。在各项事务级别，这项统计指出脏缓存比率。

l
execute count：执行的sql语句数量(包括递归sql)

l
logons current：当前连接到实例的Sessions。如果当前有两个快照则取平均值。

l
logons cumulative：自实例启动后的总登陆次数。

l
parse count (hard)：在shared pool中解析调用的未命中次数。当sql语句执行并且该语句不在shared pool或虽然在shared
pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条sql语句原文与当前存在的相同，但查询表不同则认为它们是两条不同语句，则硬解析即会发生。硬解析会带来cpu和资源使用的高昂开销，因为它需要oracle在shared
pool中重新分配内存，然后再确定执行计划，最终语句才会被执行。

l
parse count (total)：解析调用总数，包括软解析和硬解析。当session执行了一条sql语句，该语句已经存在于shared pool并且可以被使用则产生软解析。当语句被使用(即共享)所有数据相关的现有sql语句(如最优化的执行计划)必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。

l
parse time cpu：总cpu解析时间(单位：10ms)。包括硬解析和软解析。

l
parse time elapsed：完成解析调用的总时间花费。

注：SQL语句的解析有软解析soft parse与硬解析hard parse之说，以下是5个步骤：

1：语法是否合法(sql写法)

2：语义是否合法(权限，对象是否存在)

3：检查该sql是否在公享池中存在

-- 如果存在,直接跳过4和5,运行sql.此时算soft
parse

4：选择执行计划

5：产生执行计划

如果5个步骤全做,这就叫hard parse.

l physical reads：OS
blocks read数。包括插入到SGA缓存区的物理读以及PGA中的直读这项统计并非i/o请求数。

l physical writes：从SGA缓存区被DBWR写到磁盘的数据块以及PGA进程直写的数据块数量。

l
redo log space requests：在redo logs中服务进程的等待空间，表示需要更长时间的log switch。

l
redo size：redo发生的总次数(以及因此写入log buffer)，以byte为单位。这项统计显示出update活跃性。

l
session logical reads：逻辑读请求数。

l
sorts (memory) and sorts (disk)：sorts(memory)是适于在SORT_AREA_SIZE(因此不需要在磁盘进行排序)的排序操作的数量。sorts(disk)则是由于排序所需空间太大，SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算in-memory
sort ratio。

l
sorts (rows): 列排序总数。这项统计可被'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。

l
table fetch by rowid：使用ROWID返回的总列数(由于索引访问或sql语句中使用了'where rowid=&rowid'而产生)

l
table scans (rows gotten)：全表扫描中读取的总列数

l
table scans (blocks gotten)：全表扫描中读取的总块数，不包括那些split的列。

l
user commits + user rollbacks：系统事务起用次数。当需要计算其它统计中每项事务比率时该项可以被做为除数。例如，计算事务中逻辑读，可以使用下列公式：session logical reads / (user commits + user rollbacks)。



[译]其它计数器含义

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.

l DB block gets - This statistic tracks the number of blocks obtained in CURRENT mode.
l Deferred (CURRENT) block cleanout applications- The number of times cleanout records are deferred, piggyback with changes, always current get.
l Dirty buffers inspected
- The number of dirty buffers found by the foreground while the foreground is looking for a buffer to reuse.
l Enqueue conversions - The total number of enqueue converts.
l Enqueue deadlocks - The total number of enqueue deadlocks between different sessions.
l Enqueue releases - The total number of enqueue releases.
l Enqueue requests - The total number of enqueue gets.
l Enqueue timeouts - The total number of enqueue operations (get and convert) that timed out before they could complete.
l Enqueue waits - The total number of waits that happened during an enqueue convert or get because the enqueue could not be granted right away.
l 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.
l 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."
l 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.
l Global cache defers - The number of times a ping request was deferred until later.
l Global cache freelist waits
- The number of pings for free lock elements (when all releasable locks are in use).
l Global lock async converts
- The total number of asynchronous global lock converts.
l Global lock async gets
- The total number of asynchronous global lock gets.
l Global lock convert time
- The total elapsed time of all synchronous (non-asynchronous) global lock converts in 10s of milliseconds.
l Global lock get time
- The total elapsed time of all synchronous (non-asynchronous) global lock gets in 10s of milliseconds.
l Global lock releases
- The total number of synchronous global lock releases.
l Global lock sync converts
- The total number of synchronous global lock converts.
l Global lock sync gets
- The total number of synchronous global lock gets.
l Immediate (CR) block cleanout applications- The number of times cleanout records are applied immediately during CR gets.
l Immediate (CURRENT) block cleanout applications- The number of times cleanout records are applied immediately during current gets.
l 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.
l Kcmgss read SCN without going to DLM- The number of times the kernel casually confirmed the SCN without going to the LM.
l Kcmgss waited for batching
- The number of times the kernel waited on a snapshot SCN.
l 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.
l Next SCNs gotten without going to DLM- The number of SCNs (System Change Numbers) obtained without going to the DLM.
l No work - consistent read gets- The number of times CR gets require no block cleanouts nor rollbacks.
l 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.
l Opened cursors current
- The total number of current open cursors.

l Opens of replaced files
- The total number of files that needed to be reopened because they were no longer in the process file cache.
l Opens requiring cache replacement- The total number of file opens that caused a current file to be closed in the process file cache.
l Parse time CPU - The total CPU time used for parsing (hard and soft) in 10s of milliseconds.
l 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.

l Queries parallelized
- The number of SELECT statements that got parallelized.
l Recovery array read time
- The elapsed time of I/O while doing recovery.
l Recovery array reads - The number of reads performed during recovery.
l Recovery blocks read
- The number of blocks read during recovery.

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