Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Performance Tuning: Statistic Explanations by Howard J. Rogers © HOWARD J. ROGERS 2001
  2. 2. Performance Tuning – Statistic Explanations Page 2AVERAGE_REDO_ENTRY_SIZEThe average amount of redo in bytes placed INTO the log buffer.AVERAGE_WRITE_QUEUE _LENGTHThe average number of blocks still on the dirty list after DBWR has completed awrite request.BACKGROUND_CHECKPOINTS_COMPLETEDThe number of checkpoints completed by the background CKPT process.Incremented when CKPT successfully advances the thread checkpoint.BACKGROUND_CHECKPOINTS_STARTEDThe number of checkpoints started by the background CKPT process. This numbermay be larger than background_checkpoints_completed if a new checkpointoverrides an incomplete checkpoint. This can happen if, for example, a secondlog switch occurs before the checkpoint initiated at the previous log switchmanages to finish. This only includes checkpoints of the entire database, notindividual file checkpoints for operations such as offline or begin backup. Does notinclude checkpoints performed in the foreground, such as ALTER SYSTEMCHECKPOINT LOCAL.BACKGROUND_TIMEOUTSThe number of times a background process has set an alarm for itself and thealarm has timed out rather than the background process being posted by anotherprocess to do some work.BYTES_RECEIVED_VIA_SQLNET_FROM_CLIENTThe number of bytes received via SQL*Net from client processes.BYTES_RECEIVED_VIA_SQLNET_FROM_DBLINKThe number of bytes received over SQL*Net from DB LinksBYTES_SENT_VIA_SQLNET_TO_C1IENTThe number of bytes sent via SQL*Net to the client process.BYTES_SENT_VIA_SQLNET_TO_DB1INKThe number of bytes sent via SQL*Net to a DB LINK.CALLS_TO_KCMGASThe number of calls that Get and Advance the SCN. Also used when getting a Batchof SCN numbers.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  3. 3. Performance Tuning – Statistic Explanations Page 3CALLS_TO_KCMGCSThe number of calls to simply get the current SCN.CALLS_TO_KCMGRSThe number of calls to get a recent SCN.CHANGE_WRITE _TIMEThe amount of time spent waiting for redo buffer space, inserting redo informationinto a buffer and allocating an SCN if needed.CLEANOUTS_AND_ROLLBACKS_CONSISTENT_READ_GETSThe number of Consistent Read gets requiring BOTH block cleanout and subsequentrollback to get to the required snapshot time.CLEANOUTS_ONLY_CONSISTENT_READ_GETSThe number of times a Consistent Read get required a block cleanout ONLY and noapplication of undo.CLUSTER_KEY_SCAN_BLOCK_GETSThe number of blocks retrieved in cluster key scan operations.CLUSTER_KEY_SCANSThe total number of cluster key scans performed.CONSISTENT_CHANGESThe number of modifications required to produce Consistent Read blocks. Thisindicates the number of times a database block has had rollback entries applied, inorder 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 producinga large number of consistent changes, and these can be real resource hogs.CONSISTENT_GETSThe number of logical reads in consistent mode. In other words, how many readshave we performed from Read Consistent buffers, rather than from Currentbuffers.CPU_USED_BY_THIS_SESSIONThe number of centiseconds (that is, 1/100ths of a second) of CPU time used by allsessions, excluding background processes.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  4. 4. Performance Tuning – Statistic Explanations Page 4CPU_USED_WHEN_CALL_STARTEDThe number of centiseconds of CPU used by all sessions at the time of eachsessions’ last call. Again, this total doesn’t include the background processes.CR_BLOCKS_CREATEDThe number of Read Consistent blocks created in the Database Buffer Cache tocontain a Read Consistent version of another data block.CURRENT_BLOCKS_CONVERTED_FOR_CRThe number of blocks in the Database Buffer Cache which have been converted tocontain a Read Consistent version of a block.CURSOR_AUTHENTICATIONSThe number of cursor authentications. A “cursor authentication” is where weverify cursor privileges, either for a SELECT or because privileges were revokedfrom an object, causing all users of the cursor to be re-authenticated.DATA_BLOCKS_CONSISTENT_READS_UNDO_RECORDS_APPLIEDThe number of rollback records we’ve had to apply to generate Read Consistentversions of Current data blocks. (Oracle often insists on using the term “undo”when referring to what everyone else knows as “rollback”, hence the statisticnames usually refer to “undo”. Best get used to it.)DB_BLOCK_CHANGESThe number of changes made to Current data blocks. In other words, the totalnumber 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 thedatabase, and the amount of work being performed on it. It indicates (possibly ona per transaction level) the rate at which buffers are being dirtied.DB_BLOCK_GETSThe number of logical reads of Current data blocks (i.e., blocks which don’t needrollback applied to generate a Read Consistent version –in short, un-dirtiedblocks). Note that this statistic also counts the blocks associated with performingsorts which have been swapped down to a temporary tablespace.DBWR_BUFFERS_SCANNEDThe number of buffers inspected when scanning the Least Recently Used list fordirty buffers to make clean. You should divide this number by “dbwr_lru_scans" tofind the average number of buffers scanned. This count includes both dirty andclean buffers. The average buffers scanned may be different from the averagescan depth due to write batches filling up before a scan is complete. Note thatthis includes scans for reasons other than make free buffer requests.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  5. 5. Performance Tuning – Statistic Explanations Page 5DBWR_CHECKPOINTSThe number of times DBWR is asked to scan the Database Buffer Cache for thepurpose 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, notnecessarily the total number of actual checkpoints that took place. During acheckpoint there is a slight decrease in performance since data blocks are beingwritten to disk which causes I/0. If the number of checkpoints is reduced, theperformance of normal database operations improve but recovery after instancefailure is slower. DBWR checkpoints is incremented on each call to DBWR tocheckpoint blocks. This happens not only at log switches but also when droppingobjects from the database. In fact a DBWR checkpoint call is made for eachextent in the object being dropped.DBWR_FLUSH_BLOCK_RANGEThe number of times the DBWR was asked to scan the entire cache to flush ablock-range.DBWR_FREE_BUFFERS_FOUNDThe number of buffers that DBWR found already clean when requested to makefree buffers. You should divide this number by whatever“dbwr_make_free_request" shows to calculate the average number of reusablebuffers at the end of the LRU list. Note that it is only ‘make free requests’ thatcause this statistic to increment. If the LRU list is scanned for any other reason,this statistic will remain unchanged.DBWR_LRU_SCANSThe number of times that DBWR scans the LRU queue looking for more buffers towrite. This includes times when the scan is to fill out a batch being written foranother purpose such as checkpoint.DBWR_MAKE_FREE_REQUESTThe number of messages received requesting DBWR to free up some space in theDatabase Buffer Cache. This includes times when DBWR messages itself.DBWR_SUMMED_SCAN_DEPTHThe current scan depth is added to this statistic every time DBWR scans the LRUlist for dirty buffers. You should divide by "dbwr_lru_scans" to find the averagescan depth. Note that this is not the number of buffers scanned. The scan isreduced by buffers moved to the dirty queue by foregrounds, and may stop early ifa full write batch is accumulated.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  6. 6. Performance Tuning – Statistic Explanations Page 6DBWR_TIMEOUTSThe number of timeouts when DBWR had been idle since the last timeout. Theseare the times that DBWR looked for buffers to idle write. The statistic is reallymeaningless and of no significance, UNLESS it is very low –that would indicatesthat DBWR is being posted very frequently, and therefore not having much idletime.DEFERRED_CURRENT_BLOCK_CLEANOUT_APPLICATIONSThe number of times cleanout records are deferred. Deferred changes arepiggybacked with real changes.DIRTY_BUFFERS_INSPECTEDThe number of times a foreground encountered a dirty buffer which had aged outthrough the LRU list, when foreground is looking for a buffer to reuse. T his shouldbe zero if DBWR is keeping up with the rate at which Users are dirtying buffers.ENQUEUE_CONVERSIONSThe number of enqueue conversions - e.g., from shared to exclusive mode.ENQUEUE_DEADLOCKSThe number of enqueue deadlocks detected and signaled.ENQUEUE_RELEASESThe number of enqueue release operations. This should always be less than orequal to “enqueue_requests” (and it would be mighty peculiar if it ever wasn’t!).ENQUEUE_REQUESTSThe number of enqueue requests. For example, a request for a transaction (TX)lock would increment this statistic.ENQUEUE_TIMEOUTSThe number of timeouts occurring when trying to acquire an enqueue (lock).Enqueues are used to control access to a number of resources. The type ofenqueue that the timeout occurs for is important. For example, an ORA-2049 errorwaiting for a TX enqueue in a distributed transaction would increment thisstatistic. On the other hand, an ORA-54 (resource busy and acquire with NOWAITspecified) does NOT increment this statistic, as it is not a timeout.ENQUEUE_WAITSThe number of times that an enqueue request resulted in a wait. This includeswaits on TX enqueues, so if there are high values here, it might suggest that theCopyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  7. 7. Performance Tuning – Statistic Explanations Page 7application has particular areas of high concurrent access, and hence lockcontention.EXCHANGE _DEADLOCKSThe number of times that a process detected potential deadlock when exchangingtwo buffers and therefore raised an internal, re-startable error. Index scans arecurrently the only operation which perform exchanges.EXECUTE_COUNTThe total number of execute calls.FREE_BUFFER_INSPECTEDThe number of buffers skipped over from the end of the LRU list in order to find afree buffer. The difference between this and "dirty_buffers_inspected" is that wemay inspect a buffer but be unable to use it because it was busy, or needed to bewritten after rapid aging out.FREE_BUFFER_REQUESTEDThe number of times a free buffer was requested in order to create or load ablock.GLOBAL_LOCK_CONVERT_TIMEThe time spent waiting for a lock convert to complete.GLOBAL_LOCK_CONVERTS_ASYNCThe number of asynchronous global lock convert requests. An “async lockconvert” queues a request and the name of the handler functions to use onconversion/release of the lock.GLOBAL_LOCK_CONVERTS_NON_ASYNCThe number of synchronous global lock conversion requests.GLOBAL_LOCK_GET_TIMEThe time spent waiting for a lock get to complete.GLOBAL_LOCK_GETS_ASYNCThe number of asynchronous global lock gets. An “async lock get” queues a lockrequest and the name of the handler functions to use on get/release of the lock.GLOBAL_LOCK-GETS-NON-ASYNCThe number of synchronous global lock gets.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  8. 8. Performance Tuning – Statistic Explanations Page 8GLOBAL_LOCK_RELEASE_TIMETotal time spent waiting for a lock release to complete.GLOBAL_LOCK_RELEASES_ASYNCThe number of asynchronous global lock releases.GLOBAL_LOCK_RELEASES_NON_ASYNCNumber of synchronous global lock releases.HASH_LATCH_WAIT_GETSThe number of times latches had to be obtained using waits rather than no -waitgets.IMMEDIATE_CR_BLOCK_CLEANOUT_APPLICATIONSThe number of block cleanout applications applied immediately during a ReadConsistent get of a block.IMMEDIATE_CURRENT_BLOCK_CLEANOUT_APPLICATIONSThe number of block cleanout applications applied immediately to a Current get ofa data block.LOGONS_CUMULATIVEThe number of logons since the Instance was started. In a Bstat/Estat report, thisis actually the number of logons during the monitoring period. This is a good oneto check to see if the Instance was bounced during the Bstat/Estat monitoringperiod, because if it was bounced, you’ll get a negative number here –and quiteclearly, you can’t possibly get a negative number of logons by Users!LOGONS_CURRENTThe current number of logons. Pretty meaningless in a Bstat/Estat report, sincethat’s produced over a given period of time –so what does “current” mean then??MESSAGES_RECEIVEDThe number of messages received. A message is sent when one Oracle processwants to prod another into performing some action.MESSAGES_SENTThe number of messages sent between Oracle processes.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  9. 9. Performance Tuning – Statistic Explanations Page 9NO_WORK_CONSISTENT_READ_GETSThe number of Read Consistent gets satisfied without having to apply undo to rolla block back to the snapshot time. If a User rolls back his own transaction, forexample, then the data block will have a new timestamp, and will accordinglyprovoke the creation of a Read Consistent version of the block –but since the dataitself is already consistent, the reader’s Server process will not need to applyrollback in order to generate the read consistent image of the data.OPENED_CURSORS_CUMULATIVEThe total number of cursors opened. This includes cursors which are opened andthen parse an invalid SQL statement. A cursor is opened for each SQL statementwhich 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 notbe reused, it is best to close the cursor when the SQL statement completes. Tr y toreduce the number of cursors opened per transaction as opposed to the totalnumber opened on the system.OPENED_CURSORS_CURRENTThe number of currently open cursors.PARSE_COUNTThe number of distinct parse calls to Oracle.PARSE_TIME _CPUThe total CPU time spent in parse operations.PARSE_TIME _ELAPSEDThe elapsed time for parse calls.PHYSICAL_READSThe number of data blocks read from disk. Each block read from disk is a buffercache miss –in other words, the data wasn’t already in memory, so we had to fetchit off disk for ourselves.PHYSICAL_WRITESThe number of data blocks written to the disk by DBWR. Note that if sorts need tobe swapped to disk, because you’ve run out space in the PGA, then this statisticwill NOT count such writes if direct writes are enabled. Direct writes are enabledautomatically in 8i. In earlier versions, it depended on the SORT_DIRECT_WRITESparameter. 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. 10. Performance Tuning – Statistic Explanations Page 10PROCESS_LAST_NON_IDLE_TIMEThe last time this process was not idle. This is the time from a platform -dependent epoch.RECURSIVE_CALLSThe number of recursive calls occurring.RECURSIVE_CPU_USAGEThe amount of CPU used in recursive calls. A recursive call is basically a piece ofSQL that has to be issued internally in order to satisfy a User’s SQL statement (forexample, an Insert request by a User may trigger the acquisition of a new extentfor the relevant table, and that new extent is recorded (in dictionary managedtablespace at least) by a number of inserts and deletes on various data dictionarytables. Those ‘secondary’ inserts and deletes are recursive SQL calls).REDO_BLOCKS_WRITTENThe total number of redo blocks written. A redo block is the size of a single OSblock, which is obviously platform-dependent.REDO_BUFFER_ALLOCATION_RETRIESThe total number of retries necessary to allocate space in the redo buffer. Retrieswill be needed if LGWR wants to reuse a part of the Log Buffer which has notsuccessfully been flushed yet (i.e., it’s caught up on itself), or because the onlineRedo Logs are too busy (perhaps because, for example, a log switch is takingplace). A high number here might indicate that your Log Buffer is too small, orthat your redo logs are housed on suspiciously slow (or busy) hardware.REDO_ENTRIESThe total number of redo entries generated.REDO_LOG_SPACE_REQUESTSNumber of times that LGWR was requested to allocate space in the redo file. Thisgives an indication of how many times a user process waited for space in the redologs.REDO_LOG_SPACE_WAIT_TIMEThe 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. 11. Performance Tuning – Statistic Explanations Page 11REDO_LOG_SWITCH_INTERRUPTSThe number of times that other Instances asked us to advance to the next log. In aparallel server environment, idle Instances will ask to switch logs to prevent longrecovery periods in the event of a crash.REDO_SIZEThe 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 itexcludes wastage (see below)REDO_SMALL_COPIESIn the init.ora, there is a parameter LOG_SMALL_ENTRY_MAX_SIZE, measured inbytes. That determines the maximum size b elow which a redo entry will beconsidered “small”. Small entries are copied using the redo allocation latch,rather than the redo copy latch (which is inherently faster, because there is lesshouse-keeping overhead). This statistic counts the total number of such “small”writes. Incidentally, this is only of relevance on multi-processor systems.REDO_SYNCH_TIMEThe time taken to do redo synch calls, measured in the usual centiseconds.REDO_SYNCH_WRITESThe number of times that the contents of the Log Buffer are flushed to disk. Thiswill happen for a variety of reasons (such as a commit being issued, the Log Bufferbecoming one third full, more than 1Mb of unflushed redo being detected, orbecause DBWR decides for its own reasons to flush to datafiles).REDO_WASTAGEThe number of bytes "wasted" because redo blocks need to be written before theyare completely full. In other words, User B may be writing redo into the LogBuffer when User A issues a commit. That will immediately cause a LGWR flush tothe 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 placedwithin a completely fresh redo buffer.REDO_WRITE _TIMEThe total amount of time taken to write the amount of Redo indicated by the“redo_blocks_written” statistic.REDO_WRITER_LATCHING _TIMEThe time needed to obtain and release each copy latch. This is only used ifLOG_SIMULTANEOUS_COPIES in the init.ora is greater than zero.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  12. 12. Performance Tuning – Statistic Explanations Page 12REDO_WRITESThe total number of times that LGWR is forced to flush the Log Buffer.REMOTE_INSTANCE_UNDO_REQUESTSIn a parallel server environment, this is the number of times the current Instancehad to retrieve rollback from a different Instance in order to generate ReadConsistent versions of a local data block.REMOTE_INSTANCE_UNDO_WRITESAgain only of a relevance in a parallel server environment, this is the number oftimes the current Instance has been required to write a dirty rollback block to diskso that a different Instance could read it (presumably so it can generate ReadConsistent images of data of its own).ROLLBACK_CHANGES_UNDO_RECORDS_APPLIEDThe number of rollback records applied to blocks as a result of Users issuing agenuine rollback command. In other words, this statistic does not record thetechnical sort of rollback that occurs when generating read consistent images ofdata. However, PMON rolling a transaction back because a User has suffered anabnormal disconnection does increment this statistic. A high number here wouldindicate that either your Users can’t make up their minds, are unusuallyexperimental, or are running Windows 95 clients (i.e., are prone to crashing!).ROLLBACKS_ONLY_CONSISTENT_READ_GETSThe number of Read Consistent operations requiring rollback to be applied, but noblock cleanout.SESSION_CURSOR_CACHE_COUNTThe number of cached cursors.SESSION_CURSOR_CACHE_HITSThe number of hits in the session cursor cacheSESSION_CONNECT_TIMEA number representing the time when the session connected to the server. Theunit of measure is now seconds.SESSION_LOGICAL_READSThe number of logical reads for the current session (i.e., reads of data from blocksin the Database Buffer Cache).Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  13. 13. Performance Tuning – Statistic Explanations Page 13SESSION_PGA_MEMORYCurrent PGA memory size for a session (in bytes).SESSION_PGA_MEMORY_MAXThe peak PGA size (in bytes). Remember that if you set SORT_AREA_SIZE for asession to, say, 1Mb, the PGA will not start off at 1Mb. It will grow to become 1Mbmaximum 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 couldconceivably never actually reach SORT_AREA_SIZE. This statistic shows how big ithas actually ever got (remember, it’s session-specific).SESSION_STORED_PROCEDURE-SPACEThe number of bytes allocated to store procedures used in the session.SESSION_UGA_MEMORYThe size of the UGA for this session (in bytes).SESSION_UGA_MEMORY_MAXThe maximum size to which this session’s UGA has e ver reached (in bytes).SORTS_DISKThe number of sort operations that had to be swapped out to disk because the PGAran out of space. A high number might indicate increasing SORT_AREA_SIZE, orperhaps moving to multi-threaded server configuration if that would be tooexpensive on available memory.SORTS_MEMORYThe number of sorts performed entirely in memory (which is faster than swappingthem down to disk). A high number here is an unequivocally “good thing”!SORTS_ROWSThe 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, orDBA opportunities for, for example, implementing IOTs or clusters).SQLNET_ROUNDTRIPS_TO_FROM_CLIENTSQL*Net is a half duplex protocol (except for break conditions) where only one sideof 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. 14. Performance Tuning – Statistic Explanations Page 14SQLNET_ROUNDTRIPS_TO_FROM_DBLINKThe number of complete round-trips to and from DB links.SUMMED_DIRTY_QUEUE_LENGTHThe sum of the LRU queue length after every write request completes. You s houlddivide by the number of write requests to get average queue length after writecompletion.TABLE_FETCH_BY_ROWIDThe number of rows retrieved using a fetch by rowid. This would include rowsthat were accessed via an index, as well as rows that were accessed using aspecific ‘Select * where rowid = X.X.X.X’ Fetches by rowid are the fastest way toretrieve data, so a high number here is a “good thing”.TABLE_FETCH_CONTINUED_ROWIndicates the sum of the migrated *and* chained rows. A full table scan onlyincrements this value when it encounters chained rows. Migration is caused byupdates (and hence updates can increment this value if they provoke a migration).TABLE_SCAN_BLOCKS_RETRIEVEDThe number of data blocks retrieved as a result of performing a table scan, notincluding those for chained rows. A high number might indicate a lack of indexes,or a badly-written application.TABLE_SCAN_ROWS_RETRIEVEDThe total number of rows retrieved during table scans of any kind.TABLE_SCANS_DIRECT_READThe number of direct read table scans. Direct reads do *NOT* get put into thebuffer cache.TABLE_SCANS_LONG_TABLESThis is the number of full table scans performed on tables that are not "short" andare not cached. A short table is one with a High Water Mark equal to or smallerthan the SMALL_TABLE_THRESHOLD init.ora parameter. A non-cached table is onewhere the CACHE clause has not been used.TABLE_SCANS_ROWID_RANGESThe number of table scans performed that used a ROWID range scan. Such scansare used by Parallel Query operations.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01
  15. 15. Performance Tuning – Statistic Explanations Page 15TABLE_SCANS_SHORT_TABLESThis 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_TIMEThe time a background process spends waiting to acquire a transaction instancelock (measured in centiseconds).TRANSACTION_LOCK_FOREGROUND_WAIT_TIMEThe time a foreground (i.e., Client) process spends waiting to acquire atransaction instance lock.TRANSACTION_ROLLBACKSThe number of genuine rollbacks issued that involved undoing real changes. Thismight not be the same number as “user_rollbacks” (see below), because it ispossible to issue a rollback command and have nothing happen (after a commit,for example). Such a rollback command would increment “user_rollbacks”, andnot increment “transaction_rollbacks”. A big difference between the two suggestsUsers making large numbers of mistakes, and thus requiring further applicationtraining!!USER_COMMITSThe number of times Users issue “commit” statements, provided such statementsare 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_ROLLBACKSThe number of times Users issue “rollback” statements. This is incremented foreach rollback command, even if there is nothing to roll back. (And you may wellask 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_REQUESTSThe number of multi-block writes. A multi-block write occurs when DBWR collectsan entire batch of dirty buffers off the dirty list, and flushes them all down to diskin one almighty write.Copyright © Howard J. Rogers 2001 Revision 1.0.1 – 18/02/01