1、鎖（Lock）的原則Oracle當中的鎖通常是業務層面的問題，鎖是為了在並發的情況下保證資料庫的一致性，因此沒有並發就沒有鎖。Oracle的鎖有如下幾個原則：
- 只有被修改時，行才會被鎖定，因為有UNDO的關係，讀不會產生行鎖。
- 當一條語句修改了一條記錄，只有這條記錄上被鎖定，在Oracle資料庫中不存在鎖定擴大。
- 當某行被修改時，它將阻塞別人對它的修改。
- 當一個事務修改一行時，將在這個行上加上行鎖（TX），用於阻止其它事務對相同行的修改。
- 讀永遠不會阻止寫，但唯一的例外，就是select ...for update
- 寫永遠不會阻塞讀。
- 當一行被修改後，Oracle通過復原段提供給資料的一致性讀。
- 在Oracle中，鎖不上稀缺資源，只是是資料區塊上的一個屬性而已。
2、TM鎖和TX鎖
- TM 表鎖，發生在insert,update,delete以及select for update操作時，目的是保證操作能夠正常進行，並且阻止其它人對錶執行DDL操作。
- TX鎖 事務鎖（行鎖）對於正在修改的資料，阻止其它會話進行修改。
TM鎖和TX鎖的對象不一樣，TM鎖針對錶，TX鎖針對行，如所示，對某一行進行修改，加兩個鎖，其中一個是在修改的行上加TX鎖，防止其它會話對該行的修改；另一個是在表上加TM鎖，防止表DDL被修改。 3、TM鎖的機種模式（lock mode）
This lock, also called a subshare table lock (SS), indicates that the transaction holding the lock on the table has locked rows in the table and
intends to update them. A row share lock is the least restrictive mode of table lock, offering the highest degree of concurrency for a table.
- Row Exclusive Table Lock (RX)---3
This lock, also called a subexclusive table lock (SX), generally indicates that the transaction holding the lock has updated table rows or issued
SELECT ... FOR UPDATE. An SX lock allows other transactions to query, insert, update, delete, or lock rows concurrently in the same table.
Therefore, SX locks allow multiple transactions to obtain simultaneous SX and subshare table locks for the same table.
A share table lock held by a transaction allows other transactions to query the table (without using SELECT ... FOR UPDATE), but updates are
allowed only if a single transaction holds the share table lock. Because multiple transactions may hold a share table lock concurrently,
holding this lock is not sufficient to ensure that a transaction can modify the table.
- Share Row Exclusive Table Lock (SRX) ---5
This lock, also called a share-subexclusive table lock (SSX), is more restrictive than a share table lock. Only one transaction at a time can
acquire an SSX lock on a given table. An SSX lock held by a transaction allows other transactions to query the table (except for SELECT ... FOR
UPDATE) but not to update the table.
- Exclusive Table Lock (X) ---6
This lock is the most restrictive, prohibiting other transactions from performing any type of DML statement or placing any type of lock on the
table. 上面摘自官方文檔，比較抽象，下面這個表格更容易理解： 3、示範幾種鎖定的例子首先，建立測試表t：
| SQL> create table t (id int primary key); 表已建立。 |
兩個session的id為：session 1: 200session 2: 202 1) Insert在session 1中插入一條資料，不提交：
| SQL> insert into t values (1); 已建立 1 行。 |
在session 2中插入同一條資料，阻塞發生：
| SQL> insert into t values (1); |
查看v$lock：
| SQL> select sid,type,id1,id2,lmode,request,block from v$lock where type in ('TM','TX') order by sid, type; SID TY ID1 ID2 LMODE REQUEST BLOCK---------- -- ---------- ---------- ---------- ---------- ----------200 TM 74584 0 3 0 0200 TX 524317 1048 6 0 1202 TM 74584 0 3 0 0202 TX 524317 1048 0 4 0 202 TX 65539 677 6 0 0 |
session 1在該行上持有mode=6的TX鎖，session 2在該行上請求TX鎖，導致它被阻塞。注意：在11g中多了一個鎖（看最後一行），這是一個TX鎖，且ID1,ID2和前面的都一樣，想不明白這個鎖的用途是什麼。 2）update在session 1中更新id=1的那行，不提交：
| SQL> update t set id=2 where id=1; 已更新 1 行。 |
在session 2中更新同一行資料，發生阻塞：
| SQL> update t set id=3 where id=1; |
查看v$lock：
| SQL> select sid,type,id1,id2,lmode,request,block from v$lock where type in ('TM','TX') order by sid, type; SID TY ID1 ID2 LMODE REQUEST BLOCK---------- -- ---------- ---------- ---------- ---------- ----------200 TM 74584 0 3 0 0200 TX 131092 822 6 0 1202 TM 74584 0 3 0 0202 TX 131092 822 0 6 0 |
3）Delete在sesssion 1中刪除一行，不提交：
| SQL> delete from t where id=1; 已刪除 1 行。 |
在session 2中刪除同一行，發生阻塞：
| SQL> delete from t where id=1; |
查看v$lock：
4、RI鎖---基於參考關聯性的鎖定當對具有主外鍵關係的表做DML操作時，鎖定不單單發生在動作表上，相應的參考資料表上也可能加上相應的鎖定。下面類比RI鎖定導致阻塞的情境：分別建立主表和從表：
| SQL> create table p(id int primary key); 表已建立。 SQL> create table c(id int references p(id)); 表已建立。 |
在主表中插入一行資料：
| SQL> insert into p values(1); 已建立 1 行。 |
查看v$lock:
| SQL> select sid,type,id1,id2,lmode,request,block from v$lock where type in ('TM','TX') order by sid, type; SID TY ID1 ID2 LMODE REQUEST BLOCK---------- -- ---------- ---------- ---------- ---------- ---------- 200 TM 74587 0 3 0 0 200 TM 74589 0 3 0 0200 TX 524299 1051 6 0 0 |
可以看出在主表和從表上都加了TM鎖。5、死結兩個會話互相持有對方資源導致死結。死結的出現說明業務設計有問題，需要從商務邏輯上進行重新設計。Oracle可以自動監控死結，並強制讓其中一個session釋放資源的方式解決死結問題，如： 在session 1中插入資料id=1:
| SQL> insert into t values (1); 已建立 1 行。 |
在session 2中插入資料id=2：
| SQL> insert into t values (2); 已建立 1 行。 |
再在session 1中輸入資料id=2，阻塞發生：
| SQL> insert into t values (2); |
從v$lock中查看鎖定情況：
| SQL> select sid,type,id1,id2,lmode,request,block from v$lock where type in ('TM','TX') order by sid, type; SID TY ID1 ID2 LMODE REQUEST BLOCK---------- -- ---------- ---------- ---------- ---------- ----------200 TM 74584 0 3 0 0200 TX 65550 687 0 4 0200 TX 262176 648 6 0 0202 TM 74584 0 3 0 0202 TX 65550 687 6 0 1 |
再在session 2中插入資料id=1，死結出現：
| SQL> insert into t values (1); |
Oracle在死結出現後，自動釋放其中一個session的資源，解決死結問題：
| SQL> insert into t values (2);insert into t values (2)*第 1 行出現錯誤:ORA-00060: 等待資源時檢測到死結 |
關於Lock和Latch的區別請看：
