Streams miscellaneous event enq: TX - row lock contention -log file sequential read O -db file sequential read

-log file sequential read O -log file sync -db file sequential read -log file sequential read O enq: TX - row lock contention -log file sync -log file sequential read O -db file sequential read -direct path write temp -direct path read -log file sequential read O -db file sequential read -db file sequential read -log file sequential read O enq: TM - contention -library cache lock c cursor: mutex S -db file sequential read -library cache lock c cursor: mutex S library cache: mutex X -library cache lock c cursor: mutex S library cache: mutex X -db file sequential read -library cache lock c -log file sequential read O -db file sequential read -log file sequential read O -row cache lock c -db file sequential read

36,941 5 449,857 55,145 423,784 61,754 34,438 420,978 1 56,774 390,898 21,864 22,594 200,862 381,843 25,397 42,078 430,502 16 788,053 2,274,493 88,160 8,326,676 55,870,038 2,329,084 13,145,028 102,807,124 4,363,324 235,899 369,615 437,766 169,241 218,916 552 62,051

18,495

501

74.9 Other

2,859 6.E+05 11.6 Applicatio 1,208 3 4.9 System I/ 469 1,325 924 420 2,352 9 3 15 12 6 1.9 User I/O 5.1 System I/ 3.6 Commit 1.6 User I/O 9.4 System I/ 9.1 Applicatio 3.9 Commit .8 System I/ .6 User I/O .4 User I/O 1.2 User I/O .8 System I/ .7 User I/O 1.1 User I/O .8 System I/ .7 Applicatio 28.3 Concurren 3.3 Concurrenc 1.8 User I/O 65.0 Concurren 20.4 Concurrenc .7 Concurrenc 64.4 Concurren 26.3 Concurrenc .9 Concurrenc 7 2 1 5 1 218 8 6.5 User I/O 2.4 Concurren 1.5 System I/ 7.4 User I/O 1.1 System I/ 1.0 Concurren 4.5 User I/O

2,283 2.E+06 971 17 225 157 119 330 213 184 308 241 210 13151 9,273 1,071 584 135,738 42,671 1,400 252,124 103,158 3,398 1,551 580 356 865 132 120 469 12 0 7 16 1 1 19 1 1 1 7 5 2 1 7 7 1

-log file sequential read O -control file sequential read O enq: TM - contention -log file sequential read O -log file sync Log File Sync

198,256 89,649 5 254,633 110,489

197 49

1 1

1.9 System I/ .5 System I/

1,194 2.E+05 10.1 Applicatio 696 3 5.9 System I/ 363 3 3.1 Commit

The log file sync wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buff er to the redo log file. When the LGWR has finished writing, it will post the us er session. The wait is entirely dependent on LGWR to write out the necessary re do blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called commit latency . The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait ev ent:

P1 = buffer# All changes up to this buffer number (in the log buffer) must be flushed to disk and the writes confirmed to ensure that the transaction is committed and will b e kept on an instance crash. The wait is for LGWR to flush up to this buffer#. Reducing Waits / Wait times: If a SQL statement is encountering a significant amount of total time for this e vent, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by c ommitting after n rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle, reducing the overall number of commits by batchi ng transactions can be very beneficial. If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time wri ting and commit data to the AUDIT$ table. If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a sessio n continues to wait on the same If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a sessio n continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT s hould increment every second. If not then the local session has a problem with w ait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. I f the waits are because of slow I/O, then try the following:

Reduce other I/O activity on the disks containing the redo logs, or use dedi cated disks. Try to reduce resource contention. Check the number of transactions (com mits + rollbacks) each second, from V$SYSSTAT. Alternate redo logs on different disks to minimize the effect of the archive r on the log writer. Move the redo logs to faster disks or a faster I/O subsystem (for example, s witch from RAID 5 to RAID 1). Consider using raw devices (or simulated raw devices provided by disk vendor s) to speed up the writes. See if any activity can safely be done with NOLOGGING / UNRECOVERABLE option s in order to reduce the amount of redo being written. See if any of the processing can use the COMMIT NOWAIT option (be sure to un derstand the semantics of this before using it). Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - log file sync When a user session commits, the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. Wait Time: The wait time includes the writing of the log buffer and the post. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - log file sequential read Waiting for the read from this logfile to return. This is used to read redo reco rds from the log file. Wait Time: Time it takes to complete the physical I/O (read) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - control file sequential read This wait happens when reading from the control file. This happens in many cases . For example: Making a backup of the control files Sharing information (between instances) from the control file Reading other blocks from the control files Reading the header block ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - db file sequential read An Oracle session logs the db file sequential read wait event when it has to wai t for a single-block I/O read request to complete. Oracle issues single-block I/ O read requests when reading from indexes, rollback segments, sort segments, con trolfiles, datafile headers and tables (when tables are accessed via rowids). The db file sequential read and db file scattered read events can be confusing a t first, as the sequential read is associated with index read and the scattered

read has to do with full table scans. It seems like they ought to be the other w ay around. The db file sequential read is thus named because it reads blocks int o contiguous memory, and the db file scattered read gets its name because it rea ds multiple blocks and scatters them into the Buffer Cache. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - direct path write A direct path write I/O operation is just the opposite of the direct path read o peration, and it writes buffers from a session's PGA to the datafiles. The direc t path write operation allows a session to issue multiple write requests and con tinue processing. At some point, the session will wait on the direct path write event, either to confirm that the OS has completed all outstanding I/Os, or wait for slots to become available so that more writes can be issued. The direct pat h write operation is normally applied when writing to the temporary tablespace ( sort overflows) or when using the direct load method to create or populate objec ts (CTAS, insert with the APPEND hint). Oracle 8.1.7 has a separate direct write I/O wait event for LOB segments - direct path write (lob). Like the direct path read event, the number of waits and time waited for the dir ect path write event can be misleading if asynchronous I/O is supported and used . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - direct path read A direct path read I/O operation reads data into the session's PGA instead of th e SGA. Direct read I/Os may be performed in synchronous or asynchronous mode, de pending on the platform and the value of the DISK_ASYNC_IO parameter. An Oracle session waits for a direct read I/O request to complete on the direct path read wait event. Direct I/O is normally used when reading from sort segments. Paralle l query slaves also use direct I/O when scanning a table or index. As of Oracle 8.1.7, there is a separate direct read I/O wait event for LOB segments - direct path read (lob). The number of waits and time waited for this event may be somewhat misleading. I f the DISK_ASYNC_IO is FALSE or the platform does not support asynchronous I/O, then all direct path read I/Os are synchronous and each wait corresponds to a ph ysical read request. If the platform is capable of asynchronous I/O and the DISK _ASYNC_IO is TRUE, then the session may issue multiple direct read I/O requests and continue to process the blocks that are already cached in the PGA. The sessi on only registers a wait on the direct path read event when it cannot continue p rocessing because some blocks have not been read from disk. Therefore, the numbe r of waits does not equal the read requests, and the wait time is deceiving, as the clock does not start when the read requests were issued. Due to these behavi ors, this event seldom shows up as the main bottleneck in the V$SYSTEM_EVENT and V$SESSION_EVENT views. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - row cache lock The dictionary cache is known as row cache as it keeps the information at row le vel opposed to the buffer cache that keeps the information at block level. The l ocks, which protect the definition of the data dictionary objects, are called as row cache locks. Normally DDL statements require row cache locks and the sessio n will wait for the row cache lock to lock the data dictionary information. This wait is not a RAC specific wait. It is applicable in single instance also, but has a bigger impact in the RAC environment since the library cache and row c ache are globally coordinated. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Events - library cache lock

This event controls the concurrency between clients of the library cache. It acq uires a lock on the object handle so that either: One client can prevent other clients from accessing the same object. The client can maintain a dependency for a long time (for example, no other client can change the object). This lock is also obtained to locate an object in the library cach

Begin Snap: End Snap: Begin Snap: End Snap: Begin Snap: End Snap: Begin Snap: End Snap: Begin Snap: End Snap:

966 22-Dec-11 00:00:07 967 22-Dec-11 01:00:11 1082 26-Dec-11 20:00:27 1083 26-Dec-11 21:00:34 1425 03-Jan-12 14:00:25 1426 03-Jan-12 14:30:30 1529 05-Jan-12 18:00:05 1530 05-Jan-12 18:30:11 1565 06-Jan-12 12:00:24 1566 06-Jan-12 12:30:28

311 294 263 268 262 260 282 271 270 268

6.6 6.3 5.8 5.9 5.9 5.9 6.5 5.9 5.8 5.9