ACCESS断电数据库损坏

---

目录

• 一、数据库保护的必要性
• 二、事务

• 2.1 事务的基本概念
• 2.2 事务结束语句
• 2.3 事务的特征（ACID）
• 2.4 SQL事务处理模型

• 2.4.1 ISO事务处理模型
• 2.4.2 T-SQL事务处理模型

• 三、并发控制

• 3.1 并发控制概述

• 3.1.1 允许多个事务并发执行的优缺点
• 3.1.2 不同的多事务执行方式
• 3.1.3 事务并发执行带来的问题
• 3.1.4 并发操作带来的数据不一致性
• 3.1.5 并发控制机制的任务

• 3.2 并发控制措施

• 3.2.1 加锁
• 3.2.2 基本封锁类型

• 3.3 封锁协议

• 3.3.1 一级封锁协议
• 3.3.2 二级封锁协议
• 3.3.3 三级封锁协议

• 3.4 活锁和死锁

• 3.4.1 活锁和活锁的解决方法
• 3.4.2 死锁和死锁的解决方法

• 3.5 并发调度的可串行性
• 3.6 两段锁协议
• 3.7 封锁粒度

• 3.7.1 选择封锁粒度的原则
• 3.7.2 多粒度封锁协议

• 四、数据库备份与恢复

• 4.1 数据库故障的种类

• 4.1.1 事务的状态及其转换
• 4.1.2 事物内部的故障
• 4.1.3 系统故障
• 4.1.4 其他故障
• 4.1.5 故障的结果

• 4.2 数据库备份

• 4.2.1 备份内容
• 4.2.2 备份频率
• 4.2.3 备份数据（数据转储）

• 4.3 登记日志文件

• 4.3.1 日志文件的格式和内容
• 4.3.2 日志文件的作用
• 4.3.3 登记日志文件

• 4.4 数据库恢复

• 4.4.1 恢复策略
• 4.4.2 数据库恢复技术

• 小结

---

一、数据库保护的必要性

    以某个售票系统为例，假设有存在两个表，售票表Sale统计售票数，剩余表Remain统计剩余的票数。当卖出一张票时，需要同时更新Sale表和Remain表，Sale加1，Remain减1。但是一旦其中一个表的更新出现了故障，而另一个表的操作照常执行，就会发生Sale多卖出一张票，Remain没有减少剩余量，或者没有卖出票，Remain缺少了一张票的情况。
    出现故障后，系统重新提供服务时数据库状态与现实世界状态出现了不一致。
    为解决上述问题，数据库管理系统引入了事务的概念，它将这些有内在联系的操作当作一个逻辑单元看待，并采取相应策略保证一个逻辑单元内的操作要么都执行成功，要么都不执行。

二、事务

2.1 事务的基本概念

用户定义的数据操作系列，这些操作作为一个完整的工作单元，一个事务内的所有语句被作为一个整体，要么全部执行，要么全部不执行。
例：某转账活动。
A账户转给B账户n元，该活动包含两个动作，须形成事务：
动作一：A账户 - n
动作二：B账户 + n

2.2 事务结束语句

事务结束的两种类型：

• 事务提交(commit)：将成功完成事务的执行结果永久化，并释放事务占有的全部资源。
• 事务回滚(rollback)：中止当前事务，撤销其对数据库所做的更新，并释放事务占有的全部资源。

     如果事务非正常结束，会影响到数据库数据的正确性，因为事物具有一致性，事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

2.3 事务的特征（ACID）

• 原子性(Atomicity）：
  事务是数据库的逻辑工作单位，事务中的操作要么都做，要么都不做。
• 一致性(Consistency)：
  事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
• 隔离性(Isolation)：
  数据库中的一个事务的执行不能被其他事务干扰。
• 持久性(Durability)：
  事务一旦提交，对数据库数据的改变是永久的。

保证事务的ACID特性是事务处理的重要任务。
事务的ACID特性可能遭到破坏的因素有两种：

• 多个事务并行运行时，不同事务的操作有交叉情况。
• 事务在运行过程中被强迫停止。

2.4 SQL事务处理模型

• 隐式事务：
  每一条数据操作语句都自动成为一个事务。
• 显式事务：
  有显式的开始和结束标记的事务。
  ISO事务处理模型
  T-SQL事务处理模型

2.4.1 ISO事务处理模型

• 明尾暗头：事务的开头是隐含的，事务的结束有明确标记。
  A.事务结束符：
  COMMIT：事务成功结束符
  ROLLBACK：事务失败结束符
  B.事务提交方式：
  自动提交：每条SQL语句为一个事务。
  指定位置提交：在事务结束符或程序正常结束处提交。
  C.事务起始/终止位置：
  程序的首条SQL语句或事务结束符后的语句。
  在程序正常结束处或COMMIT语句处成功终止。
  在程序出错处或ROLLBACK处失败终止。
  一个ISO事务的实例：

2.4.2 T-SQL事务处理模型

• 每个事务都有显式的开始和结束标记。
• 事务的开始标记是：
  BEGIN TRANSACTION | TRAN
• 事务的结束标记为：
  COMMIT [TRANSACTION | TRAN]
  ROLLBACK [TRANSACTION | TRAN]
  一个T-SQL事务模型的实例：

三、并发控制

3.1 并发控制概述

    由于多用户数据库系统的存在，允许多个用户同时使用数据库系统（如：银行数据库系统、选课系统），特点是同一时刻并发运行的事务数可达数百个，但是有可能产生互相干扰的现象。

3.1.1 允许多个事务并发执行的优缺点

    数据库管理系统允许多个事务并发执行有优点，也有缺点。

• 优点：
  增加系统吞吐量(throughput)。吞吐量是指单位时间系统完成事务的数量，当一事务需等待磁盘I/O 时，CPU可去处理其它正在等待 CPU 的事务。这样，可减少CPU和磁盘空闲时间，增加给定时 和磁盘空闲时间，增加给定时间内完成事务的数量。
  减少平均响应时间(average response time)。事务响应时间是指事务从提交给系统到最后完成所需要的时间。缩短事物的等待时间。
• 缺点：
  若不对事务的并发执行加以控制，则可能破坏数据库的一致性。

3.1.2 不同的多事务执行方式

• 串行执行
  每个时刻只有一个事务运行，其他事务必须等到这个事务结束后才能运行。但是这样不能充分利用系统资源，发挥不了数据库共享资源的特点。
• 交叉并行执行
  单处理机系统中，事务轮流交叉运行。这样并非真正地并行，但较串行，能够减少处理机空闲时间，提高系统效率。
• 同时并发方式
  多处理机系统中，每个处理机可以运行一个事务，真正实现了多个事务的并行运行。

3.1.3 事务并发执行带来的问题

    数据库是共享资源，通常有多个事务在同时执行，当多个事务并发的存取数据库时就会存在同时读或写统一数据的情况，如果对并发操作不加控制，就会存在数据读取或存取错误，破坏数据库的一致性。 并发控制是衡量DBMS性能的重要指标之一。

3.1.4 并发操作带来的数据不一致性

• 丢失更新(Lost Update)
• 读“脏"数据(Dirty Read)
• 不可重复读(Non-repeatable Read)
  
  

3.1.5 并发控制机制的任务

• 数据不一致性原因：
  并发操作破坏了事务的隔离性(Isolation)。
• 并发控制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰，从而避免造成数据的不一致性。

3.2 并发控制措施

• 控制目标：
  事务运行过程中尽可能隔离事务外操作对本事务数据环境的影响。
• 并发控制的主要技术：
  加锁(Locking)、时间戳、乐观控制法。

3.2.1 加锁

    事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放锁前，其他事务不能更新此数据对象。

3.2.2 基本封锁类型

• 一个事务对某个数据对象加锁后究竟拥有什么样的控制权由封锁的类型决定。
• 基本封锁类型：
  排它锁（Exclusive Locks，简记为X锁）
  共享锁（Share Locks，简记为S锁）

1.排它锁：

• 排它锁又称写锁（X锁）。
• 若事务T对数据对象加上X锁，则允许事务T读取和修改数据，其他任何事务都不能再对此数据加任何类型的锁，直到事务T释放X锁。
• 保证其他事务在事务T释放X锁之前不能再读取和修改数据。
  2.共享锁：
• 共享锁又称读锁（S锁）。
• 若事务T对数据对象加上S锁，则其他事务只能再对数据加S锁，而不能加X锁，直到事务T释放数据上的S锁。
• 保证其他事务可以读数据，但是在事务T释放S锁前不能对数据做任何修改。

3.3 封锁协议

• 在运用X锁和S锁对数据对象进行加锁时，还需要约定一些规则，如：何时申请X锁或S锁、持锁时间、何时释放锁等。
• 对封锁方式规定不同的规则，就形成了各种不同级别的封锁协议。
• 不同级别的封锁协议达到的系统一致性级别不同。

3.3.1 一级封锁协议

• 规定：
  对事务T要修改的数据加X锁，直到事务结束时（包括正常结束和非正常结束）时才释放。
• 效果：
  可以防止丢失修改。
  不能防止不可重复读和读“脏”数据。

3.3.2 二级封锁协议

• 规定：
  一级封锁协议加上对事务T对要读取的数据加S锁，读完后即释放S锁。
• 效果：
  可以防止丢失修改、防止读“脏”数据，不能防止不可重复读。

3.3.3 三级封锁协议

• 规定：
  一级封锁协议加上事务T对要读取的数据加S锁，并直到事务结束才释放。
• 效果：
  可以防止丢失修改、防止读“脏”数据、防止不可重复读。
  

3.4 活锁和死锁

3.4.1 活锁和活锁的解决方法

• 活锁实例：
  
  ※避免活锁：
  当以下情况发生时，采用先来先服务的策略。
• 当多个事务请求封锁同一数据对象时。
• 按请求封锁的先后次序对这些事务排队。
• 该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁。

3.4.2 死锁和死锁的解决方法

• 死锁实例：
• 解决方法：
  1.预防死锁
  2.死锁的诊断与解除

1.死锁的预防：

• 产生死锁的原因：
  两个或多个事务都已封锁了数据对象，又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。
• 预防死锁就要破坏产生死锁的条件。
• 预防死锁的方法：
  一次封锁法、顺序封锁法。
  （1）一次封锁法：
• 要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。
• 存在的问题：
  降低系统并发度；难于实现精确地确定封锁对象。
  （2）顺序封锁法：
• 顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。
• 存在的问题：
  维护成本大（数据库系统中封锁的数据对象多，且在不断地变化）；难以实现（很难事先确定每一个事务要封锁哪些对象）。

※结论：
预防死锁的方法并不适合数据库的特点。DBMS更倾向于诊断并解除死锁。

2.死锁的诊断与解除：

• 死锁的诊断方式：
  超时法、事务等待图法

（1）超时法：
如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。
优点：实现简单。
缺点：实现设置过短会导致误判死锁；时间设置太长会导致死锁发生后不能及时发现。
（2）等待图法：
用事务等待图动态反映所有事务的等待情况。

• 事务等待图是一个有向图。
• 每个结点表示正在运行的事务。
• 每条边表示事务等待的情况。
• 若T1等待T2，则从T1指向T2划一条有向边。
• 图中存在回路，则表示系统出现了死锁。
• 并发控制子系统周期性地生成事务等待图，检测事务。如果发现图中存在回路，则表示系统中出现了死锁。
• 解除死锁：选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有的所有锁，使其它事务能够继续运行。

3.5 并发调度的可串行性

• 可串行化调度：
  多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同。
• 可串行性：
  并发事务正确调度的准则。
  一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度。

3.6 两段锁协议

指所有事务必须分两个阶段对数据加锁和解锁。

• 第一阶段是获得封锁，也称为扩展阶段：
  事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁。
• 第二个阶段是释放封锁，也成为收缩阶段：
  事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。
• 如果一个事务遵守两段锁协议，那么它就是一个可串行化调度。
• 可串行化调度不一定都符合两段锁协议。
• 两段锁协议并不要求事务必须一次将所有使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。

3.7 封锁粒度

• 封锁对象的大小称为封锁粒度。
• 何为封锁对象？比如：逻辑单元、物理单元。
  在关系数据库中，逻辑单元为：属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等。物理单元为：页（数据页/索引页）、物理记录等。

3.7.1 选择封锁粒度的原则

封锁粒度与系统并发度和并发控制的开销密切相关。

• 封锁粒度越大，数据库所能封锁的数据单元越少，并发度越小，系统开销也越小。
• 封锁粒度越小，并发度越高，系统开销也越大。

3.7.2 多粒度封锁协议

• 多粒度封锁协议允许多粒度树中的每个结点被独立地加锁。对一个结点加锁意味着这个结点的所有后裔结点也被加以同样类型的锁。
• 一个数据对象有两种封锁方式：显式封锁和隐式封锁。
• 显式封锁：直接加到数据对象上的封锁。
• 隐式封锁：该数据对象没有独立加锁，其上级结点加锁。
  显式封锁和隐式封锁的效果是一样的。
  对某个数据对象加锁，系统要检查：
• 该数据对象有无显式封锁与之冲突。
• 所有上级结点检查本事务的显式封锁是否与该数据对象上的隐式封锁（即上级结点已加的封锁造成的）冲突。

四、数据库备份与恢复

4.1 数据库故障的种类

• 故障是不可避免的：
  系统故障：计算机软、硬件故障。
  人为故障：操作员的失误、恶意的破坏。
• 数据库的恢复：
  把数据库从错误状态恢复到某一已知的正确状态（或称为一致状态或完整状态）。

4.1.1 事务的状态及其转换

• 事务开始运行进入活动状态。
• 事务执行完所有语句数据没有存入数据库中或未执行完所有语句称为部分提交状态。
• 完成所有操作并永久影响数据库，进入提交状态表示正常完成任务。
• 如果没有正常完成任务最后提交异常，结束事务。

4.1.2 事物内部的故障

• 事务内部故障指非预期的，不能由应用程序处理。
  例如：运算溢出、违反了某些完整性限制等。
• 事务故障的恢复：
  事务故障意味着事务没有达到预期的终点，数据库可能处于不正确状态，因此，要在不影响其他事务运行的情况下，撤销该事务已经做的对数据库的修改，使得该事务好像根本没有运行一样。
  -事务故障的恢复操作：撤销事务（UNDO）。

4.1.3 系统故障

• 系统故障：
  称为软故障，是指造成系统停止运转的任何事件，使得系统要重新启动。（例如：突然断电）
• 带来的问题：
  整个系统的正常运行突然被破坏，所有正在运行的事务都非正常终止，数据库缓冲区的信息全部丢失，不破坏数据库。
  -系统故障的恢复：
  发生系统故障时，若事务未完成，这时候的策略是，强行 撤销（UNDO）所有未完成的事务。
  发生系统故障时，若事务已提交，但缓冲区的信息尚未完全写回到磁盘上，这时候的策略是，重做（REDO）所有已经提交的事务。

4.1.4 其他故障

• 介质故障
  称为硬故障，指外存故障。
  1.磁盘损坏
  2.磁头碰撞
  3.操作系统的某种潜在错误
  4.瞬时强磁场干扰
  会破坏数据库或部分数据库，并影响正在存取这部分数据的事务。这类故障发生的可能性小，但破坏性很大。
  -介质故障的恢复
  1.装入数据库发生介质故障前某个时刻的数据副本。
  2.重做自此时始（副本备份时刻）的所有成功事务，将这些事务已提交的结果重新记入数据库。

4.1.5 故障的结果

故障对数据库的影响有两种：

• 数据库本身被破坏。
• 数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

4.2 数据库备份

恢复操作的基本原理：冗余。
利用存储在系统其他地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据。
数据库的恢复涉及两个关键问题：
如何建立冗余数据？
如何利用这些冗余数据实施数据库恢复？

4.2.1 备份内容

备份数据（数据转储）。

• 表（结构），包含系统表、用户定义的表。
• 数据库用户（包括用户和用户操作权）。
• 用户定义的数据库对象和数据库中的全部数据。

备份日志（登记日志文件）。

4.2.2 备份频率

要考虑两个因素：

• 出现故障时，允许丢失的数据量的大小。
• 数据库的事务类型（读多还是写多）以及事故发生的频率（经常发生还是不经常发生）。

通常情况下，数据库可以每周备份一次，事务日志可以每日备份一次。
对于一些重要的联机事务处理数据库，可以每日备份，事务日志则每隔数小时备份一次。

4.2.3 备份数据（数据转储）

数据转储：转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程，备用的数据称为后备副本或后援副本。
使用方法：

• 数据库遭到破坏后可以将后备副本重新装入。
• 重装后备副本只能将数据库恢复到转储时的状态。

备份方法：

• 静态转储与动态转储
• 海量转储与增量转储

1.静态转储：
在系统中无运行事务时进行的转储操作，转储期间不允许对数据库的任何存取、修改活动。得到的副本是符合数据一致性的副本。优点：实现简单。缺点：降低了数据库的可用性。
2.动态转储：
转储操作与用户事务并发进行，允许对数据库进行存取或修改。优点：不会影响事务的允许。缺点：不能保证副本中的数据正确有效。利用动态转储得到的副本进行故障恢复需要把动态转储期间各事务对数据库的修改活动登记下来建立日志文件，后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态。
3.海量转储：
每次转储全部数据库。从恢复角度看，使用海量转储得到的后被副本进行恢复往往更方便。
4.增量转储：
只转储上次转储后更新过的数据。如果数据库很大，事务处理十分频繁，增量转储更实用有效。

4.3 登记日志文件

4.3.1 日志文件的格式和内容

• 日志文件（log）：用来记录事务对数据库的更新操作的文件。
• 日志文件的格式：
  以记录为单位的日志文件；以数据块为单位的日志文件。

1.以记录为单位的日志文件：

2.以数据块为单位的日志文件：

4.3.2 日志文件的作用

1. 进行事务故障恢复。
2. 进行系统故障恢复。
3. 协助后备副本进行介质故障恢复。

4.3.3 登记日志文件

基本原则：
登记的次序严格按并行事务执行的时间次序。
必须先写日志文件，后写数据库。

• 写日志文件操作：将修改的记录写到日志文件。
• 写数据库操作：把对数据的修改写到数据库中。

4.4 数据库恢复

    恢复数据库是指将数据库从错误描述状态恢复到正确的描述状态（最近的正确时刻）的过程。

• 恢复策略
• 恢复技术

4.4.1 恢复策略

1. 事务故障的恢复：
事务故障就是事务在运行至正常终止点前被终止。
恢复方法就是利用日志文件撤销此事务已经对数据库进行的修改。事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预。
2.系统故障的恢复：
系统故障造成数据库不一致，往往是因为 未完成事务 对数据库的更新写入了数据库，或者已提交事务的更新还留在缓冲区没来得及写入数据库。
恢复方法就是撤销故障发生时未完成的事务或重做已完成的事务。
系统故障的恢复由系统在重新启动时自动完成。
3.介质故障的恢复：
重装数据库，然后重做已完成的事务。
介质故障的恢复需要DBA介入。DBA要重装最近转储的数据库副本和有关的各日志文件副本，执行系统提供的恢复命令。

4.4.2 数据库恢复技术

1.具有检查点的恢复技术：

• 引出该技术的原因：搜索整个日志将耗费大量的时间
• 具有检查点的恢复技术：
  在日志文件中增加检查点记录，增加重新开始文件，恢复子系统在登录日志文件期间动态地维护日志。
• 检查点记录的内容：
  1.建立检查点时刻所有正在执行的事务清单。
  2.这些事务最近一个日志记录的地址。
• 重新开始文件的内容：
  记录各个检查地记录在日志文件中的地址。

2.数据库镜像：

• 引出该计数的原因：介质故障对系统影响严重，影响数据库的可用性，恢复比较费时，为了预防介质故障，DBA必须周期性地转储数据库。
• 数据库镜像（Mirror）：DBMS自动把整个数据库或关键数据复制到另一个磁盘上。DBMS自动保证镜像数据与主数据库的一致性。当主数据库更新时，DBMS自动把更新后的数据复制过去。
• 当没有出现故障时：数据库镜像可以用于并发操作。
• 出现介质故障时：可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。
• 频繁地复制数据自然会降低系统运行效率，所以一般只对关键数据和日志文件镜像，而不是对整个数据库进行镜像。

小结

• 保证数据库一致性是对数据库的最基本的要求。
• 事务是数据库的逻辑工作单位：ACID特性。
• DBMS必须对事务故障、系统故障和介质故障进行恢复。
• 恢复中最常使用的技术：数据转储和登记日志文件。
• 恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库。
• 提高恢复效率的技术：检查点技术、镜像技术。