這篇文章將為大家詳細講解有關(guān)公司倉庫數(shù)據(jù)庫服務(wù)器死鎖過程及解決辦法是什么,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù),包含不限于網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、烏審網(wǎng)絡(luò)推廣、重慶小程序開發(fā)、烏審網(wǎng)絡(luò)營銷、烏審企業(yè)策劃、烏審品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等,從售前售中售后,我們都將竭誠為您服務(wù),您的肯定,是我們最大的嘉獎;成都創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供烏審建站搭建服務(wù),24小時服務(wù)熱線:18980820575,官方網(wǎng)址:muchs.cn
死鎖的四個必要條件:
互斥條件(Mutual exclusion):資源不能被共享,只能由一個進程使用。
請求與保持條件(Hold and wait):已經(jīng)得到資源的進程可以再次申請新的資源。
非剝奪條件(No pre-emption):已經(jīng)分配的資源不能從相應的進程中被強制地剝奪。
循環(huán)等待條件(Circular wait):系統(tǒng)中若干進程組成環(huán)路,該環(huán)路中每個進程都在等待相鄰進程正占用的資源。
倉庫揀貨卡死,排查了數(shù)據(jù)庫的很多地方,都沒有頭緒,最后到SQL Server 錯誤日志里查看,終于發(fā)現(xiàn)了蛛絲馬跡
EXEC xp_readerrorlog 0,1,NULL,NULL,'2015-09-21','2015-10-10','DESC' waiter id=process5c30e08 mode=U requestType=wait waiter-list owner id=process5c26988 mode=X owner-list keylock hobtid=72057597785604096 dbid=33 objectname=stoxxx.dbo.Orderxxx indexname=IX_PricingExpressProductCode_State id=lock17fa96980 mode=X associatedObjectId=72057597785604096 waiter id=process5c26988 mode=U requestType=wait waiter-list owner id=process5c30e08 mode=X owner-list keylock hobtid=72057597785604096 dbid=33 objectname=stoxxx.dbo.Orderxxx indexname=IX_PricingExpressProductCode_State id=lock87d69e780 mode=X associatedObjectId=72057597785604096 resource-list(@OperateState money,@HandledByNewWms bit,@State int,@OrderOut int)UPDATE [Orderxx] SET [OperateState] = @OperateState,[HandledByNewWms] = @HandledByNewWms WHERE (([Orderxxx].[State] = @State) And ([Orderxxx].[OrderOut] = @OrderOut) And ([Orderxxx].[PricingExpressProductCode] IN ('UKNIR'))) inputbufunknown frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000UPDATE [Orderxxx] SET [OperateState] = @OperateState,[HandledByNewWms] = @HandledByNewWms WHERE (([Orderxxx].[State] = @State) And ([Orderxxx].[OrderOut] = @OrderOut) And ([Orderxxx].[PricingExpressProductCode] IN ('UKNIR'))) frame procname=adhoc line=1 stmtstart=134 sqlhandle=0x020000009d376d18a17e7ea51289d8caa2fb4de65c976389 executionStack process id=process5c30e08 taskpriority=0 logused=10320 waitresource=KEY: 33:72057597785604096 (112399c2054a) waittime=4813 ownerId=31578743038 transactionname=user_transaction lasttranstarted=2015-09-24T10:22:58.410 XDES=0x372e95950 lockMode=U schedulerid=17 kpid=8496 status=suspended spid=153 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2015-09-24T10:22:58.540 lastbatchcompleted=2015-09-24T10:22:58.540 clientapp=.Net SqlClient Data Provider hostname=CK1-WIN-WEB02 hostpid=37992 loginname=ck1.biz isolationlevel=read committed (2) xactid=31578743038 currentdb=33 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056(@OperateState money,@HandledByNewWms bit,@State int,@OrderOut int)UPDATE [Orderxxx] SET [OperateState] = @OperateState,[HandledByNewWms] = @HandledByNewWms WHERE (([Orderxxx].[State] = @State) And ([Orderxxx].[OrderOut] = @OrderOut) And ([Orderxxx].[PricingExpressProductCode] IN ('UKNIR'))) inputbufunknown frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000UPDATE [Orderxxx] SET [OperateState] = @OperateState,[HandledByNewWms] = @HandledByNewWms WHERE (([Orderxxx].[State] = @State) And ([Orderxxx].[OrderOut] = @OrderOut) And ([Orderxxx].[PricingExpressProductCode] IN ('UKNIR'))) frame procname=adhoc line=1 stmtstart=134 sqlhandle=0x020000009d376d18a17e7ea51289d8caa2fb4de65c976389 executionStack process id=process5c26988 taskpriority=0 logused=9892 waitresource=KEY: 33:72057597785604096 (70f5b089bb2b) waittime=4813 ownerId=31579268946 transactionname=user_transaction lasttranstarted=2015-09-24T10:27:01.357 XDES=0x98312f950 lockMode=U schedulerid=16 kpid=9184 status=suspended spid=454 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2015-09-24T10:27:01.490 lastbatchcompleted=2015-09-24T10:27:01.487 clientapp=.Net SqlClient Data Provider hostname=CK1-WIN-WEB02 hostpid=37992 loginname=ck1.biz isolationlevel=read committed (2) xactid=31579268946 currentdb=33 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056 process-list deadlock victim=process5c26988deadlock-list
咋一看上面的錯誤信息,可以發(fā)現(xiàn)兩條相同的語句造成的死鎖,但是這么短的語句不可能持有排他鎖太久
再仔細分析一下錯誤日志,發(fā)現(xiàn)都死鎖在同一個非聚集索引上,再問了一下開發(fā),開發(fā)那邊說,這條語句是在一個大事務(wù)里面,這個事務(wù)會做7、8件事
索引屬性
還有索引里面的數(shù)據(jù),發(fā)現(xiàn)很多重復值
SQL語句是這樣的
(@OperateState money,@HandledByNewWms bit,@State int,@OrderOut int)@HandledByNewWms=(1) @OperateState=($1.0000) @OrderOut=(4055484) @State=(3) UPDATE [Orderxxx] SET [OperateState] = $1.0000,[HandledByNewWms] = 1WHERE (([Orderxxx].[State] = 3) And ([Orderxxx].[OrderOut] = 4055484) And ([Orderxxx].[PricingExpressProductCode] IN ('UKRRM','UKRLE')))
下圖為語句生成的執(zhí)行計劃
當時的情況是大量SQL語句被阻塞,而阻塞的語句正是下面這條語句
UPDATE [Orderxxx] SET [OperateState] = $1.0000,[HandledByNewWms] = 1WHERE (([Orderxxx].[State] = 3) And ([Orderxxx].[OrderOut] = 4055484) And ([Orderxxx].[PricingExpressProductCode] IN ('UKRRM','UKRLE')))
解決方法
上面得出幾個癥狀
1、update語句是在一個大事務(wù)里面,事務(wù)太大導致其他session等待排他鎖的時間變長
2、大家都在使用同一個非聚集索引,并掃描PricingExpressProductCode字段
3、索引里的重復值很多
從上面的癥狀基本可以判斷,這個非聚集索引無啥用,可以禁用之
ALTER INDEX [IX_PricingExpressProductCode_State] ON [dbo].[Orderxxx] DISABLE
禁用之后,死鎖消失,問題解決,倉庫的怨氣也隨之消失
這一次排查過程時間有點長,但是很好定位,SQL Server錯誤日志給出了足夠的信息定位死鎖問題,所以遇到問題的時候一定要分析清楚日志
關(guān)于公司倉庫數(shù)據(jù)庫服務(wù)器死鎖過程及解決辦法是什么就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
網(wǎng)站欄目:公司倉庫數(shù)據(jù)庫服務(wù)器死鎖過程及解決辦法是什么
轉(zhuǎn)載注明:http://muchs.cn/article8/jsoeip.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供微信公眾號、網(wǎng)站維護、服務(wù)器托管、用戶體驗、關(guān)鍵詞優(yōu)化、品牌網(wǎng)站制作
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)