資料庫實現 系統故障對策

2021-10-05 14:28:49 字數 3682 閱讀 4823

1 概述

1.1 資料庫是如何訪問資料的?

資料庫系統常駐於非易失性儲存器(主要是磁碟),在任何時間都只有部分內容在主存中。資料庫分成稱為塊(block)的定長儲存單位。塊是磁碟資料傳送的單位,可能包含多個資料項。事務由磁碟向主存輸入資訊,然後再將資訊輸出回磁碟。輸入和輸出操作都以塊為單位。位於磁碟上的塊為物理塊,臨時位於主存中的塊稱為緩衝塊。記憶體中用於臨時存放塊的區域叫做磁碟緩衝區。

下面這張圖描述了事務運算元據時的大致過程:

input(a):當事務t要讀a,而a的塊不在緩衝區中,則需要緩衝管理器執行input命令。將包含資料庫元素a的磁碟塊拷貝到主存緩衝區。

read(a,t):將資料庫元素a的值拷貝到事務t的位址空間中的區域性變數t。

write(a,t):將區域性變數t的值拷貝到主存緩衝區中的資料庫元素a中。(如果資料庫元素a的磁碟塊不在主存緩衝區,也要先執行input)

output(a):將包含a的緩衝區中的塊拷貝回磁碟。

如果資料庫系統在write(b)完成後和output(b)完成之前(寫到了緩衝區而未寫到磁碟)發生故障,事務已經提交的修改就會丟失。實際上,更大概率的事件是在事務提交之前就遇到了系統故障,而此時事務的部分更新已經寫回磁碟,部分更新沒有完成,破壞了磁碟資料的一致性。

因此,需要設計一些機制來保證資料據系統即使發生崩潰,事務的原子性也能得到保證,從而保證資料的一致性。

2 故障恢復的基礎

在系統重啟後,想要做一些恢復動作來保持原子性,就必須在修改資料庫之前,先寫入一些資訊來記錄後面的修改,這種工作也叫作預埋。使用最為廣泛的記錄資料庫修改的結構就是日誌,日誌是日誌記錄的序列,它記錄資料庫中的所有更新活動。

恢復的原理十分簡單,可以用乙個詞來概括:冗餘。

建立用於資料的最常用的技術是:資料轉儲和登記日誌檔案。

下圖給出了恢復管理器。當發生崩潰時,恢復管理器就被啟用。它檢查日誌並在必要時利用日誌恢復資料。

2.1 日誌記錄

每次事務執行寫操作時,必須在資料庫修改前建立該次寫操作的日誌記錄並把它加到日誌中,而日誌必須存放在穩定儲存器中。這裡需要注意的是,資料據系統所在的磁碟屬於非易失性儲存,也容易發生各種物理故障,比如磁頭和扇區損壞。而日誌所在的儲存需要更高的穩定性,穩定儲存器中的資訊永遠不會丟失(接近100%可靠),一般就是採用raid技術來盡可能保證磁碟單點故障不會損壞到資料。

日誌記錄的結構:

它記錄了某個事務在某個資料項上的修改,並儲存了修改前的舊值。事務t對資料元素x進行了修改,修改前的值為v。

日誌中還包括一些事務狀態的記錄:

事務開始

事務提交 ,這是事務的最後乙個日誌記錄,當這條記錄輸出到穩定性儲存後,就可以說這個事務提交了,這時所有更早的日誌記錄都已經輸出到穩定性儲存中,即使發生崩潰,事務所做的更新也可以重做(redo)。如果系統發生在輸出到穩定性儲存之前,事務ti將會回滾(undo)。

事務中止

需要強調的是,日誌記錄輸出到穩定儲存器也是非同步的,和資料更新一樣仍然會先寫入系統緩衝塊,再在合適的時候寫入到穩定儲存器。

2.2 事務的redo和undo

恢復管理器的第乙個任務就是將事務劃分為已提交事務和未提交事務。(這一點在undo的恢復中深有體會,從後往前掃瞄,找出兩類事務,已提交的不用考慮,未提交的執行undo操作)發生系統崩潰後,系統查詢日誌以確定為保證原子性需要對哪些事務進行重做(redo),對哪些事務進行撤銷(undo)。

(1)undo將事務更新過的所有資料項的值都恢復成舊值。

規則:先寫好日誌記錄(v是舊值),才可執行資料元素的output(),最後執行

只要見不到提交或者終止,就將操作撤銷,即將undo日誌內的東西恢復(t事務對資料庫元素a進行操作,操作前值為v)對於事物的undo操作完成後,它寫乙個日誌記錄,表示撤銷完成了。

檢查點checkpoint

如果每次系統崩潰後的恢復工作都需要掃瞄整個日誌來完成,會導致:

1.搜尋過程太耗時。

2.對於大部分事務,已經完成緩衝塊到磁碟塊的輸出操作,不存在破壞原子性的問題,對它們重做會使恢復過程加長。

實際上,需要重做或者撤銷的事務,只是那些在系統崩潰時正處於活躍狀態的事務(包括未提交的和正在回滾的事務)。因此引入checkpoint來改善恢復效率,降低恢復的開銷。

檢查點分類:①靜止檢查點 ②非靜止檢查點

①靜止檢查點的執行過程:

1.資料庫停止接收新的事務。

2.等到當前活躍的事務提交或者中止,並且在日誌中寫入了commit或者abort記錄。

3.將日誌重新整理到磁碟。

4.寫入日誌記錄,並再次重新整理日誌。*此時檢查點已經設定成功*

5.重新開始接收事務。

然而,靜止檢查點存在乙個問題:新增檢查點的時候我們必須關閉系統,正活躍的事務可能需要很長時間來提交或者中止,此時使用者看來系統似乎停止了,所以我們引入非靜止檢查點。

②非靜止檢查點的執行過程:

1.寫入日誌記錄並重新整理日誌,t1,……是所有正在活躍的事務。

2.等待t1……中的事務提交或者中止,但是在這個過程中,允許其他事務開始。

3.當t1,……都完成時,寫入並重新整理日誌。

(2)redo將事務更新過的所有資料項的值都設定成新值。

規則:先寫好日誌記錄(v是新值),日誌執行完以後,才可以執行資料元素的output()

日誌中沒見到,則資料庫所做的更新就一定還沒有寫到磁碟上。

redo日誌恢復步驟:

1.確定已經提交的事務。(事務的資料結構,status:進行,提交)

2.從首部開始掃瞄日誌。對每一條遇到的記錄:

(a)如果t是未提交的事務,則什麼也不做。

(b)如果t是已經提交的事務,則為資料庫元素x寫入v

3.對每個未完成的事務t,在日誌中寫入乙個記錄並重新整理日誌。

對於恢復演算法,一般都是對日誌進行掃瞄,在掃瞄過程中每遇到乙個redo日誌就執行redo動作,而不是針對每個事務單獨做redo,這樣可以提高恢復的效率。

如果日誌包括,以及或者,執行redo。如果有,說明事務中止完成,為什麼還要執行redo?日誌記錄是事務回滾時寫入的,日誌中一定也包含了回滾時寫入的唯讀日誌記錄,所以發現時重做是對事務ti的修改做了撤銷,這裡確實是冗餘操作,但是簡化了恢復演算法。

檢查點checkpoint

檢查點執行過程:

(a)寫入日誌記錄,其中t1,……是所有活躍的事務,並重新整理日誌。

(b)將start ckpt記錄寫入日誌時已提交事務已經寫到緩衝區,但是還沒有寫到磁碟的資料庫元素寫到磁碟。(控制檢查點開始的時候只有活躍元素,其他都已完成。所以恢復時,前邊的內容一定沒問題,不需要看)

(c)寫入日誌記錄並重新整理日誌。

Sybase資料庫死鎖對策

sybase資料庫在unix windows上的實施和管理 討論49 sybase資料庫死鎖對策 死鎖的發生對系統的效能和吞吐量都有重要影響,經檢測發現,管理資訊系統的死鎖主要是因為兩個或多個執行緒 登入 搶占同一表資料資源。引起長時間搶占同一資源不是因為我們需要處理的事務太複雜,時間太長,而往往是...

Sybase資料庫死鎖及對策

死鎖的發生對系統的效能和吞吐量都有重要影響,經檢測發現,管理資訊系統的死鎖主要是因為兩個或多個執行緒 登入 搶占同一表資料資源。引起長時間搶占同一資源不是因為我們需要處理的事務太複雜,時間太長,而往往是因為我們在前端應用程式對資料庫作操作時忘了提交。本文介紹一種處理解決這種死鎖的方法。sybase封...

資料庫故障處理

解決方法 分離出還原失敗的資料庫geb 先建立乙個同樣的資料庫geb 停掉server服務,用舊的資料檔案覆蓋新建立的檔案 只要mdf就可以 啟動server服務 執行以下命令 sp configure allow 1 goreconfigure with override goupdate sys...