Shulou(Shulou.com)06/01 Report--

Oracle R & D engineers use more than 70 queue locks to ensure the consistency of various instances of Cache Fusion, and there are more than 90 queues in version 12.2. For example, our common HW,US,TX,TM,SS,LB and so on. Queue information for each version can be viewed through the v$lock provided by Oracle. For example, our most commonly used version of 11gR2: https://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_2027.htm.

The queues used by Oracle can be roughly divided into three types:

1. Instance classes: such as instance startup and recovery, SCN synchronization

two。 Transaction classes: such as library cache,dictionary cache, parallel queries.

3. User class: user-defined queue (enq:UL-contention)

Queue structure

When a session needs to access a specified resource, it needs to acquire a lock structure (ksqlk) and request access to the resource in a specific lock mode. The lock structure of the lock request belongs to one of the following three linked lists (owner, waiter, and translator). You can distinguish between owners, waiters and converters based on the LMODE and REQUEST columns of the v$lock view. The average wait time can be calculated by v$enqueue_stat 's cum_wait_time/total_wait#, in 1/1000 seconds.

LMODE

REQUEST

ENQUEUE

Non-zero

zero

Owner

Non-zero

Non-zero

Convertor

zero

Non-zero

Waiting person

Queues and distributed management

The application for the local queue of Oracle can be completed at the ksq layer, while for the global queue, you need to go through the application at the ksi and KJu layers. Each queue resource and lock corresponds to the resources and locks managed by the distributed lock. If there is a current transaction, the transaction identifier (XID) is part of the distributed lock identification (which Oracle uses for deadlock detection). If there is no current transaction, the lock identity is made up of the identifier of the connection thread number (2 bytes), the Oracle process ID (2 bytes), and ksuseq. For each Oracle process, their ksuseq value always starts at 0 and then increments.

Non-PCM lock request flow

The ksq layer always invokes the ksi layer using XID to request the creation of a distributed lock. Other layers, such as kqr or kqlm, call the ksi layer without XID (owned by the process), so DLM's deadlock detection feature cannot be used.

Lock mode

The queue can also be seen as a resource in Cache fusion, so it will have different modes of locks, as shown in the following figure. Careful students can find that the names of DLM lock and local lock are different, which Oracle calls "some historical" reasons.

Lock compatibility principle

1. Compatible locks can exist in the authorization queue at the same time.

two。 The lock on the request queue is not compatible with the lock on the grant queue and is not compatible with other locks on the translation queue.

There is a special case in the combination of 3.PR and CW, and PR is not compatible with the smaller mode CW. This does not allow lock demotion from PR to CW.

The 4.GCS lock mode is represented by an underscore.

Lock conversion

The lock exists in the resource grant or conversion queue. If the lock mode changes, it moves between queues. Multiple locks can exist in the grant queue, but they must be compatible with each other. Locks in the same mode are not necessarily compatible with another same mode. The compatibility matrix of various locks is different between GES and GCS locks. Lock conversion in the same queue is usually degraded, that is, to a smaller mode. There are some exceptions, which will be covered later.

The lock can leave the translation queue under any of the following conditions:

The process requests lock termination (remove lock).

The process cancels the conversion; the lock is moved back to the previous mode in the authorization queue.

The requested mode is compatible with the highest level lock in the Grant queue, the requested lock is in the front column of the translation queue (FIFO) and is compatible with the previous lock mode.

Resource lock change

1. Session A tries to read a resource when it adds a shared lock (consistency) to the resource in the Grant queue.

two。 Session B then applies for a shared read lock. Because shared locks are compatible, they can reside in Grant queues at the same time.

3. Session C requests a shared read lock, and the shared read lock is placed in the Grant queue.

4. The shared lock held by session An is converted to NULL mode. Because this is a simple degradation, this conversion can be done directly in the Grant queue.

5. Session C attempts to change the resource, so the lock held by the resource attempts to switch to exclusive mode, and it must be placed in the translation queue.

Since the conversion queue is first-in, first-out (FIFO), a deadlock condition may occur in this case.

There are now two shared read locks and one shared write lock on the 1.Grant queue.

two。 Lock An attempts to upgrade to exclusive mode. This mode is not compatible with the B and C modes, so it is placed in the transformation queue. The information from the old mode retains the situation that prevents the conversion operation from being cancelled.

3. Lock B attempts to upgrade to protected read mode (no other users are allowed to write). This mode is not compatible with C's mode, so it will also be placed in the conversion queue to the north.

4. Lock C is downgraded to NULL mode (no restrictions on other access). Now, even though the exclusive mode is compatible with NULL, locking A cannot complete the conversion because it is not compatible with the old shared read mode of lock B. Lock B can complete the conversion, but it is behind lock A.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.