Oracle并发控制和DML锁机制详解

Oracle RAC 环境中，为了保证数据的一致性，采用了多种并发控制机制。根据资源类型的不同，主要分为 Cache Fusion 和 Non-Cache Fusion 两种机制。 Cache Fusion 主要用于管理数据库缓存中的数据块，其核心是将每个数据块映射为一个 PCM 资源，并利用 DLM（分布式锁管理器）进行全局锁的申请和释放。进程只有在获得 PCM 锁之后，才能访问对应的数据块。此外，Cache Fusion 还需要解决数据块版本控制问题，确保进程能够访问到最新的数据。 Non-Cache Fusion 用于管理非缓存资源，例如数据文件头等。与 Cache Fusion 不同，

SQL Server的并发控制涉及事务的基本原理以及锁的类型和应用。在查询和更新数据库时，SQL Server利用不同类型的锁来管理数据的访问和修改，以避免阻塞和提升性能。

数据库在并发执行多个事务时，可能引发脏写、脏读、不可重复读以及幻读等问题。这些问题的根源在于数据库的并发控制。为了解决这些问题，数据库引入了事务隔离机制、锁机制和 MVCC（多版本并发控制）等机制。 事务及其 ACID 属性 事务是由一组 SQL 语句构成的逻辑处理单元，具有以下四个关键属性（ACID）： 原子性（Atomicity）: 事务是一个不可分割的操作单元，其包含的操作要么全部成功执行，要么全部失败回滚。 一致性（Consistency）: 事务执行前后，数据库必须保持一致状态，满足所有预定的数据完整性约束。 隔离性（Isolation）: 数据库系统通过隔离机制确保并发执行的事务

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

数据库并发控制的结构还挺清晰的，章节拆得细，像是 11.1 到 11.6，基本把锁机制、调度、死锁这些核心问题都捋了一遍。看上去篇幅不多，但干货不少，尤其是两段锁协议部分，适合拿来搞清楚串行化调度背后的逻辑。 两段锁协议的挺严谨，从获取锁到释放锁的顺序讲得比较细。如果你之前搞事务碰到过锁冲突、死锁之类的问题，读这个就有感。顺手还能看看这篇延伸阅读，讲得更透彻。 死锁那块讲了活锁和死锁的区别，也提了怎么检测和解除。嗯，虽然不少人都听过这些概念，但真碰上了不一定能第一时间，所以这章还是挺值得过一遍的。顺带推荐一下这篇死锁诊断的文章，配合着看更有感觉。 再一个就是封锁粒度的，涉及表级锁、行级锁这些，

InnoDB 的事务、锁机制和 MVCC 并发控制，讲真，是搞 MySQL 绕不开的核心。事务这块，支持ACID不说，Group Commit和XA事务也都照顾到了，像配合别的数据库干活也不含糊。再说锁，行锁、表锁、自增锁、甚至还有隐式锁，啥并发情况都安排得明明白白。MVCC就更有意思了，能让你读数据的时候根本不用等写操作完成，快不快？ InnoDB 的ReadView机制挺巧妙，它决定了你事务里到底能看见哪些数据，像RC和RR隔离级别，也是在这里做的文章。还有一个蛮值得注意的点，mini-transaction，InnoDB 内部搞 page 读写时都得靠它，挺底层但关键。想搞清楚这些内容，

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

DML锁，即数据操作语言锁，是为了确保每次只有一个用户能修改特定行，并在用户操作表时防止其他用户删除表。Oracle在处理过程中会自动添加这些锁，分为事务级（TX）锁和表级（TM）锁，以保障数据的完整性和一致性。

意向锁是一种数据库锁机制，用于协调对数据资源的并发访问。它通过在父节点上设置意向锁，表明其子节点正在被加锁或即将被加锁，从而避免潜在的锁冲突。 具体来说，在对任何节点加基本锁之前，必须先对其上层节点加意向锁。例如，如果要对某个数据页加写锁，就必须先对包含该页的表加意向写锁。这样一来，其他事务在尝试对该表加锁时，就会知道其下层节点正在被锁定，从而避免不必要的等待或死锁。 意向锁的引入，简化了锁的管理，提高了并发访问的效率。