---

前言

• 在前幾期博客中，我們探討了 SQL 查詢，數據插入，修改與刪除，視圖，數據庫安全性，數據庫規范化與五大范式，數據庫設計的概念，關系查詢處理與查詢優化技術等知識點。
• 從本節開始，我們將深入講解數據庫恢復技術。

我的個人主頁，歡迎來閱讀我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的數據庫系統概論專欄
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

---

一、事務的基本概念

1. 什么是事務？

想象你去自動售貨機買飲料：

1. 你投了10元錢（相當于數據庫操作1）
2. 售貨機彈出一瓶可樂（相當于數據庫操作2）

這兩個動作必須"捆綁"在一起：如果錢扣了但可樂沒出來，你肯定不樂意；如果可樂出來了但錢沒扣，售貨機老板要虧本。這種"要么都成功，要么都失敗"的一組操作，在數據庫里就叫事務。

通俗定義：事務是一組操作的"包裹"，里面的操作要么全部完成，要么全部取消，就像用一個塑料袋把多個物品裝在一起，要拿就全拿走，不拿就全留下。

2. 事務的兩種"打開方式"

2.1 隱式事務

• 默認模式：數據庫自己決定什么時候把操作打包成事務，比如每條SQL語句自動成為一個事務。
• 例子：

  -- 向成績表SC插入數據（每條INSERT都是一個獨立事務）
  USE DBS
  GO
  DELETE SC  -- 刪除表中所有數據（這是一個事務）
  INSERT SC VALUES('95001','1',92);  -- 這是第二個事務
  INSERT SC VALUES('95001','2',85);  -- 第三個事務
  

• 關鍵特點：如果某條SQL出錯（比如第三條插入寫錯了），只有這條會失敗，前面的操作可能已生效。

2.2 顯式事務：自己動手打包操作

• 手動控制：用代碼明確告訴數據庫"開始打包"和"結束打包"。
• 三個關鍵命令：
  • BEGIN TRANSACTION：開始打包操作
  • COMMIT：確認打包完成，所有操作永久生效（類似結賬）
  • ROLLBACK：取消打包，所有操作全部回退（類似取消訂單）
• 例子：回滾事務（取消操作）

  USE DBS
  GO
  BEGIN TRANSACTION  -- 開始打包
  SELECT * FROM SC  -- 查看刪除前的數據
  DELETE SC  -- 刪除所有數據
  SELECT * FROM SC  -- 查看刪除后的數據
  ROLLBACK  -- 取消打包，剛才的刪除被撤銷
  SELECT * FROM SC  -- 數據恢復到刪除前
  

• 例子：提交事務（確認操作）

  USE DBS
  GO
  BEGIN TRANSACTION
  DELETE SC  -- 刪除數據
  COMMIT  -- 確認刪除，操作永久生效
  

3. 事務的四大"鐵律

3.1 原子性

• 類比：像吃包子，要么一口吞下去（全做），要么一口都不吃（全不做），不能吃一半吐出來（部分做）。
• 例子：銀行轉賬

  -- 從賬戶1212轉1000元到3434
  Update savingCard set balance=balance-1000 where account=1212;
  Update savingCard set balance=balance+1000 where account=3434;
  

  • 如果只完成第一個操作（扣錢），第二個沒完成（沒加錢），就會導致用戶少了1000元，這就是原子性失敗。

3.2 一致性

• 類比：你錢包里有100元，花了50元買東西，錢包里必須剩下50元，不能變成150元或-50元。
• 核心：事務執行前數據庫是正確的，執行后也必須正確，中間狀態可能暫時錯誤，但最終要回歸正確。
• 例子：轉賬前后，兩個賬戶的總金額必須一致：
  • 轉賬前：1212賬戶有5000元，3434賬戶有3000元，總和8000元
  • 轉賬后：1212賬戶4000元，3434賬戶4000元，總和還是8000元

3.3 隔離性

• 類比：就像在公共廁所里，你在隔間里做的事（比如洗手），外面的人看不到，也不會影響你。
• 例子：兩個事務同時操作同一個數據A：

  事務T1	事務T2
  ① 讀取A=16
  	② 讀取A=16
  ③ A=A-1，寫回A=15
  	④ A=A-3，寫回A=13

  • 如果沒有隔離性，T2可能讀到T1還沒完成的中間值（比如A=15），導致最終結果出錯（正確結果應該是A=12）。
  • 隔離性確保每個事務都像"獨自使用數據庫"一樣，不受其他事務干擾。

3.4 持久性

• 類比：你在紙上寫了字，就算把筆扔掉，字也不會消失。
• 核心：當事務提交（COMMIT）后，所有操作會永久寫入數據庫，即使數據庫突然斷電、崩潰，重啟后數據也不會丟失。

4. 為什么需要事務？

• 場景1：轉賬時突然斷網——事務會回滾，避免錢扣了卻沒到賬。
• 場景2：多個用戶同時買同一件商品——隔離性確保不會超賣（比如只剩1件，不會賣給兩個人）。
• 場景3：程序出錯導致部分操作完成——原子性確保數據不會停留在中間錯誤狀態。

二、數據庫恢復概述

1. 為什么說數據庫故障“不可避免”？

其實就像我們用手機會遇到死機、電腦會中病毒一樣，數據庫運行中也會遇到各種“意外”。這些意外主要分兩類：

1.1 計算機系統自身的故障

• 硬件故障：比如硬盤突然損壞、服務器斷電。就像你寫作業時筆突然沒水了，之前寫的字可能就沒寫完。
• 軟件故障：數據庫程序出錯、系統崩潰。比如你用文檔編輯軟件時，軟件突然閃退，沒保存的內容可能就丟了。

1.2 人為導致的故障

• 操作失誤：比如管理員不小心執行了刪除整個數據表的命令（就像你刪文件時手滑點了“刪除所有”）。
• 惡意破壞：黑客攻擊、病毒篡改數據。比如你的手機被惡意軟件入侵，通訊錄被修改或刪除。

2. 故障會對數據庫造成什么影響？

想象一下你在銀行轉賬，剛從A賬戶扣了錢，還沒轉到B賬戶時系統突然崩潰了——這時候數據庫就可能出問題，主要有兩種情況：

2.1 數據庫處于“不一致狀態”

• 例子：轉賬事務只完成了一半（A賬戶扣了錢，但B賬戶沒收到），此時數據庫里的總金額對不上，這就是“數據不一致”。
• 本質：事務沒完整執行，導致數據邏輯矛盾，就像賬本上“支出1000元”但沒記“收入”，賬算不平。

2.2 數據丟失

• 例子：硬盤損壞導致存儲的用戶信息、交易記錄全部消失；或者被惡意刪除后沒備份。
• 影響：就像你手機里的聯系人列表突然全沒了，重要信息找不回來，數據庫也會失去部分或全部有用數據。

3. 什么是數據庫的“恢復”？

既然故障會讓數據庫“生病”，那“恢復”就是給數據庫“治病”的過程：

核心目標：
把數據庫從“錯誤狀態”（比如數據不一致、丟失）變回“正確狀態”（數據完整、邏輯正確）。

舉個生活中的例子理解：

• 錯誤狀態：你寫了一篇作文，中途電腦死機，沒保存的部分丟了，剩下的內容可能還缺胳膊少腿（類似數據不一致或丟失）。
• 恢復過程：如果之前有備份（比如自動保存的草稿），就用備份還原；如果記得中間寫了什么（類似數據庫的“日志”記錄），可以補全缺失的部分。最終讓作文回到“完整正確”的狀態。

數據庫恢復的關鍵點：

• 正確狀態：通常是指最近一次“正常狀態”（比如所有事務都完整提交的時刻）。
• 恢復手段：通過備份數據、事務日志（記錄每一步操作）等機制，把數據庫“回退”或“補全”到正確狀態。

4. 數據庫恢復的核心

介質故障

想象一下：你存著重要資料的U盤突然插電腦沒反應了，或者硬盤被摔了——這就是數據庫里的介質故障（硬故障）。具體包括：

• 硬盤物理損壞（磁盤磁道壞了）
• 磁頭碰撞（像CD光盤被刮花）
• 強磁場干擾（比如硬盤靠近磁鐵）
• 破壞數據的病毒（像專門撕毀賬本的小偷）

特點：直接破壞數據庫文件，就像U盤里的文件直接消失或損壞，而且正在讀寫這些數據的操作都會中斷。

5. 恢復的核心原理

如果你的U盤壞了，但你提前把資料復制到了云端——這就是"冗余"。數據庫恢復的核心就是：用額外存儲的數據副本，重建被破壞的數據。

• 冗余數據 = 數據庫的"備胎"，可以是完整備份或操作記錄（日志）。

6. 恢復的兩大"武器"

6.1 數據轉儲

1. 什么是數據轉儲？
就像給手機相冊定期備份到電腦：DBA把整個數據庫復制到硬盤、磁帶等介質上，生成一個"后備副本"。

• 作用：數據庫被破壞時，用這個副本還原數據。
• 缺點：副本只能還原到備份那一刻的狀態，之后的新數據需要額外處理。

2. 轉儲的兩種"拍照"方式：靜態VS動態

• 靜態轉儲：
  ? 條件：數據庫完全"靜止"，沒有任何事務在運行時備份。
  🌰 類比：你把手機關機后，再復制相冊（這時相冊不會變化）。
  ? 優點：備份出來的數據絕對完整一致（就像定格照片）。
  ? 缺點：必須等所有操作結束，期間數據庫不能用（手機關機時你也用不了）。

• 動態轉儲：
  ? 條件：邊用數據庫邊備份（事務和備份同時進行）。
  🌰 類比：你一邊拍照一邊往相冊里添加新照片，備份程序同時復制所有內容。
  ? 優點：不影響數據庫使用（手機邊用邊備份）。
  ? 缺點：需要搭配"日志文件"（后面會講），因為備份時數據可能正在被修改。

3. 全量備份VS增量備份：省時間還是省空間？

• 海量轉儲：每次都備份整個數據庫（像把整個相冊復制一遍）。
• 增量轉儲：只備份上次備份后變化的數據（像只復制新拍的照片）。
• 差異備份：基于上一次全量備份，只記之后所有變化（比如上周全量備份后，這周每天只記新照片和修改過的照片）。

6.2 日志文件

1. 日志文件是什么？
就像銀行的交易記錄：每一筆轉賬、存款都會被記在賬本上。日志文件記錄了所有事務對數據庫的修改操作，包括：

• 事務開始（BEGIN TRANSACTION）、提交（COMMIT）、回滾（ROLLBACK）
• 具體操作：比如"用戶A從賬戶轉1000元到用戶B"前后的數據變化

2. 日志文件的格式：兩種"記賬方式"

• 以記錄為單位：記清楚每筆操作的"前因后果"
  🌰 記錄樣例：
  T1 U AA 18 20 → 事務T1，修改了AA字段，從18改成20
  T1 I TU 1 → 事務T1，插入了一條ID為1的記錄
• 以數據塊為單位：記哪個數據塊被修改了（適合大規模批量操作）

3. 日志文件的關鍵作用：補全"備份照片"的缺口
假設上周日全量備份了數據庫，周一到周五又做了很多操作：

• 如果周五數據庫崩潰，只靠周日的備份，周一到周五的數據就沒了。
• 但如果有日志文件，就可以通過日志重演周一到周五的所有成功操作，把數據恢復到崩潰前的狀態。

6.3 為什么必須"先寫日志，后改數據庫"？

一個致命場景：轉賬時突然斷電
假設你給朋友轉1000元，操作流程如下：

1. 事務開始，記錄日志（記上"準備轉賬1000元"）
2. 系統先把日志寫到硬盤（就像先在賬本上記一筆）
3. 正要從你的賬戶扣錢時，突然停電了（數據庫還沒修改）

為什么這樣設計？

• 如果先改數據庫再寫日志：
  萬一改完數據庫后停電，日志沒記錄，系統不知道這筆轉賬是否完成，可能導致數據不一致（你的賬戶少了錢，但朋友沒收到）。
• 先寫日志再改數據庫：
  即使停電，日志已經記錄了"要轉賬"，重啟后可以通過日志知道這筆操作該完成（重做），或者該取消（撤銷）。

四、數據庫恢復策略

1. 事務故障恢復： undo 讓錯誤操作“撤回”

什么是事務故障？
比如你轉賬時，銀行卡扣了錢，但錢還沒轉到對方賬戶，這時事務中途失敗了（比如網絡斷了），數據庫就會處于“錢扣了但沒到賬”的不一致狀態。

怎么恢復？
系統會自動用日志文件“撤回”（undo）這個事務做的所有修改：

• 比如剛才的轉賬，系統發現事務沒完成，就會把扣掉的錢“退”回你的賬戶，就像什么都沒發生過。
• 這個過程不需要人工操作，系統自己通過日志記錄的“舊值”（轉賬前的余額）來撤銷錯誤操作。

2. 系統故障恢復： redo + undo

系統故障的影響有多復雜？
比如突然停電時，可能有兩種情況：

1. 某個事務沒完成，但它改的數據已經存進數據庫了（比如你寫了一半的文檔沒保存就關機了）；
2. 某個事務已經完成了，但數據還在緩存里沒來得及存進硬盤（比如你點了“保存”但電腦瞬間關機了）。

恢復方法：先撤回未完成的，再重做已完成的

• undo 未完成事務：把那些沒走完流程的操作撤回，避免殘留錯誤數據；
• redo 已完成事務：把那些已經提交但沒存進硬盤的操作“補做”一遍，確保數據真正保存。
  例子：停電前你提交了“刪除文件”的操作，但系統沒來得及刪硬盤數據，重啟后系統會執行 redo，把文件真正刪掉；而如果你正在刪除文件時停電了，系統會 undo，取消刪除操作。

3. 介質故障恢復

介質故障有多嚴重？
比如硬盤突然損壞，數據徹底丟失或損壞，這時候前面的小故障恢復方法都沒用了，必須“大動干戈”。

恢復步驟：

1. 重裝數據庫備份：用最近的后備副本（比如上周的全量備份）恢復數據庫，就像給電腦重裝系統；
2. 重做所有已完成的事務：因為備份之后到故障發生前的新數據（比如這一周新增的文件）都沒了，需要用日志文件把這些新操作重新執行一遍（redo）。
   例子：你的硬盤壞了，里面存了100張照片，上周備份過80張。恢復時先還原這80張，然后通過日志找到這一周新增的20張照片的上傳記錄，重新“上傳”一遍，讓數據庫回到故障前的狀態。

4. 檢查點技術

為什么需要檢查點？
如果每次恢復都要從最早的日志開始掃描，效率太低了。檢查點就像游戲里的“存檔點”，定期記錄數據庫狀態，讓恢復時不用從頭開始。

檢查點的作用：

• 定期把內存中已提交的數據刷到硬盤，并在日志里記錄一個“檢查點標記”；
• 恢復時，只需要從最近的檢查點之后的日志開始處理，之前的都默認已經完成了。
  例子：你寫作業時每30分鐘存一次檔（檢查點），如果中途停電，重啟后只需要從最后一次存檔后的內容開始補，不用重新寫前30分鐘的作業。

五、數據庫鏡像

什么是數據庫鏡像？
就像給數據庫找一個實時復制的“雙胞胎”，主數據庫每次修改，鏡像數據庫都會同步更新。

鏡像如何用于恢復？

• 當主數據庫因介質故障損壞時，直接切換到鏡像數據庫，就像你用備用鑰匙開門，不用等修鎖；
• 鏡像還能用于日常查詢，減輕主庫壓力（比如查歷史數據時用鏡像庫，主庫專注處理新業務）。
  例子：你手機相冊自動同步到云端，手機壞了（主庫故障），直接從云端（鏡像庫）恢復所有照片，不用依賴備份文件。

---

以上就是這篇博客的全部內容，下一篇我們將繼續探索更多精彩內容。

我的個人主頁，歡迎來閱讀我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的數據庫系統概論專欄
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

非常感謝您的閱讀，喜歡的話記得三連哦