本篇內(nèi)容主要講解“怎樣減少SQLServer數(shù)據(jù)庫死鎖”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“怎樣減少SQLServer數(shù)據(jù)庫死鎖”吧!
網(wǎng)站設(shè)計(jì)、做網(wǎng)站介紹好的網(wǎng)站是理念、設(shè)計(jì)和技術(shù)的結(jié)合。創(chuàng)新互聯(lián)建站擁有的網(wǎng)站設(shè)計(jì)理念、多方位的設(shè)計(jì)風(fēng)格、經(jīng)驗(yàn)豐富的設(shè)計(jì)團(tuán)隊(duì)。提供PC端+手機(jī)端網(wǎng)站建設(shè),用營銷思維進(jìn)行網(wǎng)站設(shè)計(jì)、采用先進(jìn)技術(shù)開源代碼、注重用戶體驗(yàn)與SEO基礎(chǔ),將技術(shù)與創(chuàng)意整合到網(wǎng)站之中,以契合客戶的方式做到創(chuàng)意性的視覺化效果。為避免死鎖,設(shè)計(jì)應(yīng)用應(yīng)當(dāng)遵循一定的原則,包括:
讓應(yīng)用每次都以相同的次序訪問服務(wù)器資源?!≡谑聞?wù)期間禁止任何用戶輸入。應(yīng)當(dāng)在事務(wù)開始之前收集用戶輸入。盡量保持事務(wù)的短小和簡單。如合適的話,為運(yùn)行事務(wù)的用戶連接指定盡可能低的隔離級別。[適用于6.5,7.0,2000]。
怎樣減少SQLServer數(shù)據(jù)庫死鎖
使用SQLServerProfiler的CreateTraceWizard運(yùn)行“IdentifyTheCauseofaDeadlock”跟蹤來輔助識別死鎖問題,它將提供幫助查找數(shù)據(jù)庫產(chǎn)生死鎖原因的原始數(shù)據(jù)。[適用于7.0,2000]假如無法消除應(yīng)用中的所有死鎖,請確保提供了這樣一種程序邏輯:它能夠在死鎖出現(xiàn)并中止用戶事務(wù)之后,以隨機(jī)的時(shí)間間隔自動(dòng)重新提交事務(wù)。
這里等待時(shí)間的隨機(jī)性非常重要,這是因?yàn)榱硪粋€(gè)競爭的事務(wù)也可能在等待,我們不應(yīng)該讓兩個(gè)競爭的事務(wù)等待同樣的時(shí)間,然后再在同一時(shí)間執(zhí)行它們,這樣的話將導(dǎo)致新的死鎖。[適用于6.5,7.0,2000]盡可能地簡化所有T-SQL事務(wù)。此舉將減少各種類型的鎖的數(shù)量,有助于提高SQLServer應(yīng)用的整體性能。假如可能的話,應(yīng)將較復(fù)雜的事務(wù)分割成多個(gè)較簡單的事務(wù)。
[適用于6.5,7.0,2000]所有條件邏輯、變量賦值以及其他相關(guān)的預(yù)備設(shè)置操作應(yīng)當(dāng)在事務(wù)之外完成,而不應(yīng)該放到事務(wù)之內(nèi)。永遠(yuǎn)不要為了接受用戶輸入而暫停某個(gè)事務(wù),用戶輸入應(yīng)當(dāng)總是在事務(wù)之外完成。[適用于6.5,7.0,2000]在存儲(chǔ)過程內(nèi)封裝所有事務(wù),包括BEGINTRANSACTION和COMMITTRANSACTION語句。此舉從兩個(gè)方面幫助減少阻塞的鎖。首先,它限制了事務(wù)運(yùn)行時(shí)客戶程序和SQLServer之間的通信,從而使得兩者之間的任何消息只能出現(xiàn)于非事務(wù)運(yùn)行時(shí)間(減少了事務(wù)運(yùn)行的時(shí)間)。
其次,由于存儲(chǔ)過程強(qiáng)制它所啟動(dòng)的事務(wù)或者完成、或者中止,從而防止了用戶留下未完成的事務(wù)(留下未撤銷的鎖)。[適用于6.5,7.0,2000]假如客戶程序需要先用一定的時(shí)間檢查數(shù)據(jù),然后可能更新數(shù)據(jù),也可能不更新數(shù)據(jù),那么好不要在整個(gè)記錄檢查期間都鎖定記錄。假設(shè)大部分時(shí)間都是檢查數(shù)據(jù)而不是更新數(shù)據(jù),那么處理這種特殊情況的一種方法就是:先選擇出記錄(不加UPDATE子句。UPDATE子句將在記錄上加上共享鎖),然后把它發(fā)送給客戶。
假如用戶只查看記錄但從來不更新它,程序可以什么也不做;反過來,假如用戶決定更新某個(gè)記錄,那么他可以通過一個(gè)WHERE子句檢查當(dāng)前的數(shù)據(jù)是否和以前提取的數(shù)據(jù)相同,然后執(zhí)行UPDATE。
類似地,我們還可以檢查記錄中的時(shí)間標(biāo)識列(假如它存在的話)。假如數(shù)據(jù)相同,則執(zhí)行UPDATE操作;假如記錄已經(jīng)改變,則應(yīng)用應(yīng)該提示用戶以便用戶決定如何處理。雖然這種方法需要編寫更多的代碼,但它能夠減少加鎖時(shí)間和次數(shù),提高應(yīng)用的整體性能。[適用于6.5,7.0,2000]
盡可能地為用戶連接指定具有最少限制的事務(wù)隔離級別,而不是總是使用默認(rèn)的READCOMMITTED。為了避免由此產(chǎn)生任何其他問題,應(yīng)當(dāng)參考不同隔離級別將產(chǎn)生的效果,仔細(xì)地分析事務(wù)的特性。[適用于6.5,7.0,2000]使用游標(biāo)會(huì)降低并發(fā)性。
為避免這一點(diǎn),假如可以使用只讀的游標(biāo)則應(yīng)該使用READ_ONLY游標(biāo)選項(xiàng),否則假如需要進(jìn)行更新,嘗試使用OPTIMISTIC游標(biāo)選項(xiàng)以減少加鎖。設(shè)法避免使用SCROLL_LOCKS游標(biāo)選項(xiàng),該選項(xiàng)會(huì)增加由于記錄鎖定引起的問題。[適用于6.5,7.0,2000]假如用戶抱怨說他們不得不等待系統(tǒng)完成事務(wù),則應(yīng)當(dāng)檢查服務(wù)器上的資源鎖定是否是導(dǎo)致該問題的原因。
進(jìn)行此類檢查時(shí)可以使用SQLServerLocksObject:AverageWaitTime(ms),用該計(jì)數(shù)器來度量各種鎖的平均等待時(shí)間。假如可以確定一種或幾種類型的鎖導(dǎo)致了事務(wù)延遲,就可以進(jìn)一步探究是否可以確定具體是哪個(gè)事務(wù)產(chǎn)生了這種鎖。
Profiler是進(jìn)行這類具體分析的好工具。[適用于7.0,2000]使用sp_who和sp_who2(SQLServerBooksOnline沒有關(guān)于sp_who2的說明,但sp_who2提供了比sp_who更詳細(xì)的信息)來確定可能是哪些用戶阻塞了其他用戶。
[適用于6.5,7.0,2000]試試下面的一個(gè)或多個(gè)有助于避免阻塞鎖的建議:
1)對于頻繁使用的表使用集簇化的索引;
2)設(shè)法避免一次性影響大量記錄的T-SQL語句,特別是INSERT和UPDATE語句;
3)設(shè)法讓UPDATE和DELETE語句使用索引;
4)使用嵌套事務(wù)時(shí),避免提交和回退沖突。[適用于6.5,7.0,2000]
到此,相信大家對“怎樣減少SQLServer數(shù)據(jù)庫死鎖”有了更深的了解,不妨來實(shí)際操作一番吧!這里是創(chuàng)新互聯(lián)建站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!