在SSMS（Microsoft SQL Server Management Studio）里面，查看數據庫對應的表的時候，會遇到“Lock Request time out period exceeded.(Microsoft SQL Server, 錯誤1222）”，對應的中文錯誤提示為“已超過了鎖請求超時時段。 (Microsoft SQL Server，錯誤: 1222)”，如下截圖所示，不管是用一般權限的賬號還是具有sysadmin角色的登錄名都是如此。

這個錯誤有點奇怪，檢查該數據庫服務器上監控阻塞的告警郵件，發現有Blocking告警，我用下面SQL語句查看，如下截圖所示

如上所示，會話ID為65的語句執行 TRUNCATE TABLE [ESQ_ITEM_PRICE_FOR_DCA]，它阻塞了會話ID為60的會話，而會話ID為60的會話是YourSQLDba正在更新統計信息

set nocount on ;With TableSizeStats as ( select object_schema_name(Ps.object_id, db_id('ODS')) as scn --collate Chinese_PRC_CI_AS , object_name(Ps.object_id, db_id('ODS')) as tb --collate Chinese_PRC_CI_AS , Sum(Ps.Page_count) as Pg From sys.dm_db_index_physical_stats (db_id('ODS'), NULL, NULL, NULL, 'LIMITED') Ps Groupby Ps.object_id ) Insert into #tableNames (scn, tb, seq, sampling) Select scn , tb , row_number() over (orderby scn, tb) as seq , Case When pg > 200001 Then'10' When Pg between 50001 and 200000 Then'20' When Pg between 5001 and 50000 Then'30' else'100' End From TableSizeStats where (abs(checksum(tb)) % 1) = 0 

它阻塞了會話ID為68的會話

SELECT COUNT(1) FROM [ESQ_ITEM_PRICE_FOR_DCA]

上面這個案例，有兩個比較迷惑的地方：

一：會話ID為65的進程處于Sleeping狀態，而且該會話在執行TRUNCATE語句，照理說TRUNCATE應該非?？炀蛨绦型炅?。很是奇怪的是一個TRUNCATE會話處于Sleeping狀態，這個會話是從linux服務器Talend應用程序發出的請求。那么只有一種可能就是該TRUNCATE語句位于事務里面，而該事務由于邏輯原因等一直沒有提交或回滾。

二：SQL阻塞語句居然導致了上面“Lock Request time out period exceeded.(Microsoft SQL Server, 錯誤1222）”。

關于上面兩個問題，我們可以構造一個案例來看看，在測試數據庫TEST里面的按下面步驟就能重新這個錯誤：

會話語句1：

BEGIN TRAN

TRUNCATE TABLE TEST;

--ROLLBACK;

會話語句2：

UPDATE STATISTICS dbo.TEST;

會話語句3：

如上所示，會話52處于sleeping狀態了。然后你去SSMS里面查看表，就會遇到這個“已超過了鎖請求超時時段。 (Microsoft SQL Server，錯誤: 1222)”錯誤。至于實際應用程序Talend是由于什么原因沒有提交或回滾事務就不得而知。這個例子完美的演示并重現了這個問題