1.2 鎖的分類

1.2.1. 按使用者與系統劃分，可以分為自動鎖與顯示鎖

a) 自動鎖（Automatic Locks）：當進行一項資料庫操作時，預設情況下，系統自動為此資料庫操作獲得所有有必要的鎖。自動鎖分DML鎖，DDL鎖，system locks。

b) 顯示鎖（Manual Data Locks）：某些情況下，需要使用者顯示的鎖定資料庫操作要用到的資料，才能使資料庫操作執行得更好，顯示鎖是使用者為資料庫物件設定的。

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。

Lock	Description
DML Locks	Protect data. For example, table locks lock entire tables, while row locks lock selected rows. See .
DDL Locks	Protect the structure of schema objects—for example, the dictionary definitions of tables and views. See .
System Locks	Protect internal database structures such as data files. Latches, mutexes, and internal locks are entirely automatic. See .

1.2.3.1 DML鎖

DML鎖用於控制併發事務中的資料操縱，保證資料的一致性和完整性。DML 鎖主要用於保護併發情況下的資料完整性。它又分為：

（1）TM鎖（表級鎖）

（2）TX鎖（事務鎖或行級鎖）

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

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

TM鎖(表鎖)

當事務獲得行鎖後，此事務也將自動獲得該行的表鎖(共享鎖),以防止其它事務進行DDL語句影響記錄行的更新。事務也可以在進行過程中獲得共享鎖或排它鎖，只有當事務顯示使用LOCK TABLE語句顯示的定義一個排它鎖時，事務才會獲得表上的排它鎖,也可使用LOCK TABLE顯示的定義一個表級的共享鎖(LOCK TABLE具體用法請參考相關文件)。

TM鎖包括了SS、SX、S、X 等多種模式，在資料庫中用0－6來表示。不同的SQL操作產生不同型別的TM鎖。

TM鎖型別表

鎖模式	鎖描述	解釋	SQL操作
0	none
1	NULL	空	Select
2	SS(Row-S)	行級共享鎖，其他物件只能查詢這些資料行	Select for update、Lock for update、Lock row share
3	SX(Row-X)	行級排它鎖，在提交前不允許做DML操作	Insert、Update、Delete、Lock row share
4	S(Share)	共享鎖: 阻止其他DML操作	Create index、Lock share
5	SSX(S/Row-X)	共享行級排它鎖：阻止其他事務操作	Lock share row exclusive
6	X(Exclusive)	排它鎖：獨立訪問使用	Alter table、Drop able、Drop index、Truncate table 、Lock exclusive

TX鎖（事務鎖或行級鎖）

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

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

DML鎖有如下三種加鎖方式：

其中：

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語句正當訪問某個表時，防止字典中與該表有關的專案被修改。

A data dictionary (DDL) lock protects the definition of a 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 .

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 , 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 , 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 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 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

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, such as DBWn and LGWR allocate memory from the to 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 , 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 operations create contention for the library cache latch. The V$LATCHview 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 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 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.

二．死鎖

A situation in which two or more users are waiting for data locked by each other. Such deadlocks are rare in Oracle Database.

定義: 當兩個使用者希望持有對方的資源時就會發生死鎖.

即兩個使用者互相等待對方釋放資源時,oracle認定為產生了死鎖,在這種情況下,將以犧牲一個使用者作為代價,另一個使用者繼續執行,犧牲的使用者的事務將回滾.

例子：

1：使用者1對A表進行Update，沒有提交。

2：使用者2對B表進行Update，沒有提交。

此時雙反不存在資源共享的問題。

3：如果使用者2此時對A表作update,則會發生阻塞，需要等到使用者一的事物結束。

4：如果此時使用者1又對B表作update，則產生死鎖。此時Oracle會選擇其中一個使用者進行會滾，使另一個使用者繼續執行操作。

起因:

Oracle的死鎖問題實際上很少見，如果發生，基本上都是不正確的程式設計造成的，經過調整後，基本上都會避免死鎖的發生。

　在Oracle系統中能自動發現死鎖，並選擇代價最小的，即完成工作量最少的事務予以撤消，釋放該事務所擁有的全部鎖，記其它的事務繼續工作下去。

　　從系統效能上考慮，應該儘可能減少資源競爭，增大吞吐量，因此使用者在給併發操作加鎖時，應注意以下幾點：

　　1、對於UPDATE和DELETE操作，應只鎖要做改動的行，在完成修改後立即提交。

　　2、當多個事務正利用共享更新的方式進行更新，則不要使用共享封鎖，而應採用共享更新鎖，這樣其它使用者就能使用行級鎖，以增加並行性。

　　3、儘可能將對一個表的操作的併發事務施加共享更新鎖，從而可提高並行性。

　　4、在應用負荷較高的期間，不宜對基礎資料結構（表、索引、簇和檢視）進行修改

如果死鎖不能自動釋放，就需要我們手工的kill session。步驟如下：

1. 檢視有無死鎖物件，如有kill session

/* Formatted on 2010/8/18 9:51:59 (QP5 v5.115.810.9015) */

SELECT 'alter system kill session ''' || sid || ',' || serial# || ''';' "Deadlock"

FROM v$session

WHERE sid IN (SELECT sid

FROM v$lock

WHERE block = 1);

如果有，會返回類似與如下的資訊：

alter system kill session '132,731';

alter system kill session '275,15205';

alter system kill session '308,206';

alter system kill session '407,3510';

kill session：

執行alter system kill session '391,48398'(sid為391);

注意：應當注意對於sid在100以下的應當謹慎，可能該程式對應某個application，如對應某個事務,可以kill.

2. 檢視導致死鎖的SQL

/* Formatted on 2010/8/18 0:06:11 (QP5 v5.115.810.9015) */

SELECT s.sid, q.sql_text

FROM v$sqltext q, v$session s

WHERE q.address = s.sql_address AND s.sid = &sid -- 這個&sid 是第一步查詢出來的

ORDER BY piece;

返回：

SID SQL_TEXT

---------- ----------------------------------------------------------------

77 UPDATE PROFILE_USER SET ID=1,COMPANY_ID=2,CUSTOMER_ID=3,NAMED

77 _INSURED_ID=4,LOGIN=5,ROLE_ID=6,PASSWORD=7,EMAIL=8,TIME_ZON

77 E=9 WHERE PROFILE_USER.ID=:34

3 rows selected.

3. 檢視誰鎖了誰

/* Formatted on 2010/8/18 0:07:49 (QP5 v5.115.810.9015) */

SELECT s1.username

|| '@'

|| s1.machine

|| ' ( SID='

|| s1.sid

|| ' ) is blocking '

|| s2.username

|| '@'

|| s2.machine

|| ' ( SID='

|| s2.sid

|| ' ) '

AS blocking_status

FROM v$lock l1,

v$session s1,

v$lock l2,

v$session s2

WHERE s1.sid = l1.sid

AND s2.sid = l2.sid

AND l1.BLOCK = 1

AND l2.request > 0

AND l1.id1 = l2.id1

AND l2.id2 = l2.id2;

或者

/* Formatted on 2010/8/18 0:03:46 (QP5 v5.115.810.9015) */

SELECT /*+ rule */

LPAD (' ', DECODE (l.xidusn, 0, 3, 0))

|| l.oracle_username

User_name,

o.owner,

o.object_name,

o.object_type,

s.sid,

s.serial#

FROM v$locked_object l, dba_objects o, v$session s

WHERE l.object_id = o.object_id AND l.session_id = s.sid

ORDER BY o.object_id, xidusn DESC

三．鎖和阻塞

3.1 相關概念

通常來講，系統如果平時執行正常，突然會停止不動，多半是被阻塞（Blocked）住了。我們可以透過v$lock 這張檢視，看檢視阻塞的資訊。

SQL> desc v$lock;

名稱是否為空? 型別

----------------------------------------- -------- -----------------

ADDR RAW(4)

KADDR RAW(4)

SID NUMBER

TYPE VARCHAR2(2)

ID1 NUMBER

ID2 NUMBER

LMODE NUMBER

REQUEST NUMBER

CTIME NUMBER

BLOCK NUMBER

我們關注的比較多的是request 和 block 欄位。

如果某個request列是一個非0值，那麼它就是在等待一個鎖。如果block列是1，這個SID 就持有了一個鎖，並且阻塞別人獲得這個鎖。這個鎖的型別由TYPE 欄位定義。鎖的模式有LMODE 欄位定義，ID1和ID2 欄位定義了這個鎖的相關資訊。ID1相同，就代表指向同一個資源。這樣就有可能有加鎖者和等待者。 LMODE 的6中模式參考上面的TM鎖型別表。

可以結合v$lock 和 v$session 檢視來查詢相關的資訊：

/* Formatted on 2010/8/18 10:03:08 (QP5 v5.115.810.9015) */

SELECT sn.username,

m.SID,

sn.SERIAL#,

m.TYPE,

DECODE (m.lmode,

0,

'None',

1,

'Null',

2,

'Row Share',

3,

'Row Excl.',

4,

'Share',

5,

'S/Row Excl.',

6,

'Exclusive',

lmode,

LTRIM (TO_CHAR (lmode, '990')))

lmode,

DECODE (m.request,

0,

'None',

1,

'Null',

2,

'Row Share',

3,

'Row Excl.',

4,

'Share',

5,

'S/Row Excl.',

6,

'Exclusive',

request,

LTRIM (TO_CHAR (m.request, '990')))

request,

m.id1,

m.id2

FROM v$session sn, v$lock m

WHERE (sn.SID = m.SID AND m.request != 0) --存在鎖請求，即被阻塞

OR (sn.SID = m.SID --不存在鎖請求，但是鎖定的物件被其他會話請求鎖定

AND m.request = 0 AND lmode != 4

AND (id1, id2) IN

(SELECT s.id1, s.id2

FROM v$lock s

WHERE request != 0

AND s.id1 = m.id1

AND s.id2 = m.id2))

ORDER BY id1, id2, m.request;

或者

/* Formatted on 2010/8/18 0:03:02 (QP5 v5.115.810.9015) */

SELECT /*+ rule */

s .username,

DECODE (l.TYPE, 'TM', 'TABLE LOCK', 'TX', 'ROW LOCK', NULL)

LOCK_LEVEL,

o.owner,

o.object_name,

o.object_type,

s.sid,

s.serial#,

s.terminal,

s.machine,

s.program,

s.osuser

FROM v$session s, v$lock l, dba_objects o

WHERE l.sid = s.sid AND l.id1 = o.object_id(+) AND s.username IS NOTNULL

3.2 引起阻塞的幾種常見情況

（1）DML語句引起阻塞

（2）外來鍵沒有建立索引

3.2.1 DML 語句

當一個會話保持另一個會話正在請求的資源上的鎖定時，就會發生阻塞。被阻塞的會話將一直掛起，直到持有鎖的會話放棄鎖定的資源為止。4個常見的dml語句會產生阻塞

INSERT

UPDATE

DELETE

SELECT…FOR UPDATE

INSERT

Insert發生阻塞的唯一情況就是使用者擁有一個建有主鍵約束的表。當2個的會話同時試圖向表中插入相同的資料時，其中的一個會話將被阻塞，直到另外一個會話提交或會滾。一個會話提交時，另一個會話將收到主鍵重複的錯誤。回滾時，被阻塞的會話將繼續執行。

Update 和 Delete

UPDATE 和DELETE當執行Update和delete操作的資料行已經被另外的會話鎖定時，將會發生阻塞，直到另一個會話提交或會滾。

Select …for update

當一個使用者發出select..for update的錯作準備對返回的結果集進行修改時，如果結果集已經被另一個會話鎖定，

此時Oracle已經對返回的結果集上加了排它的行級鎖，所有其他對這些資料進行的修改或刪除操作都必須等待這個鎖的釋放(操作commit或rollback.)，產生的外在現象就是其他的操作將發生阻塞.

同樣這個查詢的事務將會對該表加表級鎖，不允許對該表的任何ddl操作，否則將會報出Ora-00054:resource busy and acquire with nowait specified.

可以透過發出 select… for update nowait的語句來避免發生阻塞，如果資源已經被另一個會話鎖定，則會返回以下錯誤：Ora-00054:resource busy and acquire with nowait specified.

3.2.2 外來鍵沒有建立索引

如果系統中有主，外來鍵引用關係，並且滿足一下三個條件中的任意一個，那麼就應該考慮給外來鍵欄位建立索引，否則系統的效能可能會下降甚至阻塞。

（1）主表上有頻繁的刪除操作

（2）主鍵上有頻繁的修改操作。

（3）業務上經常會出現主表和從表做關聯查詢的情況。

第一和第二個條件操作的時候，主表會在從表上建立一個鎖定，以保證主表主鍵的修改不會導致從表的資料在引用上出現問題，這是一個資料引用完整性的要求。如果主表上經常出現這樣的刪除或者是對主鍵列進行修改的操作，或者每次操作的記錄數很多，都將會造成從表長時間被鎖定，而影響其他使用者的正常操作。比如主表每次刪除1000行資料，它就需要掃描從表1000次，以確定每一行記錄的改變都不會造成從表資料在引用上的不完整。

oracle 鎖簡述

相關文章

oracle 鎖 簡述

相關文章

oracle 鎖簡述