1、2020/9/12,1,數(shù)據(jù)庫原理與設計,第6章 管理數(shù)據(jù)庫,2020/9/12,數(shù)據(jù)庫的安全管理 數(shù)據(jù)庫的完整性管理 SQL SERVER數(shù)據(jù)庫恢復 并發(fā)控制,第4章 數(shù)據(jù)庫保護,2020/9/12,數(shù)據(jù)的安全性控制指防止非法用戶對數(shù)據(jù)進行訪問，以保證數(shù)據(jù)庫的數(shù)據(jù)不會由于非法使用而造成數(shù)據(jù)的泄漏、更改和破壞。 數(shù)據(jù)庫安全必須從以下幾個級別上設置安全措施： （1）環(huán)境級 （2）職員級 （3）操作系統(tǒng)級 （4）網(wǎng)絡級 （5）數(shù)據(jù)庫系統(tǒng)級,6.1 數(shù)據(jù)庫的安全管理,6.1.1 安全性概述,2020/9/12,6.1 數(shù)據(jù)庫的安全管理,6.1.2 數(shù)據(jù)庫管理系統(tǒng)的身份識別機制,數(shù)據(jù)庫管理系統(tǒng)通過用戶

2、標識（用戶名）來識別用戶的身份，以管理和決定一個用戶在數(shù)據(jù)庫中的操作權限。在一個運行的數(shù)據(jù)庫管理系統(tǒng)實例下可以建立和管理多個數(shù)據(jù)庫，身份識別實際上有3個層次 ，具體如下： （1）一個用戶要訪問某個數(shù)據(jù)庫必須首先登錄到數(shù)據(jù)庫管理系統(tǒng)，即必須首先有一個登錄（login）身份。 （2）每個登錄用戶不一定能夠訪問所有的數(shù)據(jù)庫，對其能夠訪問的數(shù)據(jù)庫還需要有數(shù)據(jù)庫用戶（database user）身份。 （3）一個數(shù)據(jù)庫用戶并不意味著他在這個數(shù)據(jù)庫上可以進行任何操作，數(shù)據(jù)庫用戶的任何操作都必須首先得到相應的授權。,2020/9/12,6.1 數(shù)據(jù)庫的安全管理,6.1.3 SQL Server的用戶和角色管

3、理,（1）概述 用戶管理有兩個層次，一是由系統(tǒng)管理員管理的登錄用戶，二是由數(shù)據(jù)庫管理員管理的數(shù)據(jù)庫用戶。 在一個系統(tǒng)或一個數(shù)據(jù)庫上會有很多用戶，每個用戶可能有獨立的職責，也可能很多用戶有相同或相近的職責，即不同的用戶可能擔當相同的角色。為了避免管理每個單個用戶的繁瑣，可以通過角色管理使權限管理變得簡單、清晰。SQL Server為了方便系統(tǒng)和數(shù)據(jù)庫管理預定了固定的服務器角色和數(shù)據(jù)庫角色。,2020/9/12,6.1 數(shù)據(jù)庫的安全管理,6.1.3 SQL Server的用戶和角色管理,（2）服務器角色 服務器級角色的權限作用域為服務器范圍。數(shù)據(jù)庫管理員將相應的權限賦予角色，然后再將角色賦給登錄用

4、戶，從而使登錄用戶擁有了相應的權限。 SQL Server 2008提供了9種固定的服務器角色，如下： Sysadmin 、Serveradmin、 Securityadmin、 Processadmin、 Setupadmin、 Bulkadmin、 Diskadmin、 Dbcreator和 public 。,2020/9/12,（3）數(shù)據(jù)庫角色 數(shù)據(jù)庫的角色分為固定數(shù)據(jù)庫角色和用戶定義的數(shù)據(jù)庫角色。固定數(shù)據(jù)庫角色指SQL Server為每個數(shù)據(jù)庫提供的角色。各固定數(shù)據(jù)庫角色的權限如下： db_owner：在數(shù)據(jù)庫中有全部權限。 db_accessadmin：負責數(shù)據(jù)庫用戶的管理。 db_

5、securityadmin：負責數(shù)據(jù)庫的安全管理等。 db_ddladmin：主要負責數(shù)據(jù)庫的完整性和一致性檢查及管理。 db_backupoperator：主要負責數(shù)據(jù)庫的備份和恢復。 db_datareader：可以查詢數(shù)據(jù)庫中任何用戶表中的所有數(shù)據(jù)。 db_ data writer：可以更改數(shù)據(jù)庫中任何用戶表中的所有數(shù)據(jù)。 db_denydatareader：不能查詢數(shù)據(jù)庫中任何用戶表中的任何數(shù)據(jù)。 db _ denydatawriter：不能更改數(shù)據(jù)庫中任何用戶表中的任何數(shù)據(jù)。,6.1 數(shù)據(jù)庫的安全管理,6.1.3 SQL Server的用戶和角色管理,2020/9/12,6.1 數(shù)據(jù)

6、庫的安全管理,6.1.4 SQL Server的安全認證模式,（1）Windows 安全認證模式 （2）SQL Server 認證模式 （3）混合認證模式,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2.1 完整性約束,數(shù)據(jù)庫的完整性是為了保證數(shù)據(jù)庫中存儲的數(shù)據(jù)的正確性，包括數(shù)據(jù)的合法性、有效性和相容性三個方面。 數(shù)據(jù)庫完整性由各種各樣的完整性約束來保證，因此可以說數(shù)據(jù)庫完整性設計就是數(shù)據(jù)庫完整性約束的設計。在關系系統(tǒng)中，最重要的完整性約束是實體完整性和參照完整性，其他完整性約束條件都可歸入用戶定義的完整性。,完整性約束可以分為6類：靜態(tài)列級約束、靜態(tài)元組約束、靜態(tài)關系約束、動態(tài)列級約

7、束、動態(tài)元組約束、動態(tài)關系約束。動態(tài)約束通常由應用軟件來實現(xiàn)。,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2.1 完整性約束,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2.2 完整性控制,完整性控制包括完整性約束條件定義機制、完整性檢查機制和違約反應三部分。 （1）完整性約束條件定義機制 完整性約束條件是數(shù)據(jù)模型的一個重要組成部分，它約束了數(shù)據(jù)庫中數(shù)據(jù)的語義。DBMS應給用戶提供根據(jù)現(xiàn)實世界的語義定義數(shù)據(jù)庫的約束條件的手段，并允許用戶把這些完整性約束條件作為模式的一部分存入數(shù)據(jù)庫中。 （2）完整性檢查機制 完整性檢查機制檢查用戶發(fā)出的操作請求是否違背了完整性約束條件。 （3

8、）違約反應 違約反應保證了在發(fā)現(xiàn)用戶的操作請求使數(shù)據(jù)違背了完整性約束條件后，采取一定的動作來保證數(shù)據(jù)的完整性。,2020/9/12,完整性規(guī)則從執(zhí)行時間上可分為立即執(zhí)行約束（Immediate Constraints）和延遲執(zhí)行約束（Deferred Constrainsts）。 立即執(zhí)行約束是指在執(zhí)行用戶事務過程中，某一條語句執(zhí)行完成后，系統(tǒng)立即對此數(shù)據(jù)進行完整性約束條件檢查。 延遲執(zhí)行約束是指在整個事務執(zhí)行結束后，再對約束條件進行完整性檢查，結果正確后才能提交。 某一條語句執(zhí)行完成后，系統(tǒng)立即對此數(shù)據(jù)進行完整性約束條件檢查。,立即執(zhí)行約束和延遲執(zhí)行約束,2020/9/12,例如，銀行數(shù)據(jù)庫

9、中“借貸總金額應平衡”的約束就應該屬于延遲執(zhí)行約束，從賬號A轉(zhuǎn)一筆錢到賬號B為一個事務，從賬號A轉(zhuǎn)出去錢后，賬就不平了，必須等轉(zhuǎn)入賬號B后，賬才能重新平衡，這時才能進行完整性檢查。,立即執(zhí)行約束和延遲執(zhí)行約束(2),2020/9/12,實現(xiàn)參照完整性應解決的問題,（1） 外碼能否接受空值問題 （2） 在被參照關系中刪除元組的問題 步級聯(lián)刪除（CASCADES） 受限刪除（RESTRICTED） 置空值刪除（NULLIFIES） （3）在參照關系中插入元組時的問題 受限插入 遞歸插入 （4）修改關系中主碼的問題 不允許修改主碼 允許修改主碼,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2

10、.3 SQL Server數(shù)據(jù)完整性的實現(xiàn)方法,SQL Server實現(xiàn)數(shù)據(jù)完整性的主要方法有4種：約束、默認、規(guī)則和觸發(fā)器。,（1）約束 約束通過限制列中的數(shù)據(jù)、行中的數(shù)據(jù)和表之間數(shù)據(jù)來保證數(shù)據(jù)完整性。SQL Server約束的5種類型和完整性功能。,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2.3 SQL Server數(shù)據(jù)完整性的實現(xiàn)方法,（2）觸發(fā)器 觸發(fā)器是一種功能強、開銷高的數(shù)據(jù)完整性方法。觸發(fā)器具有INSERT、UPDATE和DELETE三種類型。一個表可以具有多個觸發(fā)器。 觸發(fā)器的用途是維護行級數(shù)據(jù)的完整性。與CHECK約束相比，觸發(fā)器能強制實現(xiàn)更加復雜的數(shù)據(jù)完整性，能

11、執(zhí)行操作或級聯(lián)操作，能實現(xiàn)多行數(shù)據(jù)間的完整性約束，能按定義動態(tài)地、實時地維護相關的數(shù)據(jù)。,2020/9/12,6.2 數(shù)據(jù)庫的完整性管理,6.2.3 SQL Server數(shù)據(jù)完整性的實現(xiàn)方法,（3）默認與規(guī)則 默認（DEFAULT）和規(guī)則（RULE）都是數(shù)據(jù)庫對象。當它們被創(chuàng)建后，可以綁定到一列或幾列上，并可以反復使用。當使用INSERT語句向表中插入數(shù)據(jù)時，如果有綁定DEFAULT的列，系統(tǒng)就會將DEFAULT指定的數(shù)據(jù)插入；如果有綁定RULE的列，則所插入的數(shù)據(jù)必須符合RULE的要求。 默認可以綁定到一列或多列上或用戶自定義的數(shù)據(jù)類型上，其作用類似于DEFAULT約束，能為INSERT語句

12、中沒有指定數(shù)據(jù)的列提供事先定義的默認值。默認值可以是常量、內(nèi)置函數(shù)或數(shù)學表達式。,2020/9/12,數(shù)據(jù)庫恢復的含義 雖然數(shù)據(jù)庫系統(tǒng)中已采取一定的措施，來防止數(shù)據(jù)庫的安全性和完整性的破壞，保證并發(fā)事務的正確執(zhí)行，但數(shù)據(jù)庫中的數(shù)據(jù)仍然無法保證絕對不遭受破壞，比如計算機系統(tǒng)中硬件的故障、軟件的的錯誤，操作員的失誤，惡意的破壞等都有可能發(fā)生，這些故障的發(fā)生影響數(shù)據(jù)庫數(shù)據(jù)的正確性，甚至可能破壞數(shù)據(jù)庫，使數(shù)據(jù)庫中的數(shù)據(jù)全部或部分丟失。 因此，系統(tǒng)必須具有檢測故障并把數(shù)據(jù)從錯誤狀態(tài)中恢復到某一正確狀態(tài)的功能，這就是數(shù)據(jù)庫的恢復。,6.3 恢復,2020/9/12,6.3.1 恢復的原理,1故障的種類 （

13、1）事務內(nèi)部的故障 事務故障表示由非預期的、不正常的程序結束所造成的故障。 造成程序非正常結束的原因包括輸入數(shù)據(jù)錯誤、運算溢出、違反存儲保護、并行事務發(fā)生死鎖等。 發(fā)生事務故障時，被迫中斷的事務可能已對數(shù)據(jù)庫進行了修改，為了消除該事務對數(shù)據(jù)庫的影響，要利用日志文件中所記載的信息，強行回滾（ROLLBACK）該事務，將數(shù)據(jù)庫恢復到修改前的初始狀態(tài)。,2020/9/12,（2）系統(tǒng)故障,系統(tǒng)故障是指系統(tǒng)在運行過程中，由于某種原因，造成系統(tǒng)停止運轉(zhuǎn)，致使所有正在運行的事務都以非正常方式終止，要求系統(tǒng)重新啟動。 引起系統(tǒng)故障的原因可能有：硬件錯誤如CPU故障、操作系統(tǒng)或DBMS代碼錯誤、突然斷電等。

14、這時，內(nèi)存中數(shù)據(jù)庫緩沖區(qū)的內(nèi)容全部丟失，存儲在外部存儲設備上的數(shù)據(jù)庫并未破壞，但內(nèi)容不可靠了。,2020/9/12,（3）介質(zhì)故障,介質(zhì)故障通常稱為硬故障（Hard Crash）。硬故障指外存故障，例如磁盤損壞、磁頭碰撞、瞬時強磁場干擾等。這類故障將破壞數(shù)據(jù)庫或部分數(shù)據(jù)庫，并影響正在存取這部分數(shù)據(jù)的所有事務。這類故障比前兩類故障發(fā)生的可能性小得多，但破壞性最大。 對付這類故障，一方面需要盡可能提高硬件系統(tǒng)的可靠性，但這種提高是有限的。另一方面，在系統(tǒng)發(fā)生此類故障后，可以利用冗余的數(shù)據(jù)備份將系統(tǒng)恢復到先前一致的狀態(tài)。,2020/9/12,（4）計算機病毒,計算機病毒是一種人為的故障或破壞，是一些

15、惡作劇者編寫的一種計算機程序。這種程序可以繁殖和傳播，并造成對計算機系統(tǒng)包括數(shù)據(jù)庫的危害。 計算機病毒已成為計算機系統(tǒng)的主要威脅，自然也是數(shù)據(jù)庫系統(tǒng)的主要威脅。,2020/9/12,數(shù)據(jù)庫恢復的基本原理十分簡單，就是數(shù)據(jù)的冗余。 數(shù)據(jù)庫中任何一部分被破壞的或不正確的數(shù)據(jù)都可以利用存儲在系統(tǒng)其他地方的冗余數(shù)據(jù)來修復。 因此恢復系統(tǒng)應該提供兩種類型的功能： 一種是生成冗余數(shù)據(jù)，即對可能發(fā)生的故障作某些準備； 另一種是冗余重建，即利用這些冗余數(shù)據(jù)恢復數(shù)據(jù)庫。 生成冗余數(shù)據(jù)最常用的技術是登記日志文件和數(shù)據(jù)轉(zhuǎn)儲，在實際應用中，這兩種方法常常結合起來一起使用。,6.3.1 恢復的原理,2020/9/12,

16、6.3.2 恢復的實現(xiàn),1數(shù)據(jù)轉(zhuǎn)儲 數(shù)據(jù)轉(zhuǎn)儲是指定期地將整個數(shù)據(jù)庫復制到多個存儲設備如磁帶、磁盤上保存起來的過程，它是數(shù)據(jù)庫恢復中采用的基本手段。 轉(zhuǎn)儲的數(shù)據(jù)文本稱為后備副本或后援副本，當數(shù)據(jù)庫遭到破壞后就可利用后援副本把數(shù)據(jù)庫有效地加以恢復。 轉(zhuǎn)儲是十分耗費時間和資源的，不能頻繁地進行，應該根據(jù)數(shù)據(jù)庫使用情況確定一個適當?shù)霓D(zhuǎn)儲周期。,2020/9/12,用數(shù)據(jù)庫副本恢復數(shù)據(jù)庫,數(shù)據(jù)轉(zhuǎn)儲與恢復,2020/9/12,（1）靜態(tài)轉(zhuǎn)儲和動態(tài)轉(zhuǎn)儲 靜態(tài)轉(zhuǎn)儲期間不允許有任何數(shù)據(jù)存取活動，因而需在當前用戶事務結束之后進行，新用戶事務又需在轉(zhuǎn)儲結束之后才能進行，這就降低了數(shù)據(jù)庫的可用性。 動態(tài)轉(zhuǎn)儲指轉(zhuǎn)儲期間

17、允許對數(shù)據(jù)庫進行存取和修改，即轉(zhuǎn)儲和用戶事務可并發(fā)執(zhí)行。 （2）海量轉(zhuǎn)儲和增量轉(zhuǎn)儲 海量轉(zhuǎn)儲是指每次轉(zhuǎn)儲全部數(shù)據(jù)庫； 增量轉(zhuǎn)儲則指每次只轉(zhuǎn)儲上一次轉(zhuǎn)儲后更新過的數(shù)據(jù)。,數(shù)據(jù)轉(zhuǎn)儲,2020/9/12,數(shù)據(jù)轉(zhuǎn)儲方法,表4.9 數(shù)據(jù)轉(zhuǎn)儲方法,2020/9/12,日志文件是用來記錄事務對數(shù)據(jù)庫的更新操作的文件。對數(shù)據(jù)庫的每次修改，都將被修改項目的舊值和新值寫在一個叫做運行日志的文件中，目的是為數(shù)據(jù)庫的恢復保留詳細的數(shù)據(jù)。 （1）日志文件的格式和內(nèi)容 日志文件是用來記錄事務對數(shù)據(jù)庫的更新操作的文件。不同數(shù)據(jù)庫系統(tǒng)采用的日志文件格式也不完全一樣。一般日志文件主要有兩種格式：以記錄為單位的日志文件和以數(shù)據(jù)塊

18、為單位的日志文件。,2.登記日志文件（Logging）,2020/9/12, 以記錄為單位的日志文件,對于以記錄為單位的日志文件，日志文件中需要記錄各個事務的開始（BEGIN TRANSACTION）標記、結束（COMMIT或ROLLBACK）標記和所有更新操作。這里每個事務開始的標記、每個事務的結束標記和每個更新操作均作為日志文件中的一條日志記錄（log record）。 每條日志記錄的內(nèi)容主要包括：事務標識（標明是哪個事務）、操作類型（插入、刪除或修改）、操作對象（記錄內(nèi)部標識）、更新前數(shù)據(jù)的舊值（對插入操作而言，此項為空值）、更新后數(shù)據(jù)的新值（對刪除操作而言，此項為空值），例如： （T0

19、1; update; Student (age); 23; 24),2020/9/12, 以數(shù)據(jù)塊為單位的日志文件,對于以數(shù)據(jù)塊為單位的日志文件，日志記錄的內(nèi)容包括事務標識和被更新的數(shù)據(jù)塊。由于將更新前的整個塊和更新后的整個塊都放入日志文件中，操作的類型和操作對象等信息就不必放入日志記錄中。,2020/9/12,（2）日志文件的作用, 事務故障恢復和系統(tǒng)故障必須用日志文件。 在動態(tài)轉(zhuǎn)儲方式中必須建立日志文件，后援副本和日志文件綜合起來才能有效地恢復數(shù)據(jù)庫。 在靜態(tài)轉(zhuǎn)儲方式中，也可以建立日志文件。當數(shù)據(jù)庫被毀壞后可重新裝入后援副本把數(shù)據(jù)庫恢復到轉(zhuǎn)儲結束時刻的正確狀態(tài)，然后利用日志文件，把已完成的

20、事務進行重做處理，對故障發(fā)生時尚未完成的事務進行撤銷處理。這樣不必重新運行那些已完成的事務就可把數(shù)據(jù)庫恢復到故障前某一時刻的正確狀態(tài)。,2020/9/12,（3）登記日志文件的原則,登記的次序嚴格按并發(fā)事務執(zhí)行的時間次序。 必須先寫日志文件，后寫數(shù)據(jù)庫。,2020/9/12,3恢復策略,數(shù)據(jù)庫系統(tǒng)在運行中發(fā)生故障后，有些事務尚未完成就被迫中斷，這些未完成事務對數(shù)據(jù)庫所做的修改有一部分已寫入物理數(shù)據(jù)庫。 這時數(shù)據(jù)庫就處于一種不正確的狀態(tài)，或者說是不一致的狀態(tài)，這時可利用日志文件和數(shù)據(jù)庫轉(zhuǎn)儲的后備副本將數(shù)據(jù)庫恢復到故障前的某個一致性狀態(tài)。 根據(jù)故障類型的不同，應該采取不同的恢復策略。,2020/9

21、/12,事務故障是指事務在運行至正常終止點前被終止，這時恢復子系統(tǒng)應利用日志文件撤銷（UNDO）此事務已對數(shù)據(jù)庫進行的修改。事務故障的恢復是由系統(tǒng)自動完成的，對用戶是透明的。系統(tǒng)的恢復步驟如下。 反向掃描文件日志（即從最后向前掃描日志文件），查找該事務的更新操作。 對該事務的更新操作執(zhí)行逆操作。即將日志記錄中“更新前的值”寫入數(shù)據(jù)庫。這樣，如果記錄中是插入操作，則做刪除操作（因此時“更新前的值”為空）；若記錄中是刪除操作，則做插入操作；若是修改操作，則要用修改前值代替修改后值。 繼續(xù)反向掃描日志文件，查找該事務的其他更新操作，并做同樣處理。 如此處理下去，直至讀到此事務的開始標記，事務故障恢復

22、就完成了。,（1）事務故障的恢復,2020/9/12,系統(tǒng)故障發(fā)生后，對數(shù)據(jù)庫的影響有兩種情況： 一種情況是一些未完成事務對數(shù)據(jù)庫的更新已寫入數(shù)據(jù)庫，這樣在系統(tǒng)重新啟動后，要強行撤消（UNDO）所有未完成事務，清除這些事務對數(shù)據(jù)庫所做的修改。這些未完成事務在日志文件中只有BEGIN TRANSCATION標記，而無COMMIT標記。 另一種情況是有些己提交的事務對數(shù)據(jù)庫的更新結果還保留在緩沖區(qū)中，尚未寫到磁盤上的物理數(shù)據(jù)庫中，這也使數(shù)據(jù)庫處于不一致狀態(tài)，因此應將這些事務己提交的結果重新寫入數(shù)據(jù)庫。這類恢復操作稱為事務的重做（REDO）。這種己提交事務在日志文件中既有BEGIN TRANSCAT

23、ION標記，也有COMMIT標記。 因此，系統(tǒng)故障的恢復要完成兩方面的工作，既要撤消所有未完成的事務，還需要重做所有己提交的事務，這樣才能將數(shù)據(jù)庫真正恢復到一致的狀態(tài)。,（2）系統(tǒng)故障的恢復,2020/9/12,具體做法如下： 正向掃描日志文件（即從頭掃描日志文件），找出在故障發(fā)生前已經(jīng)提交的事務（這些事務既有BEGIN TRANSACTION記錄，也有COMMIT記錄），將其事務標識記入重做（REDO）隊列。同時找出故障發(fā)生時尚未完成的事務（這些事務只有BEGIN TRANSACTION記錄，無相應的COMMIT記錄），將其事務標識記入撤銷隊列。 對撤銷隊列中的各個事務進行撤銷（UNDO）處

24、理。 進行UNDO處理的方法是，反向掃描日志文件，對每個UNDO事務的更新操作執(zhí)行逆操作，即將日志記錄中“更新前的值”寫入數(shù)據(jù)庫。 對重做隊列中的各個事務進行重做（REDO）處理。 進行REDO處理的方法是，正向掃描日志文件，對每個REDO事務重新執(zhí)行日志文件登記的操作。即將日志記錄中“更新后的值”寫入數(shù)據(jù)庫。,（2）系統(tǒng)故障的恢復(2),2020/9/12,登記日志文件順序,恢復過程,（2）系統(tǒng)故障的恢復(3),2020/9/12,（3）介質(zhì)故障的恢復,發(fā)生介質(zhì)故障后，磁盤上的物理數(shù)據(jù)和日志文件被破壞，這是最嚴重的一種故障，恢復方法是重裝數(shù)據(jù)庫，然后重做已完成的事務。 裝入最新的數(shù)據(jù)庫后備副

25、本（離故障發(fā)生時刻最近的轉(zhuǎn)儲副本），使數(shù)據(jù)庫恢復到最近一次轉(zhuǎn)儲時的一致性狀態(tài)。 對于動態(tài)轉(zhuǎn)儲的數(shù)據(jù)庫副本，還需同時裝入轉(zhuǎn)儲開始時刻的日志文件副本，利用恢復系統(tǒng)故障的方法（即REDO+UNDO），才能將數(shù)據(jù)庫恢復到一致性狀態(tài)。 裝入相應的日志文件副本（轉(zhuǎn)儲結束時刻的日志文件副本），重做已完成的事務。 首先掃描日志文件，找出故障發(fā)生時已提交的事務的標識，將其記入重做隊列。然后正向掃描日志文件，對重做隊列中的所有事務進行重做處理，將日志記錄中“更新后的值”寫入數(shù)據(jù)庫。這樣就可以將數(shù)據(jù)庫恢復至故障前某一時刻的一致狀態(tài)了。 介質(zhì)故障的恢復需要數(shù)據(jù)庫管理員介入。具體的恢復操作仍由DBMS完成。,2020/

26、9/12,4具有檢查點的恢復技術,利用日志技術進行數(shù)據(jù)庫恢復時，恢復子系統(tǒng)必須搜索日志，確定哪些事務需要REDO，哪些事務需要UNDO。原則上需要檢查所有日志記錄。但這樣做會引起兩個問題。 搜索整個日志將耗費大量的時間，數(shù)據(jù)庫系統(tǒng)可能難以承受。 大多數(shù)需要REDO處理的事務實際上已經(jīng)將它們的更新操作結果寫到數(shù)據(jù)庫中了，然而恢復子系統(tǒng)又重新執(zhí)行了這些操作，浪費了大量時間。 為了解決這些問題，提出了具有檢查點的恢復技術。這種技術在日志文件中增加一類新的記錄檢查點（checkpoint）記錄，增加一個重新開始文件，恢復子系統(tǒng)在登錄日志文件期間動態(tài)地維護日志。,2020/9/12, 檢查點記錄的內(nèi)容,

27、建立檢查點時刻所有正在執(zhí)行的事務清單； 這些事務最近一個日志記錄的地址； 重新開始文件用來記錄各個檢查點記錄在日志文件中的地址。,2020/9/12,動態(tài)維護日志文件的方法,動態(tài)維護日志文件的方法是周期性地執(zhí)行如下操作： 將當前日志緩沖中的所有日志記錄寫入磁盤的日志文件上； 在日志文件中寫入一個檢查點記錄； 將當前數(shù)據(jù)緩沖的所有數(shù)據(jù)記錄寫入磁盤的數(shù)據(jù)庫中； 把檢查點記錄在日志文件中的地址寫入一個重新開始文件。,2020/9/12,6.3.1 數(shù)據(jù)庫復制與數(shù)據(jù)庫鏡像,(1) 數(shù)據(jù)庫復制 數(shù)據(jù)庫復制是使數(shù)據(jù)庫更具容錯性的方法，主要用于分布式數(shù)據(jù)庫系統(tǒng)。復制是將整個數(shù)據(jù)庫或數(shù)據(jù)庫的子集復制到網(wǎng)絡中的

28、其他服務器上，使這部分數(shù)據(jù)在不同地點擁有多個備份。這樣做有助于消除網(wǎng)絡擁擠，提高多個服務器之間的數(shù)據(jù)訪問速度。例如，可以將用于報表的重要數(shù)據(jù)從事務處理繁忙的服務器中移出。,2020/9/12,復制的過程一般通過發(fā)送每個活動事務日志記錄的方式來進行，在接收服務器上會盡快按日志記錄順序?qū)⑵鋺玫奖镜財?shù)據(jù)庫中，保證數(shù)據(jù)庫的一致性。 當數(shù)據(jù)庫出現(xiàn)故障時，系統(tǒng)可以采用副本對其進行聯(lián)機恢復，而在恢復過程中用戶可以繼續(xù)訪問數(shù)據(jù)庫的副本，而不必中斷應用。 數(shù)據(jù)庫復制的過程類似于報紙雜志的出版過程，即把信息從信息源迅速傳送到信息接收處，因此也稱復制模型為出版/訂閱模型。其中，提供數(shù)據(jù)的過程稱為出版，提供數(shù)據(jù)給其

29、他服務器使用的服務器稱為出版服務器。把數(shù)據(jù)從出版服務器發(fā)送到信息接收處（訂閱服務器）的過程稱為分發(fā)。請求數(shù)據(jù)稱為訂閱。,2020/9/12,復制方式,（1）對等復制（peer-to-peer） 對等復制是最理想的復制方式。在對等復制方式中，各個數(shù)據(jù)庫副本的地位是平等的，可以相互復制數(shù)據(jù)。用戶可以在任何場地讀取和更新公共數(shù)據(jù)集，而且不管在哪個數(shù)據(jù)庫進行數(shù)據(jù)更新，DBMS都會立即將數(shù)據(jù)傳送給所有其他副本。 （2）主/從復制（master/slave） 主/從復制指數(shù)據(jù)只能從主數(shù)據(jù)庫復制到從數(shù)據(jù)庫中。在這種方式中，只能在主數(shù)據(jù)庫中更新數(shù)據(jù)，其他副本數(shù)據(jù)庫只供用戶讀取數(shù)據(jù)。在主數(shù)據(jù)庫出現(xiàn)故障時，更新數(shù)

30、據(jù)的操作可以轉(zhuǎn)到另一數(shù)據(jù)庫副本上進行。這種復制方式實現(xiàn)起來比較簡單，易于維護數(shù)據(jù)一致性。主數(shù)據(jù)庫與各個數(shù)據(jù)庫副本在任何時候都必須保持事務的完整性。 （3）級聯(lián)復制（cascade） 級聯(lián)復制（cascade）是指某數(shù)據(jù)庫副本從主數(shù)據(jù)庫中復制過來的數(shù)據(jù)又從該數(shù)據(jù)庫再次復制到其他數(shù)據(jù)庫副本。例如，從數(shù)據(jù)庫A把數(shù)據(jù)復制到數(shù)據(jù)庫B，再從數(shù)據(jù)庫B把這些數(shù)據(jù)或其中部分數(shù)據(jù)復制到數(shù)據(jù)庫C。級聯(lián)復制可以平衡當前各種數(shù)據(jù)需求對網(wǎng)絡交通的壓力。,2020/9/12,(2) 數(shù)據(jù)庫鏡像,數(shù)據(jù)庫鏡像（Mirror）根據(jù)數(shù)據(jù)庫管理員的要求，自動把整個數(shù)據(jù)庫或其中的關鍵數(shù)據(jù)復制到不同環(huán)境的另一個數(shù)據(jù)庫中。每當主數(shù)據(jù)庫更新

31、時，DBMS自動把更新后的數(shù)據(jù)復制過去，即DBMS自動保證鏡像數(shù)據(jù)與主數(shù)據(jù)的一致性。這樣，一旦出現(xiàn)介質(zhì)故障，可由鏡像磁盤繼續(xù)提供使用，同時DBMS自動利用鏡像磁盤數(shù)據(jù)進行數(shù)據(jù)庫的恢復，不需要關閉系統(tǒng)和重裝數(shù)據(jù)庫副本。在沒有出現(xiàn)故障時，數(shù)據(jù)庫鏡像還可以用于并發(fā)操作，即當一個用戶對數(shù)據(jù)加排它鎖修改數(shù)據(jù)時，其他用戶可以讀鏡像數(shù)據(jù)庫上的數(shù)據(jù)，而不必等待該用戶釋放鎖。,2020/9/12,完整性是保證各個事務本身能得到正確的數(shù)據(jù)，只考慮一個用戶使用數(shù)據(jù)庫的情況，但實際上數(shù)據(jù)庫中有許多用戶。 每個用戶在存取數(shù)據(jù)庫中的數(shù)據(jù)時，可能是串行執(zhí)行，即每個時刻只有一個用戶程序運行，也可能是多個用戶并行地存取數(shù)據(jù)庫。

32、 數(shù)據(jù)庫的最大特點之一就是數(shù)據(jù)資源是共享的。 為了充分利用數(shù)據(jù)庫資源，很多時候數(shù)據(jù)庫用戶都是對數(shù)據(jù)庫系統(tǒng)并行存取數(shù)據(jù)，這樣就會發(fā)生多個用戶并發(fā)存取同一數(shù)據(jù)塊的情況，如果對并發(fā)操作不加控制可能會產(chǎn)生不正確的數(shù)據(jù)，破壞數(shù)據(jù)的完整性，并發(fā)控制就是解決這類問題，以保持數(shù)據(jù)庫中數(shù)據(jù)的一致性。,6.4 并發(fā)控制,2020/9/12,1事務（Transaction） 事務（Transaction）是數(shù)據(jù)庫的邏輯工作單元，它是一組對數(shù)據(jù)操作的序列，這些操作要么全做要么全不做。事務是并發(fā)控制的基本單位。 事務是由有限的數(shù)據(jù)庫操作序列組成，但并不是任意的數(shù)據(jù)庫操作序列都能成為事務，為了保護數(shù)據(jù)的完整性，一般要求事

33、務具有以下四個特征： 原子性 一致性 隔離性 持續(xù)性,6.4.1 并發(fā)控制概述,2020/9/12, 原子性（Atomicity），即一個事務是不可分割的數(shù)據(jù)庫邏輯工作單位。 一致性（Consistency），事務的執(zhí)行結果必須使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。 隔離性（Isolation），一個事務的執(zhí)行不能被其他事務干擾。 持續(xù)性（Durability），持續(xù)性也稱為永久性，指一個事務一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變應該是永久性的，其他操作或故障不對其產(chǎn)生任何影響。,事務的特征,2020/9/12,2事務的狀態(tài),一般將事務的執(zhí)行狀態(tài)分為5種 活動狀態(tài)：事務的初始狀態(tài)，事務執(zhí)行時

34、處于這個狀態(tài)。 部分提交狀態(tài)：當操作序列的最后一條語句自動執(zhí)行后，事務處于部分提交狀態(tài)。這時，事務雖然已經(jīng)完全執(zhí)行，但由于實際輸出可能還駐留在內(nèi)存中，而在事務成功完成前仍有可能出現(xiàn)硬件故障，事務仍可能不得不中止。因此，事務處于部分提交狀態(tài)不表示事務成功執(zhí)行。 失敗狀態(tài)：由于硬件或邏輯等錯誤，使得事務不能繼續(xù)正常執(zhí)行，事務就進入了失敗狀態(tài)，處于失敗狀態(tài)的事務必須回滾（ROLLBACK）。這樣，事務就進入了中止狀態(tài)。 中止狀態(tài)：事務回滾并且數(shù)據(jù)庫恢復到事務開始執(zhí)行前的狀態(tài)。 提交狀態(tài)：當事務成功完成后，稱事務處于提交狀態(tài)（COMMIT）。,2020/9/12,3SQL中的事務定義,在SQL中定義事

35、務的語句有BEGIN TRANSACTION、COMMIT、ROLLBACK。事務以BEGIN TRANSACTION語句開始，以COMMIT（事務提交）或ROLLBACK（回滾）結束。提交即提交事務的所有操作，將事務中所有對數(shù)據(jù)庫的更新寫回到物理數(shù)據(jù)庫，事務正常結束。回滾表示在事務運行中發(fā)生了某種故障，事務不能繼續(xù)執(zhí)行，系統(tǒng)將事務中對數(shù)據(jù)庫已完成的所有操作（指更新操作）全部撤銷，回滾到事務開始時的狀態(tài)。,2020/9/12,下面是一個事務的例子，從帳號A轉(zhuǎn)移資金額R到帳號B： BEGIN TRANSACTION READ A AA-R IF A0/* A 款不足*/ THEN BEGIN D

36、ISPLAY “A款不足” ROLLBACK END ELSE /* 撥款 */ BEGIN BB+R DISPLAY “撥款完成” COMMIT END,3SQL中的事務定義(2),2020/9/12,這是對一個簡單事務的完整的描述。 該事務有兩個出口： 當A 帳號的款項不足時，事務以ROLLBACK（撤銷）命令結束，即撤銷該事務的影響； 另一個出口是以COMMIT（提交）命令結束，完成從帳號A到帳號B的撥款。 在COMMIT之前，即在數(shù)據(jù)庫修改過程中，數(shù)據(jù)可能是不一致的，事務本身也可能被撤銷。 只有在COMMIT之后，事務對數(shù)據(jù)庫所產(chǎn)生的變化才對其他事務開放，這就可以避免其他事務訪問不一致

37、或不存在的數(shù)據(jù)。,3SQL中的事務定義(3),2020/9/12,4事務的調(diào)度的一般概念,（1）調(diào)度（schedule） （2）串行調(diào)度（serial schedule） （3）并行調(diào)度（concurrent schedule） 交叉并發(fā)方式（interleaved concurrency），指在單處理機系統(tǒng)中，多個并行事務的操作輪流交叉運行，從而減少處理機的空閑時間，提高系統(tǒng)的效率。 多處理機系統(tǒng)中，每個處理機可以運行一個事務，多個處理機可以同時運行多個事務，實現(xiàn)多個事務真正的并行運行。這是最理想的并發(fā)方式，但對于硬件環(huán)境要全較高。,2020/9/12,例1并發(fā)取款操作。假設存款余額R=10

38、00元，甲事務T1取走存款100元，乙事務T2取走存款200元，如果正常操作，即甲事務T1執(zhí)行完畢再執(zhí)行乙事務T2，存款余額更新后應該是700元。但是如果按照如下順序操作，則會有不同的結果： 甲事務T1讀取存款余額R =1000元； 乙事務T2讀取存款余額R =1000元； 甲事務T1取走存款100元，修改存款余額R =R 100=900，把R =900寫回到數(shù)據(jù)庫； 乙事務T2取走存款200元，修改存款余額R =R 200=800，把R =800寫回到數(shù)據(jù)庫。,5并發(fā)所引起的問題,2020/9/12,結果兩個事務共取走存款300元，而數(shù)據(jù)庫中的存款卻只少了200元。 得到這種錯誤的結果是由甲

39、乙兩個事務并發(fā)操作引起的，數(shù)據(jù)庫的并發(fā)操作導致的數(shù)據(jù)庫不一致性主要有以下三種： （1）丟失更新（Lost Update） 當兩個事務T1和T2讀入同一數(shù)據(jù)做修改，并發(fā)執(zhí)行時， T2把T1或T1把T2的修改結果覆蓋掉，,5并發(fā)所引起的問題(2),2020/9/12,造成了數(shù)據(jù)的丟失更新問題，導致數(shù)據(jù)的不一致。 仍以例中的操作為例進行分析。 在表4.1中，數(shù)據(jù)庫中R的初值是1000，事務T1包含三個操作：讀入R初值（FIND R）；計算（R=R-100）；更新R（UPDATE R）。 事務T2也包含三個操作：FIND R；計算（R=R-200）；UPDATE R。 如果事務T1和T2順序執(zhí)行，則更

40、新后，R的值是700。但如果T1和T2按照表4.1所示的并發(fā)執(zhí)行，R的值是800，得到錯誤的結果，原因在于在t7時刻丟失了T1對數(shù)據(jù)庫的更新操作。 因此，這個并發(fā)操作不正確。,（1）丟失更新,2020/9/12,表4.1 丟失更新問題,（1）丟失更新(2),2020/9/12,事務T1更新了數(shù)據(jù)R，事務T2讀取了更新后的數(shù)據(jù)R，事務T1由于某種原因被撤消，修改無效，數(shù)據(jù)R恢復原值。事務T2得到的數(shù)據(jù)與數(shù)據(jù)庫的內(nèi)容不一致，這種情況稱為“污讀”。 在表4.2中，事務T1把R的值改為900，但此時尚未做COMMIT操作，事務T2將修改過的值900讀出來，之后事務T1執(zhí)行ROLLBACK操作，R的值恢

41、復為1000，而事務T2將仍在使用已被撤消了的R值900。 原因在于在t4時刻事務T2讀取了T1未提交的更新操作結果，這種值是不穩(wěn)定的，在事務T1結束前隨時可能執(zhí)行ROLLBACK操作。 對于這些未提交的隨后又被撤消的更新數(shù)據(jù)稱為“臟數(shù)據(jù)”。比如，這里事務T2在t2時刻讀取的就是“臟數(shù)據(jù)”。,（2）臟讀（Dirty Read）,2020/9/12,（2）臟讀（Dirty Read）(2),2020/9/12,事務T1讀取了數(shù)據(jù)R，事務T2讀取并更新了數(shù)據(jù)R，當事務T1再讀取數(shù)據(jù)R以進行核對時，得到的兩次讀取值不一致，這種情況稱為“不可重讀”。 在表4.3中，在t0時刻事務T1讀取R的值為100

42、0，但事務T2在t4時刻將R的值更新為為800。所以T1所使用的值已經(jīng)與開始讀取的值不一致。,表4.3 不可重讀問題,（3）不可重讀（Unrepeatable Read）,2020/9/12,1調(diào)度策略對事務并發(fā)操作的影響 如果有兩個事務T1、T2分別對數(shù)據(jù)X，Y進行賦值操作，由于事務的不同調(diào)度，引起了不同的結果，如圖所示。已知X，Y的初值均為0。,6.4.2 并發(fā)操作的調(diào)度,2020/9/12,2將所有事務串行起來的調(diào)度策略一定是正確的調(diào)度策略,定義4.1 多個事務的并發(fā)執(zhí)行是正確的，當且僅當其結果與按某一次序串行地執(zhí)行它們時的結果相同，我們稱這種調(diào)度策略為可串行化（Serializable

43、）的調(diào)度。 可串行性（Serializability）是并發(fā)事務正確性的準則。按這個準則規(guī)定，一個給定的并發(fā)調(diào)度，當且僅當它是可串行化的，才認為是正確調(diào)度。 為了保證并發(fā)操作的正確性，DBMS的并發(fā)控制機制必須提供一定的手段來保證調(diào)度是可串行化的。目前DBMS普遍采用封鎖方法實現(xiàn)并發(fā)操作調(diào)度的可串行性，從而保證調(diào)度的正確性。,2020/9/12,1封鎖及鎖的類型 所謂封鎖就是當一個事務在對某個數(shù)據(jù)對象（可以是數(shù)據(jù)項、記錄、數(shù)據(jù)集、以至整個數(shù)據(jù)庫）進行操作之前，必須獲得相應的鎖，以保證數(shù)據(jù)操作的正確性和一致性。 封鎖的3個環(huán)節(jié)：申請加鎖，獲得鎖，釋放鎖。 基本的封鎖類型有2種：排它鎖（Exclu

44、sive Locks，也稱X鎖）和共享鎖（Share Locks，也稱S鎖）。,6.4.3 封鎖,2020/9/12,排它鎖（Exclusive Lock） 排它鎖又稱寫鎖，簡稱為X鎖，其采用的原理是禁止并發(fā)操作。 當事務T對某個數(shù)據(jù)對象R實現(xiàn)X封鎖后，其他事務要等T解除X封鎖以后，才能對R進行封鎖。這就保證了其他事務在T釋放R上的鎖之前，不能再對R進行操作。 共享鎖（Share Lock） 共享鎖又稱讀鎖，,簡稱為S鎖，其采用的原理是允許其他用戶對同一數(shù)據(jù)對象進行查詢，但不能對該數(shù)據(jù)對象進行修改。 當事務T對某個數(shù)據(jù)對象R實現(xiàn)S封鎖后，其他事務只能對R加S鎖，而不能加X鎖，直到T釋放R上的S

45、鎖。 這就保證了其他事務在T釋放R上的S鎖之前，只能讀取R，而不能再對R作任何修改。,基本的封鎖類型,2020/9/12,封鎖可以保證合理的進行并發(fā)控制，保證數(shù)據(jù)的一致性。 實際上，鎖是一個控制塊，其中包括被加鎖記錄的標識符及持有鎖的事務的標識符等。 在封鎖時，要考慮一定的封鎖規(guī)則，例如，何時開始封鎖、封鎖多長時間、何時釋放等,這些封鎖規(guī)則稱為封鎖協(xié)議。 對封鎖方式規(guī)定不同的規(guī)則，就形成了各種不同的封鎖協(xié)議。 封鎖協(xié)議在不同程序上對正確控制并發(fā)操作提供了一定的保證。 上面講述過的并發(fā)操作所帶來的丟失更新、污讀和不可重讀等到數(shù)據(jù)不一致性問題，可以通過三級封鎖協(xié)議在不同程度上給予解決，下面介紹三級

46、封鎖協(xié)議。,2 .鎖協(xié)議（Lock Protocol）,2020/9/12,一級封鎖協(xié)議的內(nèi)容是：事務T在修改數(shù)據(jù)對象之前必須對其加X鎖，直到事務結束。 具體地說，就是任何企圖更新記錄R的事務必須先執(zhí)行“XLOCK R”操作，以獲得對該記錄進行尋址的能力并對它取得X封鎖。 如果未獲準“X 封鎖”，那么這個事務進入等待狀態(tài)，一直到獲準“X封鎖”，該事務才繼續(xù)做下去。 該事務規(guī)定事務在更新記錄R時必須獲得排它性封鎖，使得兩個同時要求更新R的并行事務之一必須在一個事務更新操作執(zhí)行完成之后才能獲得X封鎖，這樣就避免了兩個事務讀到同一個R值而先后更新時所發(fā)生的丟失更新問題。,一級封鎖協(xié)議,2020/9/

47、12,利用一級封鎖協(xié)議可以解決表4.5中的數(shù)據(jù)丟失更新問題，如表4.4所示。 事務T1先對R進行X封鎖（XLOCK），事務T2執(zhí)行“XLOCK R”操作，未獲準“X封鎖”，則進入等待狀態(tài)，直到事務T1更新R值以后，解除X封鎖操作（UNLOCK X）。 此后事務T2再執(zhí)行“XLOCK R”操作，獲準“X封鎖”，并對R值進行更新（此時R已是事務T1更新過的值，R=900）。 這樣就能得出正確的結果。,一級封鎖協(xié)議(2),2020/9/12,一級封鎖協(xié)議(3),一級封鎖協(xié)議只有當修改數(shù)據(jù)時才進行加鎖，如果只是讀取數(shù)據(jù)并不加鎖，所以它不能防止“臟讀”和“重讀”數(shù)據(jù)。,2020/9/12,二級封鎖協(xié)議的

48、內(nèi)容是：在一級封鎖協(xié)議的基礎上，另外加上事務T在讀取數(shù)據(jù)R之前必須先對其加S鎖，讀完后釋放S鎖。 所以二級封鎖協(xié)議不但可以解決更新時所發(fā)生的數(shù)據(jù)丟失問題，還可以進一步防止“臟讀”。 利用二級封鎖協(xié)議可以解決表4.2中的數(shù)據(jù)“臟讀”問題，如表4.5所示。 事務T1先對R進行X封鎖（XLOCK），把R的值改為900，但尚未提交。這時事務T2請求對數(shù)據(jù)R加S鎖，因為T1已對R加了X鎖，T2只能等待，直到事務T1釋放X鎖。,二級封鎖協(xié)議,2020/9/12,之后事務T1因某種原因撤銷，數(shù)據(jù)R恢復原值1000，并釋放R上的X鎖。事務T2可對數(shù)據(jù)R加S鎖，讀取R=1000，得到了正確的結果，從而避免了事務

49、T2讀取“臟數(shù)據(jù)”。,二級封鎖協(xié)議(2),2020/9/12,二級封鎖協(xié)議在讀取數(shù)據(jù)之后，立即釋放S鎖，所以它仍然不能防止“重讀”數(shù)據(jù)。 三級封鎖協(xié)議的內(nèi)容是：在一級封鎖協(xié)議的基礎上，另外加上事務T在讀取數(shù)據(jù)R之前必須先對其加S鎖，讀完后并不釋放S鎖，而直到事務T結束才釋放。 所以三級封鎖協(xié)議除了可以防止更新丟失問題和“污讀”數(shù)據(jù)外，還可進一步防止不可重讀數(shù)據(jù)，徹底解決了并發(fā)操作所帶來的三個不一致性問題。 利用三級封鎖協(xié)議可以解決表4.3中的不可重讀問題，如表4.6所示。, 三級封鎖協(xié)議,2020/9/12,在表4.6中，事務T1讀取R的值之前先對其加S鎖，這樣其他事務只能對R加S鎖，而不能加

50、X鎖，即其他事務只能讀取R，而不能對R進行修改。 所以當事務T2在t3時刻申請對R加X鎖時被拒絕，使其無法執(zhí)行修改操作，只能等待事務T1釋放R上的S鎖，這時事務T1再讀取數(shù)據(jù)R進行核對時，得到的值仍是1000，與開始所讀取的數(shù)據(jù)是一致的，即可重讀。 在事務T1釋放S鎖后，事務T2可以對R加X鎖，進行更新操作，這樣便保證了數(shù)據(jù)的一致性。, 三級封鎖協(xié)議(2),2020/9/12, 三級封鎖協(xié)議,2020/9/12,3兩段鎖協(xié)議,兩段鎖協(xié)議是保證調(diào)度可串行性的協(xié)議，該協(xié)議要求所有事務必須分兩個階段對數(shù)據(jù)項加鎖和解鎖。 擴展階段：在對任何數(shù)據(jù)進行讀、寫操作之前，首先要申請并獲得對該數(shù)據(jù)的封鎖。 收縮

51、階段：在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。,2020/9/12,封鎖粒度指封鎖的單位。 根據(jù)對數(shù)據(jù)的不同處理，封鎖的對象可以是這樣一些邏輯單元：字段、記錄、表、數(shù)據(jù)庫等。 封鎖粒度與系統(tǒng)的并發(fā)度和并發(fā)控制的開銷密切相關。 封鎖粒度越小，系統(tǒng)中能夠被封鎖的對象就越多，并發(fā)度越高，但封鎖機構復雜，系統(tǒng)開銷也就越大。相反，封鎖粒度越大，系統(tǒng)中能夠被封鎖的對象就越少，并發(fā)度越小，封鎖機構簡單，相應系統(tǒng)開銷也就越小。 因此，在實際應用中，選擇封鎖粒度時應同時考慮封鎖機構和并發(fā)度兩個因素，對系統(tǒng)開銷與并發(fā)度進行權衡，以求得最優(yōu)的效果。 由于同時封鎖一個記錄的概率很小，一般數(shù)據(jù)庫系統(tǒng)都在記錄

52、級上進行封鎖，以獲得更高的并發(fā)度。,4.封鎖的粒度（Lock Granularity）,2020/9/12,封鎖技術可有效解決并行操作的一致性問題，但也可產(chǎn)生新的問題，即活鎖和死鎖問題。 1活鎖（Livelock） 當某個事務請求對某一數(shù)據(jù)的排它性封鎖時，由于其他事務對該數(shù)據(jù)的操作而使這個事務處于永久等待狀態(tài)，這種狀態(tài)稱為活鎖。 例如，事務T1在對數(shù)據(jù)R封鎖后，事務T2又請求封鎖R，于是T2等待。T3也請求封鎖R。當T1釋放了R上的封鎖后首先批準了T3的請求，T2繼續(xù)等待。然后又有又T4請求封鎖R，T3釋放了R上的封鎖后又批準了T4的請求T2可能永遠處于等待狀態(tài)，從而發(fā)生了活鎖。如表4.7所示

53、。,6.4.4 死鎖和活鎖,2020/9/12,6.4.4 死鎖和活鎖(2),2020/9/12,避免活鎖的簡單方法是采用先來先服務的策略，按照請求封鎖的次序?qū)κ聞张抨?，一旦記錄上的鎖釋放，就使申請隊列中的第一個事務獲得鎖。 有關活鎖的問題我們不再詳細討論，因為死鎖的問題較為常見，這里主要討論有關死鎖的問題。 2死鎖（Deadlock） 在同時處于等待狀態(tài)的兩個或多個事務中，其中的每一個在它能夠進行之前，都等待著某個數(shù)據(jù)、而這個數(shù)據(jù)已被它們中的某個事務所封鎖，這種狀態(tài)稱為死鎖。 例如，事務T1在對數(shù)據(jù)R1封鎖后，又要求對數(shù)據(jù)R2封鎖，而事務T2已獲得對數(shù)據(jù)R2的封鎖，又要求對數(shù)據(jù)R1封鎖，這樣

54、兩個事務由于都不能得到封鎖而處于等待狀態(tài)，發(fā)生了死鎖。如表4.8所示。,4.3.4 死鎖和活鎖(3),2020/9/12,表4.8 死鎖,4.3.4 死鎖和活鎖(4),2020/9/12,死鎖一旦發(fā)生，系統(tǒng)效率將會大大下降，因而要盡量避免死鎖的發(fā)生。 在操作系統(tǒng)的多道程序運行中，由于多個進程的并行執(zhí)行需要分別占用不同資源時，也會發(fā)生死鎖。 要想預防死鎖的產(chǎn)生，就得破壞形成死鎖的條件。 同操作系統(tǒng)預防死鎖的方法類似，在數(shù)據(jù)庫環(huán)境下，常用的方法有以下兩種： （1）一次封鎖法 一次加鎖法是每個事物必須將所有要使用的數(shù)據(jù)對象全部依次加鎖，并要求加鎖成功，只要一個加鎖不成功，表示本次加鎖失敗，則應該立即釋放所有已加鎖成功的數(shù)據(jù)對象，然后重新開始從頭加鎖。 一次加鎖法的程序框圖如下圖。,3死鎖的預防,2020/9/12,(1)一次封鎖法,2020/9/12,如表4.8發(fā)生死鎖的例子，可以通過一次加鎖法加以預防。 事務T1啟動后，立即對數(shù)據(jù)R1和R2依次加鎖，加鎖成功后，執(zhí)行T1，而事務T2等待。 直到T1執(zhí)行完后釋放R1和R2上的鎖，T2繼續(xù)執(zhí)行。這樣就不會發(fā)生死鎖。 一次加鎖法雖然可以有效地預防死鎖的