事务处理办法-锁讲义

事务处理办法-锁讲义提纲并发控制基于锁的协议两段锁协议多粒度封锁带来的问题恢复故障日志恢复封锁的定义封锁就是一个事务对某个数据对象加锁，取得对它一定的控制，限制其它事务对该数据对象使用要访问一个数据项R，事务Ti必须先申请对R的封锁，如果R已经被事务Tj加了不相容的锁，则Ti需要等待，直至Tj释放它的封锁封锁的类型排它锁（X锁，eXclusivelock）事务T对数据对象R加上X锁，则其它事务对R的任何封锁请求都不能成功，直至T释放R上的X锁；又称写锁申请对R的排它锁：lock-X(R)共享锁（S锁，Sharelock）事务T对数据对象R加上S锁，则其它事务对R的X锁请求不能成功，而对R的S锁请求可以成功；又称读锁申请对R的共享锁：lock-S(R)封锁的相容矩阵不相容请求相容请求两阶段封锁协议Two-PhaseLockingProtocol两阶段封锁协议内容增长阶段(GrowingPhase)事务可以获得锁，但不能释放锁缩减阶段(ShrinkingPhase)事务可以释放锁，但不能获得锁示例

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，则ti<tj若{T0,T1,…,Tn}不可串行化，则在优先图中存在环，不妨设为T0T1…TnT0，则t0<t1<…<tn<t0，矛盾两阶段封锁协议保持到事务结束时才释放的锁称作长锁在事务中途就可以释放的锁称作短锁发生级联回滚BEGIN短X锁短S锁EOT两阶段封锁+短X锁+短S锁严格两阶段封锁协议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:=A1;write(A)；commit；T1T2不能保证可重复读BEGIN

短S锁长X锁EOT两阶段封锁+长X锁+S锁强两阶段封锁协议BEGIN

长S锁长X锁EOT长X锁+长S锁锁转换带有锁转换的两段锁协议增长阶段可获得lock-S可获得lock-X可将lock-S升级为lock-X(upgrade)缩减阶段可释放lock-S可释放lock-X可将lock-X降级为lock-S(downgrade)封锁方法直接封锁事务对它要进行存取的数据对象直接申请加锁封锁方法分层封锁数据对象从大到小有一种层次关系，当封锁了外层数据对象时也就意味着同时封锁了它的所有内层数据对象数据库段关系元组封锁粒度封锁对象属性值、属性值几何、元组、关系、某索引项、整个索引、整个数据库、物理页、块封锁粒度大，则并发度低，封锁机构简单，开销小 封锁粒度小，则并发度高，封锁机构复杂，开销高理想的情况是只封锁与规定的操作有关的的数据对象，这些数据对象称作事务的完整性相关域SQLServer的封锁粒度封锁粒度意向（预约）封锁在分层封锁中，封锁了上层节点就意味着封锁了所有内层节点。如果有事务T1对某元组加了S锁，而事务T2对该元组所在的关系加了X锁，因而隐含地X封锁了该元组，从而造成矛盾引入意向锁I（Intend）：当为某节点加上I锁，表明其某些内层节点已发生事实上的封锁，防止其它事务再去显式封锁该节点I锁的实施是从封锁层次的根开始，依次占据路径上的所有节点，直至要真正进行显式封锁的节点的父节点为止封锁粒度相容矩阵T1T2ISXI+--S-+-X---封锁粒度IS锁如果对一个数据对象加IS锁，表示它的后裔节点拟（意向）加S锁例如，要对元组加S锁，则首先要对关系和数据库加IS锁IX锁如果对一个数据对象加IX锁，表示它的后裔节点拟（意向）加X锁例如，要对元组加X锁，则首先要对关系和数据库加IX锁封锁粒度更精细的相容矩阵T1T2ISIXSXIS+++-IX++--S+-+-X----封锁粒度SIX锁如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁例如对某个表加SIX锁，则表示该事务要读整个表（对该表加S锁），同时会更新个别元组（对该表加IX锁）封锁粒度ISIXSSIXXISIXSSIXX更精细的相容矩阵SQLServer中的锁类型锁模式描述共享(S)用于不更改或不更新数据的操作（只读操作），如SELECT语句。更新(U)用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生死锁。排它(X)用于数据修改操作，例如INSERT、UPDATE或DELETE。确保不会同时对同一资源进行多重更新。意向用于建立锁的层次结构。意向锁的类型为：意向共享(IS)、意向排它(IX)以及与意向排它共享(SIX)。架构在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改(Sch-M)和架构稳定性(Sch-S)。大容量更新(BU)向表中大容量复制数据并指定了TABLOCK

提示时使用。SQLServer中的锁类型现有的授权模式请求模式ISSUIXSIXX意向共享(IS)是是是是是否共享(S)是是是否否否更新(U)是是否否否否意向排它(IX)是否否是否否与意向排它共享(SIX)是否否否否否排它(X)否否否否否否架构稳定性(Sch-S)锁与除了架构修改(Sch-M)锁模式之外的所有锁模式相兼容。架构修改(Sch-M)锁与所有锁模式都不兼容。大容量更新(BU)锁只与架构稳定性(Sch-S)锁及其它大容量更新(BU)锁相兼容。键范围锁定键范围锁定原理键范围锁定原理解决了幻像读并发问题键范围锁覆盖单个记录以及记录之间的范围，可以防止对事务访问的记录集进行幻像插入或删除键范围锁通过覆盖索引行和索引行之间的范围来工作（而不是锁定整个基础表的行）。因为第二个事务在该范围内进行任何行插入、更新或删除操作时均需要修改索引，而键范围锁覆盖了索引项，所以在第一个事务完成之前会阻塞第二个事务的进行键范围锁定键范围锁模式键范围锁包括范围组件和行组件，范围表示保护两个连续索引项之间的范围的锁模式，行表示保护索引项的锁模式键范围锁模式由两部分组成。第一部分表示用于锁定索引范围(RangeT)的锁类型，第二部分表示用于锁定特定键(K)的锁类型。这两部分用下划线(_)连接，如RangeT_K

范围行模式描述RangeSSRangeS_S共享范围，共享资源锁；可串行范围扫描RangeSURangeS_U共享范围，更新资源锁；可串行更新扫描RangeINULLRangeI_N插入范围，空资源锁；用于在索引中插入新键之前测试范围RangeXXRangeX_X排它范围，排它资源锁；用于更新范围中的键键范围锁定

现有的授权模式请求模式SUXRangeS_SRangeS_URangeI_NRangeX_X共享(S)是是否是是是否更新(U)是否否是否是否排它(X)否否否否否是否RangeS_S是是否是是否否RangeS_U是否否是否否否RangeI_N是是是否否是否RangeX_X否否否否否否否键范围锁模式兼容性矩阵键范围锁定键范围锁定范围扫描查询为了确保范围扫描查询是可串行的，每次在同一事务中执行的相同查询应返回同样的结果。其它事务不能在范围扫描查询中插入新行，否则这些插入将成为幻像插入SELECTnameFROMmytableWHEREnameBETWEEN'A'AND'C'

键范围锁放置在与数据行范围（名称在值Adam和Dale之间的行）对应的索引项上，以防止添加或删除满足上述查询条件的新行。虽然此范围中的第一个名称是Adam，但是此索引项的RangeS_S确保了以字母A开头的新名称（如Abigail）不能添加在Adam之前。同样，Dale索引项的RangeS_S确保了以字母C开头的新名称（如Clive）不能添加在Carlos之后RangeS_S锁数量为n+1，此处n

是满足查询条件的行数键范围锁定单独提取不存在数据如果事务中的查询试图选择不存在的行，则以后在相同的事务中发出这一查询时，必须返回相同的结果。不允许其它事务插入不存在的行SELECTnameFROMmytableWHEREname='Bill'

键范围锁放置在对应于名称范围Ben到Bing之间的索引项上，因为名称Bill将插入到这两个相邻的索引项之间。RangeS_S模式键范围锁放置在索引项Bing上。这样可以防止任何其它事务在索引项Ben和Bing之间插入值（如Bill）键范围锁定删除操作在事务中删除值时，在事务执行删除操作期间不必锁定值所属的范围。锁定删除的键值直至事务结束DELETEmytableWHEREname='Bob'

排它(X)锁放置在对应于名称Bob的索引项上。其它事务可以在删除值Bob的前后插入或删除值。但是任何试图读取、插入或删除值Bob的事务将被阻塞，直到删除的事务提交或回滚为止键范围锁定插入操作在事务中插入值时，在事务执行插入操作期间不必锁定值所属的范围。锁定插入的键值直至事务结束INSERTmytableVALUES('Dan') RangeI_N模式键范围锁放置在对应于名字David的索引项上以测试范围。如果已授权锁定，则插入Dan，并且排它(X)锁放置在值Dan上。RangeI_N仅对测试范围必需，而不在执行插入操作的事务期间保留。其它事务可以在Dan的前后插入或删除值。任何试图读取、插入或删除值Dan的事务将被阻塞，直到插入的事务提交或回滚为止锁的实现read(D)ifTi持有D上的锁

then read(D) else begin

如果需要，等待直到没有其它 事务在D上的X锁 授予TiD上的S锁

read(D) end锁的实现write(D)ifTi持有D上的X锁

then write(D) else begin

如果需要，等待直到没有其它 事务在D上的任何锁 如果TiD持有D上的S锁

then upgrade(D) else 授予TiD上的X锁

write(D) end锁的实现锁管理器事务向锁管理器发送封锁的申请和释放请求锁管理器维护一个锁表记录锁的授予情况和处于等待状态的封锁请求锁表锁表一般作为内存中的hash表，按被封锁对象的名字建立索引锁的实现黑矩形表示已被授予的锁，白色表示等待的封锁请求锁表同时记录锁的类型新的封锁请求加到对应请求队列的末尾，当封锁请求与前面的锁相容时被批注释放封锁时请求从队列中删除并检查后续请求是否满足如果事务放弃，所有授予的和等待的锁请求都被删除为提高效率，锁管理器会记录每个事务持有锁的情况锁的实现如何看待锁封锁资源表“Authors”、页面23、码为“23812”的元组锁管理器对资源一无所知,它只是“memcmp()”资源类型资源详细数据数据库ID锁资源格式3256585ObjectID2:3286File#:Page#2:328:119File#:Page#:SlotonPage555锁的实现RID：

8字节(File#,Page#,Slot#)除非删除或移到其他地方，否则RID保持不变；如果删除元组，RID可以重用RID可以作为封锁资源固定的RID聚集索引聚集索引行可以由唯一的聚集码标识聚集码可以作为封锁资源二级索引码位置指针(RID或聚集索引)二级索引码和位置可以作为封锁资源锁的实现3467910141346346734691014143734634679101413467Readcommitted锁在读完即刻释放，下次读取可能会遇到修改或删除的元组Repeatableread被读取的元组锁一直保持，下次读取可能会遇到插入的元组Repeatableread被读取的元组以及扫描的范围锁一直保持，避免往扫描范围内插元组锁的实现Adams66Lewis1Smith11码位置(聚集索引)聚集索引1LewisDanAdamsKim11SmithKen......6Adams6Hash0x033807FF9B2CAdamsAdams锁升级LockingcostConcurrencycostRowPageTableCost行锁代价高、并发度高表锁代价低、并发度低锁升级锁升级锁升级是将众多细粒度锁转换为较少的粗粒度的锁的过程，以削减系统开销当事务超过它的升级极限时，系统自动将行锁和页锁升级为表锁例如，当事务从表中请求行时，系统获取受影响的行上的锁，并在包含这些行的页和表或者索引上放置更高级别的意向锁。当事务控制的锁数量超过了它的极限时，系统将表上的意向锁更改为更强的锁（例如，将意向排它(IX)锁更改为排它(X)锁）。获取更强的锁后，表事务持有的所有页级锁和行级锁都被释放，从而削减锁的开销死锁(Deadlock)两个事务都封锁了一些数据对象，并相互等待对方释放另一些数据对象以便对其封锁，结果两个事务都不能结束，则发生死锁死锁--

Connection

1--

Connection

2USE

pubsWHILE

(1=1)BEGINBEGIN

TRANUPDATE

employeeSET

lname='Smith‘WHERE

emp_id='PMA42628M‘UPDATE

authorsSET

au_lname='Jones'

WHERE

au_id='172-32-1176‘COMMIT

TRANENDUSE

pubsWHILE

(1=1)BEGINBEGIN

TRANUPDATE

authorsSET

au_lname='Jones'

WHERE

au_id='172-32-1176‘UPDATE

employeeSET

lname='Smith'

WHERE

emp_id='PMA42628M‘COMMIT

TRANEND

死锁遵从两段锁协议仍可能发生死锁lock-S(A);lock-X(B);wait…...lock-S(B)lock-X(A)wait……T1T2T1:lock-S(A)…lock-S(B)…unlock(A)…unlock(B)T2:lock-S(A)…lock-S(B)…unlock(A)…unlock(B)死锁死锁发生的条件①互斥条件：事务请求对资源的独占控制②等待条件：事务已持有一定资源，又去申请并等待其它资源③非抢占条件：直到资源被持有它的事务释放之前，不可能将该资源强制从持有它的事务夺去④循环等待条件：存在事务相互等待的等待圈死锁定理：在条件①②③成立的前提下，条件④是死锁存在的充分必要条件R2R1R3解决死锁的方法预防死锁预先占据所需的全部资源，要么一次全部封锁要么全不封锁 缺点：难于预知需要封锁哪些数据并且数据使用率低所有资源预先排序，事务按规定顺序封锁数据使用抢占与事务回滚，给每个事务分配一个时间戳，若事务T2所申请的锁已经被T1持有，可以比较T1与T2的时间戳，来决定是否回滚T1，并将T1释放的锁授予T2解决死锁的方法死锁检测和恢复超时法 如果等待封锁的时间超过限时，则撤消该事务等待图法活锁(livelock)可能存在某个事务永远处于等待状态，得不到执行，称之为活锁（饿死）T2持有对R的S锁，T1申请对R的X锁，则T1必须等待T2释放S锁；若在T2完成之前有T3申请对R的S锁，则可以获得授权封锁，于是T1必须等待T2、T3释放S锁避免活锁的策略是遵从“先来先服务”的原则，按请求封锁的顺序对各事务排队；当事务Ti对数据项R加M型锁时，获得封锁的条件是不存在在R上持有与M型锁冲突的锁的其他事务不存在等待对R加锁且先于Ti申请加锁的事务数据库故障事务故障指事务的运行没有到达预期的终点就被终止非预期故障不能由事务程序处理的如运算溢出，发生死锁而被选中撤消该事务可预期故障应用程序可以发现的事务故障，并且应用程序可以让事务回滚如转帐时发现帐面金额不足数据库故障系统故障软故障(softcrash)：在硬件故障、软件错误的影响下，虽引起内存信息丢失，但未破坏外存中数据如CPU故障、突然停电，DBMS,OS,应用程序等异常终止介质故障硬故障(hardcrash)：又称磁盘故障，破坏外存上的数据库，并影响正在存取这部分数据的所有事务如磁盘的磁头碰撞、瞬时的强磁场干扰数据库恢复恢复的定义恢复是把数据库从错误状态恢复到某一正确状态的功能，从而确保数据库的一致性恢复的基本原理是冗余，即数据库中任一部分的数据可以根据存储在系统别处的冗余数据来重建数据库恢复转储将数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据称为后备（后援）副本静态转储转储期间不允许对数据库进行任何存取、修改活动动态转储转储期间允许对数据库进行存取或修改海量转储每次转储全部数据库增量转储每次只转储上次转储后更新过的数据分析可用性和恢复要求帮助分析可用性和恢复要求的基本问题您的可用性要求是什么？每天的什么时间数据库必须处于联机状态？服务器故障时间将对公司造成多大的经济损失？如果遇到媒体故障，如磁盘驱动器发生故障，可接受的故障时间是多长？一旦发生灾难，如因火灾丢失服务器，可接受的故障时间是多长？不丢失任何更改的重要程度如何？重新创建丢失的数据的难易程度如何？单位是否雇用系统或数据库管理员？谁将对执行备份和恢复操作负责，如何培训这些人？备份分析可用性和恢复要求帮助选择适合站点的工具、技术和硬件每个数据库多大？每个数据库内的数据更改是否频繁？有些表是否比其它表修改得频繁？何时为关键数据库生产周期？什么时候大量使用数据库，导致频繁的插入和更新操作？事务日志空间消耗是否由于大量的更新活动而可能是一个问题？数据库是否受限于定期的大容量数据装载？数据库是否遭受可能不会立即检测到的危险更新和应用程序错误？数据库是否在集中管理的多服务器环境中？备份策略数据库备份数据库备份创建备份完成时数据库内存在的数据的副本，通常按常规时间间隔调度还原数据库备份将重新创建数据库和备份完成时数据库中存在的所有相关文件。但是，自创建备份后所做的任何数据库修改都将丢失USEmasterEXECsp_addumpdevice'disk',‘MyBKDB', DISK='c:\MyBKDB.dat'BACKUPDATABASELJCHENTOMyBKDBRESTOREDATABASELJCHENFROMMyBKDB备份策略差异数据库备份差异数据库备份只记录自上次数据库备份后发生更改的数据，比数据库备份小而且备份速度快使用差异数据库备份将数据库还原到差异数据库备份完成时的那一点BACKUPDATABASELJCHENTOMyBKDBWITHINITBACKUPDATABASELJCHENTOMyBKDBWITHDIFFERENTIALRESTOREDATABASELJCHENFROMMyBKDB WITHNORECOVERYRESTOREDATABASELJCHENFROMMyBKDB WITHFILE=2,RECOVERY备份策略事务日志备份事务日志是自上次备份事务日志后对数据库执行的所有事务的一系列记录，它可以将数据库恢复到特定的即时点或恢复到故障点截断事务日志：在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务，在恢复过程中不再使用。这些截断的非活动空间将被重新使用BACKUPLOGLJCHENTOMyBKDBRESTORELOGLJCHENFROMMyBKDBWITHRECOVERY恢复模型简单恢复允许将数据库恢复到最新的备份数据库备份+差异备份（可选）完全恢复允许将数据库恢复到故障点状态数据库备份+差异备份（可选）+事务日志备份大容量日志记录恢复允许大容量日志记录操作（SELECTINTO，bcp，

BULKINSERT）数据库备份+差异备份（可选）+事务日志备份数据库恢复日志日志文件是以事务为单位用来记录数据库的每一次更新活动的文件，由系统自动记录日志内容包括：记录名、旧记录值、新记录值、事务标识符、操作标识符等事务Ti开始时，写入日志：<Tistart>事务Ti执行write(X)前，写入日志：<Ti,X,V1,V2>，V1

是X更新前的值，V2

是X更新后的值事务Ti结束后，写入日志：<Ti

commit>数据库恢复T0:read(A) T1

:read(C) A:-A-50

C:-C-100 Write(A) write(C) read(B) B:-B+50 write(B)<T0

start><T0

A,1000,950><T0,B,2000,2050><T0start><T0,A,1000,950><T0,

B,2000,2050><T0

commit><T1start><T1,C,700,600><T0start><T0,A,1000,950><T0,B,2000,2050><T0commit><T1start><T1,C,700,600><T1commit>(a)(b)(c)数据库恢复先写日志的原则（WAL）(运行记录优先原则）对于尚未提交的事务，在将DB缓冲区写到外存之前，必须先将日志缓冲区内容写到外存去如果先写DB，则可能在写的中途发生系统崩溃，导致内存缓冲区内容丢失，而外存DB处于不一致状态，由于日志缓冲区内容已破坏，导致无法对DB恢复日志记录将要发生何种修改写入DB表示实际发生何种修改数据库恢复事务分类圆满事务日志文件中记录了事务的commit标识夭折事务日志文件中只有事务的Begintransaction标识，无commit数据库恢复基本的恢复操作：对圆满事务所做过的修改操作应执行redo操作，即重新执行该操作，修改对象被赋予新记录值

redo=redo2对夭折事务所做过的修改操作应执行undo操作，即撤消该操作，修改对象被赋予旧记录值

undo=undo2