第一章

1.2 分布式数据库的定义 & 特性

**定义:**一个物理上分散而逻辑上集中的数据库系统

三个基本特点:a. 物理分布性 b. 逻辑整体性 c. 节点自治性

**其他特点:**d.数据分布透明性 e. 集中与自治相结合的控制机制 f. 适当的数据冗余度 g. 事务管理的分布性

分布式数据库系统的优点:

  • 可以管理具有不同透明度的数据
  • 提高可靠性和可用性:可靠性基本上定义为系统在特定时间运行的概率,而可用性定义为系统在一段时间内连续可用的概率。当 数据和DBMS软件分布在多个站点上时,一个站点可能会失败而其他站点继续运行,并且我们无法仅访问故障站 点中存在的数据,这基本上可以提高可靠性和可用性。
  • 更容易扩展
    在分布式环境中,在添加更多数据,增加数据库大小或添加更多数据方面扩展系统,增加数据库
    大小或添 加更多处理器要容易得多。
  • 改进的性能
    通过将查询分解为基本上并行执行的多个子查询,我们可以通过在不同站点执行多个查询来实现
    查询间和 内部查询并行性,这基本上可以提高性能。

分布式数据库系统的挑战:数据独立性、数据冗余、查询优化、事务管理等

1.3 分布式数据库系统体系结构和组成成分

DDBS体系结构:DB、DBMS、DBA,均分为全局和局部

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/91df2621-213f-4005-8fdd-61d755c2910b/Untitled.png

DDB:DDB是DDBS中各站点上数据库的逻辑集合。

DDB的模式结构:四层、六模式

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/8705a6d8-d41b-4e69-9700-389828d22bf5/Untitled.png

a. 全局外层:全局外模式

b. 全局概念层:全局概念模式、分片模式、分配模式

c. 局部概念层:局部概念模式

d. 局部内层:局部内层

**分片模式:**描述全局数据的逻辑划分。数据存储的单位是数据的逻辑片段。每个全局关系可以通过选择和投影这样的关系操作被逻辑划分为若干个片段,这就是数据分片。分片模式就是描述数据分片或定义片段,以及全局关系与片段之间的映像。映像是一对多的,即一个全局关系可以对应多个片段,而一个片段只能来自于一个全局关系。

**分配模式:**描述数据片段的分配情况。定义片段映像的类型,确定分布式数据库是冗余的还是非冗余的,以及冗余的程度。如果一个片段分配在多个站点上,则片段的映像是一对多的,分布式数据库是冗余的。

局部概念模式:对每个站点来说,在该站点上全部物理映像的集合称为该站点的局部概念模式。分配在同一站点上的同一个全局关系模式的一个或多个片段,构成了该全局关系模式在该站点上的一个物理映像。

1.4 数据独立性 & 分布透明性

数据独立性 = 逻辑独立性 + 物理独立性 + 数据分布独立性

分布透明性:包含三个层次,级别从高到低分别为分片透明性、位置透明性、局部数据模式透明性

a. 分片透明性:用户只需要关心全局关系模型,不必考虑数据的逻辑分片。位于全局概念模式和分片模式之间。(全局查询即可)

b. 位置透明性:各片段被复制的情况(是否被复制,复制了几个副本)、片段及各副本的节点位置分配情况。位于分片模式和分配模式之间。(精确到片段)

c. 局部数据模式透明性:与各个节点上数据库的数据模型无关。位于分配模式和局部概念模式之间。(精确到站点)

1.5 DDBS优缺点

CDBS与DDBS的冗余比较

a. CDBS:减少数据冗余,节省存储空间。其原因是,冗余数据不仅浪费空间,而且容易造成各数据副本之间的不一致性,为了保证数据的一致性,系统要付出一定的维护代价。

b. DDBS:最大特征是存在数据冗余,在不同的场地存储同一数据的多个副本。多重备份虽然损失掉了部分的存储空间,但保证了系统的可靠性和可用性。同时提高了系统性能,减少通信开销。

第二章

2.2 自顶向下设计分布式数据库

自顶向下设计步骤

需求分析 → 概念设计 → 逻辑设计 → 分布设计 → 物理设计

其中分布设计包括:a. 数据分片 b. 片段分配,其输入为全局模式,输出是局部概念模式。

分片设计的基本内容

a. 设计目的:合适的划分方案可以减少操作量,实现尽可能的本地性。

b. 分片三原则:1)完整性 2)可重构 3)不相交

c. 分片类型与其代数表达式:1)水平分片 2)垂直分片 3)混合分片

  • 水平分片:对全局关系执行选择操作,把具有相同性质的元组进行分组,构成若干不相交的子集。

    • 初级分片:以关系自身的属性性质为基础,执行选择操作,将关系分片成若干个不相交的片段。谓词集合是完整的、最小的。

    • 导出分片:从另一个关系的属性性质或水平片段推导出来的。导出分片是一种半连接操作。

    • 代数表达式:

      https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ec2192c0-7b0a-48e6-a04e-a4301261f9ac/Untitled.png

  • 垂直分片:对全局关系执行投影操作将属性分成若干组。垂直分片的组必须只在某个键属性上重叠,其他不能重叠。

    https://s3-us-west-2.amazonaws.com/secure.notion-static.com/e9759637-9103-4ea0-84e9-67bf235319f8/Untitled.png

  • **混合分片:**交替水平分片与垂直分片。

位置分配设计的基本内容

在非冗余分配中,每个片段恰好映射到一个站点上;冗余分配中,每个片段映射到一个或多个站点上。

a. 非冗余分配:“最佳适应方法”,将片段R分配到访问R次数最多的那个站点上。

b. 冗余分配:“所有得益站点”法、“附加复制”法。

  • 所有得益站点法:应用的检索访问费用总比从任何一个其他站点发出的应用对R进行更新访问的费用要低。
  • 附加复制法:从最有益处逐步附加复制的副本,直到附加复制已无明显好处。

第三章 查询处理和优化

3.2 查询优化基础

**查询树:**对一个关系代数表达式表示的查询,进行语法分析,可以得到一颗语法树,树的叶子是已知的关系,各个节点是关系代数操作符。

两个系统下的查询优化问题

a. 集中式数据库系统中的查询优化:查询优化的目的在于为每个用户查询寻求总代价最小的执行策略,尽可能降低I/O代价,使查询的响应时间最短。

  • 逻辑优化:为每个用户查询寻求总代价最小的执行策略或最优的操作符次序;
  • 物理优化:关于基本运算在实现中的优化,比如考虑索引、排序、聚集等。

b. 分布式查询优化:两种不同的目标来考虑查询优化。

  • 一是以总代价最小为标准,除了如CDBS一样考虑CPU代价和I/O代价之外,总代价还包括通过网络在站点之间传输数据和信息的代价;数据的分布和冗余也增加了查询的并行处理的可能性
  • 另一个目标是以每个查询的响应时间最短为标准。

3.3 查询分类和层次结构

查询处理步骤:查询分解 → 数据本地化 → 全局优化 → 局部优化

a. 查询分解:把SQL语句转换成一个定义在全局关系上的关系代数表达式。输入:sql语句;输出:关系代数表达式或全局查询树

b. 数据本地化:将一个在全局关系上的查询落实到合适的片段上。(全局查询树→片段查询树)

c. 全局优化:找出分片查询的最佳操作次序,使得代价最小。(片段查询树→优化的片段查询树)

d. 局部优化:采用集中式数据库系统中查询优化技术对片段查询进行优化处理。

3.4 基于关系代数等价变换的查询优化处理

**基本原理:**把查询问题转变为关系代数表达式,分析得到查询树,进行从全局到片段的变换得到基于片段上的查询树,然后利用关系代数等价变换规则的优化算法,尽可能先执行选择和投影操作。

优化思想:利用关系代数等价变换规则,把查询树中的连接和合并操作尽可能上提(向树根方向),选择和投影操作尽可能下移(向树叶方向)先进行。

实现步骤和方法

  • 将一个查询问题转变为关系代数表达式
  • 从关系代数表达式转换为查询树
  • 利用关系代数等价变换规则,对全局查询树进行优化处理
  • 利用分片信息将全局查询树转换为片段上的查询树
  • 再次利用关系代数等价变换规则,对片段查询树进行优化处理

从全局查询到片段查询优化原则

a. **水平分片关系优化:**尽可能把选择条件下移到分片的限定关系处,再把分片的限定关系与选择条件进行比较,然后去掉它们之间存在矛盾的相应片段。如果最后剩下一个水平片段,则可去掉一个“并”操作。

b. 垂直分片关系优化:把垂直分片所用到的属性集,与查询条件(查询表达式)中的投影操作所涉及的属性集相比较,去掉无关的垂直片段。如果最后剩下一个垂直片段,则可去掉一个“连接”操作。

3.5 基于半连接算法的查询优化

从片段查询到物理查询的转换

将片段查询树转换成具体的每个场地上的局部操作命令和数据传输命令序。其中操作执行次序的选择是重点!

半连接操作

a. 半连接操作具有不对称性

b. 从一个站点传送关系到另一个站点做连接之前,先出去那些与连接无关的数据,减少做连接操作的关系中的数据量,从而减少传输的代价。

选择操作与半连接操作的不同点和相同点:

  • 相同点:都是删减操作,都有过滤元组和选择元组的作用
  • 不同点:选择操作是过滤,是单目运算;半连接操作是对半连接左边的进行缩减性运算,非对称的,是双目运算。
  • 选择操作:以关系R上的选择操作为例。如果R是一个全局关系,那么简单地在包含R的站点上执行选择操作,然后把结果发送给用户站点。如果R被分片且分布在几个站点,那么在每个包含R片段的站点上执行选择操作,然后再将这些选择操作的结果合并到最终结果,发送给用户站点。
  • 半连接操作:在从一个站点传送关系到另一个站点做连接实现之前,先除去那些与连接无关的数据,减少做连接操作的关系中的数据量,从而减少传输的代价。所以,如果只需要一个关系中的一小部分元组参与和另一个关系连接的话,这是一个使数据传输量最小化的非常有效的方案。

SDD-1算法

a. 组成:基本算法 & 后优化

b. 后优化算法的两条准则:

  • 若最后一次半连接程序缩减关系的所在场地恰好是被选中的查询执行场地,则最后一次半连接可以取消。
  • 对基本算法的主迭代所构成的半连接程序程图进行修正。

c. 基本算法:

  • 输入:优化了的片段查询树
  • 方法
    • 构造出所有可能的半连接缩减程序。
    • 按半连接缩减程序的静态特性表分别计算其费用和收益,从一组可能的静态特性表中选取一个半连接程序,设M。
    • 以M完成缩减后,又将产生一组新的静态特性再进行计算,再从一组可取的静态特性表中选一个半连接程序。
    • 反复直到无半连接缩减程序为止。
  • 输出:以若干次迭代以后的最后缩减关系的静态特性表为基础,进行场地选择,决定执行查询的场地。

d. 主要思路:利用半连接把属于两个场地的连接运算用半连接变成两次的传递,先缩减后连接,以便达到减少通信。

3.6 基于直接连接算法的查询优化

**分片和复制算法:**选择一组站点,把查询引用的某个关系的所有片段分布到这些站点上,其余被引用的关系则复制到每一个选定的站点中去。

直接连接操作的常用策略

a. 两个关系在同一站点----与CDBS中策略相同。
b. 两个关系在不同站点----假设 R∞S

  • 第一种策略:整体传输
  • 第二种策略:按需传输

第四章

4.1 分布式事务概述

**集中式事务:**对数据库的一个或一段程序或命令的一次执行。

**分布式事务(全局事务):**事务具有分布式,操作命令序列及数据分布在不同的站点上。通常由一个主事务和在不同站点上执行的子事务(局部事务)组成。

主事务:负责事务的开始、提交和异常终止。

子事务:完成对相应站点上数据库的访问操作。

特性:

a. 原子性:每个事务的所有操作要么被全部成功地执行,要么一个也不被执行。

b. 一致性:如果在执行事务之前数据库是一致的,那么在执行事务之后数据库也还是一致的。//可串行性。

c. 隔离性:即使多个事务并发执行,每个事务都感觉不到系统中有其他的事务在执行,因而也就能保证数据库的一致性。

d. 持久性:事务成功执行后它对数据库的修改是永久的,即使系统出现故障也不受影响。

分布式事务 = ACID + 分布,即各个站点上的数据库全都进入一个新的一致状态,才能使整个数据库转换为新的一致状态。

全局提交原则

a. 只要有一个参与者撤消事务,协调者就必须做出全局撤消决定;

b. 只有所有参与者都同意提交事务,协调者才能做出全局提交决定.

分布式数据库中的故障类型

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/c25d4f10-9064-4b38-9ce2-f0fbe3e0b652/Untitled.png

其中比较主要的是:网络分割故障、报文错、报文失序。

4.2 执行与恢复

日志记录格式:

1)[start_transaction,T] 表示事务T开始执行;

2)[write_item,T,X,旧值,新值] 表示事务T已将数据项X的值从旧值该为新值;

3)[read_item,T,X] 表示事务T已读取数据项X的值;

4)[commit,T] 表示事务T已成功完成,其结果已被提交给数据库(永久性);

5)[abort,T] 表示事务T已被撤消;

6)Log:记录长度及用于恢复过程的辅助信息.

我们假设所有对数据库的永久改变都发生在事务内部,所以对事务故障进行恢复,实际上就是取消或重新逐个地执行日志中的事务操作.

检查点工作原理:

为了便于恢复,在日志中设定一种周期性操作点,称为检查点,以标始检查点前已执行完的事务是正确的.每遇检查点,就做如下工作:

1)将Log缓冲区内容写入日志数据集;

2)在日志数据集中写入这次检查点记录信息—当前活动事务表;

3)将DB缓冲区内容写入DB(更新当前DB);

4)将这次检查点记录在日志数据集中的地址记入“重启动文件”中.

事务故障的恢复原则

当发生事务故障时,为了保证事务的原子性需要进行事务恢复。事务故障主要是依靠日志来实现,恢复的原则是:

(1)孤立和逐步退出事务的原则
对于不影响其它事务的可排除性局部故障,例如事务操作的删除、超时、违反完整性规则、资源、限制、死锁等,应令某个事务孤立和逐步地退出,将其所做过的修改恢复,即UNDO.

(2)成功结束事务原则
成功结束事务所做过的修改应超越各种故障而存在,也就是重做(REDO)它所做过的所有修改数据库的操作.

(3)夭折事务的原则
若发生了非局部性的不可排除的故障,例如系统崩溃,则撤消全部事务,恢复到初态.

基于日志的事务故障的恢复处理过程

在系统发生故障时,需要扫描日志,检查那些已在日志中写入[start_transaction,T],但没有写入[commit,T]的所有事务T;恢复时必须回滚(UNDO)这些事务以取消它们对数据库的影响。

此外,还必须对日志中记录的已提交事务的所有写操作进行恢复,这样它们对数据库的作用才可根据这些记录重做(REDO)。

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/85bd2d21-a776-41f0-bd04-789fccceabb6/Untitled.png

掌握两阶段提交协议内容(算法描述)、实现方式对故障的处理、阻塞现象;

a. 两阶段提交协议:

  • 在两阶段提交协议中,把分布式事务的某一个代理(根代理)指定为协调者,所有其它代理称为参与者.
  • 只有协调者才有掌握提交或撤消事务的决定权,而其他参与者各自负责在其本地数据库中执行写操作,并向协调者提出撤消或提交子事务的意向.
  • 两个阶段:提交阶段 与 表决阶段
  • 2PC协议保证了事务的原子性

b. 算法描述

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0f5b6161-7e7f-4722-86ed-b62d47da4ab9/Untitled.png

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/dc762a83-b3a2-4b17-ae4f-9d70acab409b/Untitled.png

c. 故障处理

  • 场地故障

    (1)当一参与者在写入“准备提交”前发生故障时,该参与者无法向协调者发回答信息,因此,当协调者等待超时后,将决定中止事务.

    对该故障场地而言,当故障恢复后,只要撤消该事务即可.

    (2)参与者在写入“准备提交”后发生故障,这时,其它的参与者可以正常地结束该事务“提交”和“撤消”.

    故障恢复后,该参与者要访问协调者或其它参与者,以了解事务已做出的决定,然后执行相应的操作.

    (3)协调者在日志中写入“预提交”记录后,写入“全部提交”或“全部夭折”前发生故障,这时已发出“准备提交”信息的参与者将等待协调者恢复.

    协调者重启动后将从头恢复提交协议,从“预提交”记录中读出参与者的标识符,重发“预提交”命令给参与者,重新执行提交过程.

    (4)协调者在日志中写入“全部提交”或“全部夭折”记录后,在写入“完成”记录之前发生故障.

    协调者恢复时必须给所有的参与者重发其决定.

  • 丢失报文

    (1)来自参与者的回答报文(准备提交或夭折)丢失了至少一个,此时,协调者将等待回答而超时,整个事务被夭折.

    (2)丢失“预提交”报文,由于至少一个参与者收不到该命令,因此协调者会因等待参与者的回答而超时,整个事务被夭折.

    (3)丢失“提交”或“夭折”报文,此时,参与者处于等待协调者命令的状态,当等待超时时,参与者将向协调者发送请求重发该命令的信息----需要在参与者中有超时机制.

    (4)丢失“执行”报文,当协调者未收到全部的“执行”报文时,它会因等待而超时,此时,协调者重发命令给所有参与者----需要在协调者中有超时机制.

d. 阻塞现象:

  • 在2PC协议中,当参与者等待协调者的回答时,可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时。
  • 这时,事务进入阻塞状态,重发“准备提交”信息要求协调者给予回答,直到故障恢复.若一直收不到回答,则事务一直处于阻塞状态而挂在相应的场地上。

2PC协议线性通信结构中报文、网络延迟的计算

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/be214c14-950a-49e4-9ce7-e28ad64d59c6/Untitled.png

非阻塞提交协议3PC协议以及该协议是如何避免阻塞现象的

a. 原理

  • 在2PC协议中增加一段使得参与者的提交不仅要等到它知道所有的参与者均发出了“准备提交”的报文,而且还知道所有参与者的状态(如它们是处于故障状态,还是已经恢复)以后才执行,这时,2PC协议就是3PC协议。
  • 在3PC协议中,报文有三次接收和发送.协调者第2次向参与者发出的报文不是“提交”报文,而是提交前的预备报文,告诉所有的参与者均可进入准备提交状态(第2态!),而参与者的回答也不是“提交”报文,而是“准备就绪”报文.
  • 在2PC中,参与者在“等待回答”时有2种可能的情况,一是夭折,一是可以提交.后一种情况有可能出现阻塞。

b. 3PC协议的工作过程:

  • 第一阶段,协调者向所有的参与者发“预提交”报文,由每个参与者根据自己的情况进行投票,只有收到所有的参与者均赞成提交的报文才进入下一阶段.
  • 第二阶段,协调者向所有的参与者发“准备提交”报文,参与者收到该报文后若已经准备好提交,则回答“准备就绪”报文,否则进行夭折处理.
  • 第三阶段,当协调者收到所有的参与者“准备就绪”的回答,就向所有的参与者发“提交”报文,参与者收到该报文后可以提交其子事务.

c. 在3PC协议中下述两种状态是不相容的:

  • 一个参与者在其它任何一个参与者处于“赞成提交”状态(即第1状态)时,不可能进入“提交”状态(第3状态).
  • 一个参与者在另一个参与者进入“提交”状态(第3状态),或任何一个参与者都进入了“准备提交”状态(第2状态)时不能进入“夭折”状态(第1状态).

d. 3PC协议对故障的处理

  • 协调者没能及时发出“预提交”报文,导致参与者等待超时,这时,参与者将决定夭折.
  • 协调者等待参与者的投票时超时,这时,协调者将决定夭折.
  • 参与者已进入“赞成提交”状态(第1状态),在等待协调者的命令时超时或协调者故障.
  • 参与者处于“准备就绪”状态(第2状态),等待协调者的提交命令超时.

3pc协议怎么比避免在2pc协议会出现的阻塞现象:

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/bb3c8f8d-9561-4fcc-8fb0-faea5f28a68a/Untitled.png

第五章

了解多个事务并发执行可能出现的问题

  1. 丢失更新问题
  2. 不一致分析问题
  3. 依赖于未提交更新的问题

了解并掌握并发控制的基本概念,比如事务调度、串行调度、可串行化调度、事务的冲突操作、一致性调度、基于冲突等价的等价调度等;

  1. 分布式事务的一个调度

    Ti表示第i个事务,Ri(x)表示Ti对数据项x的读操作,Wi(x)表示Ti对数据项x的写操作.

    所考虑的全部事务中的所有操作的一个序列称为这组事务的一个调度S.

  2. 串行调度

    设有一组事务T={T1,T2,…,Tn},如果事务Ti的所有操作都先于事务Tj的操作,记为Ti<Tj.

    若一个调度S,其每个事务的执行均有Ti<Tj,称S为串行调度,即S={…<Ti<Tj<…}.

  3. 可串行化调度

    与串行调度等价的调度称为可串行化调度.

    直观上看,是让有冲突的操作串行执行,非冲突的操作并行执行.

  4. 冲突操作

    如果有两个操作P和Q对同一个数据x进行操作,其中有一个是写操作W[x],则P和Q称为冲突操作.

  5. 一致性调度

    如果执行一个调度S,使数据库从一个一致状态转变到另一个一致状态,则称调度S为一致性调度.

    任何一个串行调度是一致性调度.

  6. 两个调度等价(冲突等价)

    两个调度S1和S2是等价的充分条件是:对于两个有冲突的操作Oi和Oj,若:Oi,Oj ΠS1,且Oi<Oj,则Oi,Oj ΠS2,且也有Oi<Oj

结论:

  • 同一个事务集上的可串行化调度,结果未必相同;
  • 一个可串行化调度必定与某个串行调度等价,且是一致性调度;
  • 一致性调度不一定是可串行化调度;
  • 同一事务集的几个可串行化调度,它们的结果未必相同.使用优先图判别局部调度是否可串行化

使用优先图判别局部调度是否可串行化:

  • 对于调度S中的事务Ti,在图上创建一个节点Ti;
  • 对于每一种这样的情形:如果S中在Ti执行了W(x)操作后执行Tj的R(x)操作,那么在优先图中创建一条边(Ti→Tj);
  • 对于每一种这样的情形:如果S中在Ti执行了R(x)操作后执行Tj的W(x)操作,那么在优先图中创建一条边(Ti→Tj);
  • 对于每一种这样的情形:如果S中在Ti执行了W(x)操作后执行Tj的W(x)操作,那么在优先图中创建一条边(Ti→Tj);
  • 当且仅当优先图中没有环路时,调度S是可串行化的.

判别一个全局调度是否是一致性调度(全局可串行化调度的条件):

在分布式数据库中,只涉及一个站点上的调度称为局部调度,涉及多个站点,上的调度称为全局调度。

  • 如果分布式数据库中数据没有副本,并且每个局部调度都是可串行化的。那么它们的并集(即全局调度)也称作是可串行化的。
  • 如果分布式数据库中数据有副本,当局部调度满足以下两个条件时,是可串行化的。
    • 每一个局部调度必须是可串行化的;
    • 两个冲突操作在它们同时出现的各个局部调度中,必须具有相同的相对顺序.

两段锁协议

  1. 两阶段封锁协议保证调度的可串行化:如果一个事务所有的封锁操作都放在第一个解锁操作之前,那么就说该事务遵守两阶段封锁协议。这样的一个事务可以被分成两个阶段:
    • 第一阶段是扩张或成长阶段.在这个阶段中,事务只能获得新的数据项锁,而不能释放任何已持有的锁.
    • 第二阶段是收缩或衰退阶段.在这个阶段,事务只能释放已经持有的锁,而不能获得任何新的锁.
  2. 工作过程(以严格2PL协议为例):
    • 当事务T发出R(X)的请求时,系统会代表T调用read-lock(X)操作。如果lock(X)的状态是被另一个事务T’持有写锁,那么,系统会把T放到数据项X的等待队列中。否则,系统同意read-lock(X)的请求,从而允许事务T执行R(X);
    • 如果事务T发出W(X)操作的请求时,系统会代表T调用write-lock(X)操作。如果lock(X)的状态是被另一个事务T’持有读锁或写锁,那么,系统会把T放到数据项X的等待队列中。如果lock(X)的状态是读封锁,并且事务T本身就是持有X上的读锁的唯一事务,那么系统将该读锁升级为写锁,并且允许T执行W(X)的操作.
  3. 缺点:
    • 限制了一个调度中可以发生的并发事务的数量.
    • 可能出现死锁.

事务等待图和事务优先图的区别

  1. 事务等待图:一种用来表示事务之间相互等待关系的有向图,可指明哪个事务在等待别的事物释放锁
  2. 事务优先图:用于表示事务间先后次序,可以判断是否可串行化调度
  3. 等待图是动态的,有环路代表有死锁
  4. 优先图是静止的,有环路代表不可调度

**死锁的判别:**当且仅当等待图中至少包含一个回路,则存在一个死锁。

死锁的预防:

  1. 基本思想:当有发生死锁危险时,就中止并重新启动其中一个事务或让该事务等待。如果事务T1请求一资源,而该资源被另一事务T2所持有时,就进行一次预防性测试.若测试结果表明有死锁的危险时,或不让T1进入等待状态,并重新启动T1,或中止并重新启动T2.
  2. 方法:先对事务按它们的开始时间排序。
    • 非占先权:总是重新启动比较年轻的事务,允许年老的事务等待年轻的。
    • 占先权:要求中止比较年轻的事务,且允许年老的事务绝对优于年轻的事务,因而只有年轻的等待年老的。

死锁的检测和解决方法:

  • 检测: 通过对全局等待图中回路的形成进行研究来实现。
  • 解决: 撤消某个/某些事务.选择撤消哪些事务称为受害者选择.通过选择一个或多个受害者事务,这些事务将被优先执行或撤消,以打破全局等待图中的回路。

第六章

数据可靠性的几种策略:读一写全法,多数法,主副本法

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ffc7193e-d6f6-43f7-9bd1-9bf97b9bd7d4/Untitled.png