Oracle 锁机制介绍
根据保护对象的不同，单实例Oracle数据库锁可以分为以下几大类： DML lock（data locks，数据锁）：用于保护数据的完整性； DDL lock（dictionary locks，字典锁）：用于保护数据库对象的结构（例如 表、视图、索引的结构定义）； internal locks，latches，mutex，pin：保护内部数据库结构；Oracle DML锁共有两个层次，即行级锁（TX）和表级锁（TM）。
一 .Lock 锁
1.锁介绍
我们在谈到性能优化的时候，通常是讲系统缓慢的时候需要性能优化，系统缓慢通常是由什么原因导致的呢？大概上讲分为两种
- 系统的资源耗尽了(cpu耗尽了，IP，吞吐量上不去)性能枯竭，性能达到了极限。
- 锁定，阻塞，发现系统性能很高，但应用程序性能就是上不去，这种情况通常来讲是阻塞。
模拟锁的情况：
窗口一：建一张表，插入一条数据，id上有主键
窗口二：再往这张表id列插入一条同样的数据
由于primary key本质上是 unique key + not null ，由于第二个事务不知道第一个事务是提交还是回滚，如果提交则事务二插入失败，如果回滚则插入成功，此时会造成锁阻塞。
窗口一：
窗口二：
2.Oracle中锁的大体分类
Enqueues ： 队列类型的锁，通常和业务相关的锁。
Latches： 系统资源方面的锁，比如内存结构，SQL解析等
锁的所有类型可以根据视图v$lock_type 查看
环境oracle 19c 共291种 锁。
.........
3.锁的原则
- 只有被修改时,行才会被锁定。
- 当一条语句修改了一条记录,只有这条记录上被锁定,在Oracle数据库中不存在锁升级。
- 当某行被修改时,它将阻塞别人对它的修改。
- 当一个事务修改一行时,将在这个行上加上行锁(TX),用于阻止其它事务对相同行的修改。
- 读永远不会阻止写。
- 读不会阻塞写,但有唯一的一个例外,就是select …for update。
- 写永远不会阻塞读。
- 当一行被修改后,Oracle通过回滚段提供给数据的一致性读。
这里其实听过其它很多人说过Oracle锁升级的概念，根据一下Oracle资料调查Oracle不存在锁升级，但确实存在锁转换。
数据库在必要时执行锁转换。在锁转换中，数据库自动将较低限制的表锁转换为较 高限制的其它锁定。(锁转换不同于锁升级，锁升级发生在当某个粒度级别持有许多锁（例如行），数据库将其提高到更高粒度级别（例如表）Oracle数据库永远不会升级锁。
Oracle的锁是block里面实现的,（SQLSERVER、DB2是内存里面实现的。内存实 现有资源消耗问题,当内存不足会引发锁升级）但是Oracle不会发生锁升级。
事务拥有在此事务内被插入（insert）、更新（update）、删除（delete）的数 据行的排它行级锁（exclusive row lock）。对于数据行来说，排它行级锁已经是 限制程度最高的锁，因此无需再进行锁转换（lock conversion）。
4.TM锁和TX锁
- TM表锁,发生在insert,update,delete以及select for update操作时，目的是保证操 作能够正常进行,并且阻止其它人对表执行DDL操作。
- TX锁事务锁(行锁)对于正在修改的数据,阻止其它会话进行修改。
根据官方文档归纳总结： v$lock视图列出当前系统持有的或正在申请的所有锁的情况，其主要字段说明如下：
v$locked_object视图列出当前系统中哪些对象正被锁定，其主要字段说明如下：
inert 锁过程验证：
窗口一：
窗口二：
查看锁结构：
在整个过程中
- 首先会话58 对表T 加TM（表锁 ）和TX（行锁），TM锁的BLOCK = 1 代表这个会话在阻塞其它会话
- 第二个会话273 也对T表加了一个TM（表锁），又加了一个TX（行锁），这个行锁request = 4，代表它正在被阻塞
- 中间那把锁（会话273的行锁）正在请求锁并且被会话58的行锁阻塞。会话58持有的行锁（
LMODE = 6）正在阻塞会话273对相同行的访问，导致会话273的请求（REQUEST = 4）被阻塞。
update锁过程验证：
窗口一：
窗口二：
查看锁过程：
整个过程
会话53 对表T加TM和TX锁，TX锁阻塞了其它会话，会话273对表T 加TM和TX锁，TX锁request=6 被阻塞。
delete 锁过程验证：
窗口一：
窗口二：
查看锁过程：
会话58对表T加表锁和行锁，会话273对表T加表锁和行锁，58的行锁阻塞了273的行锁。
从v$session_wait 查看阻塞详情（从会话层面查看锁阻塞）：
所以TX锁又叫队列锁（enq锁）
TM锁的几种模式：
| ORACLE里锁有以下几种模式: |
TM锁几种模式的互斥关系：
| 模式 | 锁定的SQL | 排斥的模式 | 允许的DML |
| 2 | lock table t in row share mode | 6 | select, insert, update, delete, for update |
| 3 | lock table t in row exclusive mode | 4，5，6 | select, insert, update, delete, for update |
| 4 | lock table t in share mode | 3，5，6 | select |
| 5 | lock table t in share row exclusive mode | 3，4，5，6 | select |
| 6 | lock table t in exclusive mode | 2，3，4，5，6 | select |
5..RI锁 - 基于 引用关系的锁
当对具有主外键关系的表做DML操作时，锁定不单单发生在操作表上，相应的引用表上也可能加上相应的锁定
示例：
insert 操作在往主表注入一条数据的时候会在主表和从表上同时上TM锁，对主表上TX锁
update 操作 只会在主表上加TM和TX锁
6.死锁
两个会话互相持有对方资源导致死锁 （Oracle 会自动检测死锁）
会话一：
会话二：
如上，Oracle自动检测到了死锁，释放了会话一。
二 .Latch 锁（闩锁）
用中国话理解闩，就是古代插在门后面那个上锁的。（意味着获取一个资源之后，把它插住，谁也用不了，用完之后再把它打开）
Latch和Lock的区别：
Lock 可以想象成食堂排队打饭，是有序的。
Latch可以想象成微信群里抢红包，抢红包不是一个一个排队的抢，是无序的。而就因为Latch的无序性，才需要Latch锁
| Latch | Lock | |
| 队列性 | 无序 | 有序 |
| 时长 | 很短 | 可能很长 |
| 层面 | 数据库资源层 | 业务应用层 |
| 目的 | 保护资源的完整性 | 保证业务操作的完整性 |
Latch的目的
-
保证资源的串行访问： -保护SGA的资源访问 -保护内存的分配
-
保证执行的串行化： -保护关键资源的串行执行 -防止内存结构损坏
Latch在哪里 ->SGA
sharedpool -sql解析，sql重用....... buffercache -数据访问，数据写入磁盘，数据读入内存，修改数据块，数据段扩展
oracle19c 共993个Latch
Latch的的获取:
wait方式--如果无法获取请求的latch ,则：
-spin
当一个会话无法获得需要的latch时，会继续使用CPU（ CPU空转），达到一个间隔后， 再次尝试申请latch ,直到达到最大的重试次数。
-sleep
当一个会话无法获得需要的latch时，会等待一段时间（sleep） ,达到 Y间隔后，再次 尝试申清latch,如此反复，直到达到最大的重试次数。
No wait方式--如果无;标取请求的latch ,则：
-不会发生sleep或者spin.
-转而去获取其它可用的Latch
Latch锁在data buffer中的应用
data buffer存在的意义就是为了在内存中进行高速的数据查找和更新,尽量减少磁盘的IO操作, Buffer Cache中存在一个Hash Bucket结构,将数据库中已经读取的数 据块放到里面,在从数据库文件中读取到一个数据块后,Oracle会根据这个数据块的 文件编号,段编号,数据块号组合到一起通过一个内部的hash算法运算后,会放到不同 的hash bucket中,每个Hash Bucket都有一个Hash chain list,保留Buffer Header 中的信息,然后通过这个list,把相同hash值的Buffer串起来.结构如图:
为保护这个结构不受同步更新的破坏,Oracle设计了一个CBC latch的锁结构 (Cache Buffers Chains),一个latch保护32的桶(Bucket),所以为了访问hash列表, 必须先获得CBC Latch.先获取Latch后,在对Buffer进行操作.对buffer操作是一个比较耗时的操作，比如从磁盘读取block。由于一个latch管理 32个桶，所以对buffer操作时不能继续持有latch。Oracle使用两阶段加latch锁的 方式解决这个问题。
- 加latch锁
- 查找buffer，并对buffer加pin锁，如果是读取操作则为shared pin，若是写操 作，则exclusive pin
- 释放latch锁
- 对buffer进行操作
- 加latch锁
- 释放pin锁
- 释放latch锁
参见下图，一个buffer拥有一个pin锁，每个pin锁对应两个列表，user's list(拥有 锁的用户列表)和waiter's list(等待锁的列表)，如果用户等待pin锁的时间超过1 秒，则认为出现死锁。buffer和pin锁是 一 一对应关系
加上锁保护以后,整体的图
所以读取数据块的过程如下,当一个用户进程想要访问一个数据块：
- 根据数据文件号，块号生成hash 值
- 在Hash Table中找到bucket地址
- 获取CBC latch,一个latch保护32个bucket
- bucket有一个指针指向bh(buffer head)
- 根据bh的搜索链表
- 匹配bh里面的内容和要找的
- 匹配到一个bh,给bh加锁buffer pin(共享和独占)
- 释放cbc latch, cbc latch做两件事情:保护链表，保护加buffer pin锁
- 进程根据bh里面的ba地址找内存块
- 找完了，获得cbc latch,在保护下 释放buffer pin锁
利用哈希表管理已经被缓存的data block。为了使得哈希桶上链表尽量短，理想目 标是一个链表上最多只有一个buffer，哈希桶的数量一般是data buffer数量的两 倍，并把桶分组，每个组对应一个latch，latch用来保护桶中的链表。一个latch保 护32个桶。
虽然和lock相比，latch是轻量级的，但是使用latch也是有比较大的开销的，所以 oracle尽量减少latch数量，所以一个latch管理了高达32个桶。
Oracle 等待事件 latch free：
如：
Oracle事件latch free定义为：当多个进程竞争一个latch 2次，而第2次的竞争者失败时，在 Statspack 或ASH报告中可以看到的Oracle事件名称。 当数据库发生IO瓶颈，并且出现这类事件时，就可以查看latch free对Oracle性能的影响。
latch free 是一种 Oracle 的内部技术，是用于提升性能的一种需要得到保护的数据结构。 通俗讲，在有多个几秒之间，用来竞争访问相同的资源的多个进程中，如果短时间内无法访问此特定资源，则会发生latch free事件。
由于Oracle数据库中大量组件都是由不同的进程驱动的，每一个进程都可以同时访问资源，并产生latch free的。 而我们的目的是保护共有的资源，因此在资源访问时，可能会出现竞争的情况。 在竞争时，如果第二个进程竞争失败，则表示该进程无法获取资源，这就引发了latch free事件。
解决方案：首先查看 latch free 看看哪个类型latch 最多
select p1,p2,p3,inst_id,count(*) from gv$active_session_history where sample_time > sysdate-1/24 and event='latch free' group by p1,p2,p3,inst_id order by 5 desc; Latch锁类型较多，需要根据不同类型的Latch 做不同的处理方案
快速查看当前Lock锁等待信息：
Oracle提供一个名为utllockt.sql的脚本，它会给出一个树形结构的锁等待图，显示持有影响其他会话的锁的会话。使用此脚本，可以看出一个会话正在等待什么锁，哪个会话持有这些锁。该脚本位于$ORACLE_HOME/rdbms/admin目录下。
@?/rdbmsa/admin/utllockt.sql
执行脚本可以迅速看到 会话51在请求一个Share锁，等待47释放Exclusive锁。
