数据库并发控制与恢复管理全解析

### 数据库并发控制与恢复管理全解析 在数据库管理中，并发控制和恢复管理是至关重要的环节。并发控制确保多个事务能够安全、高效地同时执行，而恢复管理则在数据库出现故障时将其恢复到一致状态。下面将详细介绍相关的技术和方法。 #### 共享/排他锁机制 共享/排他锁机制是并发控制的基础。锁有三种状态：未锁定、共享（读）和排他（写）。两个事务只有在至少有一个是写事务时才会发生冲突，因为两个读事务可以安全地同时执行。共享锁允许多个读事务同时读取同一数据项。例如，若事务T1对数据项X持有共享锁，事务T2想读取数据项X，T2也可以获得数据项X的共享锁。 若事务T2要更新数据项X，则需要对数据项X持有排他锁。排他锁只有在该数据项上没有其他锁时才会被授予。若事务T1已对数据项X持有共享或排他锁，事务T2就无法获得排他锁，必须等待T1提交。这就是互斥规则：同一时间只有一个事务能对同一对象持有排他锁。 共享/排他锁模式虽然提高了数据访问效率，但也增加了锁管理器的开销，原因如下： - 授予锁之前必须知道持有的锁类型。 - 存在三种锁操作：READ_LOCK（检查锁类型）、WRITE_LOCK（发放锁）和UNLOCK（释放锁）。 - 该模式支持锁升级（从共享到排他）和锁降级（从排他到共享）。 锁虽然能防止严重的数据不一致，但也会导致两个主要问题： - 事务调度可能不可序列化。 - 可能产生死锁，即两个事务无限期地等待对方解锁数据。 #### 两阶段锁协议 两阶段锁协议用于确保事务调度的可序列化，但不能防止死锁。该协议分为两个阶段： 1. **增长阶段**：事务获取所有所需的锁，期间不释放任何数据的锁。当获取所有锁后，事务进入锁定点。 2. **收缩阶段**：事务释放所有锁，且不能再获取新锁。 两阶段锁协议遵循以下规则： - 两个事务不能有冲突的锁。 - 同一事务中，解锁操作不能在加锁操作之前。 - 直到获取所有锁（即事务到达锁定点），才会影响数据。 ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A([开始]):::startend --> B(获取锁):::process B --> C(获取锁):::process C --> D(锁定点):::process D --> E(释放锁):::process E --> F(释放锁):::process F --> G([结束]):::startend ``` 两阶段锁协议会增加事务处理成本，还可能导致死锁等不良影响。 #### 死锁及其控制 死锁是指两个事务无限期地等待对方解锁数据。例如，事务T1访问数据项X和Y，事务T2访问数据项Y和X。若T1未解锁数据项Y，T2无法开始；若T2未解锁数据项X，T1无法继续。这种情况也被称为“致命拥抱”。 在实际的数据库管理系统中，同时执行的事务越多，产生死锁的概率就越高。需要注意的是，只有当其中一个事务想获取数据项的排他锁时才可能发生死锁，共享锁之间不会出现死锁。 控制死锁的基本技术有三种： 1. **死锁预防**：当有发生死锁的可能性时，请求新锁的事务将被中止。事务被中止后，其所有更改将被回滚，获取的所有锁将被释放，然后重新安排执行。 2. **死锁检测**：数据库管理系统定期检查数据库是否存在死锁。若发现死锁，会中止其中一个事务（“受害者”），并回滚和重新启动该事务，另一个事务则继续执行。 3. **死锁避免**：事务必须在执行前获取所有所需的锁。这种技术通过要求依次获取锁来避免冲突事务的回滚，但会增加操作响应时间。 选择最佳的死锁控制方法取决于数据库环境。例如，若死锁概率较低，建议使用死锁检测；若死锁概率较高，建议使用死锁预防；若系统对响应时间的优先级不高，可采用死锁避免。 #### 时间戳方法 时间戳方法通过为每个事务分配全局唯一的时间戳来安排并发事务的执行顺序。时间戳必须具有唯一性和单调性，唯一性确保没有相等的时间戳值，单调性确保时间戳值始终递增。 同一事务内的所有数据库操作（读和写）必须具有相同的时间戳。数据库管理系统按时间戳顺序执行冲突操作，从而确保事务的可序列化。若两个事务冲突，其中一个将被停止、回滚、重新安排，并分配新的时间戳值。 时间戳方法的缺点是数据库中存储的每个值需要两个额外的时间戳字段：一个用于最后一次读取该字段的时间，一个用于最后一次更新的时间。这增加了内存需求和数据库的处理开销，因为可能需要停止、重新安排和重新标记许多事务。 #### 等待/死亡和伤害/等待方案 时间戳方法用于管理并发事务执行，而等待/死亡和伤害/等待方案则用于决定哪个事务回滚，哪个继续执行。 假设两个冲突的事务T1和T2，T1的时间戳为11548789，T2的时间戳为19562545，可知T1是较旧的事务（时间戳值较低），T2是较新的事务。两种方案的四种可能结果如下表所示： | 请求锁的事务 | 持有锁的事务 | 等待/死亡方案 | 伤害/等待方案 | | --- | --- | --- | --- | | T1 (11548789) | T2 (19562545) | T1等待直到T2完成并释放锁 | T1抢占（回滚）T2，T2使用相同时间戳重新安排 | | T2 (19562545) | T1 (11548789) | T2死亡（回滚），使用相同时间戳重新安排 | T2等待直到T1完成并释放锁 | 在等待/死亡方案中，请求锁的较旧事务会等待较新事务完成并释放锁；较新事务则回滚并重新安排。在伤害/等待方案中，请求锁的较旧事务会回滚较新事务并重新安排；较新事务则等待较旧事务完成并释放锁。 为防止死锁，每个锁请求都有一个关联的超时值。若在超时时间内未授予锁，事务将被回滚。 #### 乐观方法 乐观方法基于大多数数据库操作不会冲突的假设，不需要锁定或时间戳技术。事务在提交前无限制地执行，每个事务会经历两个或三个阶段：读、验证和写。 - **读阶段**：事务读取数据库，执行所需的计算，并将更新应用到数据库值的私有副本