何為并發: 同時訪問一種資源的用戶被視為并發訪問資源。并發數據訪問需要某些機制,以防止多個用戶試圖修改其他用戶正在使用的資源時產生負面影響。 管理并發: 并發影響? 并發控制的類型? 數據庫引擎中的隔離級別 ?并發影響: 丟失更新? 未提交的依賴關系(臟讀)? 不一致的分析(不可重復讀)? 幻讀 ?丟失更新: 當兩個或多個事務選擇同一行,然后基于最初選定的值更新該行時,會發生丟失更新問題。每個事務都不知道其他事務的存在。最后的更新將覆蓋由其他事務所做的更新,這將導致數據丟失。 ?????? 例如,兩個編輯人員制作了同一文檔的電子副本。每個編輯人員制作了同一文檔的電子副本。每個編輯人員獨立地更改其副本,然后保存更改后的副本,這樣就覆蓋了原始文檔。最后保存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成并提交事務之前,另一個編輯人員不能訪問同一文件,則可避免此問題。 ?未提交的依賴關系(臟讀): 當第二個事務選擇其他事務正在更新的行時,會發生未提交的依賴關系問題。第二個事務正在讀取的數據還沒有提交并且可能由更新此行的事務所更改。 ?? 例如,一個編輯人員正在更改電子文檔。在更改過程中,另一個編輯人員復制了該文檔(該副本包含到目前為止所做的全部更改)并將其分發給預期的用戶。此后,第一個編輯人員認為目前所做的更改是錯誤的,于是刪除了所做的編輯并保存了文檔。分發給用戶的文檔包含不再存在的編輯內容,并且這些編輯內容應視為從未存在過。如果在第一個編輯人員保存最終更改并提交事務之前,任何人都不能讀取更改的文檔,則可以避免此問題。 ?不一致的分析(不可重復讀): 當第二個事務多次訪問同一行而且每次讀取不同的數據時,會發生不一致的分析問題。不一致的分析與未提交的依賴關系類似,因為其他事務也是正在更改第二個事務正在讀取的數據。但是,在不一致的分析中,第二個事務讀取的數據是由已進行了更改的事務提交的。此外,不一致的分析涉及多次(兩次或更多)讀取同一行,而且每次信息都被其他事務更改,因此我們稱之為"不可重復讀"。???????????????????????? ? 例如,編輯人員兩次讀取同一文檔,但在兩次讀取之間,作者重寫了該文檔。當編輯人員第二次讀取文檔時,文檔已更改。原始讀取不可重復。如果在編輯人員完成最后一次讀取文檔之前,作者不能更改文檔,則可以避免此問題。 ?幻讀: 當對某行執行插入或刪除操作,而該行屬于某個事務正在讀取的行的范圍時,會發生幻讀問題。由于其他事務的刪除操作,事務第一次讀取的行的范圍顯示有一行不再存在于第二次或后續讀取內容中。同樣,由于其他事務的插入操作,事務第二次或后續讀取的內容顯示有一行并不存在于原始讀取內容中。 例如,一個編輯人員更改作者提交的文檔,但當生產部門將其更改內容合并到該文檔的主副本時,發現作者已將未編輯的新材料添加到該文檔中。與不可重復讀的情況相似,如果在編輯人員和生產部門完成對原始文檔的處理之前,任何人都不能將新材料添加到文檔中,則可以避免此問題。 ?可用性和鎖: ACID Transaction Design Requirements-->原子性(Atomicity)? 一致性(Consistency) 隔離性(Isolation) 持久性(Durability)? 隔離級別-->Level 0-讀未提交(Read Uncommitted) Level 1-讀提交(Read Committed) Level 2-可重復讀(Repeatable Reads) Level 3-可串行(Serializable)? 在2000/2005中默認隔離級別是ANSI/ISO Level 1,Read Committed? 隔離級別0-讀未提交(鎖現象: 臟讀)--> 一個讀事務可以讀另一個事務的未提交的改變A,導致了"臟讀? DML語句總是使用排他鎖? 原理: 對于臟讀事務沒有使用行銷(使用了SCH_S鎖),所讀出的數據可能是無效的。 產生現象: 因為數據被修改中,所讀出的結果可能是無效的(Rolled back) 隔離級別1-讀提交(鎖現象: 不一致分析/不可重復讀)-->所有版本的默認行為? 正在修改中的數據不能被另一個事務讀,僅當提交后方可訪問。一個事務中,select語句執行完畢后,在事務結束之前,其他事務便可修改這些數據。 DML語句總是使用排他鎖? 原理: 在一個事務中,讀操作發出行鎖,當行被檢索后,鎖就釋放(修改不釋放鎖),而無需等到事務結束,這樣別的事務就可以訪問這些行。 產生現象: 在一個事務中,再次讀的結果會不一樣--不可重復讀。但它消滅了臟讀。 隔離級別2-可重復讀(現象: 幻影)-->正在進行中的事務的數據被上鎖,即便select執行完,別的事務也不能修改這些數據,只能讀取這些數據。從而在一個事務中兩次讀結果一樣。并發低于默認隔離級別,只應在必要時才用。 原理: 在事務執行期間,讀鎖一直被保持,因此別的事務不能修改這些數據,重復讀成為可能。 產生現象: 在事務開始時未檢索出的行可能會在后續的檢索中出現。這種現象被稱之為幻影。 ?隔離級別3-可串行(鎖現象: 無)-->在數據集上放置一個范圍鎖,以防止其他用戶在事務完成之前更新數據集或將行插入數據集內。這是四個隔離級別中限制最大的級別。因為并發級別較低,所以應只在必要時才使用該選項。該選項的作用與在事務內所有SELECT語句中的所有表上設置HOLDLOCK相同。 原理: 事務中的鎖被保持在一個更高的級別上,利用索引產生key range鎖,從而阻止對數據庫集的插入。 副作用: 為了阻止向數據集插入行,數據集需要被鎖定。如果沒有合適的索引,那么便有可能產生更高級別的所,如表鎖,而非范圍鎖。 ?并發控制的類型: 悲觀并發控制? 樂觀并發控制? Microsoft SQL Server 2005支持某個范圍的并發控制。用戶通過為游標上的連接或并發選項選擇事務隔離級別來指定并發控制的類型。這些特性可以使用Transact-SQL語句或通過數據庫應用程序編程接口(API,如ADO、ADO.NET、OLE DB和ODBC)的屬性和特性來定義 運行SET TRANSACTION ISOLATION LEVEL Transact-SQL語句。 使用System.Data.SqlClient的ADO.NET應用程序可以使用SqlConnection.Begin Transaction方法來指定IsolationLevel選項。 使用ADO的應用程序可以設置"自動提交隔離級別"屬性。 使用OLE DB的應用程序可以調用ITransactionLocal: Start Transaction,其中isoLevel設置為所需的事務隔離級別。 使用ODBC的應用程序可以使用SQLSetConnectAttr來設置SQL_COPT_SS_TXN_ISOLATION屬性。 ? 數據庫引擎中的隔離級別: SQL-99標準定義了下列隔離級別,Microsoft SQL Server Database Engine支持所有這些隔離級別-->未提交讀(隔離事務的最低級別,只能保證不讀取物理上損壞的數據)? 已提交讀(數據庫引擎的默認級別)? 可重復讀? 可序列化(隔離事務的最高級別,事務之間完全隔離) SQL Server 2005新的隔離級別: SQL Server 2005還支持使用行版本控制的兩個事務隔離級別。一個是已提交讀隔離的新實現,另一個是新事務隔離級別(快照)。 行版本控制: 生成觸發器中插入的和刪除的表。 支持多個活動的結果集(MARS)。 支持指定ONLINE選項的索引操作。 支持基于行版本控制的事務隔離級別-->新實現的已提交讀隔離級別,使用行版本控制提供語句級的讀取一致性。 新快照隔離級別,提供事務級的讀取一致性。 tempdb數據庫必須具有足夠的空間用于版本存儲區。 讀取數據時的行為: 當在基于行版本控制的隔離下運行的事務讀取數據時,讀取操作不會獲取正被讀取的數據上的共享鎖(S鎖),因此不會阻塞正在修改數據的事務。另外,鎖定資源的開銷隨著所獲取的鎖的數量的減少降至最低。使用行版本控制的已提交讀隔離和快照隔離旨在提供副本數據的語句級或事務級讀取一致性。 ?修改數據時的行為: 在使用行版本控制的已提交讀事務中,使用阻塞性掃描(其中讀取數據值時將在數據行上采用更新鎖(U鎖)完成選擇要更新的行。這與不使用行版本控制的已提交讀事務相同。 ? 在快照隔離下運行的事務對數據修改采用樂觀方法: 直到數據被修改時才獲取數據上的鎖。當數據行符合更新標準時,快照事務將驗證數據行未被并發事務(在快照事務開始后提交)修改。如果數據行已在快照事務以外修改,則將出現更新沖突,同時快照事務也將終止。更新沖突由數據庫引擎處理,無法禁用更新沖突檢測。 設置SQL Server 2005新的隔離級別: 將READ_COMMITED_SNAPSHOT數據庫選項設置為ON時,已提交讀隔離使用行版本控制提供語句級別的讀取一致性。讀取操作只需要SCH-S表級別的鎖,不需要頁鎖或行鎖。 將READ_COMMITED_SNAPSHOT數據庫選項設置為OFF(默認設置)時,已提交讀隔離的行為與在SQL Server的早期版本中相同。兩個實現都滿足已提交讀隔離的ANSI定義。 SQL Server 2005新的隔離級別: 快照隔離級別使用行版本控制來提供事務級別的讀取一致性。讀取操作不獲取頁鎖或行鎖,只獲取SCH-S表鎖。讀取其他事務修改的行時,讀取操作將檢索啟動事務時存在的行的版本。將ALLOW_SNAPSHOT_ISOLATION數據庫選項設置為ON時,將啟用快照隔離。默認情況下,用戶數據庫的此選項設置為OFF。 選擇: 對于大多數應用程序,建議應用使用行版本控制的已提交讀隔離,而不要應用快照隔離,原因: 已提交讀隔離比快照隔離占用的tempdb空間少。已提交讀隔離可用于分布式事務,而快照隔離不能用于分布式事務。已提交讀隔離可用于大多數現有應用程序,而不需要進行任何更改。快照隔離會發生不適用于使用行版本控制的已提交讀隔離的更新沖突。當在快照隔離下運行的事務讀取另一個事務稍后會修改的數據時,快照事務對同一數據的更新會導致更新沖突,該事務將終止并回滾。而使用行版本控制的已提交讀隔離不存在此問題。 ???? 快照隔離提供事務級讀取的一致性。數據快照在快照事務啟動時產生并在事務持續時間內保持一致。 發生情況時,使用快照隔離: 需要開放式并發控制。 由于更新沖突必須回滾事務的可能性較低。 應用程序需要基于必須具有時點一致性的長時間運行的多語句查詢生成報告。快照隔離具有可重復讀取的優點,而不使用共享鎖。 其它技術: 數據庫快照? 數據庫快照是數據庫(源數據庫)的只讀、靜態視圖。多個快照可以位于一個源數據庫中,并且可以作為數據庫始終駐留在同一服務器實例上。創建快照時,每個數據庫快照在事務上與源數據庫一致。在被數據庫所有者顯示刪除之前,快照始終存在。 快照可用于報表。另外,如果源數據庫出現用戶錯誤,還可將源數據庫恢復到創建快照時的狀態。丟失的數據僅限于創建快照后數據庫更新的數據。 ?數據庫快照(Database Snapshot): 數據庫某個時間點的快照-->即時創建的 只讀性的? 基礎數據庫繼續變化-->快照不影響、限制對基礎數據庫的更新? 快照名與基礎數據庫名不同? 返回到以前創建的快照可挽救誤操作? 極其有效的空間管理? 采用"copy on write"機制-->無需復制數據的完整備份? 共享無變化的數據庫頁面? 僅存儲已變化的數據頁? 命令-->Create Northwind_SS Update Northwind Read Northwind_SS? 結果-->DD ?

本文轉自 葉俊生 51CTO博客，原文鏈接:http://blog.51cto.com/yejunsheng/161364

總結

以上是生活随笔為你收集整理的管理大批量并发处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。