简述

　　关系型数据库有四个显著的特征，即安全性、完整性、并发性和监测性。数据库的安全性就是要保证数据库中数据的安全，防止未授权用户随意修改数据库中的数据，确保数据的安全。在大多数数据库管理系统中，主要是通过许可来保证数据库的安全性。完整性是数据库的一个重要特征，也是保证数据库中的数据切实有效、防止错误、实现商业规则的一种重要机制。在数据库中，区别所保存的数据是无用的垃圾还是有价值的信息，主要是依据数据库的完整性是否健全。在SQL Server 7.0中，数据的完整性是通过一系列逻辑来保障的，这些逻辑分为三个方面，即实体完整性、域完整性和参考完整性。对任何系统都可以这样说，没有监测，就没有优化。这句话用在数据库管理系统方面，也是切合实际的。只有通过对数据库进行全面的性能监测，也才能发现影响系统性能的因素和瓶颈，才能针对瓶颈因素，采取切合实际策略，解决问题，提高系统的性能。并发性也是一个非常重要的概念，它是用来解决多个用户对同一数据进行操作时的问题。特别是对于网络数据库来说，这个特点更加突出。提高数据库的处理速度，单单依靠提高计算机的物理速度是不够的，还必须充分考虑数据库的并发性问题，提高数据库并发性的效率。那么如何保证并发性呢？在这个面向下一世纪的数据库产品SQL Server 7.0中，通过使用事务和锁机制，解决了数据库的并发性问题。

　　概念和特点

　　事务和锁是两个紧密联系的概念。事务就是一个单元的工作，包括一系列的操作这些操作要么全部成功，要么全部失败。事务确保多个数据的修改作为一个单元来处理。例如，在银行业务中，有一条记帐原则，即有借有贷，借贷相等。那么为了保证这种原则，就得有确保借和贷的登记要么同时成功，要么同时失败。如果出现只记录了借，或者只记录了贷，那么就违反了记帐原则，就会出现记错帐的情况。SQL Server通过支持事务机制管理多个事务，保证事务的一致性。事务使用锁，防止其他用户修改另外一个还没有完成的事务中的数据。对于多用户系统来说，锁机制是必须的。在SQL Server 7.0中，使用事务日志来保证修改的完整性和可恢复性。

　　SQL Server有多种锁，允许事务锁定不同的资源。锁就是保护指定的资源，不被其他事务操作。为了最小化锁的成本，SQL Server自动地以与任务相应等级的锁来锁定资源对象。锁定比较小的对象，例如锁定行，虽然可以提高并发性，但是却有较高的开支，因为如果锁定许多行，那么需要占有更多的锁。锁定比较大的对象，例如锁定表，会大大降低并发性，因为锁定整个表就限制了其他事务访问该表的其他部分，但是成本开支比较低，因为只需维护比较少的锁。

　　事务和锁具有以下特点:

　　事务是一个单元的工作，要么全做，要么全不做

　　事务保证操作的一致性和可恢复性

　　每一条Transact-SQL语句都可以是一个事务

　　实际使用的事务是用户定义的事务，它包括一系列操作或者语句

　　在多服务器环境中，使用用户定义的分布式事务，保证操作的一致性

　　锁是保证并发控制的手段

　　可以锁定的资源包括行、页、簇、表和数据库

　　锁的类型主要包括共享锁和排它锁

　　特殊类型的锁包括意图锁、修改锁和模式锁

　　共享锁允许其他事务继续使用锁定的资源

　　排它锁只允许一个事务访问数据

　　系统本身可以处理死锁

　　用户可以根据实际情况定制锁的一些特征

　　事务

　　事务的定义

　　事务是指一个单元的工作，这些工作要么全做，要么全部不做。作为一个逻辑单元，必须具备四个属性：自动性、一致性、独立性和持久性。自动性是指事务必须是一个自动的单元工作，要么执行全部数据的修改，要么全部数据的修改都不执行。一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。所有的内部数据结构，例如树状的索引与数据之间的链接，在事务结束之后，必须保证正确。独立性是指并行事务的修改必须与其他并行事务的修改相互独立。一个事务看到的数据要么是另外一个事务修改这些事务之前的状态，要么是第二个事务已经修改完成的数据，但是这个事务不能看到正在修改的数据。这种特征也称为串行性。持久性是指当一个事务完成之后，它的影响永久性的产生在系统中，也就是这种修改写到了数据库中。

　　事务机制保证一组数据的修改要么全部执行，要么全部不执行。SQL Server使用事务保证数据的一致性和确保在系统失败时的可恢复性。事务是一个可以恢复的单元的工作，由一条或者多条Transact-SQL语句组成，可以影响到表中的一行或者多行数据。事务打开以后，直到事务成功完成之后提交为止，或者到事务执行失败全部取消或者滚回去为止。

　　事务的工作原理图

　　事务确保数据的一致性和可恢复性。事务的工作原理如图1所示。

　　图1　 事务的工作原理图

　　事务开始之后，事务所有的操作都陆续写到事务日志中。写到日志中的操作，一般有两种：一种是针对数据的操作，一种是针对任务的操作。针对数据的操作，例如插入、删除和修改，这是典型的事务操作，这些操作的对象是大量的数据。有些操作是针对任务的，例如创建索引，这些任务操作在事务日志中记录一个标志，用于表示执行了这种操作。当取消这种事务时，系统自动执行这种操作的反操作，保证系统的一致性。系统自动生成一个检查点机制，这个检查点周期地发生。检查点的周期是系统根据用户定义的时间间隔和系统活动的频度由系统自动计算出来的时间间隔。检查点周期地检查事务日志，如果在事务日志中，事务全部完成，那么检查点将事务日志中的事务提交到数据库中，并且在事务日志中做一个检查点提交标记。如果在事务日志中，事务没有完成，那么检查点将事务日志中的事务不提交到数据库中，并且在事务日志中做一个检查点未提交标记。事务的恢复以及检查点保护系统的完整和可恢复，可以使用如图2所示的示例说明。

　　图2　 事务恢复和检查点示例

　　在这个示例图中，有五个事务：事务1、事务2、事务3、事务4和事务5。方框表示事务的开始和完成提交。水平方向表示时间。检查点表示在某一时间点发生检查点机制，系统失败表示在某一时间点由于断电、系统软件失败等原因而发生的系统失败。事务1的完成发生在检查点发生之间，所以事务1被提交到数据库中。事务2和事务4的完成发生在系统失败之前，所以这两个事务可以被系统向前滚动提交到数据库中。事务3和事务5由于系统失败而没有完成，所以这两个事务被取消。

　　使用事务的考虑

　　在使用事务时，原则上应该使事务尽可能得短并且要避免事务嵌套。事务应该尽可能得短，这是因为比较长的事务增加了事务占用数据的时间，使其它必须等待访问该事务锁定数据的事务，延长了等待访问数据的时间。在使用事务时，为了使事务尽可能得短，应该采取一些相应的方法。为了最小化时间，在使用一些Transact-SQL语句时，一定要非常小心。例如，当使用循环语句WHILE时，一定要事先确认循环的长度和占用的时间，使这种循环在完成相应的功能之前，一定要确保循环尽可能得短。在开始事务之前，一定要了解需要用户交互式操作才能得到的信息。这样，在事务的进行过程中，就可以避免进行一些耗费时间的交互式操作，缩短事务进程的时间。在一个用户定义的事务中，应该尽可能地使用一些数据操纵语言，例如INSERT、UPDATE和DELETE语句，因为这些语句主要是操纵数据库中的数据。而对于一些数据定义语言，应该尽可能地少用或者不用，因为这些数据定义语言的操作既占用比较长的时间，又占用比较多的资源，并且这些数据定义语言的操作通常不涉及到数据，所以应该在事务中尽可能地少用或者不用这些操作。另外，在使用数据操纵语言时，要注意，一定要在这些语句中使用条件判断语句，使得这些数据操纵语言涉及到尽可能少的记录，从而缩短事务的处理时间。

　　在嵌套事务时，也要注意一些问题。虽然说，在事务中间嵌套事务是可能的，并不影响SQL Server处理事务的性能。但是，实际上，使用嵌套事务，除了把事务搞得更加复杂之外，并没有这么明显的好处。因此，不建议使用嵌套事务。

　　事务的类型

　　根据系统的设置，可以把事务分成两种类型。一种是系统提供的事务，另一种是用户定义的事务。系统提供的事务是指在执行某些语句时，一条语句就是一个事务。这时要明确，一条语句的对象既可能是表中的一行数据，也可能是表中的多行数据，甚至是表中的全部数据。因此，只有一条语句构成的事务也可能包含了多行数据的处理。例如执行下面这条数据操纵语句：

　　UPDATE　authors

　　SET