国产高清在线免费观看-国产高清在线免费无码-国产高清在线男人的天堂-国产高清在线视频-国产高清在线视频精品视频-国产高清在线视频伊甸园

在SQL Server數(shù)據(jù)庫中，統(tǒng)計信息更新（UPDATE STATISTICS）會被其它會話阻塞嗎？統(tǒng)計信息更新（UPDATE STATISTICS）會引起其它會話阻塞嗎？在回答這兩個問題前，我們必須搞清楚，統(tǒng)計信息更新這個操作期間會申請/持有那些鎖。如果弄清楚了這些，那么我們就能很容易回答這兩個問題了。如果要弄清楚統(tǒng)計信息更新會申請/持有那些鎖，我們可以用SQL腳本或SQL Server Profiler工具來查詢/定位相關(guān)的鎖信息

SQL腳本方式

SELECT * FROM  sys.dm_tran_locks
WHERE request_session_id=xxx;  --xxx用具體的會話ID替換
SELECT resource_type ,
       resource_subtype ,
       resource_description ,
       resource_associated_entity_id ,
       request_mode ,
       request_type ,
       request_status ,
       request_session_id  
FROM sys.dm_tran_locks
WHERE request_session_id = xxx;

用SQL腳本的話，不太容易捕捉到統(tǒng)計信息更新（UPDATE STATISTICS）整個過程中申請的所有相關(guān)鎖信息，而且小表的統(tǒng)計信息更新速度非?？欤〞r間短到你來不及去查詢相關(guān)鎖信息，有些鎖就已經(jīng)申請成功，并釋放了，可能統(tǒng)計信息更新都已經(jīng)完成了），如果要實驗的話，可能需要構(gòu)造一個很大的表。這種方式還是有一些缺陷與不足。

SQL Server Profiler跟蹤方式

使用SQL Server Profiler工具追蹤更新統(tǒng)計信息期間會申請/持有哪一些鎖。這種方式比較容易捕捉到整個過程中所有相關(guān)的鎖申請與鎖釋放的詳細信息，而且用SQL Server Profiler跟蹤鎖的申請與釋放也非常方便。個人推薦使用這種方式。

下面我們打開一個會話窗口，找出會話ID（當前測試環(huán)境會話ID為53），然后使用SQL Server Profiler跟蹤會話ID=53的鎖的申請與釋放（Lock：Acquired， Lock：Released），此處SQL Server Profiler的相關(guān)操作細節(jié)略過。然后在會話窗口執(zhí)行下面語句

UPDATE STATISTICS  TEST WITH FULLSCAN,ALL;

如下部分截圖所示，我們可以看到在統(tǒng)計信息更新期間，數(shù)據(jù)庫會在相關(guān)對象上請求架構(gòu)穩(wěn)定鎖（Sch-S）、架構(gòu)修改鎖（Sch-M）、共享鎖（S）,排它鎖（X）,意向排他鎖（IX）,更新鎖（U）等，整個過程會有較多的鎖申請與鎖釋放。

從上面實驗可以看出，在 SQL Server 中，更新統(tǒng)計信息可能會申請持有很多類型的鎖，那么我來一項項分析，在分析之前，我們來看一下鎖的兼容矩陣，如果對這方面知識有點模糊不清的，正好可以重溫一下這方面的知識點：

注意：除了架構(gòu)修改鎖 (Sch-M)之外，架構(gòu)穩(wěn)定鎖 (Sch-S) 與所有鎖定模式都兼容。而Sch-M 鎖與所有鎖定模式都不兼容。

1. 共享鎖（S）

從實驗數(shù)據(jù)來看，共享鎖都發(fā)生在統(tǒng)計信息元數(shù)據(jù)對象上。這些元數(shù)據(jù)對象，如下截圖所示，分別為sysschobjs和sysobjvalues，當然還有OBJECT_ID=0 OBJECTID2=xxxx的數(shù)據(jù)頁或數(shù)據(jù)行。

SELECT t.object_id AS ObjectID,
       OBJECT_NAME(t.object_id) AS ObjectName,
       SUM(u.total_pages) * 8 AS Total_Reserved_kb,
       SUM(u.used_pages) * 8 AS Used_Space_kb,
       u.type_desc AS TypeDesc,
       MAX(p.rows) AS RowsCount
FROM sys.allocation_units AS u
JOIN sys.partitions AS p ON u.container_id = p.hobt_id
JOIN sys.objects AS t ON p.object_id = t.object_id
where u.allocation_unit_id=281474980642816 
GROUP BY t.object_id,
         OBJECT_NAME(t.object_id),
         u.type_desc
ORDER BY Used_Space_kb DESC,
         ObjectName;

注意：查詢條件中用實際具體的OBJECTID2的值替換。

從鎖的兼容性來分析的話，這時發(fā)生阻塞與被阻塞的可能性是存在的，統(tǒng)計信息更新期間，在申請共享鎖時，某些操作在元數(shù)據(jù)對象上持有意向排他共享鎖（SIX）、意向排它鎖（IX）、排它鎖（X）,例如并發(fā)的會話跟新統(tǒng)計數(shù)據(jù)等操作，實際場景中，統(tǒng)計信息更新很少在發(fā)生申請共享鎖時阻塞其它會話與被其它會話阻塞。

2. 架構(gòu)穩(wěn)定性鎖（Sch-S）

當UPDATE STATISTICS時，SQL Server 會獲取架構(gòu)穩(wěn)定鎖（Sch-S）。這里不僅僅是統(tǒng)計信息更新涉及的相關(guān)對象還包括統(tǒng)計信息元數(shù)據(jù)對象，都會獲取Sch-S鎖，而對于架構(gòu)穩(wěn)定鎖（Sch-S）有下面一些規(guī)則：

• 允許其他會話繼續(xù)讀取或修改數(shù)據(jù)（如 SELECT、INSERT、UPDATE）。
• 僅阻塞需要修改表結(jié)構(gòu)的操作（如 ALTER TABLE、CREATE INDEX），因為這些操作需要架構(gòu)修改鎖（Sch-M），與架構(gòu)穩(wěn)定鎖（Sch-S）不兼容。

此時，除非有并發(fā)的會話對表結(jié)構(gòu)進行修改(DDL)或者并發(fā)會話在進行統(tǒng)計信息更新操作，此時剛好持有 Sch-M 鎖，那么就可能會被阻塞。 我們會結(jié)合架構(gòu)修改鎖（Sch-M）構(gòu)造測試案例。

3. 架構(gòu)修改鎖（Sch-M）

當更新統(tǒng)計信息時，SQL Server 會嘗試獲取統(tǒng)計信息元數(shù)據(jù)對象上的架構(gòu)修改鎖（Sch-M）。這種鎖用于確保在更新統(tǒng)計信息的過程中，其他會話不會對統(tǒng)計信息進行修改。如果其他會話已經(jīng)持有與 Sch-M 不兼容的鎖（如架構(gòu)穩(wěn)定性鎖 Sch-S），則更新統(tǒng)計信息的操作可能會被阻塞。

這些元數(shù)據(jù)對象，如下截圖所示，分別為sysschobjs和sysobjvalues等對象。

那么我們簡單構(gòu)造一下統(tǒng)計信息更新被阻塞的案例，如下所示

--會話58中執(zhí)行下面語句，模擬事務(wù)正在修改表結(jié)構(gòu)（DDL），此時事務(wù)未提交/事務(wù)正在執(zhí)行階段

begin tran
alter table test add kk varchar(30);
--rollback;

--會話53中執(zhí)行下面語句更新統(tǒng)計信息

UPDATE STATISTICS  TEST WITH FULLSCAN,ALL;

在會話窗口監(jiān)控阻塞情況，如下所示，對表進行DDL操作時，會阻塞統(tǒng)計信息的更新，此時更新統(tǒng)計信息的會話的等待類型為LCK_M_SCH_S,意味著會話53正在等待獲取架構(gòu)穩(wěn)定鎖（Sch-S）， 其實反過來，更新統(tǒng)計信息也會阻塞一些會話對相關(guān)表進行DDL操作。此時對相關(guān)表進行DDL操作時。個人也構(gòu)造了另外一個大表測試案例進行了驗證。有興趣也可以驗證一下。此處略過。

4. 意向排它鎖（IX）與排它鎖（X）與更新鎖（U）

在更新統(tǒng)計信息時，SQL Server 還可能會對相關(guān)表(例如，sysobjvalues)中的數(shù)據(jù)行或頁獲取行鎖（X、U 等）或頁鎖（IX、IU 等）。這些鎖用于確保在采樣數(shù)據(jù)時，數(shù)據(jù)不會被其他事務(wù)修改。如果有并發(fā)的DDL或統(tǒng)計信息跟新的話，也有可能導致阻塞與被阻塞。但是實際生產(chǎn)環(huán)境中，這種可能性非常小。另外，在表TEST進行統(tǒng)計信息更新時，也會在TEST上有一個短暫的排它鎖（X），它的子類型(Resource subtype)為UPDSTATS，根據(jù)官方文檔，只要子類型不同（不同的子類型彼此之間不會沖突），它是不會阻塞表上的DML操作的，除非另外一個會話也在更新統(tǒng)計信息。這種概率微乎其微。

此處附上官方文檔的內(nèi)容：

Represents a subtype of resource_type. Acquiring a subtype lock without holding a non-subtyped lock of the parent type is technically valid. Different subtypes do not conflict with each other or with the non-subtyped parent type. Not all resource types have subtypes.

結(jié)論總結(jié)

統(tǒng)計信息更新可能被其它會話阻塞，統(tǒng)計信息更新也有可能阻塞其它會話。當統(tǒng)計信息更新時，會獲取統(tǒng)計信息元數(shù)據(jù)對象上的架構(gòu)修改鎖（Sch-M）。如果其他會話已經(jīng)鎖定了同一對象，或者需要在統(tǒng)計信息元數(shù)據(jù)對象上獲取架構(gòu)穩(wěn)定性鎖（Sch-S）來編譯查詢的會話，可能會被阻塞。但是這種場景比較少；另外不要同時做DDL（修改表結(jié)構(gòu)、創(chuàng)建維護索引）和統(tǒng)計信息更新操作，不要并發(fā)的去做統(tǒng)計信息更新（很少有這種場景）。絕大部分場景下，是可以大膽地執(zhí)行統(tǒng)計信息更新操作,它不會阻塞數(shù)據(jù)操作（DML），不用擔心它阻塞了其它會話或被阻塞的。

轉(zhuǎn)自https://www.cnblogs.com/kerrycode/p/18704641