More Related Content Similar to Perfstats (20) More from oracle documents
More from oracle documents (20) Perfstats2. Performance Tuning – Statistic Explanations Page 2
AVERAGE_REDO_ENTRY_SIZE
The average amount of redo in bytes placed INTO the log buffer.
AVERAGE_WRITE_QUEUE _LENGTH
The average number of blocks still on the dirty list after DBWR has completed a
write request.
BACKGROUND_CHECKPOINTS_COMPLETED
The number of checkpoints completed by the background CKPT process.
Incremented when CKPT successfully advances the thread checkpoint.
BACKGROUND_CHECKPOINTS_STARTED
The number of checkpoints started by the background CKPT process. This number
may be larger than background_checkpoints_completed if a new checkpoint
overrides an incomplete checkpoint. This can happen if, for example, a second
log switch occurs before the checkpoint initiated at the previous log switch
manages to finish. This only includes checkpoints of the entire database, not
individual file checkpoints for operations such as offline or begin backup. Does not
include checkpoints performed in the foreground, such as ALTER SYSTEM
CHECKPOINT LOCAL.
BACKGROUND_TIMEOUTS
The number of times a background process has set an alarm for itself and the
alarm has timed out rather than the background process being posted by another
process to do some work.
BYTES_RECEIVED_VIA_SQLNET_FROM_CLIENT
The number of bytes received via SQL*Net from client processes.
BYTES_RECEIVED_VIA_SQLNET_FROM_DBLINK
The number of bytes received over SQL*Net from DB Links
BYTES_SENT_VIA_SQLNET_TO_C1IENT
The number of bytes sent via SQL*Net to the client process.
BYTES_SENT_VIA_SQLNET_TO_DB1INK
The number of bytes sent via SQL*Net to a DB LINK.
CALLS_TO_KCMGAS
The number of calls that Get and Advance the SCN. Also used when getting a Batch
of SCN numbers.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
3. Performance Tuning – Statistic Explanations Page 3
CALLS_TO_KCMGCS
The number of calls to simply get the current SCN.
CALLS_TO_KCMGRS
The number of calls to get a recent SCN.
CHANGE_WRITE _TIME
The amount of time spent waiting for redo buffer space, inserting redo information
into a buffer and allocating an SCN if needed.
CLEANOUTS_AND_ROLLBACKS_CONSISTENT_READ_GETS
The number of Consistent Read gets requiring BOTH block cleanout and subsequent
rollback to get to the required snapshot time.
CLEANOUTS_ONLY_CONSISTENT_READ_GETS
The number of times a Consistent Read get required a block cleanout ONLY and no
application of undo.
CLUSTER_KEY_SCAN_BLOCK_GETS
The number of blocks retrieved in cluster key scan operations.
CLUSTER_KEY_SCANS
The total number of cluster key scans performed.
CONSISTENT_CHANGES
The number of modifications required to produce Consistent Read blocks. This
indicates the number of times a database block has had rollback entries applied, in
order to allow a consistent read on the block to take place. If this number is high,
it indicates that there are a large number of jobs active on the database producing
a large number of consistent changes, and these can be real resource hogs.
CONSISTENT_GETS
The number of logical reads in consistent mode. In other words, how many reads
have we performed from Read Consistent buffers, rather than from Current
buffers.
CPU_USED_BY_THIS_SESSION
The number of centiseconds (that is, 1/100ths of a second) of CPU time used by all
sessions, excluding background processes.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
4. Performance Tuning – Statistic Explanations Page 4
CPU_USED_WHEN_CALL_STARTED
The number of centiseconds of CPU used by all sessions at the time of each
sessions’ last call. Again, this total doesn’t include the background processes.
CR_BLOCKS_CREATED
The number of Read Consistent blocks created in the Database Buffer Cache to
contain a Read Consistent version of another data block.
CURRENT_BLOCKS_CONVERTED_FOR_CR
The number of blocks in the Database Buffer Cache which have been converted to
contain a Read Consistent version of a block.
CURSOR_AUTHENTICATIONS
The number of cursor authentications. A “cursor authentication” is where we
verify cursor privileges, either for a SELECT or because privileges were revoked
from an object, causing all users of the cursor to be re-authenticated.
DATA_BLOCKS_CONSISTENT_READS_UNDO_RECORDS_APPLIED
The number of rollback records we’ve had to apply to generate Read Consistent
versions of Current data blocks. (Oracle often insists on using the term “undo”
when referring to what everyone else knows as “rollback”, hence the statistic
names usually refer to “undo”. Best get used to it.)
DB_BLOCK_CHANGES
The number of changes made to Current data blocks. In other words, the total
number changes made to all blocks in the SGA as a result of a piece of DML.
Accordingly, this statistic is a rough and ready indication of the total load on the
database, and the amount of work being performed on it. It indicates (possibly on
a per transaction level) the rate at which buffers are being dirtied.
DB_BLOCK_GETS
The number of logical reads of Current data blocks (i.e., blocks which don’t need
rollback applied to generate a Read Consistent version –in short, un-dirtied
blocks). Note that this statistic also counts the blocks associated with performing
sorts which have been swapped down to a temporary tablespace.
DBWR_BUFFERS_SCANNED
The number of buffers inspected when scanning the Least Recently Used list for
dirty buffers to make clean. You should divide this number by “dbwr_lru_scans" to
find the average number of buffers scanned. This count includes both dirty and
clean buffers. The average buffers scanned may be different from the average
scan depth due to write batches filling up before a scan is complete. Note that
this includes scans for reasons other than make free buffer requests.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
5. Performance Tuning – Statistic Explanations Page 5
DBWR_CHECKPOINTS
The number of times DBWR is asked to scan the Database Buffer Cache for the
purpose of writing all blocks marked for checkpoint or at the end of recovery.
Note that this is the number of checkpoint messages that were sent to DBWR, not
necessarily the total number of actual checkpoints that took place. During a
checkpoint there is a slight decrease in performance since data blocks are being
written to disk which causes I/0. If the number of checkpoints is reduced, the
performance of normal database operations improve but recovery after instance
failure is slower. DBWR checkpoints is incremented on each call to DBWR to
checkpoint blocks. This happens not only at log switches but also when dropping
objects from the database. In fact a DBWR checkpoint call is made for each
extent in the object being dropped.
DBWR_FLUSH_BLOCK_RANGE
The number of times the DBWR was asked to scan the entire cache to flush a
block-range.
DBWR_FREE_BUFFERS_FOUND
The number of buffers that DBWR found already clean when requested to make
free buffers. You should divide this number by whatever
“dbwr_make_free_request" shows to calculate the average number of reusable
buffers at the end of the LRU list. Note that it is only ‘make free requests’ that
cause this statistic to increment. If the LRU list is scanned for any other reason,
this statistic will remain unchanged.
DBWR_LRU_SCANS
The number of times that DBWR scans the LRU queue looking for more buffers to
write. This includes times when the scan is to fill out a batch being written for
another purpose such as checkpoint.
DBWR_MAKE_FREE_REQUEST
The number of messages received requesting DBWR to free up some space in the
Database Buffer Cache. This includes times when DBWR messages itself.
DBWR_SUMMED_SCAN_DEPTH
The current scan depth is added to this statistic every time DBWR scans the LRU
list for dirty buffers. You should divide by "dbwr_lru_scans" to find the average
scan depth. Note that this is not the number of buffers scanned. The scan is
reduced by buffers moved to the dirty queue by foregrounds, and may stop early if
a full write batch is accumulated.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
6. Performance Tuning – Statistic Explanations Page 6
DBWR_TIMEOUTS
The number of timeouts when DBWR had been idle since the last timeout. These
are the times that DBWR looked for buffers to idle write. The statistic is really
meaningless and of no significance, UNLESS it is very low –that would indicates
that DBWR is being posted very frequently, and therefore not having much idle
time.
DEFERRED_CURRENT_BLOCK_CLEANOUT_APPLICATIONS
The number of times cleanout records are deferred. Deferred changes are
piggybacked with real changes.
DIRTY_BUFFERS_INSPECTED
The number of times a foreground encountered a dirty buffer which had aged out
through the LRU list, when foreground is looking for a buffer to reuse. T his should
be zero if DBWR is keeping up with the rate at which Users are dirtying buffers.
ENQUEUE_CONVERSIONS
The number of enqueue conversions - e.g., from shared to exclusive mode.
ENQUEUE_DEADLOCKS
The number of enqueue deadlocks detected and signaled.
ENQUEUE_RELEASES
The number of enqueue release operations. This should always be less than or
equal to “enqueue_requests” (and it would be mighty peculiar if it ever wasn’t!).
ENQUEUE_REQUESTS
The number of enqueue requests. For example, a request for a transaction (TX)
lock would increment this statistic.
ENQUEUE_TIMEOUTS
The number of timeouts occurring when trying to acquire an enqueue (lock).
Enqueues are used to control access to a number of resources. The type of
enqueue that the timeout occurs for is important. For example, an ORA-2049 error
waiting for a TX enqueue in a distributed transaction would increment this
statistic. On the other hand, an ORA-54 (resource busy and acquire with NOWAIT
specified) does NOT increment this statistic, as it is not a timeout.
ENQUEUE_WAITS
The number of times that an enqueue request resulted in a wait. This includes
waits on TX enqueues, so if there are high values here, it might suggest that the
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
7. Performance Tuning – Statistic Explanations Page 7
application has particular areas of high concurrent access, and hence lock
contention.
EXCHANGE _DEADLOCKS
The number of times that a process detected potential deadlock when exchanging
two buffers and therefore raised an internal, re-startable error. Index scans are
currently the only operation which perform exchanges.
EXECUTE_COUNT
The total number of execute calls.
FREE_BUFFER_INSPECTED
The number of buffers skipped over from the end of the LRU list in order to find a
free buffer. The difference between this and "dirty_buffers_inspected" is that we
may inspect a buffer but be unable to use it because it was busy, or needed to be
written after rapid aging out.
FREE_BUFFER_REQUESTED
The number of times a free buffer was requested in order to create or load a
block.
GLOBAL_LOCK_CONVERT_TIME
The time spent waiting for a lock convert to complete.
GLOBAL_LOCK_CONVERTS_ASYNC
The number of asynchronous global lock convert requests. An “async lock
convert” queues a request and the name of the handler functions to use on
conversion/release of the lock.
GLOBAL_LOCK_CONVERTS_NON_ASYNC
The number of synchronous global lock conversion requests.
GLOBAL_LOCK_GET_TIME
The time spent waiting for a lock get to complete.
GLOBAL_LOCK_GETS_ASYNC
The number of asynchronous global lock gets. An “async lock get” queues a lock
request and the name of the handler functions to use on get/release of the lock.
GLOBAL_LOCK-GETS-NON-ASYNC
The number of synchronous global lock gets.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
8. Performance Tuning – Statistic Explanations Page 8
GLOBAL_LOCK_RELEASE_TIME
Total time spent waiting for a lock release to complete.
GLOBAL_LOCK_RELEASES_ASYNC
The number of asynchronous global lock releases.
GLOBAL_LOCK_RELEASES_NON_ASYNC
Number of synchronous global lock releases.
HASH_LATCH_WAIT_GETS
The number of times latches had to be obtained using waits rather than no -wait
gets.
IMMEDIATE_CR_BLOCK_CLEANOUT_APPLICATIONS
The number of block cleanout applications applied immediately during a Read
Consistent get of a block.
IMMEDIATE_CURRENT_BLOCK_CLEANOUT_APPLICATIONS
The number of block cleanout applications applied immediately to a Current get of
a data block.
LOGONS_CUMULATIVE
The number of logons since the Instance was started. In a Bstat/Estat report, this
is actually the number of logons during the monitoring period. This is a good one
to check to see if the Instance was bounced during the Bstat/Estat monitoring
period, because if it was bounced, you’ll get a negative number here –and quite
clearly, you can’t possibly get a negative number of logons by Users!
LOGONS_CURRENT
The current number of logons. Pretty meaningless in a Bstat/Estat report, since
that’s produced over a given period of time –so what does “current” mean then??
MESSAGES_RECEIVED
The number of messages received. A message is sent when one Oracle process
wants to prod another into performing some action.
MESSAGES_SENT
The number of messages sent between Oracle processes.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
9. Performance Tuning – Statistic Explanations Page 9
NO_WORK_CONSISTENT_READ_GETS
The number of Read Consistent gets satisfied without having to apply undo to roll
a block back to the snapshot time. If a User rolls back his own transaction, for
example, then the data block will have a new timestamp, and will accordingly
provoke the creation of a Read Consistent version of the block –but since the data
itself is already consistent, the reader’s Server process will not need to apply
rollback in order to generate the read consistent image of the data.
OPENED_CURSORS_CUMULATIVE
The total number of cursors opened. This includes cursors which are opened and
then parse an invalid SQL statement. A cursor is opened for each SQL statement
which is parsed into a context area. Performance is improved if cursors are reused,
because the SQL statements will be not need to be re-parsed. If a cursor will not
be reused, it is best to close the cursor when the SQL statement completes. Tr y to
reduce the number of cursors opened per transaction as opposed to the total
number opened on the system.
OPENED_CURSORS_CURRENT
The number of currently open cursors.
PARSE_COUNT
The number of distinct parse calls to Oracle.
PARSE_TIME _CPU
The total CPU time spent in parse operations.
PARSE_TIME _ELAPSED
The elapsed time for parse calls.
PHYSICAL_READS
The number of data blocks read from disk. Each block read from disk is a buffer
cache miss –in other words, the data wasn’t already in memory, so we had to fetch
it off disk for ourselves.
PHYSICAL_WRITES
The number of data blocks written to the disk by DBWR. Note that if sorts need to
be swapped to disk, because you’ve run out space in the PGA, then this statistic
will NOT count such writes if direct writes are enabled. Direct writes are enabled
automatically in 8i. In earlier versions, it depended on the SORT_DIRECT_WRITES
parameter. In either case, such writes are NOT included in the “physical_writes”
count.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
10. Performance Tuning – Statistic Explanations Page 10
PROCESS_LAST_NON_IDLE_TIME
The last time this process was not idle. This is the time from a platform -
dependent epoch.
RECURSIVE_CALLS
The number of 'recursive' calls occurring.
RECURSIVE_CPU_USAGE
The amount of CPU used in recursive calls. A recursive call is basically a piece of
SQL that has to be issued internally in order to satisfy a User’s SQL statement (for
example, an Insert request by a User may trigger the acquisition of a new extent
for the relevant table, and that new extent is recorded (in dictionary managed
tablespace at least) by a number of inserts and deletes on various data dictionary
tables. Those ‘secondary’ inserts and deletes are recursive SQL calls).
REDO_BLOCKS_WRITTEN
The total number of redo blocks written. A redo block is the size of a single OS
block, which is obviously platform-dependent.
REDO_BUFFER_ALLOCATION_RETRIES
The total number of retries necessary to allocate space in the redo buffer. Retries
will be needed if LGWR wants to reuse a part of the Log Buffer which has not
successfully been flushed yet (i.e., it’s caught up on itself), or because the online
Redo Logs are too busy (perhaps because, for example, a log switch is taking
place). A high number here might indicate that your Log Buffer is too small, or
that your redo logs are housed on suspiciously slow (or busy) hardware.
REDO_ENTRIES
The total number of redo entries generated.
REDO_LOG_SPACE_REQUESTS
Number of times that LGWR was requested to allocate space in the redo file. This
gives an indication of how many times a user process waited for space in the redo
logs.
REDO_LOG_SPACE_WAIT_TIME
The amount of time spent waiting for space in the redo log to become available
(measured, as ever, in centiseconds).
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
11. Performance Tuning – Statistic Explanations Page 11
REDO_LOG_SWITCH_INTERRUPTS
The number of times that other Instances asked us to advance to the next log. In a
parallel server environment, idle Instances will ask to switch logs to prevent long
recovery periods in the event of a crash.
REDO_SIZE
The total amount of redo generated, in bytes, and written into the Log Buffer.
This does not reflect directly the number of redo records written, because it
excludes wastage (see below)
REDO_SMALL_COPIES
In the init.ora, there is a parameter LOG_SMALL_ENTRY_MAX_SIZE, measured in
bytes. That determines the maximum size b elow which a redo entry will be
considered “small”. Small entries are copied using the redo allocation latch,
rather than the redo copy latch (which is inherently faster, because there is less
house-keeping overhead). This statistic counts the total number of such “small”
writes. Incidentally, this is only of relevance on multi-processor systems.
REDO_SYNCH_TIME
The time taken to do redo synch calls, measured in the usual centiseconds.
REDO_SYNCH_WRITES
The number of times that the contents of the Log Buffer are flushed to disk. This
will happen for a variety of reasons (such as a commit being issued, the Log Buffer
becoming one third full, more than 1Mb of unflushed redo being detected, or
because DBWR decides for its own reasons to flush to datafiles).
REDO_WASTAGE
The number of bytes "wasted" because redo blocks need to be written before they
are completely full. In other words, User B may be writing redo into the Log
Buffer when User A issues a commit. That will immediately cause a LGWR flush to
the Redo Logs, and the redo buffer that User B was using will be flushed as-is –
even if it’s only partially full. The remainder of User B’s redo will be placed
within a completely fresh redo buffer.
REDO_WRITE _TIME
The total amount of time taken to write the amount of Redo indicated by the
“redo_blocks_written” statistic.
REDO_WRITER_LATCHING _TIME
The time needed to obtain and release each copy latch. This is only used if
LOG_SIMULTANEOUS_COPIES in the init.ora is greater than zero.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
12. Performance Tuning – Statistic Explanations Page 12
REDO_WRITES
The total number of times that LGWR is forced to flush the Log Buffer.
REMOTE_INSTANCE_UNDO_REQUESTS
In a parallel server environment, this is the number of times the current Instance
had to retrieve rollback from a different Instance in order to generate Read
Consistent versions of a local data block.
REMOTE_INSTANCE_UNDO_WRITES
Again only of a relevance in a parallel server environment, this is the number of
times the current Instance has been required to write a dirty rollback block to disk
so that a different Instance could read it (presumably so it can generate Read
Consistent images of data of its own).
ROLLBACK_CHANGES_UNDO_RECORDS_APPLIED
The number of rollback records applied to blocks as a result of Users issuing a
genuine rollback command. In other words, this statistic does not record the
technical sort of rollback that occurs when generating read consistent images of
data. However, PMON rolling a transaction back because a User has suffered an
abnormal disconnection does increment this statistic. A high number here would
indicate that either your Users can’t make up their minds, are unusually
experimental, or are running Windows 95 clients (i.e., are prone to crashing!).
ROLLBACKS_ONLY_CONSISTENT_READ_GETS
The number of Read Consistent operations requiring rollback to be applied, but no
block cleanout.
SESSION_CURSOR_CACHE_COUNT
The number of cached cursors.
SESSION_CURSOR_CACHE_HITS
The number of hits in the session cursor cache
SESSION_CONNECT_TIME
A number representing the time when the session connected to the server. The
unit of measure is now seconds.
SESSION_LOGICAL_READS
The number of logical reads for the current session (i.e., reads of data from blocks
in the Database Buffer Cache).
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
13. Performance Tuning – Statistic Explanations Page 13
SESSION_PGA_MEMORY
Current PGA memory size for a session (in bytes).
SESSION_PGA_MEMORY_MAX
The peak PGA size (in bytes). Remember that if you set SORT_AREA_SIZE for a
session to, say, 1Mb, the PGA will not start off at 1Mb. It will grow to become 1Mb
maximum as sorts take place, and shrink again (to SORT_AREA_RETAINED_SIZE)
when the sort has finished. If no sort requires the full 1Mb, then the PGA could
conceivably never actually reach SORT_AREA_SIZE. This statistic shows how big it
has actually ever got (remember, it’s session-specific).
SESSION_STORED_PROCEDURE-SPACE
The number of bytes allocated to store procedures used in the session.
SESSION_UGA_MEMORY
The size of the UGA for this session (in bytes).
SESSION_UGA_MEMORY_MAX
The maximum size to which this session’s UGA has e ver reached (in bytes).
SORTS_DISK
The number of sort operations that had to be swapped out to disk because the PGA
ran out of space. A high number might indicate increasing SORT_AREA_SIZE, or
perhaps moving to multi-threaded server configuration if that would be too
expensive on available memory.
SORTS_MEMORY
The number of sorts performed entirely in memory (which is faster than swapping
them down to disk). A high number here is an unequivocally “good thing”!
SORTS_ROWS
The total number of rows sorted. (I suppose the idea is that you take sorts_disk +
sorts_memory and divide by this statistic to find out the average size of your sorts.
A large number of large sorts might indicate application tuning opportunities, or
DBA opportunities for, for example, implementing IOTs or clusters).
SQLNET_ROUNDTRIPS_TO_FROM_CLIENT
SQL*Net is a half duplex protocol (except for break conditions) where only one side
of the connection is expected to be reading from the other at any one time. Or,
to put it another way, it is synchronous. This is the number of round-trips.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
14. Performance Tuning – Statistic Explanations Page 14
SQLNET_ROUNDTRIPS_TO_FROM_DBLINK
The number of complete round-trips to and from DB links.
SUMMED_DIRTY_QUEUE_LENGTH
The sum of the LRU queue length after every write request completes. You s hould
divide by the number of write requests to get average queue length after write
completion.
TABLE_FETCH_BY_ROWID
The number of rows retrieved using a fetch by rowid. This would include rows
that were accessed via an index, as well as rows that were accessed using a
specific ‘Select * where rowid = X.X.X.X’ Fetches by rowid are the fastest way to
retrieve data, so a high number here is a “good thing”.
TABLE_FETCH_CONTINUED_ROW
Indicates the sum of the migrated *and* chained rows. A full table scan only
increments this value when it encounters chained rows. Migration is caused by
updates (and hence updates can increment this value if they provoke a migration).
TABLE_SCAN_BLOCKS_RETRIEVED
The number of data blocks retrieved as a result of performing a table scan, not
including those for chained rows. A high number might indicate a lack of indexes,
or a badly-written application.
TABLE_SCAN_ROWS_RETRIEVED
The total number of rows retrieved during table scans of any kind.
TABLE_SCANS_DIRECT_READ
The number of direct read table scans. Direct reads do *NOT* get put into the
buffer cache.
TABLE_SCANS_LONG_TABLES
This is the number of full table scans performed on tables that are not "short" and
are not cached. A short table is one with a High Water Mark equal to or smaller
than the SMALL_TABLE_THRESHOLD init.ora parameter. A non-cached table is one
where the CACHE clause has not been used.
TABLE_SCANS_ROWID_RANGES
The number of table scans performed that used a ROWID range scan. Such scans
are used by Parallel Query operations.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
15. Performance Tuning – Statistic Explanations Page 15
TABLE_SCANS_SHORT_TABLES
This is the number of full table scans performed on "short" (or "cached") tables.
(see “table_scans_long_tables” for definitions of short and cached tables).
TRANSACTION_LOCK_BACKGROUND_GET_TIME
The time a background process spends waiting to acquire a transaction instance
lock (measured in centiseconds).
TRANSACTION_LOCK_FOREGROUND_WAIT_TIME
The time a foreground (i.e., Client) process spends waiting to acquire a
transaction instance lock.
TRANSACTION_ROLLBACKS
The number of genuine rollbacks issued that involved undoing real changes. This
might not be the same number as “user_rollbacks” (see below), because it is
possible to issue a rollback command and have nothing happen (after a commit,
for example). Such a rollback command would increment “user_rollbacks”, and
not increment “transaction_rollbacks”. A big difference between the two suggests
Users making large numbers of mistakes, and thus requiring further application
training!!
USER_COMMITS
The number of times Users issue “commit” statements, provided such statements
are meaningful. In other words, this statistic is incremented each time a real,
active transaction is committed; but if a User just sits there typing the word
‘commit’ repeatedly, the statistic is not incremented.
USER_ROLLBACKS
The number of times Users issue “rollback” statements. This is incremented for
each rollback command, even if there is nothing to roll back. (And you may well
ask why “user_commits” ignores spurious commit requests, but “user_rollbacks”
does not ignore spurious rollback requests… Who can say? That’s Oracle for you).
WRITE_REQUESTS
The number of multi-block writes. A multi-block write occurs when DBWR collects
an entire batch of dirty buffers off the dirty list, and flushes them all down to disk
in one almighty write.
Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01