数据库恢复技术 - 软考备战（三十四）

数据库系统六参考资料《数据库系统概论》| 第十章 数据库恢复技术 知识梳理-腾讯云开发者社区-腾讯云5.6 数据库恢复技术恢复技术的核心思想就四个字“冗余备份”。无论怎么恢复都必须依赖日志或转储的冗余数据。1. 故障类型事务内部故障事务执行到了一半因为自身逻辑错误如除数为0、死锁被选中回滚无法继续。特征仅影响该事务本身不影响整个数据库。不需要 DBMS 动用恢复子系统事务自身的回滚机制就能解决。系统故障软故障如突然断电、操作系统崩溃、DBMS 进程被杀。特征内存缓冲区数据全部丢失但磁盘上的数据库文件完好无损。这会导致两种情况有些事务没提交就崩了改了内存没写盘有些事务提交了但没来得及写盘就崩了。介质故障硬故障如硬盘损坏、强磁场干扰。特征磁盘上的物理数据库文件被破坏了数据真没了。这是最严重的故障必须结合“日志文件”“后备副本转储文件”才能恢复。2. 恢复策略的底层支撑日志文件日志先写原则在把修改后的数据块写到磁盘数据库之前必须先把描述这个修改的日志记录写到磁盘日志文件中。原因写日志是追加写速度极快写数据块是随机写速度慢。如果先写数据断电了日志里没记录恢复时就没有凭证了。日志记录的内容事务标识、操作类型、操作对象、修改前值旧值用于Undo、修改后值新值用于Redo。转储备份针对介质故障。DBA 定期把整个数据库拷贝下来。1静态转储转储期间不允许任何事务操作数据库只读数据一致性好但影响业务。2动态转储转储期间允许事务操作不阻塞业务但转储出来的副本可能不一致必须配合日志文件才能恢复到一致状态。3. 恢复机制Undo 与 Redo 的精准判定发生系统故障重启后DBMS 扫描日志会根据事务的最后状态采取不同动作Undo撤销触发条件扫描到某个事务没有 Commit 记录说明它崩在了执行中途。动作利用日志中的“修改前值旧值”反向操作把该事务已经做过的修改全部抹平。目的消除未提交事务对数据库的修改保证原子性。Redo重做触发条件扫描到某个事务有 Commit 记录说明它已经成功结束只是数据可能还停留在内存缓冲区没刷到磁盘。动作利用日志中的“修改后值新值”正向操作把该事务的修改重新执行一遍写到磁盘。目的把已提交但未落盘的数据挽救回来保证持久性。不管Ignore对于既没有Commit也没有任何操作记录的事务直接跳过。4. 检查点技术为什么需要系统故障恢复时如果不加优化DBMS 要从日志文件的第一条记录开始扫描判断每个事务是 Redo 还是 Undo。系统运行几年日志几百个G重启一次要几小时。检查点的工作原理DBMS 周期性地如每5分钟做以下动作暂停接受新事务。将当前内存中所有已提交事务的修改强制刷入磁盘数据库。在日志文件中写入一条“检查点记录”记录此刻活跃的事务列表。检查点就像游戏里的“自动存档点”只要过了存档点之前的事情就当它已经安全落盘了死了重开重启恢复只需要从最近的存档点往前回溯一点点就行了。基于检查点的恢复策略发生系统故障重启时恢复过程大幅缩短从后往前扫描日志找到最近一个检查点记录。建立两个队列1Redo 队列在检查点前已提交但可能没刷盘的事务2Undo 队列在检查点时还没提交的事务。从检查点时刻开始正向扫描日志抛弃检查点之前的日志不看1遇到 Commit 的加入 Redo 队列。2遇到没 Commit 的加入 Undo 队列。3先做 Undo把未提交的修改抹掉。4再做 Redo把已提交的修改重做一遍。