1、第8章 事务管理,事 务 并发控制 恢 复,事 务,事务的概念 事务的性质 SQL对事务的支持 并发事务中的干扰问题 事务的隔离级别,事务的概念,事务是构成单一逻辑工作单元的操作集合。 买卖交易一手交钱一手交货 订票查询、订位、(交钱)、出票（往返票？） 转帐转出、转入,为什么需要事务的概念呢？,恢复的需要 并发操作的需要 买卖交易一手交钱一手交货 订票查询、订位、(交钱)、出票（往返票？） 转帐转出、转入,James Gray1998年获得图灵奖,在数据库技术、特别是事务处理方面做出了杰出贡献。 解决了诸如完整性、安全性、并发控制等一系列技术难题。,事 务,事务的概念 事务的性质 SQL对事
2、务的支持 并发事务中的干扰问题 事务的隔离级别,事务的性质,原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability）,事务的这些性质通常称为ACID特性,原子性,事务的原子性强调了一个事务是一个逻辑工作单元，是一个整体，是不可分割的。一个事务所包含的操作要么全部做，要么全部不做。 买卖交易一手交钱一手交货 订票查询、订位、(交钱)、出票（往返票？） 转帐转出、转入,事务的性质,原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability）,事务的这些性质通常称为AC
3、ID特性,一致性,一个事务执行一项数据库操作，事务将使数据库从一种一致性的状态变换成另一种一致性状态。 在事务执行前，总是假设数据库是一致的，那么当事务成功执行后，数据库肯定仍然是一致的。 买卖交易一手交钱一手交货 订票查询、订位、(交钱)、出票（往返票？） 转帐转出、转入（帐目平衡）,事务的性质,原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability）,事务的这些性质通常称为ACID特性,隔离性,如果每个事务单独执行能保持原子性和一致性，这些事务并发执行也能保持原子性和一致性，则是事务的隔离性。 并发记帐？,事务的性质,原子
4、性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability）,事务的这些性质通常称为ACID特性,持久性,事务的持久性是指一旦事务成功完成，该事务对数据库所施加的所有更新都是永久的。 在ATM取钱后银行系统突然发生故障？,ACID性质DBMS的功能,如果让用户程序来实现结果会怎样？,事务的生命周期,事务的结束提交(Commit)或者撤销(Rollback) 事务在活动中的状态 活动状态事务初始时 部分提交状态命令执行完、但未提交 失败状态发现正常操作不能进行 撤销状态撤销事务，恢复到事务前的状态 提交状态成功完成后,事务的生命周期,命
5、令执行完只要事务没有提交事务就没有结束，还有可能转变到失败状态。,活动状态,失败状态,提交状态,撤销状态,部分提交状态,事 务,事务的概念 事务的性质 SQL对事务的支持 并发事务中的干扰问题 事务的隔离级别,SQL对事务的支持,开始事务 结束事务 事务保存点 隐含事务与自动提交,开始事务,使用BEGIN TRANSACTION命令显式说明一个事务开始，它说明了对数据库进行操作的一个单元的起始点。在事务完成之前出现任何操作错误和故障，都可以撤销事务，使事务回退到这个起始点。,SQL对事务的支持,开始事务 结束事务 事务保存点 隐含事务与自动提交,结束事务,成功结束事务的命令是COMMIT TR
6、ANSACTION，它的作用是提交或确认事务已经完成，所以该命令也称作事务提交。 撤消事务的命令是ROLLBACK TRANSACTION，即撤消在该事务中对数据库所做的更新操作，使数据库回退到事务的起始点。,SQL对事务的支持,开始事务 结束事务 事务保存点 隐含事务与自动提交,事务保存点,SQL标准还支持“事务保存点”技术，所谓事务保存点就是在事务的过程中插入若干标记，这样当发现事务中有操作错误时，可以不撤消整个事务，只撤消部分事务，即将事务回退到某个事务保存点。,事务保存点,SQL Server支持事务保存点技术，设置保存点的命令是SAVE TRANSACTION，具体格式是：SAVE
7、TRANSACTION savepoint_name 撤消部分事务或回退到事务保存点的命令也是ROLLBACK TRANSACTION，具体格式是：ROLLBACK TRANSACTION savepoint_name,假设有订票事务,每个中间结点都可以当做一个保存点。,北京,西安,成都,兰州,昆明,银川,呼市,北京,SQL对事务的支持,开始事务 结束事务 事务保存点 隐含事务与自动提交,隐含事务与自动提交事务的执行模式,显式事务 隐式事务 自动提交事务,显式事务,用BEGIN TRANSACTION命令开始一个事务 直到用COMMIT或ROLLBACK命令结束事务,隐含事务与自动提交事务的执
8、行模式,显式事务 隐式事务 自动提交事务,隐式事务,当执行如下命令时都会自动开始一个事务 ALTER，INSERT，CREATE，OPEN，DELETE，REVOKE、DROP、SELECT、FETCH、GRANT、UPDATE 直到用COMMIT或ROLLBACK命令结束事务，然后又准备开始一个新的事务。,隐含事务与自动提交事务的执行模式,显式事务 隐式事务 自动提交事务,自动提交事务,每条单独的语句都是一个事务，一条语句执行成功则提交事务，执行失败则撤销事务。,隐含事务与自动提交事务的执行模式,SQL标准规定事务的开始是隐含的，在发出COMMIT（提交事务）或ROLLBACK（撤消事务）命
9、令之前，该事务将一直保持有效。一个事务被提交或撤消之后，又将自动启动下一个新事务。,隐含事务的设置与取消,设置隐含事务方式的命令是：SET IMPLICIT_TRANSACTIONS ON 取消隐含事务方式的命令是：SET IMPLICIT_TRANSACTIONS OFF,隐含事务与自动提交,当是隐含事务方式时，不需要用BEGIN TRANSACTION命令显式的启动或开始一个事务，但需要用COMMIT或ROLLBACK命令结束事务； 当是非隐含事务方式时，如果没有用BEGIN TRANSACTION命令显式的启动或开始一个事务，则每条操作数据库的语句都将作为独立的事务被自动提交或撤消，这时
10、候不需要、也不能执行COMMIT或ROLLBACK命令。,思考题,UPDATE score SET 成绩=成绩 + 5 如果score表有1000条记录，这条语句在完成更新时只有1条记录违背了完整性约束，结果会怎么样？,事 务,事务的概念 事务的性质 SQL对事务的支持 并发事务中的干扰问题 事务的隔离级别,并发事务中的不一致问题,丢失更新问题 未提交依赖问题 不一致分析问题 幻象读问题,丢失更新问题,例： 旅客A来到A售票处，要买一张15日北京到上海的13次直达快速列车的软卧车票，售票员A（下称用户A）在终端A查看剩余票信息； 几乎在同时，旅客B来到B售票处，也要买一张15日北京到上海的13
11、次直达快速列车的软卧车票，售票员B（下称用户B）从终端B查到了同样的剩余票信息； 旅客A买了一张15日13次7车厢5号下铺的软卧票，用户A更新剩余票信息并将它存入数据库； 这时用户B不知道用户A已经将15日13次7车厢5号下铺的软卧票卖出，使旅客B也买了一张15日13次7车厢5号下铺的软卧票，用户B更新剩余票信息并将它存入数据库（重复了用户A已经做过的更新）。,丢失更新问题,例： 旅客A来到A售票处，要买一张15日北京到上海的13次直达快速列车的软卧车票，售票员A（下称用户A）在终端A查看剩余票信息； 几乎在同时，旅客B来到B售票处，也要买一张15日北京到上海的13次直达快速列车的软卧车票，售
12、票员B（下称用户B）从终端B查到了同样的剩余票信息； 旅客A买了一张15日13次7车厢5号下铺的软卧票，用户A更新剩余票信息并将它存入数据库； 这时用户B不知道用户A已经将15日13次7车厢5号下铺的软卧票卖出，使旅客B也买了一张15日13次7车厢5号下铺的软卧票，用户B更新剩余票信息并将它存入数据库（重复了用户A已经做过的更新）。,总的效果：15日13次7车厢5号下铺的软卧票卖了两次。其原因是：允许了用户B在过时的信息基础上去更新数据库，而没有迫使他去看最新的信息。,丢失更新问题,用SQL术语描述丢失更新问题,并发事务中的不一致问题,丢失更新问题 未提交依赖问题 不一致分析问题 幻象读问题,
13、未提交依赖问题,未提交依赖问题也称为读“脏”（Dirty Read）数据问题，查询一个已经被其他事务更新、但尚未提交的元组，将会引起未提交依赖问题。,并发事务中的不一致问题,丢失更新问题 未提交依赖问题 不一致分析问题 幻象读问题,不一致分析问题,不一致分析问题也称为不可重复读问题，很多应用可能需要校验功能，这时往往需要连续两次或多次读数据进行校验和分析，结果由于其他事务的干扰，使得前后结果不一致，从而产生校验错误（即不一致的分析）。,并发事务中的不一致问题,丢失更新问题 未提交依赖问题 不一致分析问题 幻象读问题,幻象读问题,幻象读问题与不一致分析问题有关，当事务A读数据时，事务B在对同一个
14、关系进行插入或删除操作，这时事务A再读同一条件的元组时，会发现神秘地多出了一些元组或丢失了一些元组，把这种现象称作幻象读。,事 务,事务的概念 事务的性质 SQL对事务的支持 并发事务中的干扰问题 事务的隔离级别,隔离级别,隔离性虽然是事务的基本性质之一，但是彻底的隔离意味着并发操作效率的降低。所以人们设想在避免干扰的前提下，适当地降低隔离的级别，从而提高并发的操作效率。隔离级别越低，并发操作的效率越高，但是产生干扰的可能性也越大；隔离级别越高，则并发操作的效率越低，同时产生干扰的可能性也越小。在设计应用时，可以在所能容忍的干扰程度范围内，尽可能的降低隔离级别，从而提高应用的执行效率。,隔离级
15、别,在SQL标准中定义了下列四种隔离级别，SQL Server支持所有这些隔离级别： 未提交读（READ UNCOMMITTED）：事务隔离的最低级别，仅可保证不读取物理损坏的数据，这是四个隔离级别中限制最小的级别。 提交读（READ COMMITTED）：SQL Server默认级别，可以保证不读取“脏”数据。 可重复读（REPEATABLE READ）：可以保证读一致性，避免不一致分析问题。 可串行化（SERIALIZABLE）：事务隔离的最高级别，事务之间完全隔离；如果事务在可串行化隔离级别上运行，则可以保证任何并发重叠事务均是串行的。,隔离级别,四种隔离级别所允许的不同类型的行为,事务
16、必须运行于可重复读或更高的隔离级别才可以防止丢失更新。,隔离级别,设置隔离级别的命令是：SET TRANSACTION ISOLATION LEVEL READ COMMITTED | READ UNCOMMITTED | REPEATABLE READ| SERIALIZABLE ,事务概念小结,什么是事务？ 事务的性质原子性、一致性、隔离性、持久性 SQL对事务的支持显式、隐式、自动提交，有关语句 并发事务中的干扰问题丢失更新、脏读、不一致分析、幻象读 事务的隔离级别未提交读、提交读、可重复读、可串行化,第8章 事务管理,事 务 并发控制 恢 复,并发控制,隔离性是事务的基本特征。在数据库
17、中当有多个事务并发执行时，由于事务之间操作的相互干扰，事务的隔离性可能不能保证，从而导致对数据库一致性的破坏。为了保持事务的隔离性，系统必须能够对并发事务之间的相互作用加以控制，这就是并发控制。,可串行性,可串行性通常看作是多个事务并发执行的正确性准则。具体判定方法如下： 各单个事务如能将数据库从一个正确状态转变为另一个正确状态，则认为该事务是正确的； 按任何一个串行顺序依次执行多个事务也是正确的（这里的串行顺序假定各个事务间彼此独立、不交叉）； 事务的交叉执行过程是正确的，当且仅当其与串行执行过程等价，则事务是可串行化的。 可串行性描述的正是事务的隔离性。,实现隔离性的基本思路,实现隔离性的
18、基本思路,当需要查询或更新数据时，先对数据进行封锁，以避免来自其他事务的干扰，即隔离其他事务。 针对不同的干扰问题可以有不同的封锁机制。 以丢失更新问题为例，实施封锁的基本思想是：当一个用户对一个表或记录进行更新时，封锁该表或记录，使其他用户不能在同一时刻更新相同的表或记录，迫使其他用户在更新后的基础上（而不是在更新前的基础上）再实施另外的更新操作。,封锁的基本思路,实施封锁以后的时间序列,封锁与事务吞吐量,事务吞吐量：单位时间内可以完成的事务数量。 封锁将降低事务吞吐量。 如何在保证事务隔离性的前提下提高事务吞吐量？,如何在保证事务隔离性的前提下提高事务吞吐量,必要的封锁策略。 根据不同的需
19、要采取不同的封锁策略。 4种隔离级别？,如何在保证事务隔离性的前提下提高事务吞吐量,必要的封锁策略。 根据不同的需要采取不同的封锁策略。 4种隔离级别： 未提交读 提交读 可重复读 可串行化 为了达到不同的目的实施不同的封锁。,封锁机制,共享封锁 独占封锁 更新封锁,共享封锁,共享封锁是为读操作设置的一种封锁，所以也称作读封锁，或简称S锁，目的是想读到一组不变的数据，也就是在读数据的过程中，不允许其他用户对该数据进行任何修改操作。这种封锁可以保证最大的并发性，任何数量的用户都可以同时对同样的数据施加这种共享锁。已经实施共享锁的表拒绝来自其他事务的独占封锁和更新封锁。,共享封锁的隔离级别？,独占
20、封锁,独占封锁也叫排他封锁，它是为修改操作设置的一种封锁，也称为写封锁，或简称为X锁，这是最严格的一类封锁。当需要对表实施插入、删除或修改操作时，应该使用独占封锁。已经实施独占封锁的表，拒绝来自其他用户的任何封锁，但不拒绝一般的查询操作。,独占封锁的隔离级别？,共享封锁和独占封锁是基本锁,共享封锁和共享封锁是相容的； 独占封锁与任何封锁均不相容。,更新封锁,当需要对一个记录或一组记录进行更新时（只是修改，不包括插入和删除）使用更新封锁，该封锁的目的是防止其他用户在同一时刻修改同一记录。已经实施更新封锁的记录，拒绝来自其他用户的任何封锁，但不拒绝一般的查询操作。,更新封锁的隔离级别？,封锁粒度,
21、封锁的对象可以是表、也可以是元组等，我们把封锁对象的大小称为封锁粒度（Granularity）。 封锁的对象可以是逻辑单元（如表和元组等），也可以是物理单元（如数据页和数据块等）。 数据库管理系统一般都具有多粒度锁定功能，允许一个事务锁定不同类型的资源。,封锁粒度,锁定在较小的粒度（例如行）可以增加并发操作的性能，但系统开销也较大。这是因为如果封锁的粒度小，则意味着需要的锁多，从而需要系统控制更多的锁。 锁定在较大的粒度（例如表）会降低操作的并发性，这是因为锁定整个表限制了其他事务对表中任意部分进行访问。封锁粒度大，则不需要太多的封锁，由于需要维护的锁较少，所以系统开销较低。,锁的释放,有些封
22、锁在执行完相应操作后就自动释放封锁，有些封锁则保持到事务结束（提交或撤消）时才释放（无论如何，所有的封锁都会在事务结束时自动释放）。,SQL Server中与封锁有关的命令,SQL Server的封锁操作是在相关语句的“WITH ()”子句中完成的，该短语可以在SELECT、INSERT、UPDATE和DELETE等语句中指定表级锁定的方式和范围。,SQL Server中与封锁有关的命令,常用的封锁关键词有： TABLOCK：对表施行共享封锁，在读完数据后立刻释放封锁，此类封锁可以避免读“脏”数据，但不具有可重复读的特性。 HOLDLOCK：与TABLOCK一起使用，可将共享锁保留到事务完成，
23、而不是在读完数据后立即释放锁，这样可以保证数据的可重复独特性。 NOLOCK：不进行封锁，此关键词仅应用于SELECT语句，这样可能会读取未提交事务的数据，即有可能发生“脏”读。 TABLOCKX：对表实施独占封锁。 UPDLOCK：对表中的指定元组实施更新封锁；这时其他事务可以对同一表中的其他元组也实施更新封锁，但是不允许对表实施共享封锁和独占封锁。,举例, DECLARE d datetime, t char(6), s char(2), n char(10) BEGIN TRANSACTION SELECT n=座位号 FROM R WITH (UPDLOCK) WHERE 日期 = d
24、 AND 车次 = t AND 座别 = s AND 状态 IS NULL IF UPDATE R SET 状态 = “Y“ WHERE 座位号 = n AND 日期 = d AND 车次 = t AND 座别 = s COMMIT TRANSACTION ELSE ROLLBACK TRANSACTION ,死锁,封锁不当会产生死锁,产生死锁的原因,右图示意了两个并发事务所发生事件的序列，假设程序A为了完成某个事务需要封锁仓库和职工两个关系，而几乎在同一时刻并发执行的程序B为完成另一个事务也需要封锁职工和仓库关系，这两个程序正好按照如图所示的交错序列执行命令，结果两个程序都为了等待对方释放数
25、据资源而产生死锁。,发生死锁,两个或多个事务等待被封锁资源形成环路时就会发生死锁。,A,B,C,“活锁”,没有发生死锁也有可能某个事务永远处于等待状态,？,“活锁”,T1：事务A共享封锁资源S,成功 T2：事务B试图独占封锁资源S，等待 T3：事务C在A释放封锁S之前，共享封锁S成功 T4：事务D在C释放封锁S之前，共享封锁S成功 结果事务B无限期等待,避免死锁,？,避免死锁,相同顺序法 所有的用户程序约定都按相同的顺序来封锁表 一次封锁法 为了完成一个事务，一次性封锁所需要的全部表 两阶段封锁协议 所有事务都必须将对数据的封锁分为封锁和释放两个阶段,避免死锁的封锁,两阶段封锁协议,第一阶段称
26、为扩展阶段，这一阶段获得各种类型的封锁，但是不能释放任何封锁。 第二阶段称为收缩阶段，这一阶段释放各种类型的封锁，一旦开始释放封锁，则不能再申请任何类型的封锁。 注意，两阶段封锁协议和一次封锁法的异同之处。一次封锁法遵守两阶段封锁协议；但是两阶段封锁协议并不要求一次封锁所有需要封锁的数据。两阶段封锁协议仍有可能发生死锁。,发现死锁,超时法 即一个事务在等待的时间超过了规定的时限后就认为发生了死锁。 这种方法非常不可靠，如果设置的等待时限长，则不能及时发现死锁；如果设置的等待时限短，则可能会将没有发生死锁的事务误判为死锁。,发现死锁,等待图法 即通过有向图判定事务是否是可串行化的，如果是则说明没
27、有发生死锁，否则说明发生了死锁。 具体思路是：用节点来表示正在运行的事务，用有向边来表示事务之间的等待关系，如右图所示，如果有向图中发现回路，则说明发生了死锁。,解决死锁,发现死锁后解决死锁的一般策略是：自动使“年轻”的事务（即完成工作量少的事务）先退回去，然后让“年老”的事务（即完成工作量多的事务）先执行，等“年老”的事务完成并释放封锁后，“年轻”的事务再重新执行。,避免“活锁”,？,避免“活锁”,按队列实施封锁 T1：事务A共享封锁资源S T2：事务B试图独占封锁资源S，等待 T3：事务C在A释放封锁S之前申请对S的共享封锁，由于事务B已经在等待S，所以事务C排队等待,封锁与隔离级别,可以
28、通过指定隔离级别或对数据资源实施封锁达到事务隔离的目的； 封锁是实现并发操作的传统方法（在SQL标准中没有提及封锁），适当的运用封锁并保证高并发操作性能是一件非常复杂的工作，这需要用户深入了解各种封锁的相容性，并设计封锁的调度策略； SQL标准中规定了事务的隔离级别，即未提交读、提交读、可重复读和可串行化，隔离级别解决了并发事务可能产生的丢失更新问题、未提交依赖问题、不一致分析问题和幻象读问题，其中为了避免丢失更新问题，事务必须运行在可重复读或可串行化隔离级别。 用户可以根据事务的需要设定隔离级别，结果由数据库管理系统控制封锁和进行并发操作调度。,封锁与隔离级别,在实际应用中，也可以将隔离级别
29、和封锁结合起来使用。例如，如果指定隔离级别是可重复读，则SQL会话中所有SELECT语句的锁定行为都运行于该隔离级别上，并一直保持有效，直到会话终止或者将隔离级别设置为另一个级别。如果必要，可以通过指定表级封锁来替代单个SELECT语句的隔离级别，指定表级封锁不会影响会话中的其他语句。一般仅在绝对必要时才使用表级封锁更改默认的锁定行为。,如何提高并发的效率、降低封锁的成本,意向锁,为了降低封锁的成本，提高并发的性能，数据库管理系统还支持一种意向锁（Intention Lock）。 意向锁表示一种封锁意向，当需要在某些底层资源上（如元组）获取封锁时，可以先对高层资源（如表）实施意向锁。例如，在表
30、级实施共享意向锁表示事务打算在表中的元组上实施共享锁，这样做可以防止另一个事务随后在同样的资源上获取排它锁。意向锁可以提高性能，因为系统仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁；而无须检查表中的每个元组上的锁，以确定事务是否可以锁定整个表。,意向共享（IS）,通过在各资源上放置IS锁，表明事务的意向是读取层次结构中的部分（而不是全部）底层资源。 例如，对表实施IS锁，则意味着要对表中的某个（些）元组实施S锁； 或者说，当需要对表中的某个（些）元组实施S锁时，应该首先对表实施IS锁。,意向排它（IX）,通过在各资源上放置IX锁，表明事务的意向是修改层次结构中的部分（而不是全部）底
31、层资源。 例如，对表实施IX锁，则意味着要对表中的某个（些）元组实施X锁； 或者说，当需要对表中的某个（些）元组实施X锁时，应该首先对表实施IX锁。,共享意向排它（SIX）,通过在各资源上放置SIX锁，表明事务的意向是读取层次结构中的全部底层资源并修改部分（而不是全部）底层资源。 SIX锁等同于加S锁、再加IX锁。 例如，对表实施SIX锁，则意味着要对表实施S锁，并对表中的某个（些）元组实施X锁； 或者说，当需要对表实施S锁，并对表中的某个（些）元组实施X锁时，应该首先对表实施SIX锁。,“悲观”与“乐观”,先实施封锁是一种悲观的并发控制方法 也许大部分事务并不会破坏事务的隔离性 大量的封锁严
32、重的影响了系统的性能,乐观的并发控制,不实施封锁 前提是发生冲突的概率很低 更新时系统自动检查被更新的数据是否已经发生变化，如果发生变化则自动撤销事务 体现了事后协调冲突的思想 避免冲突(悲观)还是事后协调(乐观)冲突是并发控制的又一种策略,“乐观”与“悲观”,悲观的方法通过等待解决冲突 乐观的方法通过撤销和重新开始事务解决冲突 如果冲突次数多、撤销和重新开始事务代价大，则“乐观”将变的不乐观 一般来说，与等待释放资源相比，撤销和重新开始事务可能会导致更长的延时,并发控制小结,为什么需要并发控制？ 保证事务隔离性的基本思路？ 封锁机制独占、共享、更新 死锁与活锁 避免和解决死锁的方法 隔离级别
33、与封锁 提高封锁的效率意向锁 悲观和乐观并发控制,第8章 事务管理,事 务 并发控制 恢 复,恢复技术,事务的原子性、一致性和持久性都与恢复技术有关。 当出现故障的时候需要恢复。 故障的类型？,故障类型,造成事务中断的故障 突然掉电引起的事务中断 硬件故障引起的事务中断 客户应用程序出错引起的事务中断 系统程序故障引起的事务中断 磁盘介质故障,事务中断的故障,事务中断只是暂时破坏了事务的原子性和一致性。 通过撤销未完成的事务即保证了事务的原子性和一致性。 如果事务中断是程序可控制的，也可以继续完成事务来保证事务的原子性和一致性。,如果异常停机造成事务中断,重新开机后如何处理事务？,事故造成的故
34、障,指数据库损坏、磁盘介质损坏、数据丢失等“硬”伤造成的故障，这时候为了保证对数据库的所有操作不丢失保证事务的持久性必须使用备份进行恢复。,备份技术,双机热备份 双工备份 磁盘镜像 数据库备份技术,备份与恢复,正常时不忘备份 灾难时及时恢复 从备份点到灾难点如何恢复？,日志的概念,日志则是对备份的补充，它可以看作是一个值班日记，它将记录下所有对数据库的更新操作。这样就可以在备份完成时立刻刷新并启用一个数据库日志，数据库日志是实时的，它将忠实地记录下所有对数据库的更新操作。 当磁盘出现故障造成数据库损坏时，就可以首先利用备份恢复数据库（恢复大部分数据），然后再运行数据库日志，即将备份后所做的更新
35、操作再重新做一遍，从而将数据库完全恢复。 为了保证日志的安全，应该将日志和主数据库安排在不同的存储设备上，否则日志和数据库可能会同时遭到破坏，日志也就失去了它本来的作用。,日志包括,事务（起始和结束，当然也有中断的事务） UPDATE的新值和旧值 INSERT的新值 DELETE的旧值,日志的结构,典型的日志包括 日志序列号LSN 事务标识符 操作（BEGIN、INSERT、DELETE、UPDATE） 时间 表、行、列 旧值、新值,恢复模型,简单恢复模型 允许将数据库恢复到最新的备份，即使用简单恢复模型可以将数据库恢复到上次备份的即时点，而无法将数据库恢复到故障点或特定的即时点。使用简单恢复
36、模型，日志实际失去了作用。使用简单恢复模型的数据库只能做数据库备份，不能做日志备份。 完全恢复模型 允许将数据库恢复到故障点状态，即完全恢复模型使用数据库备份和事务日志备份提供对介质故障的完全防范。,恢复模型,可以使用ALTER DATABASE语句的RECOVERY子句设置恢复模型。 例如，如下语句将订货数据库的恢复模型设置为完全恢复：ALTER DATABASE 订货 SET RECOVERY FULL,备份或转储,备份的类型 动态备份和静态备份 制定备份的策略 备份整个数据库 增量备份 事务日志备份 文件和文件组备份 系统数据库的备份,备份的类型,全备份：即完整的备份整个数据库； 增量备
37、份：增量数据库备份只备份自上次数据库备份后发生更改的数据； 文件和文件组备份：备份数据库文件或文件组，而不是备份数据库； 事务日志备份：只备份事务日志。,动态备份和静态备份,动态备份也称作在线备份，即在做备份时不中断数据库的运行，不中断数据库上的应用程序和事务处理。 静态备份也称作离线或脱机备份，这意味着在做备份时没有任何数据库事务在运行，这种备份方式应是首选的备份方式。,制定备份的策略,备份不是实时的，备份应该什么时候做？用什么方式做？这根据数据库的不同规模、不同用途，可能有很多因素需要考虑和衡量。,备份整个数据库,在SQL Server中系统管理员和数据库管理员可以进行备份，也可以指定某个
38、用户担当db_backupoperator角色（数据库预定义角色）来负责数据库的备份工作。 所有的备份工作可以在“企业管理器”中利用交互工具完成，也可以使用命令方式完成。,备份整个数据库,备份数据库的命令是BACKUP DATABASE，一般格式如下： BACKUP DATABASE database_name TO DISK | TAPE =physical_backup_device_name 例如，如下命令将订货数据库备份到C:dumpdump1.bak： BACKUP DATABASE 订货 TO DISK=C:dumpdumpfull.bak,增量备份,增量备份的命令也是BACKUP
39、 DATABASE，一般格式如下： BACKUP DATABASE database_name TO DISK | TAPE =physical_backup_device_nameWITH DIFFERENTIAL 例如，如下命令将对订货数据库做增量备份（备份到C:dumpdump1.bak）： BACKUP DATABASE 订货 TO DISK=C:dumpdump1.bak WITH DIFFERENTIAL,事务日志备份,备份事务日志的命令是BACKUP LOG，一般格式是： BACKUP LOG database_name TO DISK | TAPE =physical_back
40、up_device_name 例如，如下命令将备份订货数据库的日志（备份到C:dumpdumplog.bak）： BACKUP LOG 订货 TO DISK=C:dumpdumplog.bak,截断日志,截断日志的命令是： BACKUP LOG database_name WITH TRUNCATE_ONLY 例如，在备份了订货数据库或事务日志后，为了截断订货管理数据库的事务日志可以使用如下命令： BACKUP LOG 订货WITH TRUNCATE_ONLY,文件和文件组备份,可以备份和恢复数据库中的个别文件，这样当遇到介质故障时可以只恢复已损坏的文件，而不用恢复数据库的其余部分，从而加快了
41、恢复速度。 对于超大型数据库，有时不可能完成完整数据库的备份，这样则可以使用文件备份。文件备份为数据库备份提供了一种灵活的手段。 与数据库备份相比，文件备份的主要缺点是增加了管理的复杂性。必须注意维护完整的文件备份集和所覆盖的日志备份。,文件和文件组备份,备份文件或文件组的一般命令格式是： BACKUP DATABASE database_name FILE = logic_file_list | FILEGROUP = filegroup_list TO DISK | TAPE =physical_backup_device_name WITH DIFFERENTIAL ,文件和文件组备份,
42、例如，如下命令完成对订货数据库warehouse文件的备份：BACKUP DATABASE 订货FILE = warehouseTO DISK =C:dumpfile_1.bak 如下命令则完成对订货数据库文件组仓库的备份： BACKUP DATABASE 订货FILEGROUP = 仓库TO DISK =C:dumpfile_g.bak,系统数据库的备份,数据库备份不仅仅是要备份用户数据库，系统数据库也需要备份，例如SQL Server中的master、model和msdb等系统数据库。特别是master数据库，它负责整个数据库的管理，所有用户创建的数据库以及用户登录信息都存储在该数据库中。
43、所以，该数据库一旦损坏，整个系统的使用都将受到影响。,恢复或还原,恢复整个数据库 恢复数据库的部分内容 恢复特定的文件或文件组 恢复事务,可以将数据库恢复到做备份的即时点、发生故障的即时点或特定的事务即时点。,恢复或还原,根据数据库全备份进行恢复 根据增量备份进行恢复 根据事务日志进行恢复 根据文件或文件组备份进行恢复 恢复系统数据库,根据数据库全备份进行恢复,RESTORE DATABASE database_name FROM DISK | TAPE =physical_backup_device_name WITH , NORECOVERY | RECOVERY , REPLACE ,根
44、据增量备份进行恢复,在简单恢复模型和完全恢复模型中都可以选择增量备份，如果存在增量备份，则一般需要进行相应的恢复操作。 增量恢复数据库的命令也是RESTORE DATABASE，但是在根据增量备份继续恢复之前应该：已经使用RESTORE DATABASE命令完成了全备份的恢复，同时指定了NORECOVERY子句。,根据事务日志进行恢复,利用日志可以将数据库恢复到最新的一致状态或任意的事务点。 首先恢复事务日志备份之前的数据库备份或增量数据库备份。 如果有多个日志备份，则按先后顺序进行恢复。,根据事务日志进行恢复,RESTORE LOG database_name FROM DISK | TAP
45、E =physical_backup_device_name WITH , NORECOVERY | RECOVERY , STOPAT = date_time| , STOPATMARK = mark_name AFTER datetime| , STOPBEFOREMARK = mark_name AFTER datetime ,根据文件或文件组备份进行恢复,如果数据库的某个文件损坏了，并且按文件或文件组做了备份，则可以考虑根据文件或文件组备份进行恢复。 当使用文件或文件组备份进行恢复时，最后一个文件或文件组恢复操作完成后，必须将事务日志应用于数据库文件，以便使之与数据库的其余部分保持一致
46、。如果被恢复的文件自上次备份后没有做过任何修改操作，则不必应用事务日志，RESTORE语句会报告这一情况。,根据文件或文件组备份进行恢复,RESTORE DATABASE database_name FILE = logical_file_name | FILEGROUP = logical_filegroup_name FROM DISK | TAPE =physical_backup_device_name,恢复系统数据库,备份系统数据库与备份用户数据库的方式相同，除master数据库之外其他系统数据库的恢复也与恢复用户数据库类似。 master数据库是所有数据库的主数据库，也是管理所有数
47、据库的数据库。恢复其他数据库都是在SQL Server能够正常运行的基础上进行的，而master数据库的损坏可能导致SQL server根本不能运行，所以恢复master数据库是一件特殊的任务。,恢复master数据库,如果master数据库只是轻微损坏或信息丢失，master数据库的内容至少部分可用，从而能够启动SQL Server实例，则可以直接根据master数据库的完整备份恢复master数据库。 如果由于master数据库严重损坏而无法启动SQL Server实例，则不能立即恢复master数据库。因为SQL Server实例需要处于运行状态才能恢复任何数据库。为此，需要首先使用重建
48、master数据库实用工具Rebuildm.exe（该程序位于Program FilesMicrosoft SQL Server80ToolsBinn目录中）重建master数据库，然后才可以用普通方法利用备份恢复master数据库。,简单恢复模型的恢复过程,恢复最新的数据库备份 恢复最新的增量备份,完全恢复模型的恢复过程,备份当前活动日志 恢复最新的数据库备份（NORECOVERY ） 如果有增量备份，则恢复最新的增量备份（NORECOVERY ） 按照时间顺序恢复日志备份（NORECOVERY ） 应用最新的日志备份恢复数据库（RECOVERY）,恢复小结,故障类型 备份类型 日志的概念 恢复模型 备份或转储 恢复或还原,事务设计,在学习了并发控制和恢复技术后回头看一下应该如何设计事务,【本章小节】,事务 并发控制 恢复,
