亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

了解SQL Server鎖爭用:NOLOCK 和 ROWLOCK 的秘

系統 2011 0

關系型數據庫,如 SQL Server,使用鎖來避免多用戶修改數據時的并發沖突。當一組數據被某個用戶鎖定時,除非第一個用戶結束修改并釋放鎖,否則其他用戶就無法修改該組數據。

有些數據庫,包括 SQL Server,用鎖來避免用戶檢索未遞交的修改記錄。在這些系統中,如果用戶A在修改一組記錄,則其他用戶只有等用戶A修改完畢了,才能檢索。

數據庫在每個物理層上設置鎖:記錄行 (rows),數據頁(pages, 上百萬記錄行),擴展頁(extends, 多個數據頁),整個表,甚至整個數據庫。有些數據庫(如Oracle等)只使用精細的行鎖機制,而別的數據庫,則使用在頁面,擴展頁,表和數據庫上的較大范圍的鎖機制。大多數數據庫,包括SQL Server,同樣支持行鎖機制,但是經常使用的還是大范圍鎖機制。 這主要是因為管理鎖需要付出高昂的代價。鎖十分復雜而且數量很多,所以如果全都是 行鎖的話,將是極為痛苦的:一百萬行的數據更新就會輕易消耗巨大的內存,從而根本無法進行管理。

鎖爭用的描述 ?

那些不僅僅使用行級鎖的數據庫使用一種稱為混和鎖 (lock escalation)的技術來獲取較高的性能。除非很明確知道是針對整個數據表,否則這些數據庫的做法是開始使用行級鎖, 然后隨著修改的數據增多,開始使用大范圍的鎖機制。

不幸的是,這種混和鎖的方法會產生和放大新的問題:死鎖。如果兩個用戶以相反的順序修改位于不同表的記錄,而這兩條記錄雖然邏輯上不相關, 但是物理上是相鄰的,操作就會先引發行鎖,然后升級為頁面鎖。這樣, 兩個用戶都需要對方鎖定的東西,就造成了死鎖。 ?

例如:

用戶 A修改表A的一些記錄,引發的頁面鎖不光鎖定正在修改的記錄,還會有很多其它記錄也會被鎖定。

用戶 B修改表B的一些記錄,引發的頁面鎖鎖定用戶A和其它正在修改的數據。

用戶 A想修改用戶B在表B中鎖定(并不一定正在修改的)數據。

用戶 B想修改或者僅僅想訪問用戶A在表A中鎖定(并不一定正在修改)的數據。

為了解決該問題,數據庫會經常去檢測是否有死鎖存在,如果有,就把其中的一個事務撤銷,好讓另一個事務能順利完成。一般來說,都是撤銷 那個修改數據量少的事務,這樣回滾的開銷就比較少。使用行級鎖的數據庫 很少會有這個問題,因為兩個用戶同時修改同一條記錄的可能性極小,而且由于極其偶然的修改數據的順序而造成的鎖也少。

而且,數據庫使用鎖超時來避免讓用戶等待時間過長。查詢超時的引入也是為了同樣目的。我們可以重新遞交那些超時的查詢,但是這只會造成數據庫 的堵塞。如果經常發生超時,說明用戶使用 SQL Server的方式有問題。正常 情況是很少會發生超時的。

在服務器負載較高的運行環境下,使用混合鎖的 SQL Server鎖機制,表現不會很好。 原因是鎖爭用(Lock Contention)。鎖爭用造成死鎖和鎖等待問題。在一個多用戶系統中,很多用戶會同時在修改數據庫,還有更多的用戶在同時訪問數據庫,隨時會產生鎖,用戶 也爭先恐后地獲取鎖以確保自己的操作的正確性,死鎖頻繁發生,這種情形下, 用戶的心情可想而知。

確實,如果只有少量用戶, SQL Server不會遇到多少麻煩。內部測試和發布的時候,由于用戶較少, 也很難發現那些并發問題。但是當激發幾百個并發,進行持續不斷地INSERT,UPDATE,以及一些 DELETE操作時,如何觀察是否有麻煩出現,那時候你就會不得不手忙腳亂地去閱讀Oracle的文獻。 不過我有一個解決辦法,該方法只需要檢查你的T-SQL代碼,很少的調整和系統測試。用該方法教你進行適當的系統測試過程。

鎖爭用的解決方法

如果你在今年 6月-8月之間訪問Streamload.com,你可能會看到諸如“遇到死鎖”,“鎖超時”, “需要對象”等錯誤。這些錯誤都是由于鎖爭用引起的。在查閱大量文檔和討論后,我了解了這方面的知識,也就是上面所論述的內容,我再次敘述如下:

SQL Server開始是用行級鎖的,但是經常會擴大為頁面鎖和表鎖,最終造成死鎖。

即使用戶沒有修改數據, SQL Server在SELECT的時候也會遇到鎖。幸運的是,我們可以通過SQL Server 的兩個關鍵字來手工處理:NOLOCK和ROWLOCK。

它們的使用方法如下:

SELECT COUNT (UserID)
FROM ? Users ? WITH ? ( NOLOCK )
WHERE ? Username ? LIKE ? 'foobar'

UPDATE ? Users ? WITH ? ( ROWLOCK )
SET ? Username = ? 'fred' ? WHERE ? Username = ? 'foobar'

NOLOCK的使用

NOLOCK可以忽略鎖,直接從數據庫讀取數據。這意味著可以避開鎖,從而提高性能和擴展性。但同時也意味著代碼出錯的可能性存在。你可能會讀取到運行事務正在處理的無須驗證的未遞交數據。 這種風險可以量化。

如果是金融方面的代碼或者一些非常規的總計 (你想絕對保證安全性),你應該小心行事并且不使用這種技術。 但是我認為使用該技術會比你90%應用系統性能要好,當用戶(或者是交互代碼)發現一個未遞交的修改時,使用技術會保證不會像未使用該技術那樣引起大麻煩。實際上,你可能發現你的大多數數據很少或者甚至不進行 修改的,這樣我們就不會因為這些數據被鎖住而浪費大量的時間。

例如,如果你想統計在 2000年6月份到8月份之間加入Streamload.com的所有用戶,就沒有理由去鎖住任何記錄: 2000年9月1號一到來,這個用戶數就是確定的。又例如要列舉在Streamload.com的文件列表:這種結果即使 不是100%的正確,也不是大問題。因為你要么不擁有該文件,當然也無所謂你是否能找到它,或者你確實擁有該文件,這種情況下你當然知道你是否修改了該文件,以及該文件是否已經上傳完畢了。

但是,如果這些數據的修改,對數據庫來說是基礎性的修改,或者這些數據對于用戶來說,必須是百分之百保證 是修改正確的 (例如帳單或者余額數據),那么你不要使用該技術。

ROWLOCK的使用

ROWLOCK告訴SQL Server只使用行級鎖。ROWLOCK語法可以使用在SELECT,UPDATE和DELETE語句中,不過 我習慣僅僅在UPDATE和DELETE語句中使用。如果在UPDATE語句中有指定的主鍵,那么就總是會引發行級鎖的。但是當SQL Server對幾個這種UPDATE進行批處理時,某些數據正好在同一個頁面(page),這種情況在當前情況下 是很有可能發生的,這就象在一個目錄中,創建文件需要較長的時間,而同時你又在更新這些文件。當頁面鎖引發后,事情就開始變得糟糕了。而如果在UPDATE或者DELETE時,沒有指定主鍵,數據庫當然認為很多數據會收到影響,那樣 就會直接引發頁面鎖,事情同樣變得糟糕。

通過指定使用行級鎖,這種情況可以得到避免。但是需要小心的是,如果你錯誤地使用在過多行上,數據庫并不會聰明到自動將行級鎖升級到頁面鎖,服務器也會因為行級鎖的開銷而消耗大量的內存和 CPU,直至無法響應。尤其主要留意的是 企業管理器中"管理/當前活動"(Management/Current Activity)這一項。該項會花較長的時間來載入鎖的信息。這些信息 時十分有用的,當你使用行級鎖后,你如果在"鎖/處理"(Locks/Processes)下看到幾百個鎖,一點都不奇怪,而恰恰應該慶幸鎖超時和死鎖的問題減少了。

注意事項

我認為 SQL Server傾向于使用NOLOCK關鍵字,而ROWLOCK關鍵字由用戶根據情況自行決定。你可以僅僅在 SELECT語句中使用NOLOCK,這些SELECT語句場合包括INNER查詢,以及在INSERT語句中的SELECT使用,在連接查詢下也可以使用,例如:

SELECT COUNT (Users.UserID)
FROM ? Users ? WITH ? ( NOLOCK )
JOIN ? UsersInUserGroups ? WITH ? ( NOLOCK ) ? ON ?
Users.UserID = UsersInUserGroups.UserID

NOLOCK 和 ROWLOCK的使用效果

很難去量化在使用 NOLOCK和ROWLOCK后,Streamload.com或者你的網站性能到底改善了多少。 不過在使用NOLOCK和ROWLOCK前,Streamload.com的速度很慢,而且經常無法使用,以及很不穩定。使用后,就變得快速、容易訪問以及穩定了。兩者簡直就是天壤之別。這些改變當然無法在 關于鎖的文檔中很難找到。那些文檔會建議你重寫你的應用,當表數據被使用,鎖產生了(沒錯,就是這樣),然后你應該使用小事務并且以批處理的形式執行(不錯,實際經驗就是如此),使用低級別的隔離措施 (也沒錯,NOLOCK就是一個極端的例子),還建議你有限的連接,從而讓處理器進行合作(好復雜的描述,而且總覺得怪怪的不像個好點子)。我不知道是否用數據庫咨詢師會提到本文中的技術(或類似的技術), 但是我只想說的是,Streamload.com的運行狀況的確因為該技術得到了改善。如果你遇到了鎖爭用的問題,也可以試試NOLOCK和ROWLOCK。

申明

是否使用 NOLOCK和ROWLOCK,需要自行判斷,并謹慎運用。我用該技術的方法是通過查看我的存儲過程和即時查詢語句,在我自己的理解上來覺得哪里用和如何用。我需要判斷如果用NOLOCK 而引起一些返回的不準確,或者ROWLOCK是否會造成太多的鎖,這些情況出現時,對于訪問者或者使用者來說,是否是可以接受的。在大多數情況下,我認為是沒有問題的,但是也許你的代碼不適用, 你需要小心對待。你需要創建一些獨立的過程,是否加鎖,如何加鎖,以作為對比。當UPDATE或者 DELETE查詢影響到很多數據行時,你在使用PAGELOCK,TABLOCK時也會遇到別的問題。

?附:
---------------
 UPDLOCK
  讀取表時使用更新鎖,而不使用共享鎖,并將鎖一直保留到語句或事務的結束。UPDLOCK 的優點是允許您讀取數據(不阻塞其它事務)并在以后更新數據,同時確保自從上次讀取數據后數據沒有被更改。
  這是SqlServer2000中對更新鎖的說明.
  當我們用UPDLOCK來讀取記錄時可以對取到的記錄加上更新鎖,從而加上鎖的記錄在其它的線程中是不能更改的只能等本線程的事務結束后才能更改,我如下示例:
BEGIN ? TRANSACTION ? -- 開始一個事務
SELECT ?Qty
?
FROM ?myTable? WITH ?(UPDLOCK)
?
WHERE ?Id? in ?( 1 , 2 , 3 )
?
UPDATE ?myTable? SET ?Qty? = ?Qty? - ?A.Qty
?
FROM ?myTable?? AS ?A?
?
INNER ? JOIN ?? @_Table ? AS ?B? ON ?A.ID? = ?B.ID
COMMIT ? TRANSACTION ? -- 提交事務
  這樣在更新時其它的線程或事務在這些語句執行完成前是不能更改ID是1,2,3的記錄的.其它的都可以修改和讀,1,2,3的只能讀,要是修改的話只能等這些語句完成后才能操作.從而保證的數據的修改正確.

了解SQL Server鎖爭用:NOLOCK 和 ROWLOCK 的秘密


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 日韩欧美视频在线一区二区 | 国产911情侣拍拍在线播放 | 国产欧美精品区一区二区三区 | 99久久综合狠狠综合久久 | 看大片全色黄大色黄 | 亚洲天堂久久精品 | 青青青国产 | 奇米影视在线观看 | 99综合色 | 久久午夜精品 | 亚洲人成网i8禁止 | 久久婷婷午色综合夜啪 | 久久国产乱子伦精品免 | 在线欧美v日韩v国产精品v | 嫩操影院 | 亚洲综合伊人色一区 | 久久久久亚洲国产 | 99久久精品免费看国产情侣 | 日本一区二区在线播放 | 欧美成人一区二区三区在线视频 | 国内国语一级毛片在线视频 | 亚洲国产成人久久99精品 | 伊人丁香狠狠色综合久久 | 精品国产一区二区三区四 | 手机看片福利永久国产日韩 | 国产爱v| 免费观看性欧美一级 | 国产国语videosex另类 | 婷婷亚洲综合 | 免费视频成人国产精品网站 | 免费人成年短视频在线观看网站 | 国人精品视频在线观看 | 日韩中文字幕在线视频 | 91资源在线播放 | 亚洲精品国产经典一区二区 | 一本一道久久 | 真实子伦视频不卡 | 精品国产一区二区三区不卡在线 | 亚洲国产精品ⅴa在线观看 亚洲国产精品aa在线看 | 久久久久夜色精品波多野结衣 | 一级寡妇乱色毛片全18 |