思维导图
概述
之前梳理了一篇博文
首先弄清楚两个概念：
并发 concurrency: 超过两个以上的用户对相同的数据做修改
并行 parallel:将一件事情分成很多小的部分，让每一部分同时执行，最后将执行结果汇总。
事实上，没有并发就没有锁。
锁的产生是因为并发，并发的产生是因为系统需要，系统需要是因为用户需要…….
由唯一性约束引起的阻塞
场景模拟
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0
举个最简单的并发导致锁定的栗子
session 1 ：
- 查看当前session的id
SQL> select sid from v$mystat where rownum=1; SID ---------- 1287
2.创建带有主键的表 ，并插入一条数据
SQL> create table t(x int primary key); Table created SQL> insert into t(x) values(1); 1 row inserted SQL> commit; Commit complete
3.更新数据
SQL> update t set t.x=666 where t.x=1; 1 row updated
此时，暂时不要commit
紧接着上面的操作，我们再打开一个会话
session 2：
1.查看下当前会话的sid
SQL> select sid from v$mystat where rownum=1; SID ---------- 780
- 更新同一条数据
SQL> update t set t.x=666 where t.x=1;
一直执行中。
这个时候，已经发生了锁表 ，具体来说 session2被session1阻塞（session2 was blocked by session1）
锁表场景分析
产生这个现象的原因是什么呢？
我们创建T表的时候，x字段设置为主键，以确保这个列值的唯一性，然后我们在session1中更新x=1的数据， 并没有提交，此时session2 中 也同样的对x=1的数据进行了update .
session1没有提交，此时数据库会认为你还没有决定是否将这条数据更新到库表中，数据库会等待你做决定（提交or回滚）。为了确保数据不重复，数据库只能让session2等待，直到你做出决定。
当然了，我们可以从视图中查看到这些信息
select a.SID, a.TYPE, a.ID1, a.ID2, a.LMODE, a.REQUEST, a.BLOCK from v$lock a where a.SID in (1287, 780) order by a.SID;
AE锁在11g中引入，是一个版本锁.
这里我们分析一下上述的统计结果：
通过select sid from v$mystat; 查到当前session对应的sid .
我们可以知道 session1 的sid=1287 ,session2的sid=780.
BLOCK=1表示表示这个会话正在阻塞其他会话，Requst=6表示当前会话正在等待一个LMODE=6的锁，意思是这个会话正在被阻塞。
在实际的工作中，当我们得知系统卡住了的时候，事实上我们应该逆着这个过程寻根溯源。
首先要查看v$lock表。 通常来讲，系统如果正常运行，突然卡住，多半是被阻塞了，一般来讲需要查看v$lock是否有像上面一样的阻塞信息。
v$lock这个视图需要重点关注的是 request和block 两列。 如果某个sid的request是一个非0的值，那么它就是在等待一个锁，如果block列为1，说明这个sid就持有了一个锁，并且阻塞别人获得这个锁。
锁的类型是由TYPE字段定义， 锁的模式是有LMODE字段定义，ID1和ID2定义了这个锁的相关信息
下面我们继续来看 刚才的图
不难发现，这两列的ID1和ID2的值完全相同，其实这个并非偶然，而是必然。 因为他们本来就是指向同一个资源，只不过一个是持有者（sid=1287）,一个是请求等待者（sid=780）.
通过这个视图，我们很快发现了问题的所在， session2卡住是因为session1上有个事物没有提交，而在这张表上有要求列值唯一性的约束（表建有主键）。
通过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
这种我们通过方式反推系统出现的问题，充其量是一个故障定位（trouble shooting）,并不能叫做性能优化，性能优化是一个系统的工程，路还很长…..
引起阻塞的其他情况
select for update
之前有梳理过了，比较简单，不再重复了，请移步
http://blog.csdn.net/yangshangwei/article/details/53021029#t38
外键和索引
之前有梳理过了，比较简单，不再重复了，请移步
http://blog.csdn.net/yangshangwei/article/details/53021029#t39
