思維導(dǎo)圖

---

概述

之前梳理了一篇博文

Oracle-鎖解讀

首先弄清楚兩個(gè)概念：

并發(fā) concurrency: 超過兩個(gè)以上的用戶對(duì)相同的數(shù)據(jù)做修改

并行 parallel:將一件事情分成很多小的部分，讓每一部分同時(shí)執(zhí)行，最后將執(zhí)行結(jié)果匯總。

事實(shí)上，沒有并發(fā)就沒有鎖。

鎖的產(chǎn)生是因?yàn)椴l(fā)，并發(fā)的產(chǎn)生是因?yàn)橄到y(tǒng)需要，系統(tǒng)需要是因?yàn)橛脩粜枰?

---

由唯一性約束引起的阻塞

場(chǎng)景模擬

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0

舉個(gè)最簡(jiǎn)單的并發(fā)導(dǎo)致鎖定的栗子

session 1 ：

查看當(dāng)前session的id

SQL> select sid from v$mystat where rownum=1; SID ---------- 1287

2.創(chuàng)建帶有主鍵的表 ，并插入一條數(shù)據(jù)

SQL> create table t(x int primary key);Table createdSQL> insert into t(x) values(1);1 row insertedSQL> commit;Commit complete

3.更新數(shù)據(jù)

SQL> update t set t.x=666 where t.x=1;1 row updated

此時(shí)，暫時(shí)不要commit

---

緊接著上面的操作，我們?cè)俅蜷_一個(gè)會(huì)話

session 2：

1.查看下當(dāng)前會(huì)話的sid

SQL> select sid from v$mystat where rownum=1; SID ---------- 780

更新同一條數(shù)據(jù)

SQL> update t set t.x=666 where t.x=1;

一直執(zhí)行中。

這個(gè)時(shí)候，已經(jīng)發(fā)生了鎖表 ，具體來說 session2被session1阻塞（session2 was blocked by session1）

---

鎖表場(chǎng)景分析

產(chǎn)生這個(gè)現(xiàn)象的原因是什么呢？

我們創(chuàng)建T表的時(shí)候，x字段設(shè)置為主鍵，以確保這個(gè)列值的唯一性，然后我們?cè)趕ession1中更新x=1的數(shù)據(jù)， 并沒有提交，此時(shí)session2 中 也同樣的對(duì)x=1的數(shù)據(jù)進(jìn)行了update .

session1沒有提交，此時(shí)數(shù)據(jù)庫會(huì)認(rèn)為你還沒有決定是否將這條數(shù)據(jù)更新到庫表中，數(shù)據(jù)庫會(huì)等待你做決定（提交or回滾）。為了確保數(shù)據(jù)不重復(fù)，數(shù)據(jù)庫只能讓session2等待，直到你做出決定。

當(dāng)然了，我們可以從視圖中查看到這些信息

select a.SID, a.TYPE, a.ID1, a.ID2, a.LMODE, a.REQUEST, a.BLOCKfrom v$lock awhere a.SID in (1287, 780)order by a.SID;

AE鎖在11g中引入，是一個(gè)版本鎖.

---

這里我們分析一下上述的統(tǒng)計(jì)結(jié)果：

通過select sid from v$mystat; 查到當(dāng)前session對(duì)應(yīng)的sid .

我們可以知道 session1 的sid=1287 ,session2的sid=780.

BLOCK=1表示表示這個(gè)會(huì)話正在阻塞其他會(huì)話，Requst=6表示當(dāng)前會(huì)話正在等待一個(gè)LMODE=6的鎖，意思是這個(gè)會(huì)話正在被阻塞。

---

在實(shí)際的工作中，當(dāng)我們得知系統(tǒng)卡住了的時(shí)候，事實(shí)上我們應(yīng)該逆著這個(gè)過程尋根溯源。

首先要查看v$lock表。 通常來講，系統(tǒng)如果正常運(yùn)行，突然卡住，多半是被阻塞了，一般來講需要查看v$lock是否有像上面一樣的阻塞信息。

v$lock這個(gè)視圖需要重點(diǎn)關(guān)注的是 request和block 兩列。 如果某個(gè)sid的request是一個(gè)非0的值，那么它就是在等待一個(gè)鎖，如果block列為1，說明這個(gè)sid就持有了一個(gè)鎖，并且阻塞別人獲得這個(gè)鎖。

鎖的類型是由TYPE字段定義， 鎖的模式是有LMODE字段定義，ID1和ID2定義了這個(gè)鎖的相關(guān)信息

---

下面我們繼續(xù)來看 剛才的圖

不難發(fā)現(xiàn)，這兩列的ID1和ID2的值完全相同，其實(shí)這個(gè)并非偶然，而是必然。 因?yàn)樗麄儽緛砭褪侵赶蛲粋€(gè)資源，只不過一個(gè)是持有者（sid=1287）,一個(gè)是請(qǐng)求等待者（sid=780）.

通過這個(gè)視圖，我們很快發(fā)現(xiàn)了問題的所在， session2卡住是因?yàn)閟ession1上有個(gè)事物沒有提交，而在這張表上有要求列值唯一性的約束（表建有主鍵）。

通過sid，再去查詢v$session 視圖就可以確定用戶的信息了

可以使用如下腳本

SELECT s.sid, q.sql_text FROM v$sqltext q, v$session s WHERE q.address = s.sql_address AND s.sid in (1287, 780) ORDER BY piece;

或者：

http://blog.csdn.net/yangshangwei/article/details/52449489#t1

---

這種我們通過方式反推系統(tǒng)出現(xiàn)的問題，充其量是一個(gè)故障定位（trouble shooting）,并不能叫做性能優(yōu)化，性能優(yōu)化是一個(gè)系統(tǒng)的工程，路還很長…..

---

引起阻塞的其他情況

select for update

之前有梳理過了，比較簡(jiǎn)單，不再重復(fù)了，請(qǐng)移步
http://blog.csdn.net/yangshangwei/article/details/53021029#t38

---

外鍵和索引

之前有梳理過了，比較簡(jiǎn)單，不再重復(fù)了，請(qǐng)移步
http://blog.csdn.net/yangshangwei/article/details/53021029#t39

總結(jié)

以上是生活随笔為你收集整理的Oracle优化02-锁和阻塞的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。