問題背景描述：
發生死鎖的多個進程執行的都是同一個存儲過程，大概代碼及順序如下：
--1.首先通過主鍵order_no鎖住一條訂單
select t.* from order t where t.order_no='order_no' for update;
--2.其次通過主鍵channel_id鎖住一個渠道
select t.* from channel t where t.channel_id='channel_id' for update;
--3.然后通過主鍵order_no對訂單表數據進行修改
update order t set t.order_status=0,t.finish_time=sysdate where t.order_no='order_no';
commit;
死鎖情況描述
- session A
--正在執行語句3，他處于enq: TX - allocate ITL entry等待
update order t set t.order_status=0,t.finish_time=sysdate where t.order_no='orderno_a';
- session B
--正在執行語句2，他處于enq: TX - row lock contention等待
select t.* from channel t where t.channel_id='ch1' for update;
- session C
--正在執行語句2，他處于enq: TX - row lock contention等待
select t.* from channel t where t.channel_id='ch1' for update;
可能還會有更多的session處于執行語句2，并等待enq: TX - row lock contention的情況，這里暫時只列3個session，其實2個也夠了，也能形成，只是概率很低。
- 等待鏈
A被C堵塞，C被B堵塞，B被A堵塞 - 等待鏈分析：
A執行到語句3了，說明主鍵為orderno_a的order數據行鎖和ch1的channel數據行鎖已經獲取到了，而其余的B和C只能等待該ch1數據的行鎖釋放。
B和C都執行到語句2了，說明他們都獲取到了各自的order數據行鎖，且數據不是orderno_a所代表的數據。這點毋庸置疑。
疑問：A，B，C操作的都是不同的訂單數據行，且都獲取到了各自的行鎖的，為什么在表order上，還會發生A被C堵塞呢。
要知道為什么有這個疑問，就要先明白，在A執行order的for update時是已經獲取了itl資源的，所以在后來真正update數據時是不應該存在這個等待的enq: TX - allocate ITL entry，因為他已經獲取這個資源了。
死鎖分析
要分析這個死鎖就要明白等待事件enq: TX - allocate ITL entry所代表的資源itl事務槽的含義。itl事務槽是數據塊頭中用來標記事務的記錄。在這里有個重點是。想一想，如果
了會怎樣。這就是這個死鎖的關鍵點。當然不同表的事務肯定跨數據塊了，一個事務即使修改一個表的多條數據也可能跨塊了。
-
簡單說下這兩個情況
行遷移一般是update后經常出現，比如一個err_mesg字段，初期只有10個字符，后面update為1000個字符，如果這個時候原數據塊裝不下了，他就會找另外的數據塊來存放，而原數據塊上放一個新數據塊的dba（data block address），指向新的數據塊，如下圖：
image.png
行連接一般是insert時出現的，比如一條數據非常大，大到一個塊裝不下了，oracle會拆分成多個塊來存放。可以通過創建塊尺寸小的表空間來測試。
到此處,,也就是我這里死鎖中，假設orderno_a數據rowid指向的塊為dba_1，行遷移中指向的塊為dba_2,在最開始for update時獲取的是塊dba_1中的itl資源，當最后真正update數據時，為了保護操作，需要獲取dba_2上的itl資源。而此時，其余的很多session，比如B，C......N 等等session將塊dba_2上的itl資源耗盡了，那么session A就處于等待數據塊dba_2上的itl資源的狀態，對應于enq: TX - allocate ITL entry。而其他session將等待session A釋放渠道表數據的鎖。完成了鎖的閉環
到此死鎖分析完畢。
可以使用以下代碼來做簡單的測試
--創建order表，將PCTFREE置為0，INITRANS置為1
create table t_order(mesg varchar2(4000)) PCTFREE 0 INITRANS 1;
--創建channel表
create table t_channel(id NUMBER)；
--準備數據，對于order表，至少要有兩個塊有數據
--第一個塊的數據，有三條，即a,b,c
insert into t_order select rpad('a',3000,'a') from dual;
insert into t_itl select rpad('b',1000,'b') from dual;
insert into t_order select rpad('c',3000,'c') from dual;
--更改數據b，此時第一個塊裝不下，將會發生行遷移
update t_order set mesg=(select rpad('b',3000,'b') from dual) where mesg like 'b%';
--可以使用以下語句分析行遷移的表，只用作測試，在線生產慎用,可以dump第一個數據塊找到，遷移到哪一個dba去了
create table CHAINED_ROWS (
owner_name varchar2(30),
table_name varchar2(30),
cluster_name varchar2(30),
partition_name varchar2(30),
subpartition_name varchar2(30),
head_rowid rowid,
analyze_timestamp date
);
analyze table t_order list chained rows;
select * from CHAINED_ROWS;
--繼續插入數據，將遷移后的數據塊數據增加，方便之后for update時消耗這個塊的itl資源
--通常情況，下面插入的數據就是放在b數據遷移后的數據塊的
insert into t_order select rpad('d',1000,'d') from dual;
insert into t_order select rpad('f',6000,'f') from dual;
insert into t_order select rpad('g',300,'g') from dual;
insert into t_order select rpad('h',100,'h') from dual;
/*開始模擬死鎖*/
--t1時刻
--session A
select * from t_order where mesg like 'b%' for update;
select * from t_channel where id=1 for update;
--t2時刻
--session B
select * from t_order where mesg like 'd%' for update;
select * from t_channel where id=1 for update;--等待session A 釋放
--其余session
select * from t_order where mesg like 'f%' for update;
select * from t_channel where id=1 for update;--加入該條數據的行鎖等待
select * from t_order where mesg like 'g%' for update;
select * from t_channel where id=1 for update;--加入該條數據的行鎖等待
.....
/*如果這些數據不在b所在的塊，可以通過設置where條件為以下內容來指定更改b遷移后的塊
where DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) = 'block_no'
and DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) = 1;
--此時session B與其余session將t_order的第二個塊，即d,f,g,h數據所在的塊的itl耗盡
--t3時刻
--session A 去更改t_order的數據
update t_order t set t.mesg='bbbbb' where t.mesg like 'b%';
--此時會等待session B及其他session釋放itl資源，而session B及其他session又在等待session A釋放channel的鎖
--形成了互相等待，閉環，死鎖形成
