互联网数据库05（自考0911）.pptVIP

本章重点： 1. 安全性 2. 完整性 3. 并发控制 4. 恢复 表5.10 可重读问题 时间 事务T1 数据库中R的值 事务T2 t0 ? 1000 ? t1 SLOCK R ? ? t2 FIND R ? ? t3 ? ? XLOCK R t4 COMMIT WAIT ? t5 UNLOCK S ? WAIT t6 ? ? XLOCK R t7 ? ? FIND R T8 ? ? R=R-200 t9 ? ? UPDATE R t10 ? ? UNLOCK X 封锁粒度（Lock Granularity） 封锁粒度指封锁的单位。 根据对数据的不同处理，封锁的对象可以是这样一些逻辑单元：字段、记录、表、数据库等。 封锁粒度与系统的并发度和并发控制的开销密切相关。 封锁粒度越小，系统中能够被封锁的对象就越多，并发度越高，但封锁机构复杂，系统开销也就越大。相反，封锁粒度越大，系统中能够被封锁的对象就越少，并发度越小，封锁机构简单，相应系统开销也就越小。 因此，在实际应用中，选择封锁粒度时应同时考虑封锁机构和并发度两个因素，对系统开销与并发度进行权衡，以求得最优的效果。 由于同时封锁一个记录的概率很小，一般数据库系统都在记录级上进行封锁，以获得更高的并发度。 死锁和活锁 封锁技术可有效解决并行操作的一致性问题，但也可产生新的问题，即活锁和死锁问题。 1．活锁（Livelock） 当某个事务请求对某一数据的排它性封锁时，由于其他事务对该数据的操作而使这个事务处于永久等待状态，这种状态称为活锁。 例如，事务T1在对数据R封锁后，事务T2又请求封锁R，于是T2等待。T3也请求封锁R。当T1释放了R上的封锁后首先批准了T3的请求，T2继续等待。然后又有又T4请求封锁R，T3释放了R上的封锁后又批准了T4的请求……T2可能永远处于等待状态，从而发生了活锁。如表5.11所示。 表5.11 活锁 时间 事务T1 事务T2 事务T3 事务T4 t0 LOCK R ? ? ? t1 … LOCK R ? ? t2 ? WAIT LOCK R ? t3 UNLOCK WAIT WAIT LOCK R t4 … WAIT LOCK R WAIT t5 ? WAIT ? WAIT t6 ? WAIT UNLOCK WAIT t7 ? WAIT ? LOCK R T8 ? WAIT ? ? 避免活锁的简单方法是采用先来先服务的策略，按照请求封锁的次序对事务排队，一旦记录上的锁释放，就使申请队列中的第一个事务获得锁。 有关活锁的问题我们不再详细讨论，因为死锁的问题较为常见，这里主要讨论有关死锁的问题。 1．死锁（Deadlock） 在同时处于等待状态的两个或多个事务中，其中的每一个在它能够进行之前，都等待着某个数据、而这个数据已被它们中的某个事务所封锁，这种状态称为死锁。 例如，事务T1在对数据R1封锁后，又要求对数据R2封锁，而事务T2已获得对数据R2的封锁，又要求对数据R1封锁，这样两个事务由于都不能得到封锁而处于等待状态，发生了死锁。如表5.12所示。 表5.12 死锁 时间 事务T1 事务T2 t0 LOCK R1 ? t1 ? LOCK R2 t2 ? … t3 LOCK R2 ? t4 WAIT ? t5 WAIT LOCK R1 t6 WAIT WAIT t7 WAIT WAIT A（assertion）：代表数据对象必须满足的语义约束，这是规则的主体； C（condition）：代表选择A作用的数据对象值的谓词； P（procdure）：代表违反完整性规则时触发执行的操作过程。 例如，对于“学号不能为空”的这条完整性约束， D：代表约束作用的数据对象为SNO属性； O（operation）：当用户插入或修改数据时需要检查该完整性规则； A（assertion）：SNO不能为空； C（condition）：A可作用于所有记录的SNO属性； P（procdure）：拒绝执行用户请求。 关系模型的完整性包括实体完整性，参照完整性和用户定义完整性。 对于违反实体完整性和用户定义完整性规则的操作一般都是采用拒绝执行的方式进行处理。 而对于违反参照完整性的操作，并不都是简单的拒绝执行，一般在接受这个操作的同时，执行一些附加的操作，以保证数据库的状态仍然是正确的。 例如在删除被参照关系中的元组时，应该将参照关系中所有的外码值与被参照关系中要删除元组主码值相对应的元组