---

前言

• 在前几期博客中，我们探讨了 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

非常感谢您的阅读，喜欢的话记得三连哦