rebuildindexonline的鎖機制淺析

1、一般都說，rebuildindexonline不阻塞DML操作，這是相對于rebuildindex來說的，加上了online，只是在rebuild的期間不阻塞DML，但是在開始和結束階段還是可能阻塞其他進程的DML的，要弄清楚到底是阻塞還是不阻塞，何處阻塞，為什么阻塞，還是要從鎖的角度來分析。本文實驗環(huán)境為acle10.2.0.4。acle中的鎖，一共有6兩種模式：0：none1：null空2：RowS行共享(RS)：共享表鎖，subs

2、hare3：RowX行獨占(RX)：用于行的修改，subexclusive4：Share共享鎖(S)：阻止其他DML操作，share5：SRowX共享行獨占(SRX)：阻止其他事務操作，sharesubexclusive6：exclusive獨占(X)：獨立訪問使用，exclusive我們知道，DML操作一般要加兩個鎖，一個是對表加模式為3的TM鎖，一個是對數(shù)據行的模式為6的TX鎖。只要操作的不是同一行數(shù)據，是互不阻塞的。但是rebui

3、ldindexonline在開始和結束的時候是需要對表加一個模式為4的TM鎖的，這個可以很容易通過實驗觀察到，實驗中的測試表t是通過createtabletasfromall_objects生成，并且多次執(zhí)行intotfromt產生較多的數(shù)據，以便延遲rebuild的時間來觀察系統(tǒng)中鎖的情況：session1：SQLtwhereobject_id=28281rowd.session2：SQLalterindexix_trebuildon

4、lineSession2被阻塞，會話掛起，這時查詢v$lock，可以得到如下結果：SQLsidtypeid1id2lmoderequestfromv$lockwheretypein(DLTMTX)SIDTYID1ID2LMODEREQUEST16431643DL105991059903016431643DL105991059903016221622TM105991059903016431643TM10599105990241627就是s

5、ession3，請求模式為3的TM鎖無法獲得，會話被阻塞。這是因為鎖請求是需要排隊的，即使session3和session1是可以并發(fā)的，但由于session2先請求鎖并進入等待隊列，或來的session3也只好進入隊列等待。所以如果在執(zhí)行rebuildindexonline前長事務，并且并發(fā)量比較大，則一旦執(zhí)行alterindexrebuildonline，可能因為長事務阻塞，可能導致系統(tǒng)瞬間出現(xiàn)大量的鎖，對于壓力比較大的系統(tǒng)，這是一

6、個不小的風險。這是需要迅速找出導致阻塞的會話kill掉，rebuildindexonline一旦執(zhí)行，不可輕易中斷，否則可能遇到A08104。在session1執(zhí)行rollback，可以發(fā)現(xiàn)很短時間內session3也正常執(zhí)行完畢，說明session2只有模式4的TM鎖的時間很短，然后在rebuildonline的進行過程中，對表加的是模式為2的TM鎖，所以這段時間不會阻塞DML操作：SQLsidtypeid1id2lmodereque

7、stfromv$lockwheretypein(DLTMTX)SIDTYID1ID2LMODEREQUEST1643DL105990301643DL105990301643TM105990201643TM106070401627TM105990301627TX655392136160保持session3的事務不提交，等待一段時間后，session2始終無法完成操作，再觀察系統(tǒng)中鎖的情況，可以發(fā)現(xiàn)又發(fā)生了變化：SQLsidtypeid1i

8、d2lmoderequestfromv$lockwheretypein(DLTMTX)SIDTYID1ID2LMODEREQUEST16431643DL105991059903016431643DL105991059903016431643TM105991059902416431643TM106071060704016271627TM105991059903016431643TX5898525898522582586016271627T