Latch Enqueue Hash Chains Doc ID 445076 1

分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

               

(Doc ID 445076.1),

Solution


Acquiring a lock is a series of steps from getting an index number to identify the hash bucket in the hash table to releasing free resource structures and lock data structures.

Here are the steps:

1. Identifying the Hash Chain and Allocating the Resource Structure

Oracle finds the resource structure associated with the named resource using a hashing algorithm.
In the hashing algorithm Oracle uses a hash table (array of hash buckets), which is controlled by
the parameter _ENQUEUE_HASH. The size of the hash table depends upon the value of this parameter.
The Hash chain contains the resource structures for that hash value. When a session tries to
acquire an enqueue, Oracle applies a hash function to convert the resource name to an index number
in the array of hash buckets. Each hash bucket has one linked list attached to it, which is called
a hash chain. Before accessing the hash bucket, the session acquires an enqueue hash chain latch.
After the session acquires an enqueue hash chain latch it moves down the hash chain attached to the
bucket to locate the required resource structure. At this point because the session acquires an
enqueue hash chain latch it will record a miss or spin get in the V$LATCH view depending upon the
result of the latch operation.
There can be situations where the resource structure is not available on the hash chain. In this
case where a resource structure is not present, the session will acquire an enqueue latch and will
record statistics about the latch operation in V$LATCH. After acquiring the enqueue latch, the
session will unlink the head of the resource free list and link it into a hash chain associated
with the hash bucket. The enqueue latch will be held while the resource is allocated to the
resource table.

2. Populating the Lock Data Structure with the requested resource

Now the session will acquire the enqueue latch again and will unlink the head of the lock free
list. It will populate the information related to the resource being requested, like mode of lock
etc. Now after populating this information, the session will link this lock structure to one of
the linked lists (owner, waiter or converter) associated with the resource structure, depending
upon the other sessions owning that resource structure or waiting to own the lock, or waiting to
convert the existing held lock for that resource. Oracle will record the statistics in V$LATCH
according to the result of the enqueue latch operation. By this time both the enqueue latch and
enqueue hash chain latch are held by this session. The session will release the enqueue latch
first then the enqueue hash chain latch after linking the lock data structure with the resource
structure.

Now if the session is waiting in any queue (owner, waiter or converter) for another session to
complete, the enqueue wait event will be recorded in V$SESSION_EVENT.

3. Releasing a Lock

The method to release a lock is mostly the same as acquiring a lock. First of all Oracle will use
a hash function to determine the hash bucket where the resource structure is allocated. It will
acquire the enqueue hash chain latch and record statistics of the latch operation in V$LATCH. Then
it will locate the resource in the hash chain (linked list associated with the hash bucket
identified by hash function). The session will acquire the enqueue latch and will unlink the lock
data structure from the resource structure, and link the lock data structure to the lock free list
and release the enqueue latch. After releasing the enqueue latch, the session will post the next
process (waiter or converter) to proceed if appropriate. Depending upon the LRU algorithm, Oracle
will decide whether to unlink the resource structure from the hash chain and link it to the
resource free list or not. After all of this, the session will release the enqueue hash chain
latch and the lock will be released.


DML locks protect objects from concurrent modification.
Frequently, DML lock allocation latch contention is seen with enqueue hash chain latches, as
dml_locks are implemented through TM enqueue locks. These resource structures are hanging from
enqueue hash chains serialized by enqueue hash chain latches. So, reducing DML lock allocation
latch contention should resolve enqueue hash chain latch contention.


About the two bugs that were identified in your previous SR  #(high session with this latch and resmgr:resource group CPU method 、)
PROBLEM DESCRIPTION: 
There is a high contention on resource manager runnable list latch on big system. 

FIX DESCRIPTION: 
Have multiple runnable lists per consumer group with multiple child latches. The fix is to have multiple runnable lists for a consumer group with multiple child latches. 

1) Number of runnable lists. 
I allocate 1 runnable list per 16 CPUs. If there are 128 CPUs, then there 
will be 8 runnable lists per consumer group. The number of runnable lists is 
capped to 10. The number of runnable lists is tunable using an underscore 
parameter. 

2) Adding a vt to runnable list 
The group of runnable lists for a consumer group is maintained by kgkp. kgsk 
calls the add vt function and kgkp is the one that decides which runnable 
list the vt should go to. To spread the vts evenly across the group of 
runnable lists, an add counter is introduced for each consumer group. The 
add counter decides the runnable list that a vt goes to. The add counter is 
increased(not atomically) every time the counter is used. 

3) Picking a vt from a runnable list 
kgsk calls pick vt function and kgkp is the one that decides which runnable 
list to pick from. To pick the vts evenly from all runnable lists, a pick 
counter is introduced for each consumer group. The pick counter serves as the 
target index. If the corresponding target runnable list is empty, the current 
process will traverse the runnable lists to find the nearest non-empty 
runnable list. The pick counter is increased(not atomically) every time the 
counter is used. 


As to P1, P2 and P3, they are
P1 = Latch address
P2 = Latch number
P3 = Tries           

给我老师的人工智能教程打call!http://blog.csdn.net/jiangjunshow

这里写图片描述

猜你喜欢

转载自blog.csdn.net/ugghhj/article/details/84191279
今日推荐