Problem
You’re seeing a high number of latch waits, and you’d like to reduce the latch contention.
Solution
Severe latch contention can slow your database down noticeably. When you’re dealing with a latch contention issue, start by executing the following query to find out the specific types of latches and the total wait time caused by each wait.
SQL> select event, sum(P3), sum(seconds_in_wait) seconds_in_wait from v$session_wait
where event like 'latch%' group by event;
The previous query shows the latches that are currently being waited for by this session. To find out the amount of time the entire instance has waited for various latches, execute the following SQL statement.
SQL> select wait_class, event, time_waited / 100 time_secs from v$system_event e
where e.wait_class <> 'Idle' AND time_waited > 0 union
select 'Time Model', stat_name NAME, round ((value / 1000000), 2) time_secs from v$sys_time_model
where stat_name not in ('background elapsed time', 'background cpu time') order by 3 desc;
WAIT_CLASS EVENT TIME_SECS --- --- --- Concurrency library cache pin 622.24 Concurrency latch: library cache 428.23 Concurrency latch: library cache lock 93.24 Concurrency library cache lock 24.20 Concurrency latch: library cache pin 60.28
…
The partial output from the query shows the latch-related wait events, which are part of the Concurrency wait class.
You can also view the top five wait events in the AWR report to see if lache contention is an issue, as shown here:
Here are the most common Oracle latch wait types and how you can reduce them.
Shared pool and library latches: These are caused mostly by the database repeatedly executing the same SQL statement that varies slightly each time. For example, a database may execute a SQL statement 10,000 times, each time with a different value for a variable. The solution in all such cases is to use bind variables. An application that explicitly closes all cursors after each execution may also contribute to this type of wait. The solution for this is to specify the CURSOR_SPACE_FOR_TIME initialization parameter. Too small a shared pool may also contribute to the latch problem, so check your SGA size.
Cache buffers LRU chain: These latch events are usually due to excessive buffer cache usage and may be caused both by excessive physical reads as well as logical reads. Either the database is performing large full table scans, or it’s performing large index range scans. The usual cause for these types of latch waits is either the lack of an index or the presence of an unselective index. Also check to see if you need to increase the size of the buffer cache.
Cache buffer chains: These waits are due to one or more hot blocks that are being repeatedly accessed. Application code that updates a table’s rows to generate sequence numbers, rather than using an Oracle sequence, can result in such hot blocks. You might also see the cache buffer chains wait event when too many processes are scanning an unselective index with similar predicates.
Also, if you’re using Oracle sequences, re-create them with a larger cache size setting and try to avoid using the ORDER clause. The CACHE clause for a sequence determines the number of sequence values the database must cache in the SGA. If your database is processing a large number of inserts and
updates, consider increasing the cache size to avoid contention for sequence values. By default, the cache is set to 20 values. Contention can result if values are being requested fast enough to frequently deplete the cache. If you’re dealing with a RAC environment, using the NOORDER clause will prevent enqueue contention due to the forced ordering of queued sequence values.
How It Works
Oracle uses internal locks called latches to protect various memory structures. When a server process attempts to get a latch but fails to do so, that attempt is counted as a latch free wait event. Oracle doesn’t group all latch waits into a single latch free wait event. Oracle does use a generic latch free wait event, but this is only for the minor latch-related wait events. For the latches that are most common, Oracle uses various subgroups of latch wait events, with the name of the wait event type. You can identify the
CHAPTER 5 ■ MINIMIZING SYSTEM CONTENTION
exact type of latch by looking at the latch event name. For example, the latch event latch: library cache indicates contention for library cache latches. Similarly, the latch: cache buffer chains event indicates contention for the buffer cache.
Oracle uses various types of latches to prevent multiple sessions from updating the same area of the SGA. Various database operations require sessions to read or update the SGA. For example, when a session reads a data block into the SGA from disk, it must modify the buffer cache least recently used chain. Similarly, when the database parses a SQL statement, that statement has to be added to the library cache component of the SGA. Oracle uses latches to prevent database operations from stepping on each other and corrupting the SGA.
A database operation needs to acquire and hold a latch for very brief periods, typically lasting a few nanoseconds. If a session fails to acquire a latch at first because the latch is already in use, the session will try a few times before going to “sleep.” The session will re-awaken and try a few more times, before going into the sleep mode again if it still can’t acquire the latch it needs. Each time the session goes into the sleep mode, it stays longer there, thus increasing the time interval between subsequent attempts to acquire a latch. Thus, if there’s a severe contention for latches in your database, it results in a severe degradation of response times and throughput.
Don’t be surprised to see latch contention even in a well-designed database running on very fast hardware. Some amount of latch contention, especially the cache buffers chain latch events, is pretty much unavoidable. You should be concerned only if the latch waits are extremely high and are slowing down database performance.
Contention due to the library cache latches as well as shared pool latches is usually due to
applications not using bind variables. If your application can’t be recoded to incorporate bind variables, all’s not lost. You can set the CURSOR_SHARING parameter to force Oracle to use bind variables, even if your application hasn’t specified them in the code. You can choose between a setting of FORCE or SIMILAR for this parameter to force the substituting of bind variables for hard-coded values of variables. The default setting for this parameter is EXACT, which means that the database won’t substitute bind variables for literal values. When you set the CURSOR_SHARING parameter to FORCE, Oracle converts all literals to bind variables. The SIMILAR setting causes a statement to use bind variables only if doing so doesn’t change a statement’s execution plan. Thus, the SIMILAR setting seems a safer way to go about forcing the database to use bind variables instead of literals. Although there are some concerns about the safety of setting the CURSOR_SHARING parameter to FORCE, we haven’t seen any real issues with using this setting. The library cache contention usually disappears once you set the CURSOR_SHARING parameter to FORCE or to SIMILAR.
The CURSOR_SHARING parameter is one of the few Oracle silver bullets that’ll improve database performance immediately by eliminating latch contention. Use it with confidence when dealing with library cache latch contention.
The cache buffer chains latch contention is usually due to a session repeatedly reading the same data blocks. First identify the SQL statement that’s responsible for the highest amount of the cache buffers chain latches and see if you can tune it. If this doesn’t reduce the latch contention, you must identify the actual hot blocks that are being repeatedly read.
If a hot block belongs to an index segment, you may consider partitioning the table and using local indexes. For example, a hash partitioning scheme lets you spread the load among multiple partitioned indexes. You can also consider converting the table to a hash cluster based on the indexed columns.
This way, you can avoid the index altogether. If the hot blocks belong to a table segment instead, you can still consider partitioning the table to spread the load across the partitions. You may also want to reconsider the application design to see why the same blocks are being repeatedly accessed, thus rendering them “hot.”