saas建站平台源码,做平台的网站有哪些,广州做餐饮的招聘网站,有了网站 域名然后么做1. 数据故障恢复的宏观思路 我们知道DBMS是利用内存#xff08;主存#xff09;和外存#xff08;辅存#xff09;这样的存储体系进行数据库的管理#xff0c;其中内存也就是我们常说的缓存是易失的。而事务时DBMS对数据库进行控制的基本单元#xff0c;宏观上是由程序设…1. 数据故障恢复的宏观思路 我们知道DBMS是利用内存主存和外存辅存这样的存储体系进行数据库的管理其中内存也就是我们常说的缓存是易失的。而事务时DBMS对数据库进行控制的基本单元宏观上是由程序设置的一条或者多条SQL语句的一次执行微观上是对数据元素的一系列基本操作如读写等需要提交commit和撤销abort。事务满足ACID特性而故障恢复设计的是如何保证原子性和持久性即故障恢复需要把DB由当前的不正确状态恢复到已知为正确的某一状态要保证已经commit的事务要保持持久性确保其保存到我们的外存永久存储介质上未完成的事务为了保持一致性恢复其至未事务开始前的状态。 原子性事务的所有操作要么全都执行要么全都不执行。持久性提交的事务对数据库产生的影响是持久的未提交的事务对数据库不应有影响。 注DBMS中故障恢复程序约占10%。 实际遇到的故障类型及影响如下表所示。 故障类型故障原因影响范围事务故障 某一个程序事务自身运行错误所引起的故障 影响该程序事务本身系统故障掉电、非正常关机等所引起的故障影响正在运行的事务以及数据库缓冲区数据库缓冲区将涉及正在运行和已经运行的事务介质故障由于介质损害等所引起的故障影响是全面的既影响内存中的数据又影响介质中的存储数据
1.1 事务故障恢复思路
事务故障可通过重做事务Redo和撤销事务Undo来恢复。重做事务可保证提交事务的持久性而撤销事务则消除未提交事务的影响
1.2 系统故障恢复思路 系统故障可通过运行日志System Log进行恢复。 运行日志是DBMS维护的一个文件该文件以流水方式速度很快记录了每一个事务对数据库的每一次操作及顺序。当事务对数据库进行操作时先写运行日志写成功后再将缓冲区信息刷到外存即磁盘上。当发生系统故障时我们可以根据运行日志记录的事务操作顺序重做事务当事务在发生故障时已经正确结束或撤销事务当事务在发生故障时未结束但是这样我们遇到了一个问题运行日志可能保留了很久的记录我们应道从哪一个点开始恢复呢为了解决该问题提出了检查点checkpoint机制检查点是这样的时刻在该时刻DBMS强制使内存DB Buffer中的内容与介质DB的内容保持一致。 进行系统故障恢复时 检查点之前结束的事务不需要处理已经写回DB介质 检查点之后结束或发生的事务需要依据运行日志进行恢复不能确定是否写回DB故障点前结束的重做故障点时刻未结束的撤销。 1.3 介质故障恢复思路 由于介质故障影响是全面的发生该故障时首先需要用转储点的副本替换破坏的数据库然后再根据运行日志进行恢复。
1.4 小结 2. 什么是日志
2.1 日志 日志是一个包含日志记录的只能追加的顺序文件夹不同事务的日志交错存储按发生时间存储。 发生系统故障时使用日志进行恢复 故障时已提交的事务重做Redo故障时未提交的事务撤销Undo 日志涉及到设计元素和事务。 2.2 缓冲区策略 日志类型和缓冲区的策略相关为了确定应何时将内存中的更改刷宝到磁盘上数据库定义了steal/no-steal和force/no-force缓冲区策略。 缓冲区的处理策略主要有如下几种根据是否允许在commit之前把内存中的数据写入磁盘中分为 Steal / No steal策略根据是否要求在commit点及之前将数据写入磁盘中分为Force / No force 处理策略。
Force内存中的数据最晚在commit的时候写入磁盘No force内存中的数据可以一直保留在commit之后过一段时间再写入磁盘。此时在系统崩溃的时候可能还没写入到磁盘需要Redo--灵活Steal允许在事务commit之前把内存中的数据写入磁盘。此时若系统在commit之前崩溃时已经有数据写入到磁盘了要恢复到崩溃前的状态需要Undo--灵活No steal不允许在事务commit之前把内存中的数据写入磁盘。
2.3 缓冲区处理策略与日志/恢复策略的关系 3. 三种类型的运行日志
日志分三种类型Undo型日志、Redo型日志、Undo/Redo型日志。 4. 小结
