ORACLE 鎖機制是怎樣的

這期內容當中小編將會給大家帶來有關ORACLE 鎖機制是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

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

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

加鎖是實現數據庫并發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前，先向系統發出請求，對其加鎖。加鎖后事務就對該數據對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數據對象進行更新操作。

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


1.2 鎖的分類

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

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 )： 共享鎖使一個事務對特定數據庫資源進行共享訪問——另一事務也可對此資源進行訪問或獲得相同共享鎖。共享鎖為事務提供高并發性，但如拙劣的事務設計+共享鎖容易造成死鎖或數據更新丟失。
b) 排它鎖( X)： 事務設置排它鎖后，該事務單獨獲得此資源，另一事務不能在此事務提交之前獲得相同對象的共享鎖或排它鎖。

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


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

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

在數據行上只有X鎖（排他鎖）。在Oracle數據庫中，當一個事務首次發起一個DML語句時就獲得一個TX鎖，該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行DML語句時，第一個會話在該條記錄上加鎖，其他的會話處于等待狀態。當第一個會話提交后，TX鎖被釋放，其他會話才可以加鎖。

當Oracle數據庫發生TX鎖等待時，如果不及時處理常常會引起Oracle數據庫掛起，或導致死鎖的發生，產生ORA-600的錯誤。這些現象都會對實際應用產生極大的危害，如長時間未響應，大量事務失敗等。

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



TX鎖（行鎖）
 當事務執行數據庫插入、更新、刪除操作時，該事務自動獲得操作 表中操作行的排它鎖。

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

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

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

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

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

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

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

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

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

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

獨占方式封鎖通常用于更新數據，當某個更新事務涉及多個表時，可減少發生死鎖。

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

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

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

當出現如下之一的條件，便釋放共享更新鎖：
（1）、執行提交（COMMIT）語句；
（2）、退出數據庫（LOG　OFF）
（3）、程序停止運行。

執行ROLLBACK操作不能釋放行鎖。

1.2.3.2  DDL鎖（dictionary locks）

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

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

字典/語法分析加鎖共分三類：
（1）字典操作鎖：
用于對字典操作時，鎖住數據字典，此封鎖是獨占的，從而保護任何一個時刻僅能對一個字典操作。
（2）字典定義鎖：
用于防止在進行字典操作時又進行語法分析，這樣可以避免在查詢字典的同時改動某個表的結構。
（3）表定義鎖：
用于一個SQL語句正當訪問某個表時，防止字典中與該表有關的項目被修改。
 
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. 在前面的內容里里，已有相關的說明。 Latch 是Oracle 為保護內存結構而發明的一種資源。

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

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

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

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

如果發現系統中經常由于Lock 導致用戶等待，這時需要考慮系統在邏輯設計上是否有問題，比如多用戶對主鍵的刪除或者修改，是否有用戶使用select … for update這樣的語法，外鍵是否創建索引的因素。 這些因素是需要結合系統的業務邏輯性來進行數據庫對象設計的。

如果發現系統慢是因為很多的Latch爭用，就要考慮系統及數據庫自身設計上是否存在問題，比如是否使用綁定變量，是否存在熱快，數據存儲參數設計是否合理等因素。

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

Oracle 內存 架構 詳解
http://blog.csdn.net/xujinyang/article/details/6829522

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

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

在分析系統性能時，如果看到有library cache 這樣的Latch爭用，就可以斷定是共享池中出現了問題，這種問題基本是由SQL語句導致的，比如沒有綁定變量或者一些存儲過程被反復分析。

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

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

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

當一個會話需要訪問一個數據塊，而這個數據塊正在被另一個用戶從磁盤讀取到內存中或者這個數據塊正在被另一個會話修改時，當前的會話就需要等待，就會產生一個buffer busy waits等待。

產生這些Latch爭用的直接原因是太多的會話去訪問相同的數據塊導致熱快問題，造成熱快的原因可能是數據庫設置導致或者重復執行的SQL 頻繁訪問一些相同的數據塊導致。

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

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

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

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


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

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

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


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

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

當出現這種現象時，可以考慮對索引做分區，以便于使用這些根，枝數據塊分布到不同的數據段（分區）上，減少數據塊的并行訪問的密度，從而避免由于索引根，枝數據塊太集中導致熱塊產生。


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

當數據塊的數據達到數據塊總容量的一個比例時（PCT_FREE 參數決定），數據塊就會從Free list中刪除，這個數據塊就不能在插入數據。

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

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

當出現這個問題時，一個常見的解決方法是增加Free List的數量，以便于分散會話訪問數據塊的密度。

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

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

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

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