第 8章 事务管理
事 务
并发控制
恢 复
事 务
? 事务的概念
? 事务的性质
? 可串行性和隔离级别
? SQL对事务的支持
事务的概念
? 事务是构成单一逻辑工作单元的操作集合。
? 为什么需要事务的概念呢？
– 恢复的需要
– 并发操作的需要
事务的性质
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持久性（ Durability）
事务的这些性质通常称为 ACID特性
原子性
? 事务的原子性强调了一个事务是一个逻辑工作单
元，是一个整体，是不可分割的。一个事务所包
含的操作要么全部做，要么全部不做。
一致性
? 一个事务执行一项数据库操作，事务将使数据库
从一种一致性的状态变换成另一种一致性状态。
? 在事务执行前，总是假设数据库是一致的，那么
当事务成功执行后，数据库肯定仍然是一致的。
隔离性
? 如果每个事务单独执行能保持原子性和一致性，
这些事务并发执行也能保持原子性和一致性，则
是事务的隔离性。
持久性
? 事务的持久性是指一旦事务成功完成，该事务对
数据库所施加的所有更新都是永久的。
可串行性
? 可串行性通常看作是多个事务并发执行的正确性
准则。具体判定方法如下：
– 各单个事务如能将数据库从一个正确状态转变为另一
个正确状态，则认为该事务是正确的；
– 按任何一个串行顺序依次执行多个事务也是正确的
（这里的串行顺序假定各个事务间彼此独立、不交
叉）；
– 事务的交叉执行过程是正确的，当且仅当其与串行执
行过程等价，则事务是可串行化的。
隔离级别
? 隔离性虽然是事务的基本性质之一，但是彻底的
隔离意味着并发操作效率的降低。所以人们设想
在避免干扰的前提下，适当地降低隔离的级别，
从而提高并发的操作效率。隔离级别越低，并发
操作的效率越高，但是产生干扰的可能性也越大；
隔离级别越高，则并发操作的效率越低，同时产
生干扰的可能性也越小。在设计应用时，可以在
所能容忍的干扰程度范围内，尽可能的降低隔离
级别，从而提高应用的执行效率。
隔离级别
? 在 SQL标准中定义了下列四种隔离级别,SQL
Server支持所有这些隔离级别：
– 未提交读（ READ UNCOMMITTED）,事务隔离的最
低级别，仅可保证不读取物理损坏的数据，这是四个隔
离级别中限制最小的级别。
– 提交读（ READ COMMITTED）,SQL Server默认级
别，可以保证不读取“脏”数据。
– 可重复读（ REPEATABLE READ）,可以保证读一致
性，避免不一致分析问题。
– 可串行化（ SERIALIZABLE）,事务隔离的最高级别，
事务之间完全隔离；如果事务在可串行化隔离级别上运
行，则可以保证任何并发重叠事务均是串行的。
隔离级别
四种隔离级别所允许的不同类型的行为
事务必须运行于可重复读或更高的隔离级别才可以
防止丢失更新。
隔离级别
? 设置隔离级别的命令是：
SET TRANSACTION ISOLATION LEVEL
{ READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE }
SQL对事务的支持
? 开始事务
? 结束事务
? 事务保存点
? 隐含事务与自动提交
开始事务
? 使用 BEGIN TRANSACTION命令显式说明一个
事务开始，它说明了对数据库进行操作的一个单
元的起始点。在事务完成之前出现任何操作错误
和故障，都可以撤销事务，使事务回退到这个起
始点。
结束事务
? 成功结束事务的命令是 COMMIT TRANSACTION，
它的作用是提交或确认事务已经完成，所以该命令
也称作事务提交。
? 撤消事务的命令是 ROLLBACK TRANSACTION，
即撤消在该事务中对数据库所做的更新操作，使数
据库回退到事务的起始点。
事务保存点
? SQL标准还支持“事务保存点”技术，所谓事务
保存点就是在事务的过程中插入若干标记，这样
当发现事务中有操作错误时，可以不撤消整个事
务，只撤消部分事务，即将事务回退到某个事务
保存点。
事务保存点
? SQL Server支持事务保存点技术, 设置保存点
的命令是 SAVE TRANSACTION（ 在 SQL标准
中是 SAVEPOINT命令 ）, 具体格式是：
SAVE TRANSACTION savepoint_name
? 撤消部分事务或回退到事务保存点的命令也是
ROLLBACK TRANSACTION,具体格式是：
ROLLBACK TRANSACTION savepoint_name
事务保存点
? 在 SQL标准中还支持取消事务保存点的命令
RELEASE SAVEPOINT,在 SQL Server目
前的版本中不支持取消事务保存点。
隐含事务与自动提交
? SQL标准规定事务的开始是隐含的，在发出 COMMIT
（ 提交事务）或 ROLLBACK（ 撤消事务）命令之前，
该事务将一直保持有效。一个事务被提交或撤消之后，
又将自动启动下一个新事务。
隐含事务与自动提交
? SQL Server也可以设置成隐含事务方式, 设置
隐含事务方式的命令是：
SET IMPLICIT_TRANSACTIONS ON
? 取消隐含事务方式的命令是：
SET IMPLICIT_TRANSACTIONS OFF
隐含事务与自动提交
? 当 是 隐 含 事 务 方 式 时, 不需要用 BEGIN
TRANSACTION命令显式的启动或开始一个事
务, 但需要用 COMMIT或 ROLLBACK命令结束
事务；
? 当是非隐含事务方式时, 如果没有用 BEGIN
TRANSACTION命令显式的启动或开始一个事
务, 则每条操作数据库的语句都将作为独立的事
务被自动提交或撤消, 这时候不需要, 也不能执
行 COMMIT或 ROLLBACK命令 。
并发控制
? 干扰问题
? 解决干扰 ——封锁
? 封锁不当 ——死锁
? 封锁与隔离级别
干扰问题
? 丢失更新问题
? 未提交依赖问题
? 不一致分析问题
? 幻象读问题
丢失更新问题
? 例：
– 旅客 A来到 A售票处，要买一张 15日北京到上海的 13次直达快速列
车的软卧车票，售票员 A（ 下称用户 A） 在终端 A查看剩余票信息；
– 几乎在同时，旅客 B来到 B售票处，也要买一张 15日北京到上海的
13次直达快速列车的软卧车票，售票员 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术语描述丢失更新问题
未提交依赖问题
? 未提交依赖问题也称为
读“脏”（ Dirty Read）
数据问题，查询一个已
经被其他事务更新、但
尚未提交的元组，将会
引起未提交依赖问题。
不一致分析问题
? 不一致分析问题也称为
不可重复读问题，很多
应用可能需要校验功能，
这时往往需要连续两次
或多次读数据进行校验
和分析，结果由于其他
事务的干扰，使得前后
结果不一致，从而产生
校验错误（即不一致的
分析）。
幻象读问题
? 幻象读问题与不一致分析问题有关，当事务 A读
数据时，事务 B在对同一个关系进行插入或删除
操作，这时事务 A再读同一条件的元组时，会发
现神秘地多出了一些元组或丢失了一些元组，把
这种现象称作幻象读。
封锁
? 封锁的基本技术
? 封锁机制
? SQL Server中与封锁有关的命令
? 封锁粒度
? 意向锁
封锁的基本技术
? 当需要查询或更新数据时，先对数据进行封锁，
以避免来自其他事务的干扰。针对不同的干扰问
题可以有不同的封锁机制。
? 以丢失更新问题为例，实施封锁的基本思想是：
当一个用户对一个表或记录进行更新时，封锁该
表或记录，使其他用户不能在同一时刻更新相同
的表或记录，迫使其他用户在更新后的基础上
（而不是在更新前的基础上）再实施另外的更新
操作。
封锁的基本技术
实施封锁以后的时间序列
封锁机制
? 共享封锁
? 独占封锁
? 更新封锁
有些封锁在执行完相应操作后就自动释放封
锁，有些封锁则保持到事务结束（提交或撤消）
时才释放（无论如何，所有的封锁都会在事务结
束时自动释放）。
共享封锁
? 共享封锁是为读操作设置的一种封锁，所以也称
作读封锁，或简称 S锁，目的是想读到一组不变
的数据，也就是在读数据的过程中，不允许其他
用户对该数据进行任何修改操作。这种封锁可以
保证最大的并发性，任何数量的用户都可以同时
对同样的数据施加这种共享锁。已经实施共享锁
的表拒绝来自其他事务的独占封锁和更新封锁。
独占封锁
? 独占封锁也叫排他封锁，它是为修改操作设置的
一种封锁，也称为写封锁，或简称为 X锁，这是
最严格的一类封锁。当需要对表实施插入、删除
或修改操作时，应该使用独占封锁。已经实施独
占封锁的表，拒绝来自其他用户的任何封锁，但
不拒绝一般的查询操作。
更新封锁
? 当需要对一个记录或一组记录进行更新时（只是
修改，不包括插入和删除）使用更新封锁，该封
锁的目的是防止其他用户在同一时刻修改同一记
录。已经实施更新封锁的记录，拒绝来自其他用
户的任何封锁，但不拒绝一般的查询操作。
SQL Server中与封锁有关的命令
? SQL Server的封锁操作是在相关语句的
,WITH (<table_hint>)”子句中完成的，该短
语可以在 SELECT,INSERT,UPDATE和
DELETE等语句中指定表级锁定的方式和范围。
SQL Server中与封锁有关的命令
? 常用的封锁关键词有：
– TABLOCK,对表施行共享封锁，在读完数据后立刻释放封锁，
此类封锁可以避免读“脏”数据，但不具有可重复读的特性。
– HOLDLOCK,与 TABLOCK一起使用，可将共享锁保留到事务
完成，而不是在读完数据后立即释放锁，这样可以保证数据的
可重复独特性。
– NOLOCK,不进行封锁，此关键词仅应用于 SELECT语句，这
样可能会读取未提交事务的数据，即有可能发生“脏”读。
– TABLOCKX,对表实施独占封锁。
– UPDLOCK,对表中的指定元组实施更新封锁；这时其他事务可
以对同一表中的其他元组也实施更新封锁，但是不允许对表实
施共享封锁和独占封锁。
SQL Server中与封锁有关的命令
…
DECLARE @d datetime,@t char(6),@s char(2),@n char(10)
…
BEGIN TRANSACTION
SELECT @n=座位号 FROM R WITH (UPDLOCK)
WHERE 日期 = @d 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
…
封锁粒度
? 封锁的对象可以是表、也可以是元组等，我们把
封锁对象的大小称为封锁粒度（ Granularity）。
? 封锁的对象可以是逻辑单元（如表和元组等），
也可以是物理单元（如数据页和数据块等）。
? 数据库管理系统一般都具有多粒度锁定功能，允
许一个事务锁定不同类型的资源。
封锁粒度
? 锁定在较小的粒度（例如行）可以增加并发操作
的性能，但系统开销也较大。这是因为如果封锁
的粒度小，则意味着需要的锁多，从而需要系统
控制更多的锁。
? 锁定在较大的粒度（例如表）会降低操作的并发
性，这是因为锁定整个表限制了其他事务对表中
任意部分进行访问。封锁粒度大，则不需要太多
的封锁，由于需要维护的锁较少，所以系统开销
较低。
意向锁
? 为了降低封锁的成本，提高并发的性能，数据库管理系
统还支持一种意向锁（ Intention Lock）。
? 意向锁表示一种封锁意向，当需要在某些底层资源上
（如元组）获取封锁时，可以先对高层资源（如表）实
施意向锁。例如，在表级实施共享意向锁表示事务打算
在表中的元组上实施共享锁，这样做可以防止另一个事
务随后在同样的资源上获取排它锁。意向锁可以提高性
能，因为系统仅在表级检查意向锁来确定事务是否可以
安全地获取该表上的锁；而无须检查表中的每个元组上
的锁，以确定事务是否可以锁定整个表。
意向锁
? 意向共享（ IS）
? 意向排它（ IX）
? 共享意向排它（ SIX）
意向共享（ IS）
? 通过在各资源上放置 IS锁，表明事务的意向是读
取层次结构中的部分（而不是全部）底层资源。
? 例如，对表实施 IS锁，则意味着要对表中的某个
（些）元组实施 S锁；
? 或者说，当需要对表中的某个（些）元组实施 S
锁时，应该首先对表实施 IS锁。
意向排它（ IX）
? 通过在各资源上放置 IX锁，表明事务的意向是修
改层次结构中的部分（而不是全部）底层资源。
? 例如，对表实施 IX锁，则意味着要对表中的某个
（些）元组实施 X锁；
? 或者说，当需要对表中的某个（些）元组实施 X
锁时，应该首先对表实施 IX锁。
共享意向排它（ SIX）
? 通过在各资源上放置 SIX锁，表明事务的意向是
读取层次结构中的全部底层资源并修改部分（而
不是全部）底层资源。
? SIX锁等同于加 S锁、再加 IX锁。
? 例如，对表实施 SIX锁，则意味着要对表实施 S
锁，并对表中的某个（些）元组实施 X锁；
? 或者说，当需要对表实施 S锁，并对表中的某个
（些）元组实施 X锁时，应该首先对表实施 SIX
锁。
死锁
? 产生死锁的原因
? 避免死锁
? 发现死锁
? 解决死锁
产生死锁的原因
? 右图示意了两个并发事务
所发生事件的序列，假设
程序 A为了完成某个事务
需要封锁仓库和职工两个
关系，而几乎在同一时刻
并发执行的程序 B为完成
另一个事务也需要封锁职
工和仓库关系，这两个程
序正好按照如图所示的交
错序列执行命令，结果两
个程序都为了等待对方释
放数据资源而产生死锁。
避免死锁
? 相同顺序法
– 所有的用户程序约定都按相同的顺序来封锁表
? 一次封锁法
– 为了完成一个事务，一次性封锁所需要的全部表
? 两阶段封锁协议
– 所有事务都必须将对数据的封锁分为封锁和释放两个
阶段
避免死锁的封锁
两阶段封锁协议
? 第一阶段称为扩展阶段，这一阶段获得各种类型
的封锁，但是不能释放任何封锁。
? 第二阶段称为收缩阶段，这一阶段释放各种类型
的封锁，一旦开始释放封锁，则不能再申请任何
类型的封锁。
? 注意，两阶段封锁协议和一次封锁法的异同之处。
一次封锁法遵守两阶段封锁协议；但是两阶段封
锁协议并不要求一次封锁所有需要封锁的数据。
两阶段封锁协议仍有可能发生死锁。
发现死锁
? 超时法
– 即一个事务在等待的时间超过了规定的时限后就认为
发生了死锁。
– 这种方法非常不可靠，如果设置的等待时限长，则不
能及时发现死锁；如果设置的等待时限短，则可能会
将没有发生死锁的事务误判为死锁。
发现死锁
? 等待图法
– 即通过有向图判定事务是否是
可串行化的，如果是则说明没
有发生死锁，否则说明发生了
死锁。
– 具体思路是：用节点来表示正
在运行的事务，用有向边来表
示事务之间的等待关系，如右
图所示，如果有向图中发现回
路，则说明发生了死锁。
解决死锁
? 发现死锁后解决死锁的一般策
略是：自动使“年轻”的事务
（即完成工作量少的事务）先
退回去，然后让“年老”的事
务（即完成工作量多的事务）
先执行，等“年老”的事务完
成并释放封锁后，“年轻”的
事务再重新执行。
封锁与隔离级别
? 可以通过指定隔离级别或对数据资源实施封锁达到事务隔
离的目的；
? 封锁是实现并发操作的传统方法（在 SQL标准中没有提及
封锁），适当的运用封锁并保证高并发操作性能是一件非
常复杂的工作，这需要用户深入了解各种封锁的相容性，
并设计封锁的调度策略；
? SQL标准中规定了事务的隔离级别，即未提交读、提交读、
可重复读和可串行化，隔离级别解决了并发事务可能产生
的丢失更新问题、未提交依赖问题、不一致分析问题和幻
象读问题，其中为了避免丢失更新问题，事务必须运行在
可重复读或可串行化隔离级别。
? 用户可以根据事务的需要设定隔离级别，结果由数据库管
理系统控制封锁和进行并发操作调度。
封锁与隔离级别
? 在实际应用中，也可以将隔离级别和封锁结合起
来使用。例如，如果指定隔离级别是可重复读，
则 SQL会话中所有 SELECT语句的锁定行为都运
行于该隔离级别上，并一直保持有效，直到会话
终止或者将隔离级别设置为另一个级别。如果必
要，可以通过指定表级封锁来替代单个 SELECT
语句的隔离级别，指定表级封锁不会影响会话中
的其他语句。一般仅在绝对必要时才使用表级封
锁更改默认的锁定行为。
恢 复
? 故障类型
? 备份类型
? 日志的概念
? 恢复模型
? 备份或转储
? 恢复或还原
故障类型
? 造成事务中断的故障
– 突然掉电引起的事务中断
– 硬件故障引起的事务中断
– 客户应用程序出错引起的事务中断
– 系统程序故障引起的事务中断
? 磁盘介质故障
备份类型
? 双机热备份
? 双工备份
? 磁盘镜像
? 数据库备份技术
日志的概念
? 日志则是对备份的补充，它可以看作是一个值班日记，
它将记录下所有对数据库的更新操作。这样就可以在备
份完成时立刻刷新并启用一个数据库日志，数据库日志
是实时的，它将忠实地记录下所有对数据库的更新操作。
? 当磁盘出现故障造成数据库损坏时，就可以首先利用备
份恢复数据库（恢复大部分数据），然后再运行数据库
日志，即将备份后所做的更新操作再重新做一遍，从而
将数据库完全恢复。
? 为了保证日志的安全，应该将日志和主数据库安排在不
同的存储设备上，否则日志和数据库可能会同时遭到破
坏，日志也就失去了它本来的作用。
恢复模型
? 简单恢复模型
– 允许将数据库恢复到最新的备份, 即使用简单恢复模
型可以将数据库恢复到上次备份的即时点, 而无法将
数据库恢复到故障点或特定的即时点 。 使用简单恢复
模型, 日志实际失去了作用 。 使用简单恢复模型的数
据库只能做数据库备份, 不能做日志备份 。
? 完全恢复模型
– 允许将数据库恢复到故障点状态, 即完全恢复模型使
用数据库备份和事务日志备份提供对介质故障的完全
防范 。
恢复模型
? 可以使用 ALTER DATABASE语句的 RECOVERY子
句设置恢复模型 。
? 例如, 如下语句将订货数据库的恢复模型设置为完
全恢复：
ALTER DATABASE 订货 SET RECOVERY FULL
备份或转储
? 备份的类型
? 动态备份和静态备份
? 制定备份的策略
? 备份整个数据库
? 增量备份
? 事务日志备份
? 文件和文件组备份
? 系统数据库的备份
备份的类型
? 全备份：即完整的备份整个数据库；
? 增量备份：增量数据库备份只备份自上次数据库
备份后发生更改的数据；
? 文件和文件组备份：备份数据库文件或文件组，
而不是备份数据库；
? 事务日志备份：只备份事务日志。
动态备份和静态备份
? 动态备份也称作在线备份，即在做备份时不中断
数据库的运行，不中断数据库上的应用程序和事
务处理。
? 静态备份也称作离线或脱机备份，这意味着在做
备份时没有任何数据库事务在运行，这种备份方
式应是首选的备份方式。
制定备份的策略
? 备份不是实时的，备份应该什么时候做？用什么
方式做？这根据数据库的不同规模、不同用途，
可能有很多因素需要考虑和衡量。
备份整个数据库
? 在 SQL Server中系统管理员和数据库管理
员可以进行备份，也可以指定某个用户担
当 db_backupoperator角色（数据库预定义
角色）来负责数据库的备份工作。
? 所有的备份工作可以在“企业管理器”中
利用交互工具完成，也可以使用命令方式
完成。
备份整个数据库
? 备份数据库的命令是 BACKUP DATABASE,一般格式如
下：
BACKUP DATABASE database_name
TO {DISK | TAPE } ='physical_backup_device_name'
? 例如，如下命令将订货数据库备份到 C:\dump\dump1.bak：
BACKUP DATABASE 订货
TO DISK='C:\dump\dumpfull.bak'
增量备份
? 增量备份的命令也是 BACKUP DATABASE,一般格式如
下：
BACKUP DATABASE database_name
TO {DISK | TAPE } ='physical_backup_device_name'
WITH DIFFERENTIAL
? 例如，如下命令将对订货数据库做增量备份（备份到
C:\dump\dump1.bak）：
BACKUP DATABASE 订货
TO DISK='C:\dump\dump1.bak'
WITH DIFFERENTIAL
事务日志备份
? 备份事务日志的命令是 BACKUP LOG,一般格式是：
BACKUP LOG database_name
TO {DISK | TAPE } ='physical_backup_device_name'
? 例如，如下命令将备份订货数据库的日志（备份到
C:\dump\dumplog.bak）：
BACKUP LOG 订货
TO DISK='C:\dump\dumplog.bak'
截断日志
? 截断日志的命令是：
BACKUP LOG database_name
WITH TRUNCATE_ONLY
? 例如，在备份了订货数据库或事务日志后，为了
截断订货管理数据库的事务日志可以使用如下命
令：
BACKUP LOG 订货
WITH TRUNCATE_ONLY
文件和文件组备份
? 可以备份和恢复数据库中的个别文件，这样当遇
到介质故障时可以只恢复已损坏的文件，而不用
恢复数据库的其余部分，从而加快了恢复速度。
? 对于超大型数据库，有时不可能完成完整数据库
的备份，这样则可以使用文件备份。文件备份为
数据库备份提供了一种灵活的手段。
? 与数据库备份相比，文件备份的主要缺点是增加
了管理的复杂性。必须注意维护完整的文件备份
集和所覆盖的日志备份。
文件和文件组备份
? 备份文件或文件组的一般命令格式是：
BACKUP DATABASE database_name
{FILE = logic_file_list | FILEGROUP = filegroup_list }
TO {DISK | TAPE } ='physical_backup_device_name'
[ WITH DIFFERENTIAL ]
文件和文件组备份
? 例如，如下命令完成对订货数据库 warehouse文件
的备份：
BACKUP DATABASE 订货
FILE = 'warehouse'
TO DISK ='C:\dump\file_1.bak'
? 如下命令则完成对订货数据库文件组仓库的备份：
BACKUP DATABASE 订货
FILEGROUP = '仓库 '
TO DISK ='C:\dump\file_g.bak'
系统数据库的备份
? 数据库备份不仅仅是要备份用户数据库，系统数
据库也需要备份，例如 SQL Server中的 master、
model和 msdb等系统数据库。特别是 master数
据库，它负责整个数据库的管理，所有用户创建
的数据库以及用户登录信息都存储在该数据库中。
所以，该数据库一旦损坏，整个系统的使用都将
受到影响。
恢复或还原
? 恢复整个数据库
? 恢复数据库的部分内容
? 恢复特定的文件或文件组
? 恢复事务
可以将数据库恢复到做备份的即时点、
发生故障的即时点或特定的事务即时点。
恢复或还原
? 根据数据库全备份进行恢复
? 根据增量备份进行恢复
? 根据事务日志进行恢复
? 根据文件或文件组备份进行恢复
? 恢复系统数据库
根据数据库全备份进行恢复
RESTORE DATABASE database_name
FROM {DISK | TAPE }
='physical_backup_device_name'
[ WITH
[ [,] { NORECOVERY | RECOVERY } ]
[ [,] REPLACE ]
]
根据增量备份进行恢复
? 在简单恢复模型和完全恢复模型中都可以选择增量备
份，如果存在增量备份，则一般需要进行相应的恢复
操作。
? 增量恢复数据库的命令也是 RESTORE DATABASE，
但是在根据增量备份继续恢复之前应该：已经使用
RESTORE DATABASE命令完成了全备份的恢复，
同时指定了 NORECOVERY子句。
根据事务日志进行恢复
? 利用日志可以将数据库恢复到最新的一致状态或
任意的事务点。
? 首先恢复事务日志备份之前的数据库备份或增量
数据库备份。
? 如果有多个日志备份，则按先后顺序进行恢复。
根据事务日志进行恢复
RESTORE LOG database_name
FROM {DISK | TAPE } ='physical_backup_device_name'
[ WITH
[ [,] { NORECOVERY | RECOVERY } ]
[ [,] STOPAT = date_time
| [,] STOPATMARK = 'mark_name' [AFTER datetime]
| [,] STOPBEFOREMARK = 'mark_name'
[AFTER datetime] ]
]
根据文件或文件组备份进行恢复
? 如果数据库的某个文件损坏了，并且按文件或文
件组做了备份，则可以考虑根据文件或文件组备
份进行恢复。
? 当使用文件或文件组备份进行恢复时，最后一个
文件或文件组恢复操作完成后，必须将事务日志
应用于数据库文件，以便使之与数据库的其余部
分保持一致。如果被恢复的文件自上次备份后没
有做过任何修改操作，则不必应用事务日志，
RESTORE语句会报告这一情况。
根据文件或文件组备份进行恢复
RESTORE DATABASE database_name
{ FILE = logical_file_name
| FILEGROUP = logical_filegroup_name }
FROM {DISK | TAPE } ='physical_backup_device_name'
恢复系统数据库
? 备份系统数据库与备份用户数据库的方式相同，
除 master数据库之外其他系统数据库的恢复也
与恢复用户数据库类似。
? master数据库是所有数据库的主数据库，也是
管理所有数据库的数据库。恢复其他数据库都是
在 SQL Server能够正常运行的基础上进行的，
而 master数据库的损坏可能导致 SQL server根
本不能运行，所以恢复 master数据库是一件特
殊的任务。
恢复 master数据库
? 如果 master数据库只是轻微损坏或信息丢失,master数
据库的内容至少部分可用，从而能够启动 SQL Server实
例，则可以直接根据 master数据库的完整备份恢复
master数据库。
? 如果由于 master数据库严重损坏而无法启动 SQL Server
实例，则不能立即恢复 master数据库。因为 SQL Server
实例需要处于运行状态才能恢复任何数据库。为此，需
要首先使用重建 master数据库实用工具 Rebuildm.exe
（ 该程序位于 Program Files\Microsoft SQL Server\80\Tools\Binn目
录中）重建 master数据库，然后才可以用普通方法利用
备份恢复 master数据库。
【本章小节】
?事务的概念
?事务的性质
?并发控制
?恢复
事 务
并发控制
恢 复
事 务
? 事务的概念
? 事务的性质
? 可串行性和隔离级别
? SQL对事务的支持
事务的概念
? 事务是构成单一逻辑工作单元的操作集合。
? 为什么需要事务的概念呢？
– 恢复的需要
– 并发操作的需要
事务的性质
? 原子性（ Atomicity）
? 一致性（ Consistency）
? 隔离性（ Isolation）
? 持久性（ Durability）
事务的这些性质通常称为 ACID特性
原子性
? 事务的原子性强调了一个事务是一个逻辑工作单
元，是一个整体，是不可分割的。一个事务所包
含的操作要么全部做，要么全部不做。
一致性
? 一个事务执行一项数据库操作，事务将使数据库
从一种一致性的状态变换成另一种一致性状态。
? 在事务执行前，总是假设数据库是一致的，那么
当事务成功执行后，数据库肯定仍然是一致的。
隔离性
? 如果每个事务单独执行能保持原子性和一致性，
这些事务并发执行也能保持原子性和一致性，则
是事务的隔离性。
持久性
? 事务的持久性是指一旦事务成功完成，该事务对
数据库所施加的所有更新都是永久的。
可串行性
? 可串行性通常看作是多个事务并发执行的正确性
准则。具体判定方法如下：
– 各单个事务如能将数据库从一个正确状态转变为另一
个正确状态，则认为该事务是正确的；
– 按任何一个串行顺序依次执行多个事务也是正确的
（这里的串行顺序假定各个事务间彼此独立、不交
叉）；
– 事务的交叉执行过程是正确的，当且仅当其与串行执
行过程等价，则事务是可串行化的。
隔离级别
? 隔离性虽然是事务的基本性质之一，但是彻底的
隔离意味着并发操作效率的降低。所以人们设想
在避免干扰的前提下，适当地降低隔离的级别，
从而提高并发的操作效率。隔离级别越低，并发
操作的效率越高，但是产生干扰的可能性也越大；
隔离级别越高，则并发操作的效率越低，同时产
生干扰的可能性也越小。在设计应用时，可以在
所能容忍的干扰程度范围内，尽可能的降低隔离
级别，从而提高应用的执行效率。
隔离级别
? 在 SQL标准中定义了下列四种隔离级别,SQL
Server支持所有这些隔离级别：
– 未提交读（ READ UNCOMMITTED）,事务隔离的最
低级别，仅可保证不读取物理损坏的数据，这是四个隔
离级别中限制最小的级别。
– 提交读（ READ COMMITTED）,SQL Server默认级
别，可以保证不读取“脏”数据。
– 可重复读（ REPEATABLE READ）,可以保证读一致
性，避免不一致分析问题。
– 可串行化（ SERIALIZABLE）,事务隔离的最高级别，
事务之间完全隔离；如果事务在可串行化隔离级别上运
行，则可以保证任何并发重叠事务均是串行的。
隔离级别
四种隔离级别所允许的不同类型的行为
事务必须运行于可重复读或更高的隔离级别才可以
防止丢失更新。
隔离级别
? 设置隔离级别的命令是：
SET TRANSACTION ISOLATION LEVEL
{ READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE }
SQL对事务的支持
? 开始事务
? 结束事务
? 事务保存点
? 隐含事务与自动提交
开始事务
? 使用 BEGIN TRANSACTION命令显式说明一个
事务开始，它说明了对数据库进行操作的一个单
元的起始点。在事务完成之前出现任何操作错误
和故障，都可以撤销事务，使事务回退到这个起
始点。
结束事务
? 成功结束事务的命令是 COMMIT TRANSACTION，
它的作用是提交或确认事务已经完成，所以该命令
也称作事务提交。
? 撤消事务的命令是 ROLLBACK TRANSACTION，
即撤消在该事务中对数据库所做的更新操作，使数
据库回退到事务的起始点。
事务保存点
? SQL标准还支持“事务保存点”技术，所谓事务
保存点就是在事务的过程中插入若干标记，这样
当发现事务中有操作错误时，可以不撤消整个事
务，只撤消部分事务，即将事务回退到某个事务
保存点。
事务保存点
? SQL Server支持事务保存点技术, 设置保存点
的命令是 SAVE TRANSACTION（ 在 SQL标准
中是 SAVEPOINT命令 ）, 具体格式是：
SAVE TRANSACTION savepoint_name
? 撤消部分事务或回退到事务保存点的命令也是
ROLLBACK TRANSACTION,具体格式是：
ROLLBACK TRANSACTION savepoint_name
事务保存点
? 在 SQL标准中还支持取消事务保存点的命令
RELEASE SAVEPOINT,在 SQL Server目
前的版本中不支持取消事务保存点。
隐含事务与自动提交
? SQL标准规定事务的开始是隐含的，在发出 COMMIT
（ 提交事务）或 ROLLBACK（ 撤消事务）命令之前，
该事务将一直保持有效。一个事务被提交或撤消之后，
又将自动启动下一个新事务。
隐含事务与自动提交
? SQL Server也可以设置成隐含事务方式, 设置
隐含事务方式的命令是：
SET IMPLICIT_TRANSACTIONS ON
? 取消隐含事务方式的命令是：
SET IMPLICIT_TRANSACTIONS OFF
隐含事务与自动提交
? 当 是 隐 含 事 务 方 式 时, 不需要用 BEGIN
TRANSACTION命令显式的启动或开始一个事
务, 但需要用 COMMIT或 ROLLBACK命令结束
事务；
? 当是非隐含事务方式时, 如果没有用 BEGIN
TRANSACTION命令显式的启动或开始一个事
务, 则每条操作数据库的语句都将作为独立的事
务被自动提交或撤消, 这时候不需要, 也不能执
行 COMMIT或 ROLLBACK命令 。
并发控制
? 干扰问题
? 解决干扰 ——封锁
? 封锁不当 ——死锁
? 封锁与隔离级别
干扰问题
? 丢失更新问题
? 未提交依赖问题
? 不一致分析问题
? 幻象读问题
丢失更新问题
? 例：
– 旅客 A来到 A售票处，要买一张 15日北京到上海的 13次直达快速列
车的软卧车票，售票员 A（ 下称用户 A） 在终端 A查看剩余票信息；
– 几乎在同时，旅客 B来到 B售票处，也要买一张 15日北京到上海的
13次直达快速列车的软卧车票，售票员 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术语描述丢失更新问题
未提交依赖问题
? 未提交依赖问题也称为
读“脏”（ Dirty Read）
数据问题，查询一个已
经被其他事务更新、但
尚未提交的元组，将会
引起未提交依赖问题。
不一致分析问题
? 不一致分析问题也称为
不可重复读问题，很多
应用可能需要校验功能，
这时往往需要连续两次
或多次读数据进行校验
和分析，结果由于其他
事务的干扰，使得前后
结果不一致，从而产生
校验错误（即不一致的
分析）。
幻象读问题
? 幻象读问题与不一致分析问题有关，当事务 A读
数据时，事务 B在对同一个关系进行插入或删除
操作，这时事务 A再读同一条件的元组时，会发
现神秘地多出了一些元组或丢失了一些元组，把
这种现象称作幻象读。
封锁
? 封锁的基本技术
? 封锁机制
? SQL Server中与封锁有关的命令
? 封锁粒度
? 意向锁
封锁的基本技术
? 当需要查询或更新数据时，先对数据进行封锁，
以避免来自其他事务的干扰。针对不同的干扰问
题可以有不同的封锁机制。
? 以丢失更新问题为例，实施封锁的基本思想是：
当一个用户对一个表或记录进行更新时，封锁该
表或记录，使其他用户不能在同一时刻更新相同
的表或记录，迫使其他用户在更新后的基础上
（而不是在更新前的基础上）再实施另外的更新
操作。
封锁的基本技术
实施封锁以后的时间序列
封锁机制
? 共享封锁
? 独占封锁
? 更新封锁
有些封锁在执行完相应操作后就自动释放封
锁，有些封锁则保持到事务结束（提交或撤消）
时才释放（无论如何，所有的封锁都会在事务结
束时自动释放）。
共享封锁
? 共享封锁是为读操作设置的一种封锁，所以也称
作读封锁，或简称 S锁，目的是想读到一组不变
的数据，也就是在读数据的过程中，不允许其他
用户对该数据进行任何修改操作。这种封锁可以
保证最大的并发性，任何数量的用户都可以同时
对同样的数据施加这种共享锁。已经实施共享锁
的表拒绝来自其他事务的独占封锁和更新封锁。
独占封锁
? 独占封锁也叫排他封锁，它是为修改操作设置的
一种封锁，也称为写封锁，或简称为 X锁，这是
最严格的一类封锁。当需要对表实施插入、删除
或修改操作时，应该使用独占封锁。已经实施独
占封锁的表，拒绝来自其他用户的任何封锁，但
不拒绝一般的查询操作。
更新封锁
? 当需要对一个记录或一组记录进行更新时（只是
修改，不包括插入和删除）使用更新封锁，该封
锁的目的是防止其他用户在同一时刻修改同一记
录。已经实施更新封锁的记录，拒绝来自其他用
户的任何封锁，但不拒绝一般的查询操作。
SQL Server中与封锁有关的命令
? SQL Server的封锁操作是在相关语句的
,WITH (<table_hint>)”子句中完成的，该短
语可以在 SELECT,INSERT,UPDATE和
DELETE等语句中指定表级锁定的方式和范围。
SQL Server中与封锁有关的命令
? 常用的封锁关键词有：
– TABLOCK,对表施行共享封锁，在读完数据后立刻释放封锁，
此类封锁可以避免读“脏”数据，但不具有可重复读的特性。
– HOLDLOCK,与 TABLOCK一起使用，可将共享锁保留到事务
完成，而不是在读完数据后立即释放锁，这样可以保证数据的
可重复独特性。
– NOLOCK,不进行封锁，此关键词仅应用于 SELECT语句，这
样可能会读取未提交事务的数据，即有可能发生“脏”读。
– TABLOCKX,对表实施独占封锁。
– UPDLOCK,对表中的指定元组实施更新封锁；这时其他事务可
以对同一表中的其他元组也实施更新封锁，但是不允许对表实
施共享封锁和独占封锁。
SQL Server中与封锁有关的命令
…
DECLARE @d datetime,@t char(6),@s char(2),@n char(10)
…
BEGIN TRANSACTION
SELECT @n=座位号 FROM R WITH (UPDLOCK)
WHERE 日期 = @d 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
…
封锁粒度
? 封锁的对象可以是表、也可以是元组等，我们把
封锁对象的大小称为封锁粒度（ Granularity）。
? 封锁的对象可以是逻辑单元（如表和元组等），
也可以是物理单元（如数据页和数据块等）。
? 数据库管理系统一般都具有多粒度锁定功能，允
许一个事务锁定不同类型的资源。
封锁粒度
? 锁定在较小的粒度（例如行）可以增加并发操作
的性能，但系统开销也较大。这是因为如果封锁
的粒度小，则意味着需要的锁多，从而需要系统
控制更多的锁。
? 锁定在较大的粒度（例如表）会降低操作的并发
性，这是因为锁定整个表限制了其他事务对表中
任意部分进行访问。封锁粒度大，则不需要太多
的封锁，由于需要维护的锁较少，所以系统开销
较低。
意向锁
? 为了降低封锁的成本，提高并发的性能，数据库管理系
统还支持一种意向锁（ Intention Lock）。
? 意向锁表示一种封锁意向，当需要在某些底层资源上
（如元组）获取封锁时，可以先对高层资源（如表）实
施意向锁。例如，在表级实施共享意向锁表示事务打算
在表中的元组上实施共享锁，这样做可以防止另一个事
务随后在同样的资源上获取排它锁。意向锁可以提高性
能，因为系统仅在表级检查意向锁来确定事务是否可以
安全地获取该表上的锁；而无须检查表中的每个元组上
的锁，以确定事务是否可以锁定整个表。
意向锁
? 意向共享（ IS）
? 意向排它（ IX）
? 共享意向排它（ SIX）
意向共享（ IS）
? 通过在各资源上放置 IS锁，表明事务的意向是读
取层次结构中的部分（而不是全部）底层资源。
? 例如，对表实施 IS锁，则意味着要对表中的某个
（些）元组实施 S锁；
? 或者说，当需要对表中的某个（些）元组实施 S
锁时，应该首先对表实施 IS锁。
意向排它（ IX）
? 通过在各资源上放置 IX锁，表明事务的意向是修
改层次结构中的部分（而不是全部）底层资源。
? 例如，对表实施 IX锁，则意味着要对表中的某个
（些）元组实施 X锁；
? 或者说，当需要对表中的某个（些）元组实施 X
锁时，应该首先对表实施 IX锁。
共享意向排它（ SIX）
? 通过在各资源上放置 SIX锁，表明事务的意向是
读取层次结构中的全部底层资源并修改部分（而
不是全部）底层资源。
? SIX锁等同于加 S锁、再加 IX锁。
? 例如，对表实施 SIX锁，则意味着要对表实施 S
锁，并对表中的某个（些）元组实施 X锁；
? 或者说，当需要对表实施 S锁，并对表中的某个
（些）元组实施 X锁时，应该首先对表实施 SIX
锁。
死锁
? 产生死锁的原因
? 避免死锁
? 发现死锁
? 解决死锁
产生死锁的原因
? 右图示意了两个并发事务
所发生事件的序列，假设
程序 A为了完成某个事务
需要封锁仓库和职工两个
关系，而几乎在同一时刻
并发执行的程序 B为完成
另一个事务也需要封锁职
工和仓库关系，这两个程
序正好按照如图所示的交
错序列执行命令，结果两
个程序都为了等待对方释
放数据资源而产生死锁。
避免死锁
? 相同顺序法
– 所有的用户程序约定都按相同的顺序来封锁表
? 一次封锁法
– 为了完成一个事务，一次性封锁所需要的全部表
? 两阶段封锁协议
– 所有事务都必须将对数据的封锁分为封锁和释放两个
阶段
避免死锁的封锁
两阶段封锁协议
? 第一阶段称为扩展阶段，这一阶段获得各种类型
的封锁，但是不能释放任何封锁。
? 第二阶段称为收缩阶段，这一阶段释放各种类型
的封锁，一旦开始释放封锁，则不能再申请任何
类型的封锁。
? 注意，两阶段封锁协议和一次封锁法的异同之处。
一次封锁法遵守两阶段封锁协议；但是两阶段封
锁协议并不要求一次封锁所有需要封锁的数据。
两阶段封锁协议仍有可能发生死锁。
发现死锁
? 超时法
– 即一个事务在等待的时间超过了规定的时限后就认为
发生了死锁。
– 这种方法非常不可靠，如果设置的等待时限长，则不
能及时发现死锁；如果设置的等待时限短，则可能会
将没有发生死锁的事务误判为死锁。
发现死锁
? 等待图法
– 即通过有向图判定事务是否是
可串行化的，如果是则说明没
有发生死锁，否则说明发生了
死锁。
– 具体思路是：用节点来表示正
在运行的事务，用有向边来表
示事务之间的等待关系，如右
图所示，如果有向图中发现回
路，则说明发生了死锁。
解决死锁
? 发现死锁后解决死锁的一般策
略是：自动使“年轻”的事务
（即完成工作量少的事务）先
退回去，然后让“年老”的事
务（即完成工作量多的事务）
先执行，等“年老”的事务完
成并释放封锁后，“年轻”的
事务再重新执行。
封锁与隔离级别
? 可以通过指定隔离级别或对数据资源实施封锁达到事务隔
离的目的；
? 封锁是实现并发操作的传统方法（在 SQL标准中没有提及
封锁），适当的运用封锁并保证高并发操作性能是一件非
常复杂的工作，这需要用户深入了解各种封锁的相容性，
并设计封锁的调度策略；
? SQL标准中规定了事务的隔离级别，即未提交读、提交读、
可重复读和可串行化，隔离级别解决了并发事务可能产生
的丢失更新问题、未提交依赖问题、不一致分析问题和幻
象读问题，其中为了避免丢失更新问题，事务必须运行在
可重复读或可串行化隔离级别。
? 用户可以根据事务的需要设定隔离级别，结果由数据库管
理系统控制封锁和进行并发操作调度。
封锁与隔离级别
? 在实际应用中，也可以将隔离级别和封锁结合起
来使用。例如，如果指定隔离级别是可重复读，
则 SQL会话中所有 SELECT语句的锁定行为都运
行于该隔离级别上，并一直保持有效，直到会话
终止或者将隔离级别设置为另一个级别。如果必
要，可以通过指定表级封锁来替代单个 SELECT
语句的隔离级别，指定表级封锁不会影响会话中
的其他语句。一般仅在绝对必要时才使用表级封
锁更改默认的锁定行为。
恢 复
? 故障类型
? 备份类型
? 日志的概念
? 恢复模型
? 备份或转储
? 恢复或还原
故障类型
? 造成事务中断的故障
– 突然掉电引起的事务中断
– 硬件故障引起的事务中断
– 客户应用程序出错引起的事务中断
– 系统程序故障引起的事务中断
? 磁盘介质故障
备份类型
? 双机热备份
? 双工备份
? 磁盘镜像
? 数据库备份技术
日志的概念
? 日志则是对备份的补充，它可以看作是一个值班日记，
它将记录下所有对数据库的更新操作。这样就可以在备
份完成时立刻刷新并启用一个数据库日志，数据库日志
是实时的，它将忠实地记录下所有对数据库的更新操作。
? 当磁盘出现故障造成数据库损坏时，就可以首先利用备
份恢复数据库（恢复大部分数据），然后再运行数据库
日志，即将备份后所做的更新操作再重新做一遍，从而
将数据库完全恢复。
? 为了保证日志的安全，应该将日志和主数据库安排在不
同的存储设备上，否则日志和数据库可能会同时遭到破
坏，日志也就失去了它本来的作用。
恢复模型
? 简单恢复模型
– 允许将数据库恢复到最新的备份, 即使用简单恢复模
型可以将数据库恢复到上次备份的即时点, 而无法将
数据库恢复到故障点或特定的即时点 。 使用简单恢复
模型, 日志实际失去了作用 。 使用简单恢复模型的数
据库只能做数据库备份, 不能做日志备份 。
? 完全恢复模型
– 允许将数据库恢复到故障点状态, 即完全恢复模型使
用数据库备份和事务日志备份提供对介质故障的完全
防范 。
恢复模型
? 可以使用 ALTER DATABASE语句的 RECOVERY子
句设置恢复模型 。
? 例如, 如下语句将订货数据库的恢复模型设置为完
全恢复：
ALTER DATABASE 订货 SET RECOVERY FULL
备份或转储
? 备份的类型
? 动态备份和静态备份
? 制定备份的策略
? 备份整个数据库
? 增量备份
? 事务日志备份
? 文件和文件组备份
? 系统数据库的备份
备份的类型
? 全备份：即完整的备份整个数据库；
? 增量备份：增量数据库备份只备份自上次数据库
备份后发生更改的数据；
? 文件和文件组备份：备份数据库文件或文件组，
而不是备份数据库；
? 事务日志备份：只备份事务日志。
动态备份和静态备份
? 动态备份也称作在线备份，即在做备份时不中断
数据库的运行，不中断数据库上的应用程序和事
务处理。
? 静态备份也称作离线或脱机备份，这意味着在做
备份时没有任何数据库事务在运行，这种备份方
式应是首选的备份方式。
制定备份的策略
? 备份不是实时的，备份应该什么时候做？用什么
方式做？这根据数据库的不同规模、不同用途，
可能有很多因素需要考虑和衡量。
备份整个数据库
? 在 SQL Server中系统管理员和数据库管理
员可以进行备份，也可以指定某个用户担
当 db_backupoperator角色（数据库预定义
角色）来负责数据库的备份工作。
? 所有的备份工作可以在“企业管理器”中
利用交互工具完成，也可以使用命令方式
完成。
备份整个数据库
? 备份数据库的命令是 BACKUP DATABASE,一般格式如
下：
BACKUP DATABASE database_name
TO {DISK | TAPE } ='physical_backup_device_name'
? 例如，如下命令将订货数据库备份到 C:\dump\dump1.bak：
BACKUP DATABASE 订货
TO DISK='C:\dump\dumpfull.bak'
增量备份
? 增量备份的命令也是 BACKUP DATABASE,一般格式如
下：
BACKUP DATABASE database_name
TO {DISK | TAPE } ='physical_backup_device_name'
WITH DIFFERENTIAL
? 例如，如下命令将对订货数据库做增量备份（备份到
C:\dump\dump1.bak）：
BACKUP DATABASE 订货
TO DISK='C:\dump\dump1.bak'
WITH DIFFERENTIAL
事务日志备份
? 备份事务日志的命令是 BACKUP LOG,一般格式是：
BACKUP LOG database_name
TO {DISK | TAPE } ='physical_backup_device_name'
? 例如，如下命令将备份订货数据库的日志（备份到
C:\dump\dumplog.bak）：
BACKUP LOG 订货
TO DISK='C:\dump\dumplog.bak'
截断日志
? 截断日志的命令是：
BACKUP LOG database_name
WITH TRUNCATE_ONLY
? 例如，在备份了订货数据库或事务日志后，为了
截断订货管理数据库的事务日志可以使用如下命
令：
BACKUP LOG 订货
WITH TRUNCATE_ONLY
文件和文件组备份
? 可以备份和恢复数据库中的个别文件，这样当遇
到介质故障时可以只恢复已损坏的文件，而不用
恢复数据库的其余部分，从而加快了恢复速度。
? 对于超大型数据库，有时不可能完成完整数据库
的备份，这样则可以使用文件备份。文件备份为
数据库备份提供了一种灵活的手段。
? 与数据库备份相比，文件备份的主要缺点是增加
了管理的复杂性。必须注意维护完整的文件备份
集和所覆盖的日志备份。
文件和文件组备份
? 备份文件或文件组的一般命令格式是：
BACKUP DATABASE database_name
{FILE = logic_file_list | FILEGROUP = filegroup_list }
TO {DISK | TAPE } ='physical_backup_device_name'
[ WITH DIFFERENTIAL ]
文件和文件组备份
? 例如，如下命令完成对订货数据库 warehouse文件
的备份：
BACKUP DATABASE 订货
FILE = 'warehouse'
TO DISK ='C:\dump\file_1.bak'
? 如下命令则完成对订货数据库文件组仓库的备份：
BACKUP DATABASE 订货
FILEGROUP = '仓库 '
TO DISK ='C:\dump\file_g.bak'
系统数据库的备份
? 数据库备份不仅仅是要备份用户数据库，系统数
据库也需要备份，例如 SQL Server中的 master、
model和 msdb等系统数据库。特别是 master数
据库，它负责整个数据库的管理，所有用户创建
的数据库以及用户登录信息都存储在该数据库中。
所以，该数据库一旦损坏，整个系统的使用都将
受到影响。
恢复或还原
? 恢复整个数据库
? 恢复数据库的部分内容
? 恢复特定的文件或文件组
? 恢复事务
可以将数据库恢复到做备份的即时点、
发生故障的即时点或特定的事务即时点。
恢复或还原
? 根据数据库全备份进行恢复
? 根据增量备份进行恢复
? 根据事务日志进行恢复
? 根据文件或文件组备份进行恢复
? 恢复系统数据库
根据数据库全备份进行恢复
RESTORE DATABASE database_name
FROM {DISK | TAPE }
='physical_backup_device_name'
[ WITH
[ [,] { NORECOVERY | RECOVERY } ]
[ [,] REPLACE ]
]
根据增量备份进行恢复
? 在简单恢复模型和完全恢复模型中都可以选择增量备
份，如果存在增量备份，则一般需要进行相应的恢复
操作。
? 增量恢复数据库的命令也是 RESTORE DATABASE，
但是在根据增量备份继续恢复之前应该：已经使用
RESTORE DATABASE命令完成了全备份的恢复，
同时指定了 NORECOVERY子句。
根据事务日志进行恢复
? 利用日志可以将数据库恢复到最新的一致状态或
任意的事务点。
? 首先恢复事务日志备份之前的数据库备份或增量
数据库备份。
? 如果有多个日志备份，则按先后顺序进行恢复。
根据事务日志进行恢复
RESTORE LOG database_name
FROM {DISK | TAPE } ='physical_backup_device_name'
[ WITH
[ [,] { NORECOVERY | RECOVERY } ]
[ [,] STOPAT = date_time
| [,] STOPATMARK = 'mark_name' [AFTER datetime]
| [,] STOPBEFOREMARK = 'mark_name'
[AFTER datetime] ]
]
根据文件或文件组备份进行恢复
? 如果数据库的某个文件损坏了，并且按文件或文
件组做了备份，则可以考虑根据文件或文件组备
份进行恢复。
? 当使用文件或文件组备份进行恢复时，最后一个
文件或文件组恢复操作完成后，必须将事务日志
应用于数据库文件，以便使之与数据库的其余部
分保持一致。如果被恢复的文件自上次备份后没
有做过任何修改操作，则不必应用事务日志，
RESTORE语句会报告这一情况。
根据文件或文件组备份进行恢复
RESTORE DATABASE database_name
{ FILE = logical_file_name
| FILEGROUP = logical_filegroup_name }
FROM {DISK | TAPE } ='physical_backup_device_name'
恢复系统数据库
? 备份系统数据库与备份用户数据库的方式相同，
除 master数据库之外其他系统数据库的恢复也
与恢复用户数据库类似。
? master数据库是所有数据库的主数据库，也是
管理所有数据库的数据库。恢复其他数据库都是
在 SQL Server能够正常运行的基础上进行的，
而 master数据库的损坏可能导致 SQL server根
本不能运行，所以恢复 master数据库是一件特
殊的任务。
恢复 master数据库
? 如果 master数据库只是轻微损坏或信息丢失,master数
据库的内容至少部分可用，从而能够启动 SQL Server实
例，则可以直接根据 master数据库的完整备份恢复
master数据库。
? 如果由于 master数据库严重损坏而无法启动 SQL Server
实例，则不能立即恢复 master数据库。因为 SQL Server
实例需要处于运行状态才能恢复任何数据库。为此，需
要首先使用重建 master数据库实用工具 Rebuildm.exe
（ 该程序位于 Program Files\Microsoft SQL Server\80\Tools\Binn目
录中）重建 master数据库，然后才可以用普通方法利用
备份恢复 master数据库。
【本章小节】
?事务的概念
?事务的性质
?并发控制
?恢复
