8数据库的并发性控制.docVIP

上一章：数据库监视和优化 第八章 数据库的并发性控制 提纲： 能够被加锁的数据库对象 DB2支持的锁的模式及其兼容性 隔离级的概念及使用 影响加锁策略的因素 8.1、锁的概念 作为一个大型的关系数据库系统，应该能够允许多个应用程序同时对相同数据进行访问。当这种情况发生时，要保证数据库的完整性，就必须要有一定的机制用于控制数据记录的读取、插入、删除和更新。锁就是一种这样的机制。我们可以通过调整数据库加锁的策略，来适应一定的并发性的需求。 通过对数据库对象加锁，我们可以避免以下情况的发生： 由于并发更改造成数据的丢失 例如下表： reservations： FLIGHT SEAT P_NAME 512 7A NULL 512 7C NULL 想象如下场景： Bob和John 两人同时来到不同的航空代理处购买512航班的机票，两个代理都想为自己的顾客预订7A座位，然后两个代理同时输入下列命令： 代理1: update reservations set p_name=’Bob’ where flight=512 and seat=’7A’ and p_name is null; 代理2: update reservations set p_name=’John’ where flight=512 and seat=’7A’ and p_name is null; 如果没有一定的机制阻止对同一数据的并发更改，则两个代理都会收到更改成功的信息。Bob和John将会在机场出现并认为他们都已经预订好座位。 如果我们使用了加锁机制进行控制，这种情况可以避免。 避免对未提交数据的存取 未提交数据是指被命令所更改，但还未被提交的数据。在很多情况下，如果允许用户对未提交的数据进行存取而该数据最终未被提交，用户依据其作出的决定有可能是错误的。 例如下表： reservations FLIGHT SEAT P_NAME 512 7A Mary 512 7C NULL 想象如下场景： 在512航班上7C是唯一剩下的座位，现在Bob来到某个航空代理处想购买512航班的机票，该代理发现7C是唯一剩下的座位。于是键入下列命令： update reservations set p_name=’Bob’ where flight=512 and seat=’7C’ and p_name=NULL 这时，John来到另外一个航空代理处想购买512航班的机票，该代理输入下列查询命令： select seat from reservations where p_name is NULL 如果不阻止对未提交数据的读取，则由于7C已经被Bob预订了，则该语句返回的记录数为零，意味着该航班已经客满，John没有能买到座位。 过了一会儿，Bob认为该航班太贵，于是，该事务相应地回滚，7C座位被空出。如果数据库通过加锁机制阻止对未提交数据的存取，John可以买到7C座位。 DB2可以通过加锁机制来阻止对未提交数据的访问。当然，在某些情况下，对未提交数据的访问是允许的。 防止不可重复读 不可重复读是指由于在同一事务中，两次执行同样的Select语句，得到的结果不同。这种情况会导致原先作出的决定由于条件的更改会产生偏差。 例如下列航班表： 航班 座位 旅客名称 目的地 出发地 512 7B DENVER DALLAS 814 8A SAN JOSE DENVER 134 1C HONOLULU SAN JOSE 想象以下场景： John需要从DALLAS飞往HONOLULU，他找到航空代理处，该代理发现没有直达航班，但可以从DALLAS到DENVER到SAN JOSE再到HONOLULU的路线（如上表）。John正在决定该路线是否可行时，Bob从另外一个航空代理处预订了814航班的8 A座位。而这恰好是该航班的最后一个座位。如果这时John决定代理提供的路线可行，决定购买时，却发现该路线已经不能成立，John必须重新选择路线。 采用加锁机制，DB2能够支持可重复读请求，它可以允许或阻止应用程序修改其它应用程序正在访问的数据。 8.2、锁的对象、策略及模式 8.2.1、锁的对象 DB2支持对表空间、表、行和索引加锁（大型机上的数据库还可以支持对数据页加锁）来保证数据库的并发完整性。不过在考虑用户应用程序的并发性的问题上，通常并不检查用于表空间和索引的锁。该类问题分析的焦点在于表锁和行锁。 8.2.2、加锁策略 DB2可以只对表进行加锁，也可以对表和表中的行进行加锁。如果只对表进行加锁，则表中所有的