第8章

事務管理

事

務

并發控制

恢

復

事

務

事務的概念

事務的性質

可串行性和隔離級別

SQL對事務的支持

事務的概念事務是構成單一邏輯工作單元的操作集合。

為什么需要事務的概念呢？

恢復的需要并發操作的需要事務的性質

原子性（Atomicity）

一致性（Consistency）隔離性（Isolation）

持久性（Durability）

事務的這些性質通常稱為ACID特性原子性

事務的原子性強調了一個事務是一個邏輯工作單元，是一個整體，是不可分割的。一個事務所包含的操作要么全部做，要么全部不做。

一致性

一個事務執行一項數據庫操作，事務將使數據庫從一種一致性的狀態變換成另一種一致性狀態。

在事務執行前，總是假設數據庫是一致的，那么當事務成功執行后，數據庫肯定仍然是一致的。

隔離性

如果每個事務單獨執行能保持原子性和一致性，這些事務并發執行也能保持原子性和一致性，則是事務的隔離性。持久性

事務的持久性是指一旦事務成功完成，該事務對數據庫所施加的所有更新都是永久的。

可串行性可串行性通常看作是多個事務并發執行的正確性準則。具體判定方法如下：各單個事務如能將數據庫從一個正確狀態轉變為另一個正確狀態，則認為該事務是正確的；

按任何一個串行順序依次執行多個事務也是正確的（這里的串行順序假定各個事務間彼此獨立、不交叉）；

事務的交叉執行過程是正確的，當且僅當其與串行執行過程等價，則事務是可串行化的。

SQL對事務的支持

開始事務

結束事務

事務保存點

隱含事務與自動提交

開始事務

使用BEGINTRANSACTION命令顯式說明一個事務開始，它說明了對數據庫進行操作的一個單元的起始點。在事務完成之前出現任何操作錯誤和故障，都可以撤銷事務，使事務回退到這個起始點。

結束事務

成功結束事務的命令是COMMITTRANSACTION，它的作用是提交或確認事務已經完成，所以該命令也稱作事務提交。

撤消事務的命令是ROLLBACKTRANSACTION，即撤消在該事務中對數據庫所做的更新操作，使數據庫回退到事務的起始點。

事務保存點

SQL標準還支持“事務保存點”技術，所謂事務保存點就是在事務的過程中插入若干標記，這樣當發現事務中有操作錯誤時，可以不撤消整個事務，只撤消部分事務，即將事務回退到某個事務保存點。

并發控制

干擾問題

解決干擾——封鎖

封鎖不當——死鎖

封鎖與隔離級別

干擾問題

丟失更新問題

未提交依賴問題

不一致分析問題

幻象讀問題

丟失更新問題

例：旅客A來到A售票處，要買一張15日北京到上海的13次直達快速列車的軟臥車票，售票員A（下稱用戶A）在終端A查看剩余票信息；

幾乎在同時，旅客B來到B售票處，也要買一張15日北京到上海的13次直達快速列車的軟臥車票，售票員B（下稱用戶B）從終端B查到了同樣的剩余票信息；

旅客A買了一張15日13次7車廂5號下鋪的軟臥票，用戶A更新剩余票信息并將它存入數據庫；

這時用戶B不知道用戶A已經將15日13次7車廂5號下鋪的軟臥票賣出，使旅客B也買了一張15日13次7車廂5號下鋪的軟臥票，用戶B更新剩余票信息并將它存入數據庫（重復了用戶A已經做過的更新）。

總的效果：15日13次7車廂5號下鋪的軟臥票賣了兩次。其原因是：允許了用戶B在過時的信息基礎上去更新數據庫，而沒有迫使他去看最新的信息。丟失更新問題

用SQL術語描述丟失更新問題未提交依賴問題

未提交依賴問題也稱為讀“臟”（DirtyRead）數據問題，查詢一個已經被其他事務更新、但尚未提交的元組，將會引起未提交依賴問題。

不一致分析問題

不一致分析問題也稱為不可重復讀問題，很多應用可能需要校驗功能，這時往往需要連續兩次或多次讀數據進行校驗和分析，結果由于其他事務的干擾，使得前后結果不一致，從而產生校驗錯誤（即不一致的分析）。

幻象讀問題

幻象讀問題與不一致分析問題有關，當事務A讀數據時，事務B在對同一個關系進行插入或刪除操作，這時事務A再讀同一條件的元組時，會發現神秘地多出了一些元組或丟失了一些元組，把這種現象稱作幻象讀。

封鎖

封鎖的基本技術

封鎖機制

SQLServer中與封鎖有關的命令

封鎖粒度

意向鎖

封鎖的基本技術當需要查詢或更新數據時，先對數據進行封鎖，以避免來自其他事務的干擾。針對不同的干擾問題可以有不同的封鎖機制。

以丟失更新問題為例，實施封鎖的基本思想是：當一個用戶對一個表或記錄進行更新時，封鎖該表或記錄，使其他用戶不能在同一時刻更新相同的表或記錄，迫使其他用戶在更新后的基礎上（而不是在更新前的基礎上）再實施另外的更新操作。

封鎖的基本技術實施封鎖以后的時間序列封鎖機制

共享封鎖

獨占封鎖

更新封鎖

有些封鎖在執行完相應操作后就自動釋放封鎖，有些封鎖則保持到事務結束（提交或撤消）時才釋放（無論如何，所有的封鎖都會在事務結束時自動釋放）。共享封鎖

共享封鎖是為讀操作設置的一種封鎖，所以也稱作讀封鎖，或簡稱S鎖，目的是想讀到一組不變的數據，也就是在讀數據的過程中，不允許其他用戶對該數據進行任何修改操作。這種封鎖可以保證最大的并發性，任何數量的用戶都可以同時對同樣的數據施加這種共享鎖。已經實施共享鎖的表拒絕來自其他事務的獨占封鎖和更新封鎖。

獨占封鎖

獨占封鎖也叫排他封鎖，它是為修改操作設置的一種封鎖，也稱為寫封鎖，或簡稱為X鎖，這是最嚴格的一類封鎖。當需要對表實施插入、刪除或修改操作時，應該使用獨占封鎖。已經實施獨占封鎖的表，拒絕來自其他用戶的任何封鎖，但不拒絕一般的查詢操作。

更新封鎖

當需要對一個記錄或一組記錄進行更新時（只是修改，不包括插入和刪除）使用更新封鎖，該封鎖的目的是防止其他用戶在同一時刻修改同一記錄。已經實施更新封鎖的記錄，拒絕來自其他用戶的任何封鎖，但不拒絕一般的查詢操作。

封鎖粒度

封鎖的對象可以是表、也可以是元組等，我們把封鎖對象的大小稱為封鎖粒度（Granularity）。封鎖的對象可以是邏輯單元（如表和元組等），也可以是物理單元（如數據頁和數據塊等）。數據庫管理系統一般都具有多粒度鎖定功能，允許一個事務鎖定不同類型的資源。

意向鎖

為了降低封鎖的成本，提高并發的性能，數據庫管理系統還支持一種意向鎖（IntentionLock）。

意向鎖表示一種封鎖意向，當需要在某些底層資源上（如元組）獲取封鎖時，可以先對高層資源（如表）實施意向鎖。意向鎖意向共享（IS）

意向排它（IX）

共享意向排它（SIX）

死鎖

產生死鎖的原因

避免死鎖

發現死鎖解決死鎖

產生死鎖的原因右圖示意了兩個并發事務所發生事件的序列，假設程序A為了完成某個事務需要封鎖倉庫和職工兩個關系，而幾乎在同一時刻并發執行的程序B為完成另一個事務也需要封鎖職工和倉庫關系，這兩個程序正好按照如圖所示的交錯序列執行命令，結果兩個程序都為了等待對方釋放數據資源而產生死鎖。

避免死鎖

相同順序法

所有的用戶程序約定都按相同的順序來封鎖表

一次封鎖法

為了完成一個事務，一次性封鎖所需要的全部表

兩階段封鎖協議

所有事務都必須將對數據的封鎖分為封鎖和釋放兩個階段

避免死鎖的封鎖

兩階段封鎖協議

第一階段稱為擴展階段，這一階段獲得各種類型的封鎖，但是不能釋放任何封鎖。第二階段稱為收縮階段，這一階段釋放各種類型的封鎖，一旦開始釋放封鎖，則不能再申請任何類型的封鎖。

注意，兩階段封鎖協議和一次封鎖法的異同之處。一次封鎖法遵守兩階段封鎖協議；但是兩階段封鎖協議并不要求一次封鎖所有需要封鎖的數據。兩階段封鎖協議仍有可能發生死鎖。

發現死鎖超時法

即一個事務在等待的時間超過了規定的時限后就認為發生了死鎖。

這種方法非常不可靠，如果設置的等待時限長，則不能及時發現死鎖；如果設置的等待時限短，則可能會將沒有發生死鎖的事務誤判為死鎖。

發現死鎖等待圖法

即通過有向圖判定事務是否是可串行化的，如果是則說明沒有發生死鎖，否則說明發生了死鎖。具體思路是：用節點來表示正在運行的事務，用有向邊來表示事務之間的等待關系，如右圖所示，如果有向圖中發現回路，則說明發生了死鎖。

解決死鎖發現死鎖后解決死鎖的一般策略是：自動使“年輕”的事務（即完成工作量少的事務）先退回去，然后讓“年老”的事務（即完成工作量多的事務）先執行，等“年老”的事務完成并釋放封鎖后，“年輕”的事務再重新執行。

恢

復

故障類型

備份類型

日志的概念

恢復模型

備份或轉儲

恢復或還原

故障類型造成事務中斷的故障

突然掉電引起的事務中斷

硬件故障引起的事務中斷

客戶應用程序出錯引起的事務中斷

系統程序故障引起的事務中斷

磁盤介質故障

備份類型

雙機熱備份

雙工備份

磁盤鏡像

數據庫備份技術

日志的概念

日志則是對備份的補充，它可以看作是一個值班日記，它將記錄下所有對數據庫的更新操作。這樣就可以在備份完成時立刻刷新并啟用一個數據庫日志，數據庫日志是實時的，它將忠實地記錄下所有對數據庫的更新操作。當磁盤出現故障造成數據庫損壞時，就可以首先利用備份恢復數據庫（恢復大部分數據），然后再運行數據庫日志，即將備份后所做的更新操作再重新做一遍，從而將數據庫完全恢復。恢復模型

簡單恢復模型允許將數據庫恢復到最新的備份，即使用簡單恢復模型可以將數據庫恢復到上次備份的即時點，而無法將數據庫恢復到故障點或特定的即時點。使用簡單恢復模型，日志實際失去了作用。使用簡單恢復模型的數據庫只能做數據庫備份，不能做日志備份。完全恢復模型允許將數據庫恢復到故障點狀態，即完全恢復模型使用數據庫備份和事務日志備份提供對介質故障的完全防范。備份或轉儲

備份的類型

備份整個數據庫

增量備份

事務日志備份

文件和文件組備份

系統數據庫的備份

數據庫備份的類型

全備份：即完整的備份整個數據庫；增量備份：增量數據庫備份只備份自上次數據庫備份后發生更改的數據；文件和文件組備份：備份數據庫文件或文件組，而不是備份數據庫；事務日志備份：只備份事務日志。恢復或還原

恢復整個數據庫

恢復數據庫的部分內容

恢復特定的文件或文件組

恢復事務

可以將數據庫恢復到做備份的即時點、發生故障的即時點或特定的事務即時點。恢復或還原根據數據庫全備份進行恢復

根據增量備份進行恢復

根據事務日志進行恢復

根據文件或文件組備份進行恢復

恢復系統數據庫

根據數據庫全備份進行恢復RESTOREDATABASEdatabase_nameFROM{DISK|TAPE}

='physical_backup_device_name'[WITH[[,]{NORECOVERY|RECOVERY}][[,]REPLACE]]根據增量備份進行恢復

在簡單恢復模型和完全恢復模型中都可以選擇增量備份，如果存在增量備份，則一般需要進行相應的恢復操作。

增量恢復數據庫的命令也是RESTOREDATABASE，但是在根據增量備份繼續恢復之前應該：已經使用RESTOREDATABASE命令完成了全備份的恢復，同時指定了NORECOVERY子句。

根據事務日志進行恢復

利用日志可以將數據庫恢復到最新的一致狀態或任意的事務點。

首先恢復事務日志備份之前的數據庫備份或增量數據庫備份。

如果有多個日志備份，則按先后順序進行恢復。

根據事務日志進行恢復RESTORELOGdatabase_nameFROM{DISK|TAPE}='physical_backup_device_name'[WITH[[,]{NORECOVERY|RECOVERY

}][[,]STOPAT=

date_time|[,]STOPATMARK='mark_name'[AFTERdatetime]|[,]STOPBEFOREMARK='mark_name'

[AFTERdatetime]]]根據文件或文件組備份進行恢復

如果數據庫的某個文件損壞了，并且按文件或文件組做了備份，則可以考慮根據文件或文件組備份進行恢復。

當使用文件或文件組備份進行恢復時，最后一個文件或文件組恢復操作完成后，必須將事務日志應用于數據庫文件，以便使之與數據庫的其余部分保持一致。如果被恢復的文件自上次備份后沒有做過任何修改操作，則不必應用事務日志，RESTORE語句會報告這一情況。

根據文件或文件組備份進行恢復RESTOREDATABASEdatabase_name{FILE=

logical_file_name

|FILEGROUP=

logical_filegroup_name}F