ORACLE 鎖機制是怎樣的

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)ORACLE 鎖機制是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

http://blog.csdn.net/xujinyang/article/details/6822936

鎖這東西是純概念性的東西，但是作用又非常大。 以前整理過兩篇文章，今天又看了點書，覺得還不是很清楚。 就重新整理了下。 在想要不要把以前的文章刪掉，這樣在blog里是比較簡介的，但后來又一想。 這些連接在其他的地方可能被引用了。 就決定還是保留著了，也算見證自己成長的一個過程。

一．鎖（Lock）
1.1 鎖的概念
數(shù)據(jù)庫是一個多用戶使用的共享資源。當(dāng)多個用戶并發(fā)地存取數(shù)據(jù)時，在數(shù)據(jù)庫中就會產(chǎn)生多個事務(wù)同時存取同一數(shù)據(jù)的情況。若對并發(fā)操作不加控制就可能會讀取和存儲不正確的數(shù)據(jù)，破壞數(shù)據(jù)庫的一致性。

加鎖是實現(xiàn)數(shù)據(jù)庫并發(fā)控制的一個非常重要的技術(shù)。當(dāng)事務(wù)在對某個數(shù)據(jù)對象進行操作前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務(wù)就對該數(shù)據(jù)對象有了一定的控制，在該事務(wù)釋放鎖之前，其他的事務(wù)不能對此數(shù)據(jù)對象進行更新操作。

在Oracle 數(shù)據(jù)庫中，它并不是對某個表加上鎖或者某幾行加上鎖，鎖是以數(shù)據(jù)塊的一個屬性存在的。 也就是說，每個數(shù)據(jù)塊本身就存儲著自己數(shù)據(jù)塊中數(shù)據(jù)的信息，這個地方叫ITL（Interested Transaction List），凡是在這個數(shù)據(jù)塊上有活動的事務(wù)，它的信息就會記錄在這里面供后續(xù)的操作查詢，一保證事務(wù)的一致性。


1.2 鎖的分類

1.2.1. 按用戶與系統(tǒng)劃分，可以分為自動鎖與顯示鎖
a) 自動鎖（Automatic Locks）：當(dāng)進行一項數(shù)據(jù)庫操作時，缺省情況下，系統(tǒng)自動為此數(shù)據(jù)庫操作獲得所有有必要的鎖。自動鎖分DML鎖，DDL鎖，system locks。
b) 顯示鎖（Manual Data Locks）：某些情況下，需要用戶顯示的鎖定數(shù)據(jù)庫操作要用到的數(shù)據(jù)，才能使數(shù)據(jù)庫操作執(zhí)行得更好，顯示鎖是用戶為數(shù)據(jù)庫對象設(shè)定的。

Oracle Database performs locking automatically to ensure data concurrency, data integrity, and statement-level read consistency. However, you can manually override the Oracle Database default locking mechanisms. Overriding the default locking is useful in situations such as the following:

Applications require transaction-level read consistency or repeatable reads.

In this case, queries must produce consistent data for the duration of the transaction, not reflecting changes by other transactions. You can achieve transaction-level read consistency by using explicit locking, read-only transactions, serializable transactions, or by overriding default locking.

Applications require that a transaction have exclusive access to a resource so that the transaction does not have to wait for other transactions to complete.

You can override Oracle Database automatic locking at the session or transaction level. At the session level, a session can set the required transaction isolation level with the ALTER SESSION statement. At the transaction level, transactions that include the followingSQL statements override Oracle Database default locking:
（1）The SET TRANSACTION ISOLATION LEVEL statement
（2）The LOCK TABLE statement (which locks either a table or, when used with views, the base tables)
（3）The SELECT ... FOR UPDATE statement

Locks acquired by the preceding statements are released after the transaction ends or a rollback to savepoint releases them.

If Oracle Database default locking is overridden at any level, then the database administrator or application developer should ensure that the overriding locking procedures operate correctly. The locking procedures must satisfy the following criteria: data integrity is guaranteed, data concurrency is acceptable, and deadlocks are not possible or are appropriately handled.

 
1.2.2. 按鎖級別劃分，可分為: 排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）
a) 共享鎖( S )： 共享鎖使一個事務(wù)對特定數(shù)據(jù)庫資源進行共享訪問——另一事務(wù)也可對此資源進行訪問或獲得相同共享鎖。共享鎖為事務(wù)提供高并發(fā)性，但如拙劣的事務(wù)設(shè)計+共享鎖容易造成死鎖或數(shù)據(jù)更新丟失。
b) 排它鎖( X)： 事務(wù)設(shè)置排它鎖后，該事務(wù)單獨獲得此資源，另一事務(wù)不能在此事務(wù)提交之前獲得相同對象的共享鎖或排它鎖。

1.2.3 按操作劃分，可分為DML鎖（data locks，數(shù)據(jù)鎖）、DDL鎖（data dictionary lock）和 System Locks。


1.2.3.1  DML鎖
DML鎖用于控制并發(fā)事務(wù)中的數(shù)據(jù)操縱，保證數(shù)據(jù)的一致性和完整性。DML 鎖主要用于保護并發(fā)情況下的數(shù)據(jù)完整性。 它又分為：
（1）TM鎖（表級鎖）
（2）TX鎖（事務(wù)鎖或行級鎖）

當(dāng)Oracle執(zhí)行DML語句時，系統(tǒng)自動在所要操作的表上申請TM類型的鎖。當(dāng)TM鎖獲得后，系統(tǒng)再自動申請TX類型的鎖，并將實際鎖定的數(shù)據(jù)行的鎖標(biāo)志位進行置位。這樣在事務(wù)加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標(biāo)志，而只需檢查TM鎖模式的相容性即可，大大提高了系統(tǒng)的效率。

在數(shù)據(jù)行上只有X鎖（排他鎖）。在Oracle數(shù)據(jù)庫中，當(dāng)一個事務(wù)首次發(fā)起一個DML語句時就獲得一個TX鎖，該鎖保持到事務(wù)被提交或回滾。當(dāng)兩個或多個會話在表的同一條記錄上執(zhí)行DML語句時，第一個會話在該條記錄上加鎖，其他的會話處于等待狀態(tài)。當(dāng)?shù)谝粋€會話提交后，TX鎖被釋放，其他會話才可以加鎖。

當(dāng)Oracle數(shù)據(jù)庫發(fā)生TX鎖等待時，如果不及時處理常常會引起Oracle數(shù)據(jù)庫掛起，或?qū)е滤梨i的發(fā)生，產(chǎn)生ORA-600的錯誤。這些現(xiàn)象都會對實際應(yīng)用產(chǎn)生極大的危害，如長時間未響應(yīng)，大量事務(wù)失敗等。

TM鎖(表鎖)
當(dāng)事務(wù)獲得行鎖后，此事務(wù)也將自動獲得該行的表鎖(共享鎖),以防止其它事務(wù)進行DDL語句影響記錄行的更新。事務(wù)也可以在進行過程中獲得共享鎖或排它鎖，只有當(dāng)事務(wù)顯示使用LOCK TABLE語 句顯示的定義一個排它鎖時，事務(wù)才會獲得表上的排它鎖,也可使用LOCK TABLE顯示的定義一個表級的共享鎖(LOCK TABLE具體用法請參考相關(guān)文檔)。
TM鎖包括了SS、SX、S、X 等多種模式，在數(shù)據(jù)庫中用0－6來表示。不同的SQL操作產(chǎn)生不同類型的TM鎖。



TX鎖（行鎖）
 當(dāng)事務(wù)執(zhí)行數(shù)據(jù)庫插入、更新、刪除操作時，該事務(wù)自動獲得操作 表中操作行的排它鎖。

對用戶的數(shù)據(jù)操縱，Oracle可以自動為操縱的數(shù)據(jù)進行加鎖，但如果有操縱授權(quán)，則為滿足并發(fā)操縱的需要另外實施加鎖。DML鎖可由一個用戶進程以顯式的方式加鎖，也可通過某些SQL語句隱含方式實現(xiàn)。 這部分屬于Manual Data Locks。

DML鎖有如下三種加鎖方式：
（1）、共享鎖方式（SHARE）
（2）、獨占鎖方式（EXCLUSIVE）
（3）、共享更新鎖（SHARE UPDATE）

其中：
SHARE，EXCLUSIVE用于TM鎖（表級鎖）
SHARE UPDATE用于TX鎖（行級鎖）。

（1）共享方式的表級鎖（Share）
共享方式的表級鎖是對表中的所有數(shù)據(jù)進行加鎖，該鎖用于保護查詢數(shù)據(jù)的一致性，防止其它用戶對已加鎖的表進行更新。其它用戶只能對該表再施加共享方式的鎖，而不能再對該表施加獨占方式的鎖，共享更新鎖可以再施加，但不允許持有共享更新封鎖的進程做更新。共享該表的所有用戶只能查詢表中的數(shù)據(jù)，但不能更新。

共享方式的表級鎖只能由用戶用SQL語句來設(shè)置，基語句格式如下：　
　 LOCK TABLE <表名>[,<表名>]...　 IN SHARE MODE [NOWAIT]　　
執(zhí)行該語句，對一個或多個表施加共享方式的表封鎖。當(dāng)指定了選擇項NOWAIT，若該鎖暫時不能施加成功，則返回并由用戶決定是進行等待，還是先去執(zhí)行別的語句。

持有共享鎖的事務(wù)，在出現(xiàn)如下之一的條件時，便釋放其共享鎖：
A、執(zhí)行COMMIT或ROLLBACK語句。
B、退出數(shù)據(jù)庫（LOG　OFF）。
C、程序停止運行。

共享方式表級鎖常用于一致性查詢過程，即在查詢數(shù)據(jù)期間表中的數(shù)據(jù)不發(fā)生改變。

 
（2）獨占方式表級鎖（Exclusive）
獨占方式表級鎖是用于加鎖表中的所有數(shù)據(jù)，擁有該獨占方式表封鎖的用戶，即可以查詢該表，又可以更新該表，其它的用戶不能再對該表施加任何加鎖（包括共享、獨占或共享更新封鎖）。其它用戶雖然不能更新該表，但可以查詢該表。

獨占方式的表封鎖可通過如下的SQL語句來顯示地獲得：
LOCK TABLE <表名>[,<表名>].... IN EXCLUSIVE MODE [NOWAIT]
獨占方式的表級鎖也可以在用戶執(zhí)行DML語句INSERT、UPDATE、DELETE時隱含獲得。

擁有獨占方式表封鎖的事務(wù)，在出現(xiàn)如下條件之一時，便釋放該封鎖：
（1）、執(zhí)行COMMIT或ROLLBACK語句。
（2）、退出數(shù)據(jù)庫（LOG OFF）
（3）、程序停止運行。

獨占方式封鎖通常用于更新數(shù)據(jù)，當(dāng)某個更新事務(wù)涉及多個表時，可減少發(fā)生死鎖。

 
（3）共享更新加鎖方式（Share Update）
共享更新加鎖是對一個表的一行或多行進行加鎖，因而也稱作行級加鎖。表級加鎖雖然保證了數(shù)據(jù)的一致性，但卻減弱了操作數(shù)據(jù)的并行性。行級加鎖確保在用戶取得被更新的行到該行進行更新這段時間內(nèi)不被其它用戶所修改。因而行級鎖即可保證數(shù)據(jù)的一致性又能提高數(shù)據(jù)操作的迸發(fā)性。

可通過如下的兩種方式來獲得行級封鎖：
（1）、執(zhí)行如下的SQL封鎖語句，以顯示的方式獲得：
       LOCK TABLE <表名>[,<表名>].... IN SHARE UPDATE　MODE [NOWAIT]
（2）、用如下的SELECT ...FOR UPDATE語句獲得：
       SELECT <列名>[,<列名>]...FROM <表名> WHERE <條件> FOR UPDATE OF <列名>[,<列名>].....[NOWAIT]

一旦用戶對某個行施加了行級加鎖，則該用戶可以查詢也可以更新被加鎖的數(shù)據(jù)行，其它用戶只能查詢但不能更新被加鎖的數(shù)據(jù)行．如果其它用戶想更新該表中的數(shù)據(jù)行，則也必須對該表施加行級鎖．即使多個用戶對一個表均使用了共享更新，但也不允許兩個事務(wù)同時對一個表進行更新，真正對表進行更新時，是以獨占方式鎖表，一直到提交或復(fù)原該事務(wù)為止。行鎖永遠(yuǎn)是獨占方式鎖。

當(dāng)出現(xiàn)如下之一的條件，便釋放共享更新鎖：
（1）、執(zhí)行提交（COMMIT）語句；
（2）、退出數(shù)據(jù)庫（LOG　OFF）
（3）、程序停止運行。

執(zhí)行ROLLBACK操作不能釋放行鎖。

1.2.3.2  DDL鎖（dictionary locks）

DDL鎖用于保護數(shù)據(jù)庫對象的結(jié)構(gòu)，如表、索引等的結(jié)構(gòu)定義。
DDL鎖又可以分為：排它DDL鎖、共享DDL鎖、分析鎖
 
（1） 排它DDL鎖：
創(chuàng)建、修改、刪除一個數(shù)據(jù)庫對象的DDL語句獲得操作對象的 排它鎖。如使用alter table語句時，為了維護數(shù)據(jù)的完成性、一致性、合法性，該事務(wù)獲得一排它DDL鎖。
（2） 共享DDL鎖：
需在數(shù)據(jù)庫對象之間建立相互依賴關(guān)系的DDL語句通常需共享獲得DDL鎖。如創(chuàng)建一個包，該包中的過程與函數(shù)引用了不同的數(shù)據(jù)庫表，當(dāng)編譯此包時，該事務(wù)就獲得了引用表的共享DDL鎖。
（3） 分析鎖：
ORACLE使用共享池存儲分析與優(yōu)化過的SQL語句及PL/SQL程序，使運行相同語句的應(yīng)用速度更快。一個在共享池中緩存的對象獲得它所引用數(shù)據(jù)庫對象的分析鎖。分析鎖是一種獨特的DDL鎖類型，ORACLE使用它追蹤共享池對象及它所引用數(shù)據(jù)庫對象之間的依賴關(guān)系。當(dāng)一個事務(wù)修改或刪除了共享池持有分析鎖的數(shù)據(jù)庫對象時，ORACLE使共享池中的對象作廢，下次在引用這條SQL/PLSQL語 句時，ORACLE重新分析編譯此語句。

DDL級加鎖也是由ORACLE　RDBMS來控制，它用于保護數(shù)據(jù)字典和數(shù)據(jù)定義改變時的一致性和完整性。它是系統(tǒng)在對SQL定義語句作語法分析時自動地加鎖，無需用戶干予。

字典/語法分析加鎖共分三類：
（1）字典操作鎖：
用于對字典操作時，鎖住數(shù)據(jù)字典，此封鎖是獨占的，從而保護任何一個時刻僅能對一個字典操作。
（2）字典定義鎖：
用于防止在進行字典操作時又進行語法分析，這樣可以避免在查詢字典的同時改動某個表的結(jié)構(gòu)。
（3）表定義鎖：
用于一個SQL語句正當(dāng)訪問某個表時，防止字典中與該表有關(guān)的項目被修改。
 
Automatic Locks in DDL Operations
http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/ap_locks002.htm#SQLRF55509

A data dictionary (DDL) lock protects the definition of a schema object while an ongoing DDL operation acts on or refers to the object. Only individual schema objects that are modified or referenced are locked during DDL operations. The database never locks the whole data dictionary.

Oracle Database acquires a DDL lock automatically on behalf of any DDL transaction requiring it. Users cannot explicitly request DDL locks. For example, if a user creates a stored procedure, then Oracle Database automatically acquires DDL locks for all schema objects referenced in the procedure definition. The DDL locks prevent these objects from being altered or dropped before procedure compilation is complete.

Exclusive DDL Locks

An exclusive DDL lock prevents other sessions from obtaining a DDL or DML lock. Most DDL operations, except for those described in "Share DDL Locks", require exclusive DDL locks for a resource to prevent destructive interference with other DDL operations that might modify or reference the same schema object. For example, DROP TABLE is not allowed to drop a table while ALTER TABLE is adding a column to it, and vice versa.

Exclusive DDL locks last for the duration of DDL statement execution and automatic commit. During the acquisition of an exclusive DDL lock, if another DDL lock is already held on the schema object by another operation, then the acquisition waits until the older DDL lock is released and then proceeds.

Share DDL Locks

A share DDL lock for a resource prevents destructive interference with conflicting DDL operations, but allows data concurrency for similar DDL operations.

For example, when a CREATE PROCEDURE statement is run, the containing transaction acquires share DDL locks for all referenced tables. Other transactions can concurrently create procedures that reference the same tables and acquire concurrent share DDL locks on the same tables, but no transaction can acquire an exclusive DDL lock on any referenced table.

A share DDL lock lasts for the duration of DDL statement execution and automatic commit. Thus, a transaction holding a share DDL lock is guaranteed that the definition of the referenced schema object remains constant during the transaction.

Breakable Parse Locks

A parse lock is held by a SQL statement or PL/SQL program unit for each schema object that it references. Parse locks are acquired so that the associated shared SQL area can be invalidated if a referenced object is altered or dropped. A parse lock is called a breakable parse lock because it does not disallow any DDL operation and can be broken to allow conflicting DDL operations.

A parse lock is acquired in the shared pool during the parse phase of SQL statement execution. The lock is held as long as the shared SQL area for that statement remains in the shared pool.

1.2.3.2  System Locks
System Locks
http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/consist.htm#CIHJBIBB

Oracle Database uses various types of system locks to protect internal database and memory structures. These mechanisms are inaccessible to users because users have no control over their occurrence or duration.

Latches

Latches are simple, low-level serialization mechanisms that coordinate multiuser access to shared data structures, objects, and files. Latches protect shared memory resources from corruption when accessed by multiple processes. Specifically, latches protect data structures from the following situations:
（1）Concurrent modification by multiple sessions
（2）Being read by one session while being modified by another session
（3）Deallocation (aging out) of memory while being accessed

Typically, a single latch protects multiple objects in the SGA. For example, background processes such as DBWn and LGWR allocate memory from the shared poolto create data structures. To allocate this memory, these processes use a shared pool latch that serializes access to prevent two processes from trying to inspect or modify the shared pool simultaneously. After the memory is allocated, other processes may need to access shared pool areas such as the library cache, which is required for parsing. In this case, processes latch only the library cache, not the entire shared pool.

Unlike enqueue latches such as row locks, latches do not permit sessions to queue. When a latch becomes available, the first session to request the latch obtains exclusive access to it. Latch spinning occurs when a process repeatedly requests a latch in a loop, whereas latch sleeping occurs when a process releases the CPU before renewing the latch request.

Typically, an Oracle process acquires a latch for an extremely short time while manipulating or looking at a data structure. For example, while processing a salary update of a single employee, the database may obtain and release thousands of latches. The implementation of latches is operating system-dependent, especially in respect to whether and how long a process waits for a latch.

An increase in latching means a decrease in concurrency. For example, excessive hard parse operations create contention for the library cache latch. TheV$LATCH view contains detailed latch usage statistics for each latch, including the number of times each latch was requested and waited for.

Mutexes

A mutual exclusion object (mutex) is a low-level mechanism that prevents an object in memory from aging out or from being corrupted when accessed by concurrent processes. A mutex is similar to a latch, but whereas a latch typically protects a group of objects, a mutex protects a single object.

Mutexes provide several benefits:
（1）A mutex can reduce the possibility of contention.
Because a latch protects multiple objects, it can become a bottleneck when processes attempt to access any of these objects concurrently. By serializing access to an individual object rather than a group, a mutex increases availability.
（2）A mutex consumes less memory than a latch.
（3）When in shared mode, a mutex permits concurrent reference by multiple sessions.


Internal Locks

Internal locks are higher-level, more complex mechanisms than latches and mutexes and serve various purposes. The database uses the following types of internal locks:

（1）Dictionary cache locks

These locks are of very short duration and are held on entries in dictionary caches while the entries are being modified or used. They guarantee that statements being parsed do not see inconsistent object definitions. Dictionary cache locks can be shared or exclusive. Shared locks are released when the parse is complete, whereas exclusive locks are released when the DDL operation is complete.

（2）File and log management locks

These locks protect various files. For example, an internal lock protects the control file so that only one process at a time can change it. Another lock coordinates the use and archiving of the online redo log files. Data files are locked to ensure that multiple instances mount a database in shared mode or that one instance mounts it in exclusive mode. Because file and log locks indicate the status of files, these locks are necessarily held for a long time.

（3）Tablespace and undo segment locks

These locks protect tablespaces and undo segments. For example, all instances accessing a database must agree on whether a tablespace is online or offline. Undo segments are locked so that only one database instance can write to a segment.

二． Latch 和 等待
Latch 屬于System Locks. 在前面的內(nèi)容里里，已有相關(guān)的說明。 Latch 是Oracle 為保護內(nèi)存結(jié)構(gòu)而發(fā)明的一種資源。

在Oracle 復(fù)雜的內(nèi)存結(jié)構(gòu)中，比如SGA中，各種數(shù)據(jù)被反復(fù)從磁盤讀取到內(nèi)存，又被重新寫回到磁盤上，如果有并發(fā)的用戶做相同的事情，Oracle必須使用一種機制，來保證數(shù)據(jù)在讀取的時候，只能由一個會話來完成，這種保護機制就是Latch。

并發(fā)（concurrency）：是說有超過兩個以上的用戶對同樣的數(shù)據(jù)做修改（可能包括插入，刪除和修改）。

并行（parallel）：是說將一件事情分成很多小部分，讓每一部分同時執(zhí)行，最后將執(zhí)行結(jié)果匯總成最終結(jié)果。

可以把Latch 理解為一種輕量級的鎖，它不會造成阻塞，只會導(dǎo)致等待。 阻塞是一種系統(tǒng)設(shè)計上的問題，等待是一種系統(tǒng)資源爭用的問題。

如果發(fā)現(xiàn)系統(tǒng)中經(jīng)常由于Lock 導(dǎo)致用戶等待，這時需要考慮系統(tǒng)在邏輯設(shè)計上是否有問題，比如多用戶對主鍵的刪除或者修改，是否有用戶使用select … for update這樣的語法，外鍵是否創(chuàng)建索引的因素。 這些因素是需要結(jié)合系統(tǒng)的業(yè)務(wù)邏輯性來進行數(shù)據(jù)庫對象設(shè)計的。

如果發(fā)現(xiàn)系統(tǒng)慢是因為很多的Latch爭用，就要考慮系統(tǒng)及數(shù)據(jù)庫自身設(shè)計上是否存在問題，比如是否使用綁定變量，是否存在熱快，數(shù)據(jù)存儲參數(shù)設(shè)計是否合理等因素。

導(dǎo)致Latch爭用而等待的原因非常多，內(nèi)存中很多資源都可能存在爭用。 最常見的兩類latch爭用如下：
（1）共享池中的Latch爭用。
（2）數(shù)據(jù)緩沖池中的latch爭用。

Oracle 內(nèi)存 架構(gòu) 詳解
http://blog.csdn.net/xujinyang/article/details/6829522

 
2.1 共享池中的Latch爭用
共享池中如果存在大量的SQL被反復(fù)分析，就會造成很大的Latch爭用和長時間的等待，最常見的現(xiàn)象就是沒有綁定變量。

最常見的集中共享池里的Latch是 library cache。 可以通過一下SQL 來查詢：select * from v$latchname where name like 'library cache%';

在分析系統(tǒng)性能時，如果看到有l(wèi)ibrary cache 這樣的Latch爭用，就可以斷定是共享池中出現(xiàn)了問題，這種問題基本是由SQL語句導(dǎo)致的，比如沒有綁定變量或者一些存儲過程被反復(fù)分析。

 
2.2 數(shù)據(jù)緩沖池Latch爭用
訪問頻率非常高的數(shù)據(jù)塊被稱為熱快（Hot Block），當(dāng)很多用戶一起去訪問某幾個數(shù)據(jù)塊時，就會導(dǎo)致一些Latch爭用，最常見的latch爭用有：
（1）buffer busy waits
（2）cache buffer chain

這兩個Latch的爭用分別發(fā)生在訪問數(shù)據(jù)塊的不同時刻。
    
Oracle 常見的33個等待事件
http://blog.csdn.net/xujinyang/article/details/6882035

當(dāng)一個會話需要去訪問一個內(nèi)存塊時，它首先要去一個像鏈表一樣的結(jié)構(gòu)中去搜索這個數(shù)據(jù)塊是否在內(nèi)存中，當(dāng)會話訪問這個鏈表的時候需要獲得一個Latch，如果獲取失敗，將會產(chǎn)生Latch cache buffer chain 等待，導(dǎo)致這個等待的原因是訪問相同的數(shù)據(jù)塊的會話太多或者這個列表太長（如果讀到內(nèi)存中的數(shù)據(jù)太多，需要管理數(shù)據(jù)塊的hash列表就會很長，這樣會話掃描列表的時間就會增加，持有chache buffer chain latch的時間就會變長，其他會話獲得這個Latch的機會就會降低，等待就會增加）。

當(dāng)一個會話需要訪問一個數(shù)據(jù)塊，而這個數(shù)據(jù)塊正在被另一個用戶從磁盤讀取到內(nèi)存中或者這個數(shù)據(jù)塊正在被另一個會話修改時，當(dāng)前的會話就需要等待，就會產(chǎn)生一個buffer busy waits等待。

產(chǎn)生這些Latch爭用的直接原因是太多的會話去訪問相同的數(shù)據(jù)塊導(dǎo)致熱快問題，造成熱快的原因可能是數(shù)據(jù)庫設(shè)置導(dǎo)致或者重復(fù)執(zhí)行的SQL 頻繁訪問一些相同的數(shù)據(jù)塊導(dǎo)致。

熱快產(chǎn)生的原因不盡相同，按照數(shù)據(jù)塊的類型，可以分成一下幾種類型，不同熱快類型處理的方式都是不同的，如下：
（1）表數(shù)據(jù)塊
（2）索引數(shù)據(jù)塊
（3）索引根數(shù)據(jù)塊
（4）文件頭數(shù)據(jù)塊

2.2.1 表數(shù)據(jù)塊
比如在OLTP系統(tǒng)中，對于一些小表，會給出某些數(shù)據(jù)塊被頻繁查詢或者修改的操作，這時候，這些被頻繁訪問的數(shù)據(jù)塊就會變成熱塊，導(dǎo)致內(nèi)存中Latch爭用。
如果出現(xiàn)這樣熱塊的情況，并且表不太大，一個方法是可以考慮將表數(shù)據(jù)分布在更多的數(shù)據(jù)塊上，減少數(shù)據(jù)塊被多數(shù)會話同時訪問的頻率。

可以通過一下命令將每個數(shù)據(jù)塊存放記錄的數(shù)量減少到最少： Alter table minimize records_per_block;

我們把數(shù)據(jù)分布到更多的數(shù)據(jù)塊上，大大降低了一個數(shù)據(jù)塊被重復(fù)讀取的概率。 但是這種方法的缺點很明顯，就是降低了數(shù)據(jù)的性能，在這種情況下，訪問相同的數(shù)據(jù)意味著需要讀取更多的數(shù)據(jù)塊，性能會有所降低。


2.2.2 索引數(shù)據(jù)塊
這樣的情況通常發(fā)生在一個RAC架構(gòu)里，某個表的索引鍵值出現(xiàn)典型的“右傾”現(xiàn)象，比如一個表的主鍵使用一個序列來生成鍵值，那么在這個主鍵在索引數(shù)據(jù)塊上的鍵值就是以一種順序遞增的方式排列的，比如：1，2，3，4，5….，由于這些鍵值分布得非常接近，當(dāng)許多用戶在RAC的不同實例來向表中插入主鍵時，就會出現(xiàn)相同的索引數(shù)據(jù)塊在不同實例的內(nèi)存中被調(diào)用，形成一種數(shù)據(jù)塊的爭用，對于這種情況，使用反向索引可以緩解這種爭用。 反向索引是將從前的索引鍵值按照反向的方式排列，在正常的主鍵B-Tree索引中，鍵值會按照大小的順序排列，比如：1234，反向索引，鍵值就變成4321.

這樣，本來是放在相同的索引數(shù)據(jù)塊上的鍵值，現(xiàn)在分布熬不同的數(shù)據(jù)塊上，這樣用戶在RAC不同的實例上插入的主鍵值因為分布在不同的數(shù)據(jù)塊上，所以不會導(dǎo)致熱塊的產(chǎn)生，這基本是反向索引被使用的唯一情況。

 反向索引使用場合之所以如此受限制，是因為它丟棄了B-Tree 索引的一個最重要的功能：Index range scan。
索引訪問方式中，Index range scan這個方式最常見，但是反向索引卻不能使用這個功能，因為反向索引已經(jīng)把鍵值的排列順序打亂，當(dāng)按照鍵值順序查找一個范圍時，在反向索引中，由于鍵值被反向存儲，這些值已經(jīng)不是連續(xù)存放的了。 所以Index range scan 的方式在反向索引中沒有任何意義。在反向索引中只能通過全表掃描或者全索引掃描的方式來實現(xiàn)。 這就是反向索引的一個非常嚴(yán)重的缺陷。


2.2.3 索引根數(shù)據(jù)塊
熱塊也可能發(fā)生在索引的根數(shù)據(jù)塊上。 在B-Tree索引里，當(dāng)Oracle 訪問一個索引鍵值時，首先訪問索引的根，然后是索引的分支，最后才是索引的葉塊。索引的鍵值就是存儲在葉塊上面。 如圖：

       
當(dāng)索引的根，枝數(shù)據(jù)都集中在幾個數(shù)據(jù)塊上時，比如D，G所在的枝數(shù)據(jù)塊，當(dāng)用戶訪問的范圍從A-F，都會訪問這個數(shù)據(jù)塊，如果很多用戶頻繁的訪問這個范圍的索引鍵值，有可能導(dǎo)致這個枝數(shù)據(jù)塊變成熱快。

當(dāng)出現(xiàn)這種現(xiàn)象時，可以考慮對索引做分區(qū)，以便于使用這些根，枝數(shù)據(jù)塊分布到不同的數(shù)據(jù)段（分區(qū)）上，減少數(shù)據(jù)塊的并行訪問的密度，從而避免由于索引根，枝數(shù)據(jù)塊太集中導(dǎo)致熱塊產(chǎn)生。


2.2.4  段頭數(shù)據(jù)塊
在Oracle 9i 之前，數(shù)據(jù)塊的空間使用情況需要手工來管理，在每個數(shù)據(jù)段的段頭有一個或者幾個Free list 列表，用于存放段中哪些數(shù)據(jù)塊可以使用。

當(dāng)數(shù)據(jù)塊的數(shù)據(jù)達(dá)到數(shù)據(jù)塊總?cè)萘康囊粋€比例時（PCT_FREE 參數(shù)決定），數(shù)據(jù)塊就會從Free list中刪除，這個數(shù)據(jù)塊就不能在插入數(shù)據(jù)。

當(dāng)數(shù)據(jù)塊的空間減少到一個比例時（PCT_USED參數(shù)決定），數(shù)據(jù)塊就會被放到Free list列表中，這些數(shù)據(jù)庫可以被用來插入數(shù)據(jù)。

在OLTP系統(tǒng)中，一些數(shù)據(jù)段的Free List可能會是一個訪問很頻繁的數(shù)據(jù)塊，比如這個數(shù)據(jù)庫上有些表有很多刪除，插入的動作，很多會話需要不斷訪問這些數(shù)據(jù)塊的Free List列表，以便獲得需要的數(shù)據(jù)塊信息。 此時這個數(shù)據(jù)塊（稱作段頭數(shù)據(jù)塊）就會變成一個熱塊，此時內(nèi)存中就會出現(xiàn)如cacha buffer chain這樣的Latch等待事件。

當(dāng)出現(xiàn)這個問題時，一個常見的解決方法是增加Free List的數(shù)量，以便于分散會話訪問數(shù)據(jù)塊的密度。

從Oracle 9i開始，引入了一個自動段管理的技術(shù)ASSM（Automatic Segment Space Management： ASSM），它讓Oracle 自動管理“Free List”。 實際上在ASSM里，已經(jīng)沒有Free List 這樣的結(jié)構(gòu)，Oracle 使用位圖方式來標(biāo)記數(shù)據(jù)塊是否可用，這種數(shù)據(jù)塊的空間管理方式比用一個列表來管理效率更高。

對于OLTP系統(tǒng)，表的DML操作非常密集，對于這些表，使用ASSM方式來管理會比人工管理更加方便和準(zhǔn)確，能有效的避免段頭變成熱塊。

對于OLAP系統(tǒng)，這個參數(shù)并沒有太大的實際意義，因為在這樣的數(shù)據(jù)庫中，很少有表發(fā)生頻繁的修改，OLAP系統(tǒng)主要的工作是報表和海量數(shù)據(jù)的批量加載。

上述就是小編為大家分享的ORACLE 鎖機制是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。