数据库并发控制中的基本封锁类型

在数据库管理系统（DBMS）中，通常会提供多种类型的锁机制。其中，排它锁（X锁）又称为写锁，当事务对数据对象加上X锁后，只允许该事务读取和修改该对象，其他事务无法再对该对象加任何类型的锁，直到释放X锁。共享锁（S锁）又称为读锁，当事务对数据对象加上S锁后，其他事务只能再对该对象加S锁，不能加X锁，直到释放S锁。这些锁的类型决定了事务对数据对象的访问控制和并发处理方式。

顺序封锁是一种在SQL数据库系统中常见的并发控制策略，它预先规定了数据对象的封锁顺序，所有事务均按此顺序执行封锁。然而，顺序封锁策略面临着高昂的维护成本和动态变化的数据对象挑战，例如数据的插入和删除操作会使得封锁顺序难以长期稳定。此外，事务在执行过程中动态决定封锁请求，进一步增加了实施顺序封锁的复杂性。

在处理SQL并发控制中的脏数据时，使用封锁机制是一种有效的方法。例如，事务T1在修改C之前会对A加上X锁，确保其他事务如T2在请求C的S锁时被拒绝，从而避免T2读取到脏数据。即使T1撤销后，C的值恢复为100，T2在等待T1释放锁之后再读取C的值，仍然可以确保数据的一致性。这种方法有效地解决了并发操作中的数据安全问题。

尽管单个事务的独立执行不会破坏数据库的完整性，但是当它们并发执行时，如果没有适当的控制，可能会导致以下问题：1. 并发不一致问题：A B A 1）不可重复读：事务T读取X；事务T修改X为X’；事务T再次读取X（实际上读取到了X’）； 2）脏读：事务T修改X为X’；事务T读取X（实际上读取到了X’）；事务T被回滚，X’又恢复为X； A A B

在SQL并发控制中，事务T在修改数据R之前需先加X锁，并在事务结束时释放。一级封锁协议确保了修改的数据不会丢失，尽管它不能保证可重复读和避免读取“脏”数据。

在数据库事务处理与并发控制过程中，我们可以通过以下案例来说明并发异常的问题。假设有两个事务同时执行，事务1和事务2。初始时刻，数据库中数值为1。事务1读取A的值并将其加上40，然后写回数据库，使得A的值变为140，并提交事务。而事务2在事务1提交后读取A的值为140，并将其加上50，最后将结果190写回数据库并提交事务。这种并发执行导致最终数据库中A的值不符合预期，展示了并发控制的必要性。

乐观的并发控制与传统方法不同，它不对事务执行过程进行检查，也不立即对数据库进行修改，而是在事务结束时进行有效性检查。如果事务执行不会破坏可串性，则提交事务；否则撤销并回滚事务，重新尝试。该协议包括三个阶段：1）读取阶段，事务从数据库直接读取数据项X的值，但修改保持在副本中；2）有效性阶段，在提交操作之前，对操作结果进行有效性（可串性）检查；3）写入阶段，如果通过有效性检查，则将事务操作结果写回数据库，否则放弃修改结果，重新尝试事务。这种方法在冲突操作较少时效率较高，但在冲突操作增多时，可能导致大量重启，从而降低效率。

ORACLE数据库是一个多用户共享的资源。在多用户并发存取数据时，可能会出现多个事务同时访问同一数据的情况。如果没有适当的并发控制，可能导致数据读取和存储不正确，从而破坏数据库的一致性。

在多处理机系统中，每个处理机可以同时运行一个事务，从而实现多个事务的真正并行运行。这种并发控制策略在现代数据库系统中至关重要。