天天看點

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

Oracle 資料庫作為業界的翹楚,這麼多年沒有深入實在是......,每種資料庫都有自己獨有的特性,知曉這些特性或者共性,就可以做到根據目前公司的情況,業務的情況,甚至是程式員的LEVEL,來找尋更适合當下的資料庫。ZIP My Fly, next.

最近學習了一些關于ORACLE 鎖的概念,來總結一些,很 Junior, 資深的ORACLE  DBAER 們,湊合着看,歡迎指正。

——————————————————————————————

Oracle 在鎖上面主要分為兩大類

1 Enqueues 

2 Latches

Enqueues 主要是應用或者更直白的說DML 産生的鎖,這是應用使用資料庫進行 INSERT UPDATE DELETE SELECT 産生的鎖

Latches ,這主要是系統内部的鎖,尤其常見于BUFFER 記憶體管理中,保證資料完整和事務性以及資料庫特殊内部架構下操作資料時産生了所,俗稱闩鎖。

說道這裡,還的對比着看,SQL SERVER 和 MYSQL 中 LOCK 的種類可能要比ORACLE 要多,尤其是SQL SERVER, 鎖的種類在資料庫界,(包含POSTGRESQL),那絕對是NO.1,這和資料庫的底層存儲架構以及資料灌入BUFFER  及資料的DML 操作挾制有關。

那ORACLE 中有什麼特性是别的資料庫沒有的,也成就了ORACLE 資料庫在資料庫界有着不可動搖地位的其中有兩點(目前學習中獲知,并非隻有兩點)。

1  讀不會阻塞阻塞寫 (排除 select for update)

2  寫不會阻塞讀          (復原段在起着作用)

或許在ORACLE DBA中覺得,這不是很正常嘛,NO NO NO ,這絕對是ORACLE 資料庫最大的賣點之一, 要知道 其他資料庫(PG未知),在此方面可能通過部分手段來達到部分ORACLE 的這兩個特性,而ORACLE 則自帶這兩個功能,Bravo.

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

ORACLE中有TM 和  TX 兩種類型的鎖,前者是防止 DML時進行 DDL的操作的鎖,後者是事務鎖。而我們要研究的也就是TX鎖。

說道鎖,要知道鎖的模式,這是所有資料庫都有的概念

ORALCE 中到底有哪幾種鎖的模式:

0:none 

1:null 空 

2:Row-S 行共享(RS):共享表鎖,sub share  

3:Row-X 行獨占(RX):用于行的修改,sub exclusive  

4:Share 共享鎖(S):阻止其他DML操作,share 

5:S/Row-X 共享行獨占(SRX):阻止其他事務操作,share/sub exclusive  

6:exclusive 獨占(X):獨立通路使用,exclusive

下面這張圖很清晰的說明了ORACLE 鎖MODE的之間那些可以和平共處,那些則是有你沒我,你死我活的陣仗。清晰明了,如果讓我畫出SQL SERVER的 鎖MODE,那我估計滿屏都不夠用

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

有人可能問,知道這些幹嘛,當然有用,在操作用哪些資源被鎖定,産生死鎖或者 LOCK (oracle 官方名詞 enqueues),是要對資料庫性能産生根本性的影響。

現在做幾個實驗:

1 建立一個表  create table t (id int primary key);

insert into t (id) values (1);

update t set id = 2 where id = 1;  (在一個 SQLPLUS中不要COMMIT)

update t set id = 3 where id =1 ; (應該被阻塞了)通過

下面的查詢我們可以很清晰的看到有一個BLOCK  并且需要的是 6号MODE

SELECT SID,TYPE,id1, id2,lmode,request,BLOCK FROM v$lock WHERE TYPE IN ('TM','TX') ORDER BY 1,2;

我們可以看到 SID 20 在請求一個 6号的 X鎖,而 148的TX鎖有BLOCKED 其他線程的鎖。

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

其實很明顯,上面的查詢可以清楚的明白線程的阻塞情況。通過下面的查詢也很明顯的看到,20号的查詢已經在等待 enqueues 類型的鎖。

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

說道這裡,我必須要回應題目中我個人的一個見解,在大型并發高的系統,不要用外鍵。

我們來做一個實驗:

create table p (id int primary key);

create table c (id references p(id));

insert into p (id) values (1);

我們繼續看,在主表中插入一條資料,可以看到在P 表上插入一條資料不光要給P表加 TM鎖,同時還要給 C 表加 TM 鎖

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

可以通過下面的查詢獲得 ID1 中産生TM鎖的表

ORACLE Learning ONE -- ORACLE 鎖,及大型并發系統為什麼反對建立外鍵

的确我們在操作P表的時候 C表也會被加上TM鎖,DDL鎖。相同,在從表上插入資料的時候,主表也要加相應的TM鎖。 

這樣的鎖定在ORACLE 裡面有一個名詞 叫 RI 鎖, DBA都應該明确,任何的鎖都要有資源的消耗,以及産生各種BLOCKED 的可能性。一般大型的系統中都是要避免過多的鎖,提高系統的并發性。并且我們在主表DML操作時,要根據限制性掃描從表的,如果沒有索引,操作是要對從表進行一次全表掃描的,,這就加大了資料處理的耦合性,對資料庫并發性産生不好的影響。現在大部分資料庫尤其是OLTP 的系統中,是非常不建議使用主外鍵關聯的。(部分傳統行業還在使用主外鍵的原因還是對程式設計的不信任,以及業務的重要性決定的,并且這部分系統對并發性的要求較低)主外鍵興盛,主要是由于早期程式語言和程式設計的不成熟不完善,需要通過資料庫來進行輔助保證邏輯正确性,是以早期系統大多還是使用主外鍵,(早期學習FOXPRO VF時,是非常熱衷主外鍵的,大約是22年前)。

而現在随着資料量越來越大,程式設計越來越完善,分布式設計,MQ,還有很多我不知道的工具和架構(程式員威武),保證邏輯的正确性,程式設計變得越來越強大的情況下,高并發,大資料量的資料庫設計早已不青睐用主外鍵來完成業務的邏輯性。 尤其網際網路使用MYSQL資料庫,徹底将外鍵踢出資料庫設計的曆史舞台,這也是高等級程式設計的趨勢。

——————————————————————————————

那為什麼ORACLE 有上面談到的獨門秘籍,這就要涉及ORACLE 的 BUFFER CACHE 原理了,困了,待續..........