第08章 事务管理

第8章

事务管理

事

务

并发控制

恢

复

事

务

事务的概念

事务的性质

可串行性和隔离级别

SQL对事务的支持

事务的概念事务是构成单一逻辑工作单元的操作集合。

为什么需要事务的概念呢？

恢复的需要并发操作的需要事务的性质

原子性（Atomicity）

一致性（Consistency）隔离性（Isolation）

持久性（Durability）

事务的这些性质通常称为ACID特性原子性

事务的原子性强调了一个事务是一个逻辑工作单元，是一个整体，是不可分割的。一个事务所包含的操作要么全部做，要么全部不做。

一致性

一个事务执行一项数据库操作，事务将使数据库从一种一致性的状态变换成另一种一致性状态。

在事务执行前，总是假设数据库是一致的，那么当事务成功执行后，数据库肯定仍然是一致的。

隔离性

如果每个事务单独执行能保持原子性和一致性，这些事务并发执行也能保持原子性和一致性，则是事务的隔离性。持久性

事务的持久性是指一旦事务成功完成，该事务对数据库所施加的所有更新都是永久的。

可串行性可串行性通常看作是多个事务并发执行的正确性准则。具体判定方法如下：各单个事务如能将数据库从一个正确状态转变为另一个正确状态，则认为该事务是正确的；

按任何一个串行顺序依次执行多个事务也是正确的（这里的串行顺序假定各个事务间彼此独立、不交叉）；

事务的交叉执行过程是正确的，当且仅当其与串行执行过程等价，则事务是可串行化的。

SQL对事务的支持

开始事务

结束事务

事务保存点

隐含事务与自动提交

开始事务

使用BEGINTRANSACTION命令显式说明一个事务开始，它说明了对数据库进行操作的一个单元的起始点。在事务完成之前出现任何操作错误和故障，都可以撤销事务，使事务回退到这个起始点。

结束事务

成功结束事务的命令是COMMITTRANSACTION，它的作用是提交或确认事务已经完成，所以该命令也称作事务提交。

撤消事务的命令是ROLLBACKTRANSACTION，即撤消在该事务中对数据库所做的更新操作，使数据库回退到事务的起始点。

事务保存点

SQL标准还支持“事务保存点”技术，所谓事务保存点就是在事务的过程中插入若干标记，这样当发现事务中有操作错误时，可以不撤消整个事务，只撤消部分事务，即将事务回退到某个事务保存点。

并发控制

干扰问题

解决干扰——封锁

封锁不当——死锁

封锁与隔离级别

干扰问题

丢失更新问题

未提交依赖问题

不一致分析问题

幻象读问题

丢失更新问题

例：旅客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术语描述丢失更新问题未提交依赖问题

未提交依赖问题也称为读“脏”（DirtyRead）数据问题，查询一个已经被其他事务更新、但尚未提交的元组，将会引起未提交依赖问题。

不一致分析问题

不一致分析问题也称为不可重复读问题，很多应用可能需要校验功能，这时往往需要连续两次或多次读数据进行校验和分析，结果由于其他事务的干扰，使得前后结果不一致，从而产生校验错误（即不一致的分析）。

幻象读问题

幻象读问题与不一致分析问题有关，当事务A读数据时，事务B在对同一个关系进行插入或删除操作，这时事务A再读同一条件的元组时，会发现神秘地多出了一些元组或丢失了一些元组，把这种现象称作幻象读。

封锁

封锁的基本技术

封锁机制

SQLServer中与封锁有关的命令

封锁粒度

意向锁

封锁的基本技术当需要查询或更新数据时，先对数据进行封锁，以避免来自其他事务的干扰。针对不同的干扰问题可以有不同的封锁机制。

以丢失更新问题为例，实施封锁的基本思想是：当一个用户对一个表或记录进行更新时，封锁该表或记录，使其他用户不能在同一时刻更新相同的表或记录，迫使其他用户在更新后的基础上（而不是在更新前的基础上）再实施另外的更新操作。

封锁的基本技术实施封锁以后的时间序列封锁机制

共享封锁

独占封锁

更新封锁

有些封锁在执行完相应操作后就自动释放封锁，有些封锁则保持到事务结束（提交或撤消）时才释放（无论如何，所有的封锁都会在事务结束时自动释放）。共享封锁

共享封锁是为读操作设置的一种封锁，所以也称作读封锁，或简称S锁，目的是想读到一组不变的数据，也就是在读数据的过程中，不允许其他用户对该数据进行任何修改操作。这种封锁可以保证最大的并发性，任何数量的用户都可以同时对同样的数据施加这种共享锁。已经实施共享锁的表拒绝来自其他事务的独占封锁和更新封锁。

独占封锁

独占封锁也叫排他封锁，它是为修改操作设置的一种封锁，也称为写封锁，或简称为X锁，这是最严格的一类封锁。当需要对表实施插入、删除或修改操作时，应该使用独占封锁。已经实施独占封锁的表，拒绝来自其他用户的任何封锁，但不拒绝一般的查询操作。

更新封锁

当需要对一个记录或一组记录进行更新时（只是修改，不包括插入和删除）使用更新封锁，该封锁的目的是防止其他用户在同一时刻修改同一记录。已经实施更新封锁的记录，拒绝来自其他用户的任何封锁，但不拒绝一般的查询操作。

封锁粒度

封锁的对象可以是表、也可以是元组等，我们把封锁对象的大小称为封锁粒度（Granularity）。封锁的对象可以是逻辑单元（如表和元组等），也可以是物理单元（如数据页和数据块等）。数据库管理系统一般都具有多粒度锁定功能，允许一个事务锁定不同类型的资源。

意向锁

为了降低封锁的成本，提高并发的性能，数据库管理系统还支持一种意向锁（IntentionLock）。

意向锁表示一种封锁意向，当需要在某些底层资源上（如元组）获取封锁时，可以先对高层资源（如表）实施意向锁。意向锁意向共享（IS）

意向排它（IX）

共享意向排它（SIX）

死锁

产生死锁的原因

避免死锁

发现死锁解决死锁

产生死锁的原因右图示意了两个并发事务所发生事件的序列，假设程序A为了完成某个事务需要封锁仓库和职工两个关系，而几乎在同一时刻并发执行的程序B为完成另一个事务也需要封锁职工和仓库关系，这两个程序正好按照如图所示的交错序列执行命令，结果两个程序都为了等待对方释放数据资源而产生死锁。

避免死锁

相同顺序法

所有的用户程序约定都按相同的顺序来封锁表

一次封锁法

为了完成一个事务，一次性封锁所需要的全部表

两阶段封锁协议

所有事务都必须将对数据的封锁分为封锁和释放两个阶段

避免死锁的封锁

两阶段封锁协议

第一阶段称为扩展阶段，这一阶段获得各种类型的封锁，但是不能释放任何封锁。第二阶段称为收缩阶段，这一阶段释放各种类型的封锁，一旦开始释放封锁，则不能再申请任何类型的封锁。

注意，两阶段封锁协议和一次封锁法的异同之处。一次封锁法遵守两阶段封锁协议；但是两阶段封锁协议并不要求一次封锁所有需要封锁的数据。两阶段封锁协议仍有可能发生死锁。

发现死锁超时法

即一个事务在等待的时间超过了规定的时限后就认为发生了死锁。

这种方法非常不可靠，如果设置的等待时限长，则不能及时发现死锁；如果设置的等待时限短，则可能会将没有发生死锁的事务误判为死锁。

发现死锁等待图法

即通过有向图判定事务是否是可串行化的，如果是则说明没有发生死锁，否则说明发生了死锁。具体思路是：用节点来表示正在运行的事务，用有向边来表示事务之间的等待关系，如右图所示，如果有向图中发现回路，则说明发生了死锁。

解决死锁发现死锁后解决死锁的一般策略是：自动使“年轻”的事务（即完成工作量少的事务）先退回去，然后让“年老”的事务（即完成工作量多的事务）先执行，等“年老”的事务完成并释放封锁后，“年轻”的事务再重新执行。

恢

复

故障类型

备份类型

日志的概念

恢复模型

备份或转储

恢复或还原

故障类型造成事务中断的故障

突然掉电引起的事务中断

硬件故障引起的事务中断

客户应用程序出错引起的事务中断

系统程序故障引起的事务中断

磁盘介质故障

备份类型

双机热备份

双工备份

磁盘镜像

数据库备份技术

日志的概念

日志则是对备份的补充，它可以看作是一个值班日记，它将记录下所有对数据库的更新操作。这样就可以在备份完成时立刻刷新并启用一个数据库日志，数据库日志是实时的，它将忠实地记录下所有对数据库的更新操作。当磁盘出现故障造成数据库损坏时，就可以首先利用备份恢复数据库（恢复大部分数据），然后再运行数据库日志，即将备份后所做的更新操作再重新做一遍，从而将数据库完全恢复。恢复模型

简单恢复模型允许将数据库恢复到最新的备份，即使用简单恢复模型可以将数据库恢复到上次备份的即时点，而无法将数据库恢复到故障点或特定的即时点。使用简单恢复模型，日志实际失去了作用。使用简单恢复模型的数据库只能做数据库备份，不能做日志备份。完全恢复模型允许将数据库恢复到故障点状态，即完全恢复模型使用数据库备份和事务日志备份提供对介质故障的完全防范。备份或转储

备份的类型

备份整个数据库

增量备份

事务日志备份

文件和文件组备份

系统数据库的备份

数据库备份的类型

全备份：即完整的备份整个数据库；增量备份：增量数据库备份只备份自上次数据库备份后发生更改的数据；文件和文件组备份：备份数据库文件或文件组，而不是备份数据库；事务日志备份：只备份事务日志。恢复或还原

恢复整个数据库

恢复数据库的部分内容

恢复特定的文件或文件组

恢复事务

可以将数据库恢复到做备份的即时点、发生故障的即时点或特定的事务即时点。恢复或还原根据数据库全备份进行恢复

根据增量备份进行恢复

根据事务日志进行恢复

根据文件或文件组备份进行恢复

恢复系统数据库

根据数据库全备份进行恢复RESTOREDATABASEdatabase_nameFROM{DISK|TAPE}

='physical_backup_device_name'[WITH[[,]{NORECOVERY|RECOVERY}][[,]REPLACE]]根据增量备份进行恢复

在简单恢复模型和完全恢复模型中都可以选择增量备份，如果存在增量备份，则一般需要进行相应的恢复操作。

增量恢复数据库的命令也是RESTOREDATABASE，但是在根据增量备份继续恢复之前应该：已经使用RESTOREDATABASE命令完成了全备份的恢复，同时指定了NORECOVERY子句。

根据事务日志进行恢复

利用日志可以将数据库恢复到最新的一致状态或任意的事务点。

首先恢复事务日志备份之前的数据库备份或增量数据库备份。

如果有多个日志备份，则按先后顺序进行恢复。

根据事务日志进行恢复RESTORELOGdatabase_nameFROM{DISK|TAPE}='physical_backup_device_name'[WITH[[,]{NORECOVERY|RECOVERY

}][[,]STOPAT=

date_time|[,]STOPATMARK='mark_name'[AFTERdatetime]|[,]STOPBEFOREMARK='mark_name'

[AFTERdatetime]]]根据文件或文件组备份进行恢复

如果数据库的某个文件损坏了，并且按文件或文件组做了备份，则可以考虑根据文件或文件组备份进行恢复。

当使用文件或文件组备份进行恢复时，最后一个文件或文件组恢复操作完成后，必须将事务日志应用于数据库文件，以便使之与数据库的其余部分保持一致。如果被恢复的文件自上次备份后没有做过任何修改操作，则不必应用事务日志，RESTORE语句会报告这一情况。

根据文件或文件组备份进行恢复RESTOREDATABASEdatabase_name{FILE=

logical_file_name

|FILEGROUP=

logical_filegroup_name}F