如何處理鎖阻塞

liuyong20395

程序因?yàn)楸容^大的而且多次點(diǎn)了查詢，造成數(shù)據(jù)庫(kù)阻塞，速度很慢。如何能比較快速的解除鎖阻塞呢？

解決方案：
1，sp_lock與sp_who，查看鎖的狀態(tài)，然后kill掉相應(yīng)的進(jìn)程。
2，查看sybase在系統(tǒng)中進(jìn)程，windows下結(jié)束進(jìn)程或liunx下kill進(jìn)程。
3，用dba工具查看鎖狀態(tài)，然后一次選中刪除。

方案缺陷：
方法1：sp_who和sp_lock因?yàn)榇藭r(shí)數(shù)據(jù)庫(kù)已經(jīng)較慢，顯示鎖阻塞和殺的過(guò)程中也耗時(shí)，速度并不占優(yōu)。而且有的進(jìn)程還要重復(fù)殺才能殺掉（測(cè)試時(shí)大約有30多個(gè)鎖阻塞，大約超過(guò)5分鐘后正常）
方法2：擔(dān)心會(huì)造成數(shù)據(jù)不一致
方法3：個(gè)人認(rèn)為較快。界面化操作，可以一次殺掉多個(gè)鎖阻塞。


不知道還有那位有更好的方法可以處理鎖阻塞的問(wèn)題，可以一起分享下嘛？

D_D_D_D

不一致應(yīng)該不會(huì)產(chǎn)生，經(jīng)常會(huì)阻塞的原因就多了，有可能是程序設(shè)計(jì)的問(wèn)題，有可能是數(shù)據(jù)庫(kù)鎖級(jí)別設(shè)置的不合理，還是要從源頭進(jìn)行分析

chuxu

先看一下鎖的級(jí)別是什么，頁(yè)級(jí)？表級(jí)？還是行級(jí)？
確定是否可以改為行級(jí)鎖，以減少阻塞的可能

liuyong20395

感謝上面兩位的回復(fù)，不過(guò)程序應(yīng)該說(shuō)沒(méi)有問(wèn)題。
可能有的操作員無(wú)意多點(diǎn)了幾次操作，造成了阻塞。
主要關(guān)心鎖阻塞后的處理方法，不知道那位有更好的方法？

tyrone.dev

LZ,不是說(shuō)程序運(yùn)行出來(lái)結(jié)果正確就代表沒(méi)問(wèn)題，用戶多點(diǎn)幾下就有長(zhǎng)時(shí)間的鎖產(chǎn)生，這就是明顯的有問(wèn)題。這種情況下有幾種可能性，
1、點(diǎn)一次更新的內(nèi)容太多，一下子更新了幾十個(gè)表的記錄或者一下子更新了N多條記錄。如果是這種情況，應(yīng)當(dāng)在客戶端限制用戶不斷的重復(fù)點(diǎn)。
2、更新的條數(shù)不多，還是有長(zhǎng)時(shí)間的鎖，第一可能是表是頁(yè)鎖，沒(méi)有改成行鎖。第二，有熱表不斷的使用，常見(jiàn)的有自已建表保存表的最大key值，每次都去取+1后在保存，或者直接從表中取max+1。第三可能是每個(gè)交易時(shí)間花費(fèi)太長(zhǎng)，可能是索引不對(duì)引起的。
3、如果需要kill進(jìn)程來(lái)回收鎖，這種系統(tǒng)實(shí)際使用時(shí)也是屬于問(wèn)題多多的系統(tǒng)。反正送我用，我也不會(huì)去用的。

liuyong20395

原帖由 tyrone.dev 于 2009-3-29 04:21 發(fā)表
LZ,不是說(shuō)程序運(yùn)行出來(lái)結(jié)果正確就代表沒(méi)問(wèn)題，用戶多點(diǎn)幾下就有長(zhǎng)時(shí)間的鎖產(chǎn)生，這就是明顯的有問(wèn)題。這種情況下有幾種可能性，
1、點(diǎn)一次更新的內(nèi)容太多，一下子更新了幾十個(gè)表的記錄或者一下子更新了N多條記 ...

感謝你的回復(fù)，現(xiàn)實(shí)情況是你所說(shuō)的第一種。操作員查詢時(shí)條件少，查詢數(shù)據(jù)量很大造成，已經(jīng)修改程序不允許多次點(diǎn)擊了。

不過(guò)上次發(fā)生了這種情況處理時(shí)間（先判斷嘗試kill，最后關(guān)閉sybase服務(wù)，總共耗時(shí)接近20分鐘），現(xiàn)在就想對(duì)于這種問(wèn)題有更快速的處理方法嗎？

liuyong20395

原帖由 tyrone.dev 于 2009-3-29 04:21 發(fā)表
LZ,不是說(shuō)程序運(yùn)行出來(lái)結(jié)果正確就代表沒(méi)問(wèn)題，用戶多點(diǎn)幾下就有長(zhǎng)時(shí)間的鎖產(chǎn)生，這就是明顯的有問(wèn)題。這種情況下有幾種可能性，
1、點(diǎn)一次更新的內(nèi)容太多，一下子更新了幾十個(gè)表的記錄或者一下子更新了N多條記 ...

感謝你的回復(fù)，現(xiàn)實(shí)情況是你所說(shuō)的第一種。操作員查詢時(shí)條件少，查詢數(shù)據(jù)量很大造成，已經(jīng)修改程序不允許多次點(diǎn)擊了。

不過(guò)上次發(fā)生了這種情況處理時(shí)間（先判斷嘗試kill，最后關(guān)閉sybase服務(wù)，總共耗時(shí)接近20分鐘），現(xiàn)在就想對(duì)于這種問(wèn)題有更快速的處理方法嗎？

tyrone.dev

查詢數(shù)據(jù)量，如果光查詢的不會(huì)使用排它鎖的，應(yīng)當(dāng)是更新吧，如果更新很多的話，并且kill的話，會(huì)rollback trans ,對(duì)事務(wù)已經(jīng)超過(guò)1/2的處理來(lái)說(shuō)kill了之后反而更花時(shí)間，這個(gè)是沒(méi)有辦法解決的。

chuxu

原帖由 liuyong20395 于 2009-3-30 10:20 發(fā)表



感謝你的回復(fù)，現(xiàn)實(shí)情況是你所說(shuō)的第一種。操作員查詢時(shí)條件少，查詢數(shù)據(jù)量很大造成，已經(jīng)修改程序不允許多次點(diǎn)擊了。

不過(guò)上次發(fā)生了這種情況處理時(shí)間（先判斷嘗試kill，最后關(guān)閉sybase服務(wù)，總共耗時(shí) ...

我感覺(jué)這種問(wèn)題處理的有效的方法是優(yōu)化應(yīng)用或者環(huán)境，避免出現(xiàn)長(zhǎng)時(shí)間的鎖阻塞，而不是等阻塞了再去處理。