数据库原理课程教案.docx
《数据库原理课程教案.docx》由会员分享，可在线阅读，更多相关《数据库原理课程教案.docx（27页珍藏版）》请在冰豆网上搜索。
数据库原理课程教案
数据库原理课程教案
授课题目（教学章、节或主题）：
第七章数据库系统的恢复和并发控制技术：
包括事务的概念以及事务的ACID特性，数据库恢复技术，并发操作产生的数据不一致性，并发调度的可串行性概念，封锁协议与数据一致性的关系，死锁的预防和诊断，饥饿的概念及预防等。
教学目的、要求（分掌握、熟悉、了解三个层次）：
把所学的知识和第六章所学习的知识联系起来，在实际的应用中，提升对这些技术的理解和掌握，保证数据的完整性、安全性和一致性，保证数据库系统24小时正确运行，保证数据库系统在遇到故障时能及时恢复正常运行，提高抗故障抗灾难的能力。
课时安排：
6节
授课方式：
理论课
教学基本内容：
以教师为中心的讲授、提问及论证等的教学方法，教学手段使用板书与多媒体相结合的手段。
第七章数据库系统的恢复和并发控制技术
v本章学习目的
▪把所学的知识和第六章所学习的知识联系起来，在实际的应用中，提升对这些技术的理解和掌握，保证数据的完整性、安全性和一致性，保证数据库系统24小时正确运行，保证数据库系统在遇到故障时能及时恢复正常运行，提高抗故障抗灾难的能力。
v本章要点
▪事务的基本概念
▪事务的ACID属性
▪数据库恢复技术，针对不同的故障类型，掌握恢复数据库的策略和方法
▪并发操作产生的数据不一致性
▪并发调度的可串行性概念
▪封锁协议与数据一致性的关系
▪死锁的预防和诊断
▪饥饿的概念及预防
7.1事务的基本概念和特性
7.1.1事务的基本概念
v事务定义
▪一个数据库操作序列
▪一个不可分割的工作单位
▪恢复和并发控制的基本单位
v在SQL语言中，定义事务的语句有三条：
▪BEGINTRANSACTION
▪COMMIT
▪ROLLBACK
1）什么是事务
●事务（Transaction）是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位
●事务和程序是两个概念
Ø在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序
Ø一个应用程序通常包含多个事务
●事务是恢复和并发控制的基本单位
2）如何定义事务
●显式定义方式
BEGINTRANSACTIONBEGINTRANSACTION
SQL语句1SQL语句1
SQL语句2SQL语句2
。
。
。
。
。
。
。
。
。
。
COMMITROLLBACK
●隐式方式
当用户没有显式地定义事务时，DBMS按缺省规定自动划分事务
vCOMMIT
▪事务正常结束
▪提交事务的所有操作（读+更新）
▪事务中所有对数据库的更新永久生效
vROLLBACK
▪事务异常终止
•事务运行的过程中发生了故障，不能继续执行
▪回滚事务的所有更新操作
•事务滚回到开始时的状态
7.1.2事务的ACID特性
事务的ACID特性：
v原子性（Atomicity）
v一致性（Consistency）
v隔离性（Isolation）
v持续性（Durability）
7.2数据库恢复
v故障是不可避免的
▪系统故障
▪人为故障
v数据库的恢复
把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）
7.2.1故障的种类
v1.事务内部的故障
v2.系统故障
v3.介质故障
1.事务内部故障
v事务内部的故障
⏹有的是预期的，在程序中可以预先估计到的，由事务程序加入判断和ROLLBACK语句进行处理。
⏹有的是非预期的
v事务内部更多的故障是非预期的，是不能由应用程序处理的。
⏹运算溢出
⏹并发事务发生死锁而被选中撤销该事务
⏹违反了某些完整性限制等
以后，事务故障仅指这类非预期的故障
v事务故障的恢复：
撤消事务（UNDO）
2.系统故障
v系统故障是指引起系统停止运转随之要求重新启动的任何事件。
v原因：
硬件故障（如CPU故障）、软件故障（如操作系统故障）、突然断电等。
v特点：
▪整个系统的正常运行突然被破坏
▪所有正在运行的事务都非正常终止
▪不破坏数据库
▪内存中数据库缓冲区的信息全部丢失
系统故障的恢复
v发生系统故障时，事务未提交
▪恢复策略：
强行撤消（UNDO）所有未完成事务
v发生系统故障时，事务已提交，但缓冲区中的信息尚未完全写回到磁盘上。
▪恢复策略：
重做（REDO）所有已提交的事务
3.介质故障
v介质故障
称为硬故障，指外存故障
▪磁盘损坏
▪磁头碰撞
▪瞬时强磁场干扰
▪计算机病毒
介质故障的恢复
▪
（1）重装转储的备份副本到新的磁盘，使数据库恢复到转储时的一致状态；
▪
（2）在日志中找出转储后所有已提交的事务；
▪（3）对这些已提交的事务进行REDO处理，即子系统撤消所有未完成事务，对所有已提交的事务进行重做。
7.2.2数据库恢复技术
v恢复操作的基本原理：
冗余
使用存储在另一个系统中的“冗余”数据以及事先建立起来的日志文件，重新构建数据库中已经被损坏的数据，或者修复已经不正确的数据。
v恢复机制涉及的关键问题
▪如何建立冗余数据
⏹数据转储
⏹登记日志文件
▪如何利用这些冗余数据实施数据库恢复
7.2.2数据库恢复技术
v1．数据转储技术
v2．登记日志文件
v3．使用多副本的恢复技术
1.数据转储技术
v所谓数据转储，是指由DBA（数据库管理员）定期的将整个数据库中的内容复制到另一个存储设备或另一个磁盘上去，这些转储的副本称为后备副本或后援副本。
v如何使用
▪数据库遭到破坏后可以将后备副本重新装入
▪重装后备副本只能将数据库恢复到最近转储时的状态
转储方法
（1）从转储的运行状态，可分为静态转储与动态转储
（2）从转储的进行方式，可分为海量转储与增量转储
静态转储
v在系统中无运行事务时进行的转储操作
v转储开始时数据库处于一致性状态
v转储期间不允许对数据库的任何存取、修改操作
v得到的一定是一个数据一致性的副本
v优点：
实现简单，可保证副本与数据库的一致性
v缺点：
降低了数据库的可用性，效率较低
▪转储必须等待正运行的用户事务结束
▪新的事务必须等转储结束
动态转储
v转储操作与用户事务并发进行
v转储期间允许对数据库进行存取或修改
v优点
▪不用等待正在运行的用户事务结束
▪不会影响新事务的运行
v动态转储的缺点
▪不能保证副本中的数据正确有效
v利用动态转储得到的副本进行故障恢复
▪需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
▪后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态
（2）海量转储与增量转储
v海量转储:
每次转储全部数据库
v增量转储:
只转储上次转储后更新过的数据
v海量转储与增量转储比较
▪从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
▪但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用、更有效
2.登记日志文件
v什么是日志文件
日志文件（log）是用来记录事务对数据库的更新操作的文件
v日志文件的格式
⏹以记录为单位的日志文件
⏹以数据块为单位的日志文件
v以记录为单位的日志文件内容
▪各个事务的开始标记（BEGINTRANSACTION）
▪各个事务的结束标记（COMMIT或ROLLBACK）
▪各个事务的所有更新操作
v具体来说，每个日志记录的格式为：
（事务标识，操作类型，操作对象，前像，后像）
日志文件的格式和内容（续）
v以记录为单位的日志文件，每条日志记录的内容
▪事务标识（标明是哪个事务）
▪操作类型（插入、删除或修改）
▪操作对象（记录内部标识）
▪前像（对插入操作而言，此项为空值）
▪后像（对删除操作而言,此项为空值）
v举例说明日志文件记录，对于下面每次操作，在日志文件中写一个记录：
▪
（1）事务T开始，日志记录为（T，start，，，）
▪
（2）事务T修改对象A，日志记录为（T，update，A，前像，后像）
▪（3）事务T插入对象A，日志记录为（T，insert，A，，后像）
▪（4）事务T删除对象A，日志记录为（T，delete，A，前像，）
▪（5）事务T提交，日志记录为（T，commit，，，）
▪（6）事务T回滚，日志记录为（T，rollback，，，）
v以数据块为单位的日志文件，每条日志记录的内容
▪事务标识（标明是那个事务）
▪被更新的数据块
日志文件的作用
v
（1）当数据库发生的是事务故障和系统故障时，直接根据日志文件对相应的数据库操作进行UNDO和REDO操作即可；
v
（2）当发生介质故障时，
▪如果采用的是动态转储方式，则将后备副本和日志文件结合起来才能有效恢复数据库；
▪如果采用的是静态转储方式，也可建立日志文件，二者结合完成数据库的恢复。
使用后备副本和日志文件恢复数据库
登记日志文件
v基本原则
▪
（1）登记的次序必须严格按照并发事务执行的时间次序；
▪
（2）必须先写日志文件，后写数据库，并且日志文件不能和数据库放在同一磁盘上，要经常把它复制到磁带上。
3．使用多副本的恢复技术
v如果系统中有多个数据库副本，并且各个副本不会因故障而同时失效，则称这些副本具有独立的失效模式。
v优点：
用户可以利用这些独立副本互为备份，很方便地恢复数据库
v缺点：
硬件和系统的代价比较高
7.2.3恢复策略
1.事务故障的恢复
2.系统故障的恢复
3.介质故障的恢复
1.事务故障的恢复
v事务故障：
事务在运行至正常结束提交前被终止
v恢复方法
▪应该撤消（UNDO）该事务对数据库的一切更新
v事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预
v
（1）反向扫描日志文件，查找该事务的更新操作；
v
（2）对查到更新操作的事务执行逆操作。
即将日志记录中“更新前的值”写入数据库
▪若是UPDATE操作，则将日志文件“前像”写入数据库；
▪若是INSERT操作，则将数据对象删去；
▪若是DELETE操作，则做插入操作，插入数据对象的值为日志记录中“前像”；
v（3）继续反向扫描日志文件，找出其他的更新操作，并做同样处理。
直至读到该事务的Start标记为止。
2.系统故障的恢复
v系统故障造成数据库不一致状态的原因
▪未完成事务对数据库的更新已写入数据库
▪已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
v恢复方法
▪1.Undo故障发生时未完成的事务
▪2.Redo已完成的事务
v系统故障的恢复由系统在重新启动时自动完成，不需要用户干预
系统故障的恢复步骤
（1）正向扫描日志文件（即从头扫描日志文件）
▪重做（REDO）队列:
在故障发生前已经提交的事务
Ø这些事务既有BEGINTRANSACTION记录，也有COMMIT记录
▪撤销（Undo）队列:
故障发生时尚未完成的事务
Ø这些事务只有BEGINTRANSACTION记录，无相应的COMMIT记录
（2）对重做队列事务进行重做（REDO）处理
⏹依据登入日志文件中次序，重新执行登记的操作；
（3）对撤销队列事务进行撤销（UNDO）处理
⏹依据登入日志文件中相反次序，对每个更新操作执行逆操作
⏹即将日志记录中“更新前的值”写入数据库
v在上述步骤
（1）中，扫描所有的日志文件需要耗费大量的时间，重做的操作中很多是不必要的，故引入了一种称为检查点的恢复技术。
该技术是在日志文件中增加了一类新的记录，即检查点（Checkpoint）记录。
v检查点记录的内容包括：
▪①建立检查点时刻正在执行的事务清单；
▪②这些事务最近一个日志记录的地址。
v设置检查点时要执行下列动作：
▪①把仍保留在日志缓冲区中的内容写到日志文件中；
▪②在日志文件中写一个“检查点记录”；
▪③把数据库缓冲区的内容写到数据库；
▪④把日志文件中检查点记录的地址写到“重新启动文件”中。
3.介质故障的恢复
v具体措施：
▪
（1）检查磁盘的毁坏程度，必要时更换磁盘；
▪
（2）然后修复系统（包括操作系统和DBMS），重新启动系统；
▪（3）重新装入最近的后备副本，使数据库恢复到最近一次转储时的一致性状态；
▪（4）重新装入有关的日志文件副本，对日志记录中转储点之后的已提交的事务进行REDO操作，将数据库恢复到故障前某一时刻的一致状态。
7.3并发控制
v问题的产生
▪多用户数据库系统的存在
允许多个用户同时使用的数据库系统
⏹飞机定票数据库系统
⏹银行数据库系统
特点：
在同一时刻并发运行的事务数可达数百个
v不同的多事务执行方式
（1）事务串行执行
▪每个时刻只有一个事务运行，其他事务必须等到这个事务结束以后方能运行
▪不能充分利用系统资源，发挥数据库共享资源的特点
（2）交叉并发方式（InterleavedConcurrency）
▪在单处理机系统中，事务的并行执行是这些并行事务的并行操作轮流交叉运行
▪单处理机系统中的并行事务并没有真正地并行运行，但能够减少处理机的空闲时间，提高系统的效率
（3）同时并发方式（simultaneousconcurrency）
▪多处理机系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行
v事务并发执行带来的问题
▪会产生多个事务同时存取同一数据的情况
▪可能会存取和存储不正确的数据，破坏事务一致性和数据库的一致性
7.3.1并发操作引发的问题
v并发操作带来的数据不一致性
▪1丢失更新（LostUpdate）
▪2读“脏”数据（DirtyRead）
▪3不可重复读（Non-repeatableRead）
v记号
▪R（x）:
读数据x
▪W（x）:
写数据x
1.丢失更新
v
（1）甲事务T1读取存款余额R=5000元；
v
（2）乙事务T2想在网上购物，读取存款余额5000元；
v（3）甲事务T1由于需要取走1000元，则系统修改存款余额R=R-1000=5000-1000=4000，并将存款余额4000元写回数据库；
v（4）乙事务网上购物转帐支取300元，则系统修改存款余额R=R-300=5000-300=4700，并将存款余额4700元写回数据库。
v两个事务T1和T2读入同一数据并修改，T2的提交结果破坏了T1提交的结果，导致T1的更新被丢失。
2.读“脏”数据
v
（1）甲事务T1读取存款余额R=5000元；
v
（2）甲事务T1由于需要取走1000元，则系统修改存款余额R=R-1000=5000-1000=4000，并将存款余额4000元写回数据库，此时取款的事务还未提交；
v（3）乙事务T2由于某种需要，读取存款余额为4000元；
v（4）因为某种原因，甲事务的操作要撤销，此时对甲事务执行ROLLBACK操作，该帐户余额恢复为R=5000元。
读“脏”数据是指：
⏹事务T1修改某一数据，并将其写回磁盘
⏹事务T2读取同一数据后，T1由于某种原因被撤销
⏹这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致
⏹T2读到的数据就为“脏”数据，即不正确的数据
3.不可重复读
v
（1）甲事务T1读取存款余额R=5000元；
v
（2）乙事务T2想在网上购物，读取存款余额5000元；
v（3）乙事务网上购物转帐支取300元，则系统修改存款余额R=R-300=5000-300=4700，并将存款余额4700元写回数据库。
v（4）甲事务T1再次读取帐户余额进行验证时发现前后两次读取值发生了变化，无法读取前一次读取的结果。
v不可重复读是指事务T1读取数据后，事务T2
执行更新操作，使T1无法再现前一次读取结果。
v不可重复读包括三种情况：
①事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时，得到与前一次不同的值
⏹T1读取R=5000进行运算
⏹T2读取同一数据R，对其进行修改后将R=4700写回数据库。
⏹T1为了对读取值校对重读R，R已为4700，与第一次读取值不一致
v②当事务T1按照一定条件从数据库中读取某些纪录后，事务T2删除了其中的某些纪录，结果当事务T1再次按照同样条件读取该数据时，发现某些纪录已经不存在了；
v③当事务T1按照一定条件从数据库中读取某些纪录后，事务T2插入了一些纪录，结果当事务T1再次按照同样条件读取该数据时，发现多出了某些数据。
7.3.1并发操作引发的问题
v分析：
v从事务的ACID性质考虑，产生上述三个问题的原因在于并发操作破坏了事务的隔离性。
v并发控制的任务就是要用正确的调度方式控制并发的事务正确地执行，使多个事务互不干扰，以避免造成数据库中的数据不一致。
v当多个事务并发时，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同，称这种调度策略为可串行化的调度。
7.3.2调度的可串行性
vDBMS对并发事务不同的调度可能会产生不同的结果
v什么样的调度是正确的？
v可串行化（Serializable）调度
⏹多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同
v可串行性（Serializability）
▪是并发事务正确调度的准则
▪一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度
【例7-1】有两个事务T1和T2，分别包含如下操作：
T1：
Read（A）T2：
Read（B）
A：
=A-2B：
=B-2
Write（A）Write（B）
Read（B）
B：
=B+2
Write（B）
现给出对这两个事务不同的调度策略
串行调度,正确的调度
串行调度,正确的调度
可串行化调度，正确的调度
不可串行化调度，错误的调度
7.3.2调度的可串行性
v为了保证调度的可串行性，采用技术
▪封锁（Locking）方法
▪时间戳（Timestamp）
▪乐观控制法
v商用的DBMS一般都采用封锁方法
7.4基于封锁的并发控制技术
7.4.1封锁
v封锁就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁
v加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。
基本封锁类型
v一个事务对某个数据对象加锁后究竟拥有什么样的控制由封锁的类型决定。
v基本封锁类型
▪排它锁（ExclusiveLocks，简记为X锁）
▪共享锁（ShareLocks，简记为S锁）
排它锁
v排它锁又称为写锁
v若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁
v保证其他事务在T释放A上的锁之前不能再读取和修改A
共享锁
v共享锁又称为读锁
v若事务T对数据对象A加上S锁，则其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁
v保证其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改
锁的相容矩阵
在锁的相容矩阵中：
v最左边一列表示事务T1已经获得的数据对象上的锁的类型，其中横线表示没有加锁。
v最上面一行表示另一事务T2对同一数据对象发出的封锁请求。
vT2的封锁请求能否被满足用矩阵中的Y和N表示
▪Y表示事务T2的封锁要求与T1已持有的锁相容，封锁请求可以满足
▪N表示T2的封锁请求与T1已持有的锁冲突，T2的请求被拒绝
如何利用封锁机制解决不可串行化调度？
使用封锁机制解决数据不一致问题
7.4.2封锁协议
v在运用封锁方法，对数据对象加锁时，需要约定一些规则，如何时申请加锁、申请锁的类型、持锁时间、何时释放封锁等，我们称这些规则为封锁协议（LockingProtocol）。
v对封锁方式规定不同的规则，就形成了各种不同的封锁协议，三级封锁协议分别在不同程度上解决了数据不一致性问题。
v1.一级封锁协议
v2.二级封锁协议
v3.三级封锁协议
1.一级封锁协议
v一级封锁协议是：
事务T在修改数据A之前，必须先对其加X锁，直到事务结束才释放。
事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。
v一级封锁协议可防止“丢失修改”所产生的数据不一致性的问题，并保证事务T是可恢复的。
如何使用一级封锁协议解决“丢失更新”问题
2.二级封锁协议
v二级封锁协议在一级封锁协议的基础上，加上了事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
v二级封锁协议除防止了丢失修改，还可进一步防止读“脏”数据。
如何使用二级封锁协议解决读“脏”数据问题?
3.三级封锁协议
v三级封锁协议是：
在一级封锁协议的基础上加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。
v三级封锁协议可进一步防止不可重复读的问题。
前面所讲的不可重复读问题
⏹T1读取R=5000进行运算
⏹T2读取同一数据R，对其进行修改后将R=4700写回数据库。
⏹T1为了对读取值校对重读R，R已为200，与第一次读取值不一致
如何使用三级封锁协议解决不可重复读问题?
7.4.3两段锁协议
v三级封锁协议可以防止并发执行中出现的三类问题，但是，并不能保证并发执行一定是可串行化的。
v两段封锁协议（Two-PhaseLocking，简称2PL）是最常用的一种封锁协议，理论上证明使用两段封锁协议产生的是可串行化调度。
v两段锁协议是将所有事务的加锁和解锁分成两个阶段：
▪
（1）获得封锁，也称为扩展阶段，在该阶段，事务可以获得任何数据项上的任何类型的锁；
▪
（2）释放封锁，也称为收缩阶段，在此阶段，事务可以释放任何数据项上的任何类型的锁，但一旦释放一个锁之后，事务不能再获得任何其他加锁。
例
两个事务T1，T2：
T1：
lock（A）lock（B）lock（C）unlock（B）unlock（C）unlock（A）
T2：
lock（A）unlock（A）lock（B）lock（C）unlock（C）unlock（B）
T1遵守两段锁协议，T2不遵守两段锁协议。
对于T1，T2遵守两段锁协议的并发执行
v两个事务T1和T2均遵守两段锁协议，其执行结果为A=60，B=110，跟按照T1→T2顺序的串行执行的
升级会员 