1、事务处理-锁,提纲,并发控制 基于锁的协议 两段锁协议 多粒度 封锁带来的问题 恢复 故障 日志 恢复,封锁的定义,封锁就是一个事务对某个数据对象加锁，取得对它一定的控制，限制其它事务对该数据对象使用 要访问一个数据项R，事务Ti必须先申请对R的封锁，如果R已经被事务Tj加了不相容的锁，则Ti需要等待，直至Tj释放它的封锁,封锁的类型,排它锁（X锁，eXclusive lock） 事务T对数据对象R加上X锁，则其它事务对R的任何封锁请求都不能成功，直至T释放R上的X锁；又称写锁 申请对R的排它锁：lock-X(R) 共享锁（S锁，Share lock） 事务T对数据对象R加上S锁，则其它事务对
2、R的X锁请求不能成功，而对R的S锁请求可以成功；又称读锁 申请对R的共享锁： lock-S(R),封锁的相容矩阵,两阶段封锁协议,Two-Phase Locking Protocol 两阶段封锁协议内容 增长阶段(Growing Phase) 事务可以获得锁，但不能释放锁 缩减阶段(Shrinking Phase) 事务可以释放锁，但不能获得锁 示例lock-S(A)lock-S(B)lock-X(C)unlock(A) unlock(C)unlock(B)遵从两段锁协议lock-S(A)unlock-S(A)lock-S(B)lock-X(C) unlock(C)unlock(B)不遵从两段
3、锁协议,两阶段封锁协议,封锁点：事务获得其最后封锁的时间 事务调度等价于和它们的封锁点顺序一致的串行调度 令T0, T1, ,Tn是参与调度S的事务集，如果Ti对数据项R加A型锁，Tj对数据项R加B型锁，且comp(A, B)=false，则称Ti先于Tj，记作TiTj，得到一个优先图 设ti是Ti的封锁点，若TiTj，则titj 若T0, T1, ,Tn不可串行化，则在优先图中存在环，不妨设为T0T1TnT0，则t0t1tnt0，矛盾,两阶段封锁协议,保持到事务结束时才释放的锁称作长锁 在事务中途就可以释放的锁称作短锁,发生级联回滚,严格两阶段封锁协议,lock-S(A); read(A);
4、 A1 := A; unlock(A);lock-S(A); read(A); A1 := A; unlock(A); commit；,lock-X(A) read(A); A := A 1; write(A)； commit；,T1,T2,不能保证 可重复读,两阶段封锁+长X锁+S锁,强两阶段封锁协议,锁转换,带有锁转换的两段锁协议 增长阶段 可获得lock-S 可获得lock-X 可将lock-S升级为lock-X (upgrade) 缩减阶段 可释放lock-S 可释放lock-X 可将lock-X降级为lock-S (downgrade),封锁方法,直接封锁 事务对它要进行存取的数据对
5、象直接申请加锁,封锁方法,分层封锁 数据对象从大到小有一种层次关系，当封锁了外层数据对象时也就意味着同时封锁了它的所有内层数据对象,封锁粒度,封锁对象 属性值、属性值几何、元组、关系、某索引项、整个索引、整个数据库、物理页、块 封锁粒度大，则并发度低，封锁机构简单，开销小封锁粒度小，则并发度高，封锁机构复杂，开销高 理想的情况是只封锁与规定的操作有关的的数据对象，这些数据对象称作事务的完整性相关域,SQL Server的封锁粒度,封锁粒度,意向（预约）封锁 在分层封锁中，封锁了上层节点就意味着封锁了所有内层节点。如果有事务T1对某元组加了S锁，而事务T2对该元组所在的关系加了X锁，因而隐含地X
6、封锁了该元组，从而造成矛盾 引入意向锁I（Intend）：当为某节点加上I锁，表明其某些内层节点已发生事实上的封锁，防止其它事务再去显式封锁该节点 I锁的实施是从封锁层次的根开始，依次占据路径上的所有节点，直至要真正进行显式封锁的节点的父节点为止,封锁粒度,相容矩阵,封锁粒度,IS锁 如果对一个数据对象加IS锁，表示它的后裔节点拟（意向）加S锁 例如，要对元组加S锁，则首先要对关系和数据库加IS锁 IX锁 如果对一个数据对象加IX锁，表示它的后裔节点拟（意向）加X锁 例如，要对元组加X锁，则首先要对关系和数据库加IX锁,封锁粒度,更精细的相容矩阵,封锁粒度,SIX锁 如果对一个数据对象加SIX
7、锁，表示对它加S锁，再加IX锁 例如对某个表加SIX锁，则表示该事务要读整个表（对该表加S锁），同时会更新个别元组（对该表加IX锁）,封锁粒度,更精细的相容矩阵,SQL Server中的锁类型,SQL Server中的锁类型,架构稳定性 (Sch-S) 锁与除了架构修改 (Sch-M) 锁模式之外的所有锁模式相兼容。 架构修改 (Sch-M) 锁与所有锁模式都不兼容。 大容量更新 (BU) 锁只与架构稳定性 (Sch-S) 锁及其它大容量更新 (BU) 锁相兼容。,键范围锁定,键范围锁定原理 键范围锁定原理解决了幻像读并发问题 键范围锁覆盖单个记录以及记录之间的范围，可以防止对事务访问的记录集
8、进行幻像插入或删除 键范围锁通过覆盖索引行和索引行之间的范围来工作（而不是锁定整个基础表的行）。因为第二个事务在该范围内进行任何行插入、更新或删除操作时均需要修改索引，而键范围锁覆盖了索引项，所以在第一个事务完成之前会阻塞第二个事务的进行,键范围锁定,键范围锁模式 键范围锁包括范围组件和行组件，范围表示保护两个连续索引项之间的范围的锁模式，行表示保护索引项的锁模式 键范围锁模式由两部分组成。第一部分表示用于锁定索引范围 (RangeT) 的锁类型，第二部分表示用于锁定特定键 (K) 的锁类型。这两部分用下划线 (_) 连接，如 RangeT_K,键范围锁定,键范围锁模式兼容性矩阵,键范围锁定,
9、键范围锁定,范围扫描查询 为了确保范围扫描查询是可串行的，每次在同一事务中执行的相同查询应返回同样的结果。其它事务不能在范围扫描查询中插入新行，否则这些插入将成为幻像插入 SELECT name FROM mytable WHERE name BETWEEN A AND C 键范围锁放置在与数据行范围（名称在值 Adam 和 Dale 之间的行）对应的索引项上，以防止添加或删除满足上述查询条件的新行。虽然此范围中的第一个名称是 Adam，但是此索引项的 RangeS_S 确保了以字母 A 开头的新名称（如 Abigail）不能添加在 Adam 之前。同样，Dale索引项的RangeS_S确保了
10、以字母C开头的新名称（如 Clive）不能添加在 Carlos 之后 RangeS_S 锁数量为 n+1，此处 n 是满足查询条件的行数,键范围锁定,单独提取不存在数据 如果事务中的查询试图选择不存在的行，则以后在相同的事务中发出这一查询时，必须返回相同的结果。不允许其它事务插入不存在的行 SELECT name FROM mytable WHERE name = Bill键范围锁放置在对应于名称范围 Ben 到 Bing 之间的索引项上，因为名称 Bill 将插入到这两个相邻的索引项之间。RangeS_S 模式键范围锁放置在索引项 Bing 上。这样可以防止任何其它事务在索引项 Ben 和
11、Bing 之间插入值（如 Bill）,键范围锁定,删除操作 在事务中删除值时，在事务执行删除操作期间不必锁定值所属的范围。锁定删除的键值直至事务结束 DELETE mytable WHERE name = Bob排它 (X) 锁放置在对应于名称 Bob 的索引项上。其它事务可以在删除值 Bob 的前后插入或删除值。但是任何试图读取、插入或删除值 Bob 的事务将被阻塞，直到删除的事务提交或回滚为止,键范围锁定,插入操作 在事务中插入值时，在事务执行插入操作期间不必锁定值所属的范围。锁定插入的键值直至事务结束 INSERT mytable VALUES (Dan)RangeI_N 模式键范围锁放
12、置在对应于名字David的索引项上以测试范围。如果已授权锁定，则插入Dan，并且排它 (X) 锁放置在值Dan上。RangeI_N仅对测试范围必需，而不在执行插入操作的事务期间保留。其它事务可以在Dan的前后插入或删除值。任何试图读取、插入或删除值Dan的事务将被阻塞，直到插入的事务提交或回滚为止,锁的实现,read(D)if Ti 持有D上的锁thenread(D)elsebegin 如果需要，等待直到没有其它事务在D上的X锁授予Ti D上的S锁 read(D) end,锁的实现,write(D)if Ti 持有D上的X锁then write(D)else begin 如果需要，等待直到没有
13、其它事务在D上的任何锁如果Ti D持有D上的S锁then upgrade(D)else 授予Ti D上的X锁 write(D) end,锁的实现,锁管理器 事务向锁管理器发送封锁的申请和释放请求 锁管理器维护一个锁表记录锁的授予情况和处于等待状态的封锁请求 锁表 锁表一般作为内存中的hash表，按被封锁对象的名字建立索引,锁的实现,黑矩形表示已被授予的锁，白色表示等待的封锁请求 锁表同时记录锁的类型 新的封锁请求加到对应请求队列的末尾，当封锁请求与前面的锁相容时被批注 释放封锁时请求从队列中删除并检查后续请求是否满足 如果事务放弃，所有授予的和等待的锁请求都被删除 为提高效率，锁管理器会记录每
14、个事务持有锁的情况,锁的实现,如何看待锁 封锁资源 表 “Authors”、页面 23、码为“23812”的元组 锁管理器对资源一无所知,它只是 “memcmp()”,325658,5,Object ID,2:328,6,File#: Page#,2:328:11,9,File#: Page#: Slot on Page,5,5,5,锁的实现,RID： 8字节(File#, Page#, Slot#) 除非删除或移到其他地方，否则RID保持不变；如果删除元组，RID可以重用 RID可以作为封锁资源,固定的RID,聚集索引,聚集索引 行可以由唯一的聚集码标识 聚集码可以作为封锁资源,二级索引 码
15、和位置可以作为封锁资源,锁的实现,Read committed 锁在读完即刻释放，下次读取可能会遇到修改或删除的元组,Repeatable read 被读取的元组锁一直保持，下次读取可能会遇到插入的元组,Repeatable read 被读取的元组以及扫描的范围锁一直保持，避免往扫描范围内插元组,锁的实现,锁升级,行锁代价高、并发度高 表锁代价低、并发度低,锁升级,锁升级 锁升级是将众多细粒度锁转换为较少的粗粒度的锁的过程，以削减系统开销 当事务超过它的升级极限时，系统自动将行锁和页锁升级为表锁 例如，当事务从表中请求行时，系统获取受影响的行上的锁，并在包含这些行的页和表或者索引上放置更高级别
16、的意向锁。当事务控制的锁数量超过了它的极限时，系统将表上的意向锁更改为更强的锁（例如，将意向排它 (IX) 锁更改为排它 (X) 锁）。获取更强的锁后，表事务持有的所有页级锁和行级锁都被释放，从而削减锁的开销,死锁(Deadlock),两个事务都封锁了一些数据对象，并相互等待对方释放另一些数据对象以便对其封锁，结果两个事务都不能结束，则发生死锁,死锁,死锁,遵从两段锁协议仍可能发生死锁,lock-S(A);lock-X(B); wait.,lock-S(B)lock-X(A) wait,T1,T2,T1: lock-S(A)lock-S(B)unlock(A)unlock(B),T2: loc
17、k-S(A)lock-S(B)unlock(A)unlock(B),死锁,死锁发生的条件 互斥条件：事务请求对资源的独占控制 等待条件：事务已持有一定资源，又去申请并等待其它资源 非抢占条件：直到资源被持有它的事务释放之前，不可能将该资源强制从持有它的事务夺去 循环等待条件：存在事务相互等待的等待圈,死锁,定理：在条件 成立的前提下，条件是死锁存在的充分必要条件,R2,R1,R3,解决死锁的方法,预防死锁 预先占据所需的全部资源，要么一次全部封锁要么全不封锁缺点：难于预知需要封锁哪些数据并且数据使用率低 所有资源预先排序，事务按规定顺序封锁数据 使用抢占与事务回滚，给每个事务分配一个时间戳，若
18、事务T2所申请的锁已经被T1持有，可以比较T1与T2的时间戳，来决定是否回滚T1，并将T1释放的锁授予T2,解决死锁的方法,死锁检测和恢复 超时法如果等待封锁的时间超过限时，则撤消该事务 等待图法,活锁(live lock),可能存在某个事务永远处于等待状态，得不到执行，称之为活锁（饿死） T2持有对R的S锁，T1申请对R的X锁，则T1必须等待T2释放S锁；若在T2完成之前有T3申请对R的S锁，则可以获得授权封锁，于是T1必须等待T2、T3释放S锁 避免活锁的策略是遵从“先来先服务”的原则，按请求封锁的顺序对各事务排队；当事务Ti对数据项R加M型锁时，获得封锁的条件是 不存在在R上持有与M型锁
19、冲突的锁的其他事务 不存在等待对R加锁且先于Ti申请加锁的事务,数据库故障,事务故障 指事务的运行没有到达预期的终点就被终止 非预期故障 不能由事务程序处理的 如运算溢出，发生死锁而被选中撤消该事务 可预期故障 应用程序可以发现的事务故障，并且应用程序可以让事务回滚 如转帐时发现帐面金额不足,数据库故障,系统故障 软故障(soft crash)：在硬件故障、软件错误的影响下，虽引起内存信息丢失，但未破坏外存中数据 如CPU故障、突然停电，DBMS, OS, 应用程序等异常终止 介质故障 硬故障(hard crash)：又称磁盘故障，破坏外存上的数据库，并影响正在存取这部分数据的所有事务 如磁盘
20、的磁头碰撞、瞬时的强磁场干扰,数据库恢复,恢复的定义 恢复是把数据库从错误状态恢复到某一正确状态的功能，从而确保数据库的一致性 恢复的基本原理是冗余，即数据库中任一部分的数据可以根据存储在系统别处的冗余数据来重建,数据库恢复,转储 将数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据称为后备（后援）副本 静态转储 转储期间不允许对数据库进行任何存取、修改活动 动态转储 转储期间允许对数据库进行存取或修改 海量转储 每次转储全部数据库 增量转储 每次只转储上次转储后更新过的数据,分析可用性和恢复要求,帮助分析可用性和恢复要求的基本问题 您的可用性要求是什么？每天的什么时间数据库必须处于
21、联机状态？ 服务器故障时间将对公司造成多大的经济损失？ 如果遇到媒体故障，如磁盘驱动器发生故障，可接受的故障时间是多长？ 一旦发生灾难，如因火灾丢失服务器，可接受的故障时间是多长？ 不丢失任何更改的重要程度如何？ 重新创建丢失的数据的难易程度如何？ 单位是否雇用系统或数据库管理员？ 谁将对执行备份和恢复操作负责，如何培训这些人？,备份分析可用性和恢复要求,帮助选择适合站点的工具、技术和硬件 每个数据库多大？ 每个数据库内的数据更改是否频繁？ 有些表是否比其它表修改得频繁？ 何时为关键数据库生产周期？ 什么时候大量使用数据库，导致频繁的插入和更新操作？ 事务日志空间消耗是否由于大量的更新活动而可
22、能是一个问题？ 数据库是否受限于定期的大容量数据装载？ 数据库是否遭受可能不会立即检测到的危险更新和应用程序错误？ 数据库是否在集中管理的多服务器环境中？,备份策略,数据库备份 数据库备份创建备份完成时数据库内存在的数据的副本，通常按常规时间间隔调度 还原数据库备份将重新创建数据库和备份完成时数据库中存在的所有相关文件。但是，自创建备份后所做的任何数据库修改都将丢失,USE master EXEC sp_addumpdevice disk, MyBKDB,DISK =c:MyBKDB.dat BACKUP DATABASE LJCHEN TO MyBKDB RESTORE DATABASE L
23、JCHEN FROM MyBKDB,备份策略,差异数据库备份 差异数据库备份只记录自上次数据库备份后发生更改的数据，比数据库备份小而且备份速度快 使用差异数据库备份将数据库还原到差异数据库备份完成时的那一点,BACKUP DATABASE LJCHEN TO MyBKDB WITH INIT BACKUP DATABASE LJCHEN TO MyBKDB WITH DIFFERENTIAL RESTORE DATABASE LJCHEN FROM MyBKDB WITH NORECOVERY RESTORE DATABASE LJCHEN FROM MyBKDBWITH FILE = 2,R
24、ECOVERY,备份策略,事务日志备份 事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录，它可以将数据库恢复到特定的即时点或恢复到故障点 截断事务日志：在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务，在恢复过程中不再使用。这些截断的非活动空间将被重新使用,BACKUP LOG LJCHEN TO MyBKDB RESTORE LOG LJCHEN FROM MyBKDB WITH RECOVERY,恢复模型,简单恢复 允许将数据库恢复到最新的备份 数据库备份+差异备份（可选） 完全恢复 允许将数据库恢复到故障点状态 数据库备份+差异备份（
25、可选）+事务日志备份 大容量日志记录恢复 允许大容量日志记录操作（SELECT INTO，bcp， BULK INSERT） 数据库备份+差异备份（可选）+事务日志备份,数据库恢复,日志 日志文件是以事务为单位用来记录数据库的每一次更新活动的文件，由系统自动记录 日志内容包括：记录名、旧记录值、新记录值、事务标识符、操作标识符等 事务Ti开始时，写入日志： 事务Ti执行write(X)前，写入日志：，V1 是X更新前的值，V2 是X更新后的值 事务Ti结束后，写入日志：,数据库恢复,T0: read (A) T1 : read (C)A: - A - 50 C:- C- 100Write (A
26、) write (C)read (B)B:- B + 50write (B),(a),(b),(c),数据库恢复,先写日志的原则（WAL）(运行记录优先原则） 对于尚未提交的事务，在将DB缓冲区写到外存之前，必须先将日志缓冲区内容写到外存去 如果先写DB，则可能在写的中途发生系统崩溃，导致内存缓冲区内容丢失，而外存DB处于不一致状态，由于日志缓冲区内容已破坏，导致无法对DB恢复 日志记录将要发生何种修改 写入DB表示实际发生何种修改,数据库恢复,事务分类 圆满事务 日志文件中记录了事务的commit标识 夭折事务 日志文件中只有事务的Begin transaction标识，无commit,数据
27、库恢复,基本的恢复操作： 对圆满事务所做过的修改操作应执行redo操作，即重新执行该操作，修改对象被赋予新记录值redo=redo2 对夭折事务所做过的修改操作应执行undo操作，即撤消该操作，修改对象被赋予旧记录值undo=undo2,数据库恢复,事务故障恢复 撤消事务已对数据库所做的修改 措施 反向扫描日志文件，查找该事务的更新操作 对该事务的更新操作执行逆操作，即将事务更新前的旧值写入数据库 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理 如此处理下去，直至读到此事务的开始标识，事务的故障恢复就完成了,数据库恢复,系统故障恢复 不一致状态原因 未完成事务对数据库的更新已写入
28、数据库 已提交事务对数据库的更新未写入数据库 措施 正向扫描日志文件，找出圆满事务，记入重做队列；找出夭折事务，记入撤消队列 对撤消队列中各个事务进行UNDO处理 对重做队列中各个事务进行REDO处理,数据库恢复,介质故障恢复 磁盘上数据文件和日志文件遭到破坏 措施 装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态 装入相应的日志文件副本，重做已完成的事务,Ta,Tb,Tf,正常运行,介质故障恢复,转储,运行事务,故障发生点,重装后援副本,利用日志文件恢复事务,继续运行,检查点(Checkpoint),作用 避免故障恢复时扫描整个日志文件 避免redo2 检查点技术 在日志文
29、件中增加检查点记录 增加重新开始文件 记录各个检查点记录在日志文件中的地址,检查点,带有检查点记录的日志生成 将当前日志缓冲区的所有日志记录写入稳存中 在日志文件中写入一个检查点记录 将当前数据缓冲区的所有数据记录写入稳存中 把检查点记录在日志文件中的地址写入重新开始文件,事务日志物理构架,每个物理日志文件分成许多虚拟日志文件 虚拟日志文件的大小或数量不能由管理员配置或设置，而是由 SQL Server 代码动态确定 事务日志是回绕的日志文件。当创建数据库时，逻辑日志文件从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末端增长 当逻辑日志的末端到达物理日志文件的
30、末端时，新的日志记录绕回物理日志文件的始端。这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端,事务日志物理构架,从 MinLSN 到日志末端的日志文件部分称为日志的活动部分。这是进行数据库完全恢复所需的日志部分 永远不能截断活动日志的任何部分。所有的日志截断都必须从 MinLSN 之前的日志部分进行 截断操作发生时，删除最小恢复日志序号（MinLSN）之前的虚拟日志内的记录,事务日志物理构架,虚拟日志1,虚拟日志2,虚拟日志3,虚拟日志4,虚拟日志5,被截断,未使用,逻辑日志 的始端,逻辑日志 的末端,MinLSN,最后一个 检查点,虚拟日志1,虚拟日志2,虚拟日志3,虚拟日志4,被截
31、断,逻辑日志 的始端,逻辑日志 的末端,MinLSN,最后一个 检查点,倒数第二 个检查点,检查点,检查点执行过程 将标记检查点起点的记录写入日志文件 将为检查点记录的信息存储在检查点日志记录链内。将这条链起点的 LSN 写入数据库根页 记录在检查点记录中的一条信息是MinLSN 在检查点记录中的另一条信息是所有未完成的活动事务的列表 如果数据库使用的是简单恢复模式，则删除新的 MinLSN 之前的所有日志记录 将所有脏日志和数据页写入磁盘 将标记检查点末端的记录写入日志文件,检查点,最小恢复 LSN (MinLSN)，它是下面这些 LSN 中的最小 LSN： 检查点起点的 LSN 最旧的活动事务起点的 LSN检查点的生成 检查点由系统自动。自动检查点的时间间隔基于日志内的记录数而非时间,
