SQL Server 鎖實驗（重建索引）

昨晚某現場報一個重建索引失敗的問題，遠程查看後發現是自動收縮的內部會話引發的鎖申請超時，突然想起來自己的加鎖實驗還沒完成索引重建部分，今天有空正好做一下：

USE [資料庫名]
GO
ALTER INDEX <索引名> ON dbo.<表名> REBUILD PARTITION = ALL WITH ( MAXDOP = 4, ONLINE = OFF, SORT_IN_TEMPDB = OFF )
GO

先試了下聚集索引的重建，以下是相關會話的所有加鎖情況：

從以上的鎖分佈情況來分析，首先我們過濾掉所有非相關表的鎖，那麼整個結果集只剩下了6行：

55	    5	    1589580701	0	    TAB	        S	    GRANT
55	    5	    1589580701	0	    TAB	        S	    GRANT
55	    5	    1589580701	0	    TAB	        S	    GRANT
55	    5	    1589580701	0	    TAB	        S	    GRANT
55	    5	    1589580701	0	    TAB	        Sch-M   GRANT
55	    5	    1605580758	0	    TAB	        Sch-M   GRANT

這裡出現了4個TAB類型的S鎖和一個表級的Sch-M鎖以及一個聚集索引的Sch-M鎖，從官網提供的鎖相容圖來看S鎖和Sch-M鎖是不相容的，因此這幾個S鎖的出現就比較詭異了，因此查看dm_tran_locks發現request_exec_context_id不一樣，而官網對此欄位的解釋就一句：Execution context ID of the process that currently owns this request.

所以這裡有一個問題：不同的request_exec_context_id代表的TAB類型的S鎖到底是什麼？為何與Sch-M鎖不衝突？

Ps:下圖裡的object_id與之前的不同是因為不是一個表，無需在意。

因此重建聚集索引的過程中會對錶和涉及的索引加Sch-M的架構鎖，而此架構鎖與所有其他鎖衝突，因此不能再執行任何針對此表的增刪改查。

之後測試了非聚集索引的情況，加鎖情況一致因此不作討論。