《事务处理锁》PPT课件.ppt

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