常见的等待事件：db file scattered read DB ,db file sequential read DB,free buffer waits,log buffer space,log file switch,log file sync
We can view the current waiting events of the system and the information about the resources corresponding to the waiting events through the view v$session_wait, so as to determine the type of bottleneck and its object. The p1, p2, and p3 of v$session_wait tell us the specific meaning of the waiting event, and its content is different depending on the event. The following is some introduction on how to deal with some common waiting events and how to locate hot objects and block sessions.
<1> db file scattered read DB file scattered read (too many index reads, full table scan ----- adjust the code, put small tables into memory)This situation usually shows waits related to full table scans. When full table scans are limited to memory, they rarely go into contiguous buffers, but are scattered throughout the buffer memory. If this number is large, it indicates that the table cannot find indexes, or that only a limited number of indexes can be found. Although it may be more efficient to perform full table scans than index scans under certain conditions, it is a good idea to check whether these full table scans are necessary if such waits occur. Because full table scans are placed at the cold end of the LRU (Least Recently Used) list, you should try to store smaller tables to avoid re-reading them again and again.
=====================================================
For this type of event, p1text=file#, p1 is file_id, and p2 is block_id. The hotspot object (table or index) can be determined through dba_extents
select owner, segment_name, segment_type
from dba_extents
where file_id = &file_id
and &block_id between block_id and block_id + &blocks - 1;
================================================= ===
<2> db file sequential read DB file sequential read (poor table join order-----adjust code, especially table join)
This event usually shows a read of a single block (such as an index read). A high number of such waits may indicate that the tables are not joined in order, or are indexed indiscriminately. This value is mostly normal for a high-transaction, well-tuned system, but in some cases it can indicate a problem in the system. You should tie this wait statistic to a known issue in the Statspack report, such as inefficient SQL. Check index scans to ensure that each scan is necessary, and check join order for multi-table joins. DB_CACHE_SIZE is also a determinant of how often these waits occur. Hash-area connections in question should appear in PGA memory, but they also consume a lot of memory, causing a lot of waits on sequential reads. They may also come in the form of direct path read/write waits.
===================================================== =
p1text=file# of this type of event, p1 is file_id, p2 is block_id, hotspot object (table or index) can be determined through dba_extents
select owner, segment_name, segment_type
from dba_extents
where file_id = &file_id
and &block_id between block_id and block_id + &blocks - 1;
=============================================== ====
<3> free buffer waits release buffer waits (increase DB_CACHE_SIZE, speed up checkpoints, adjust code)
This wait indicates that the system is waiting for a buffer in memory because there is no more buffer space available in memory. If all SQL is tuned, this wait may indicate that you need to increase DB_BUFFER_CACHE. A free buffer wait may also indicate that indiscriminate SQL caused data to overflow buffer memory with index blocks, leaving no buffer left for a particular statement waiting to be processed by the system. This situation usually indicates that a considerable amount of DML (insert/update/delete) is being performed, and the database writer (DBWR) is not writing fast enough, the buffer memory may be filled with multiple versions of the same buffer, resulting in very efficient Low. To address this issue, you may want to consider increasing checkpoints, utilizing more DBWR processes, or increasing the number of physical disks.
<4> buffer busy waits Buffer busy waits (BUFFER hot block)
This is to wait for a buffer used in a non-shared manner, or a buffer that is being read into the buffer memory. The buffer busy wait should not be greater than 1%. Check the buffer wait statistics section (or V$WAITSTAT):
A. If the wait is at the head of the field, increase the number of groups in the freelist, or increase the distance between pctused and pctfree.
B. If waiting for the head block of the rollback segment (undo), the buffer problem can be solved by adding a rollback segment;
C. If waiting for the non-head block of the rollback segment (undo), then Need to reduce the data density in the table that drives consistent reading, or increase DB_CACHE_SIZE;
D. If waiting in a data block, you can move the data to another data block to avoid this "hot" data block and increase the freedom in the table List or use the LMT table space;
E. If the wait is in the index block, you should rebuild the index, split the index or use the reverse key index.
To prevent buffer busy-waiting associated with data blocks, smaller blocks can also be used: in this case, there are fewer records in a single block, so the block is not as "busy". When performing DML (insert/update/delete), Oracle DBWR writes information to the block, including all users who are "interested" in the state of the block (interested transaction table, ITL). To reduce waits in this area, initrans can be increased, which will create space in the block, allowing you to use multiple ITL slots. You can also increase the pctfree in the table where the block is located (when the number of slots established according to the specified initrans is insufficient, this can make the number of ITL messages reach the number specified by maxtrans).
<6> enqueue
enqueue is a locking mechanism to protect shared resources. This locking mechanism protects shared resources, such as data in records, from two people updating the same data at the same time. enqueue includes a queuing mechanism, the FIFO (first in, first out) queuing mechanism. Note: Oracle's latch mechanism is not FIFO. Enqueue wait usually refers to ST enqueue, HW enqueue, TX4 enqueue and TM enqueue.
A. ST enqueue is used for the allocation of space management and dictionary management table space. With LMT, either try to preallocate the region, or at least make the next region larger than the dictionary-managed tablespace in question.
B. The HW enqueue is used in conjunction with the segment's high water mark; manually assigning regions avoids this wait.
C. TX4 enqueue is the most common enqueue wait, which is usually the result of one of the following three problems:
the first problem is the duplicate index in the unique index, which needs to be released by performing a commit/rollback operation enqueue.
The second problem is multiple updates to the same bitmap index segment. Because a single bitmap segment may contain multiple row addresses (rowids), when multiple users try to update the same segment, you need to perform a commit or rollback operation to release the enqueue.
The third and most likely problem is that multiple users update the same block at the same time. Block-level locking occurs when there are no free ITL slots. This can easily be avoided by increasing initrans and/or maxtrans to allow multiple ITL slots, or by increasing the pctfree value on the table.
D. The TM enqueue is generated during DML to avoid using DDL on the affected objects. If there are foreign keywords, be sure to index them to avoid this common locking problem.
<7> log buffer space Log buffer space (writing REDO is slow-----increase log_buffer, redo log file is placed on a fast disk)
When the log buffer (log buffer) writes to the redo log (redo log) faster than This wait occurs when the LGWR is slow to write, or when the log switch is too slow. To solve this problem, you can increase the size of the log file, or increase the size of the log buffer, or use a faster write disk. Even solid state disks might be considered because of their high speed.
<8> log file switch
There are two cases for log file conversion (slow archiving----increase or expand redo logs):
A. log file switch (archiving needed)
When the log is switched, the log group uses a circular Circle but the log archiving has not been completed, usually there is a serious problem with io, you can increase the log file and increase the log group, adjust log_archive_max_processes
B, log file switch (checkpoint incomplete)
When the log is switched, the log group has been used in a circle but the checkpoint in the log group to be used has not been completed. Usually, there is a serious problem in io. You can increase the log file and increase the log group.
<9> log file sync Log file synchronization (commit too frequently----batch submission)
When the user commits, lgwr is notified to write the log but lwgr is busy. The possible reason is that the commit is too frequent or the time for lgwr to write the log is too long (probably because a log io size is too large), you can adjust _log_io_size, combined with log_buffer, so that (_log_io_size*db_block_size)*n = log_buffer, this can avoid conflicts with increasing log_buffer; place log files on high-speed disks
<10> library cache pin
this event It usually occurs when a session is running objects such as PL/SQL, VIEW, TYPES, etc., and another session executes and recompiles these objects, that is, a shared lock is first added to the object, and then an exclusive lock is added to it. , so that this wait will occur on a session with an exclusive lock. P1, P2 can be related to x$kglpn and x$kglob tables
X$KGLOB (Kernel Generic Library Cache Manager Object)
X$KGLPN (Kernel Generic Library Cache Manager Object Pins)
-- Query X$KGLOB to find related objects, The SQL statement is as follows
(ie, associate P1raw in V$SESSION_WAIT with KGLHDADR in X$KGLOB)
select kglnaown, kglnaobj from X$KGLOB
where KGLHDADR =(select p1raw from v$session_wait
where event='library cache pin')
-- find out the sid of the blocker that caused the wait event
select sid from x$kglpn , v$session
where KGLPNHDL in
(select p1raw from v $session_wait
where wait_time=0 and event like 'library cache pin%')
and KGLPNMOD <> 0
and v$session.saddr=x$kglpn.kglpnuse
-- find out the SQL statement being executed by the blocker
select sid,sql_text
from v $session, v$sqlarea
where v$session.sql_address=v$sqlarea.address
and sid=<blocker's sid> In
this way, the root cause of the "library cache pin" waiting can be found and the resulting performance problems can be solved.
<11> library cache lock
This event is usually caused by performing multiple DDL operations, that is, after adding an exclusive lock to the library cache object, an exclusive lock is added to it from another session, so that in the second The session will generate a wait. The corresponding object can be found by going to the base table x$kgllk.
-- Query the sid, session user, and locked object of the blocker that caused the waiting event
select b.sid, a.user_name, a.kglnaobj
from x$kgllk a , v$session b
where a.kgllkhdl in
(select p1raw from v$session_wait
where wait_time=0 and event = 'library cache lock')
and a.kgllkmod <> 0
and b.saddr=a.kgllkuse
Of course, it can also be viewed directly from v$locked_objects, but there is no above statement intuitively based on sid You can go to v$process to find out the pid, and then kill it or do other processing.
<5> latch free (waiting for LATCH FREE)
latch is a low-level queuing mechanism (they are accurately called mutual exclusion mechanism), used to protect the shared memory structure in the system global area (SGA). A latch is like a memory lock that is quickly acquired and released. The latch is used to prevent shared memory structures from being accessed by multiple users at the same time. If the latch is not available, a latch release failure is logged. Most latch problems are related to: inability to use bound variables (library cache latches), duplicate generation problems (duplicate allocation of latches), buffer memory race problems (buffer store LRU chains), and "hot" buffer memory block (chain of buffer memory). There are also some latch waits related to bugs (program errors), if you suspect this is the case, check the bug report on MetaLink.
The hotspot object of the event can be found by the following statement, where &2 value is P1RAW in v$session_wait, and the field Hladdr in x$bh indicates which cache buffer chain latch the block buffer is on, and which segments can be located by v$latch_children Hotspot block.
===================================================== =
select a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
from x$bh a, dba_objects b
where (a.obj = b.object_id or a.obj = b. data_object_id)
and a.hladdr = &2
union
select hladdr, file#, dbablk, tch, obj, null
from x$bh
where obj in
(select obj from x$bh
where hladdr = &2
minus
select object_id from dba_objects
minus
select data_object_id from dba_objects )
and hladdr = &2
order by 4;
===================================================== ==
***Latch problems and possible solutions
-------------------------------
* Library Cache and Shared Pool (unbound Fixed variable---binding variable, adjusting shared_pool_size)
This Latch is used whenever SQL or PL/SQL stored procedures, packages, functions and triggers are executed. This Latch is also frequently used in Parse operations.
* Redo Copy (increase _LOG_SIMULTANEOUS_COPIES parameter)
Redo copy Latch is used to copy redo records from PGA to redo log buffer.
* Redo Allocation (minimize REDO generation, avoid unnecessary commit)
This Latch is used to allocate redo logs For space in the buffer, NOLOGGING can be used to slow down the competition.
* Row Cache Objects (increase the shared pool)
data dictionary competition. Excessive parsing.
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS should be increased or set to a prime number)
caused by "overheated" data blocks The memory buffer chain Latch competition is eliminated.
* Cache Buffers Lru Chain (adjust SQL, set DB_BLOCK_LRU_LATCHES, or use multiple buffer pools)
The memory buffer LRU chain Latch is used when scanning the LRU (least recently used) chain of all memory buffer blocks. Too small memory buffer, too large memory buffer throughput, too much sorting operation in memory, This Latch contention is caused by DBWR speed not keeping up with the workload, etc.
<12> The wait related to the DBWR process of db file parallel write
generally represents a problem with the I/O capability. It is usually related to the number of configured multiple DBWR processes or the number of I/O slaves of the DBWU. Of course, it may also mean that the device There is an I/O competition on
<13> db file single write
indicates the wait related to the file header write operation when the checkpoint occurs. Usually related to the disorder of the file number when the checkpoint synchronizes the data file header.
<14> direct path read and direct path write
represent waits associated with direct I/O reads. Direct path read occurs when reading data directly into PGA memory. This type of read request is typically done as: sort IO (for sorts that cannot be done in memory time), parallel slave queries or read-ahead requests, etc. Usually this wait is related to I/O capacity or I/O competition.
<15> free buffer inspected
means waiting for the process to find enough when reading data into the data adjustment buffer Large internal space Usually this type of wait indicates that the data adjustment buffer is too small.
<16> library cache load lock
indicates that there is a wait when loading the object into the library cache. This event usually represents a heavy load. Statement overloading or loading may be caused by the fact that the SQL statement is not shared or the shared pool area is compiled.
<17> log file parallel write
Indicates waiting for LGWR to request I/O to the operating system to start until IO is completed. In the case of triggering LGWR write, such as 3 seconds, 1/3, 1MB, before DBWR write may occur. This event usually means that the log file has I/O O contention or the drive where the file is located is slow
<18> log file single write
indicates that there is a wait when writing the log file header block. Generally, it occurs when a checkpoint occurs.
<19> transaction
indicates that a blocking rollback operation occurred. Waiting for
<20> undo segment extension
means waiting for the dynamic expansion of the rollback segment. This means that the transaction volume may be too large, and it also means that the size of the rollback segment may not be optimal, and the MINEXTENTS setting is too small. Consider reducing transactions, Or use a rollback segment with a larger minimum number of extents.