[Oracle] Lock&Latch梳理

Oracle lock&latch

1. 概述

4种锁机制

• lock
• latch
• pin
• mutex

保证资源在并发访问和修改时不被破坏

锁类型	行为	持有时间	级别	保护类型
lock	队列(先到先服务)	长	Enqueues: 多个, 复杂(KGL锁: 共享/独占)	对象
pin	队列(先到先服务)	长	共享/独占
latch	随机抢占	短	共享/独占	共享内存
mutex	随机抢占	长(某些mutex)	共享/独占

---

2. 几种内存结构

• 数组

  相同形状和大小的对象列表.

  x$ksuse: 用户会话的结构体, v$session视图的基表.

• 指针

  内存地址.

• 链表

  相对少量的相关项.

  undo段头事务表(事务控制)

  index叶子块

  • 双向链表

  • 单向链表

数组适合处理定长结构, 链表非常适合处理相对少量的相关项, 这2种情况下需要遍历整个数组或者链表来查找某项, 如果项数少的话是可以的. 如何处理大量持续出现和消失的项, 并且每次都需要快速定位其中一项?

• 散列表

  hash cluster: 散列聚簇.

  

  图1: hash cluster管理

  每个latch管理多个hash bucket, 每个hash bucket管理一条hash chain(双向链表), 指向具体的block地址.

  

  图2: 双向链表操作

  hash chain对象会有LRU算法维护大小. 并且会维护hash chain的原子操作.

3. Latch

根据latch的类型分为:

• 独占
• 共享

根据latch的活动分为:

• willing to wait

• immediate get

本质上, latch是一块内存位置和一个用于检查更新内存位置的CPU原子操作.

• 独占latch

  获取伪操作:

  • 设置寄存器X, 指向latch内存地址A
  • 如果内存地址A的值是0, 那么将它设置为0xff <= CPU原子操作
  • 如果内存地址A的值设为0xff, 那么就"持有"latch
  • 如果不是, 就回到最上一步重试, 持续尝试N次

  CPU原子操作, "Test and Set"CPU指令

  持续尝试是spin的过程:

  

  图3: spin过程

• 共享latch

  实现要复杂很多, 应用在一些最繁忙的代码区.

  CPU架构中更精细的比较(compare)和交换(swap)操作, 简称CAS

  CAS涉及3个操作数:

  • 内存值V
  • 旧的预期值A
  • 要修改的新值B

  "我认为V的值应该是A, 如果是, 那么将V的值更新为B; 如果不是, 不修改并告诉我V的实际值是多少." 当且仅当预期值A和内存值V相同时, 将内存值V修改为B, 否则什么都不做.

    int compare_and_swap (int* reg, int oldval, int newval)
    {
    	ATOMIC();
    	int old_reg_val = *reg;
    	if (old_reg_val == oldval)
    		*reg = newval;
    	END_ATOMIC();
    	return old_reg_val;
    }
  

  典型的操作伪码:

  • 设置标志F为0
  • 设置寄存器X指向latch的地址L
  • 设置寄存器Y的值为L目前的值
  • 设置寄存器Z的值为你想要在L上设置的新值
  • 如果Y的值等于L的值, 那么设置"L的值"为"Z的值", 并设置标志F为1 <= CPU原子操作
  • 如果标志F的值为1, 那么你已经成功地修改了latch的值

  

  图4: CAS逻辑图

  设置Flag的优点在于可以允许多个读者"获取和释放latch时进行增减计数", 同时也允许"写者"设置"独占写"位来阻塞新的读者(和其他写者).

  读者请求:

  • 循环(自旋)N次
  • 如果设置了写标志位, 那么回到循环的开头
  • 尝试将latch值加1(以获得读权限)
  • 如果标志位已设置, 退出循环

  当读进程完成了读操作, 使用类似循环把latch的标志位减小1

  写者请求(独占):

  • 循环(自旋)N次
  • 如果写标志位已经设置, 那么回到循环的开头
  • 尝试将latch值设为"写标志位+当前值" (获取写标志)
  • 如果标志已经设置, 那么推出循环
  • 等待读标记减小为0

  允许写进程在读进程正在使用资源时抢占"独占"位, 然后等待读进程对标志位减少至0. 同时新的读进程在写进程持有写位时不能够增加标志位, 并且同一时刻只有一个写进程持有写标志位, 这样对读进程来说, 最大化了读共享, 同时最小化了写进程延迟.

  latch值	解释
  0x00000005	当前有5个进程以共享方式持有latch
  0x40000003	当前有3个进程以共享方式持有latch, 但有一个独占写进程(无法得知是谁)已经设置了阻塞位来禁止新的读进程
  0x20000014	进程0x14(v$process.pid)正以独占方式持有latch

• latch统计

  v$latch, v$latch_parent, v$latch_children

  统计项	解释
  gets	willing to wait方式获取latch的次数. 最终成功得到latch的次数累积.
  misses	willing to wait方式获取latch, 并在首次test and set/compare and swap失败时的次数.
  spin_gets	willing to wait方式获取latch, 首次test and set/compare and swap失败后spin的次数.
  sleeps	willing to wait方式获取latch, 在自旋(spin)后仍然失败的次数.
  sleep1... sleep11	willing to wait方式获取latch, 休眠的次数.
  immediate_gets	立即模式获取latch的次数, 最终成功得到latch的次数累计.
  immedaite_misses	理解模式获取latch, 并在首次test and set/compare and swap失败时的次数.
  wait_time	session等待该latch的总等待时间, 仅是willing to wait的latch, 单位是微妙.

  首次尝试未得到latch时的活动汇总:

  需要的latch访问	使用方式
  获取独占latch	尝试立即获取, 进入spin自旋循环一次. 附加到等待列表, 尝试理解获取, 进入休眠.
  以独占模式获取其他进程正以某种模式(共享/独占/处于阻塞)持有的可共享latch	进入spin循环, 附加至等待列表, 重复spin循环, 如果不成功则进入休眠.
  以共享模式获取其他进程以独占/阻塞模式持有的可共享latch	不进入spin状态, 直接附加到等待列表.
  以共享模式获取其他进程以共享模式持有的可共享latch	休眠前仅spin循环cpu_count +2次

  关键: 当前进程无法得到latch时, 会附加到一个列表中, 然后等待被唤醒.

  post/wait机制: 当前持有latch的进程, 在它释放latch时, 会通知(post)位于列表顶端的进程.

  _enable_reliable_latch_waits参数控制

  

  图5: post/wait机制

  ---

  Mutex

  Mutex的实现和使用和latch很类似. 在library cache处理中用以替代pin.

  Mutex本质上是一个"私有的小型latch", 作为library cache对象的一部分. Mutex替代了少量latch保护大量对象的方式 - 会引起latch竞争.

  每个library cache的hash bucket都有单独的Mutex.

4. Lock

回忆一下library cache的局部hash cluster结构.

图6: 局部library hash cluster

在这里, latch作为一项查找(或修改)内存对象的保护机制. 应该避免持有任意时间长度的latch. 当找到所需的内存对象时, 并做一些时间消耗的工作时, 需要一种不同的机制来保护这些内存对象, 以便能及时释放latch. 这就是下面要总结的库缓存锁(和pin).

• 一些基础

  x$ksqrs: 排队资源

  x$ksqeq: 排队

  x$ktqdm: 表/DML锁

  x$ktcxb: 事务

  v$lock视图

  col_name	type	col describle
  ADDR	RAW (4, 8)	Address of lock state object
  KADDR	RAW (4, 8)	Address of lock
  SID	NUMBER	会话的sid
  TYPE	VARCHAR2(2)	该lock保护的对象类型:TM(DML enqueue), TX(Transaction enqueue), UL(User supplied)
  ID1/ID2	NUMBER	对于TM锁:ID1表示被锁定表的object_id, ID2为0. 对于TX锁:ID1是十进制值表示的改事务所占用的回滚段号和事务槽slot number号, ID2是十进制值表示的环绕wrap的次数, 即事务槽被重用的次数.
  LMODE	NUMBER	0-none, 1-null(NULL), 2-row-S(SS), 3-row-X(SX), 4-share(S), 5-S/Row-X(SSX), 6-exclusive(X)
  REQUEST	NUMBER	同LMODE, 大于0时, 表示当前会话被阻塞, 其他会话占有该锁的模式.
  CTIME	NUMBER	已持有或者等待锁的时间
  BLOCK	NUMBER	是否阻塞其他会话申请, 1:阻塞, 0:不阻塞

  锁模式

  模式	描述	解释	SQL操作
  0	none
  1	Null		select
  2	SS(Row-S)	行级共享锁, 其他对象只能查询这些数据行	select for update, lock for update, lock row share
  3	SX(Row-X)	行级排他锁, 在提交前不允许做DML操作	insert/update/delete, lock row share
  4	S(Share)	共享锁	create index, lock share
  5	SSX(S/Row-X)	共享级排他锁	lock share row exclusive
  6	X(Exclusive)	排他锁	alter table, drop table, drop index, truncate table, lock exclusive

  Null: This lock mode doesn.t implement any restrictions for other session to acquire a lock but has the very important function of invalidating the session.s (holding the null lock) private cached information upon invalidation of the resource structure.

  Sub-Shared: To provide shared access to a part of the shared resource rather than the whole object, sub-shared lock mode is used so that exclusive access to other parts of an object can be provided.

  Sub-Exclusive: This mode is inline with Sub-Shared. This mode is held to provide exclusive access to a part of a shared resource, while other parts of the resource are being concurrently accessed.

  Shared: Sessions hold shared mode of a lock on a resource when it simply wants to inspect the resource and does not want to allow another session to modify this resource while providing concurrent access to that shared resource.

  Shared-Sub-Exclusive: This mode is a combination of Sub-Shared and Sub-Exclusive modes. This mode provides shared access to a part of a resource as well shared access to the whole resource.

  Exclusive: As it is exclusive, it prevents any concurrent access. This means when a session holds an exclusive lock on an object, no other session can have concurrent access to that shared resource.

  锁兼容性

  Gets/Held(->)	N	SS	SX	S	SSX	X
  N	Yes	Yes	Yes	Yes	Yes	Yes
  SS	Yes	Yes	Yes	Yes	Yes	No
  SX	Yes	Yes	Yes	No	No	No
  S	Yes	Yes	No	No	No	No
  SSX	Yes	Yes	No	No	No	No
  X	Yes	No	No	No	No	No

• 锁实现

  Oracle Kernel Enqueue Service layer (KSQ)负责管理所有队列.

  当一个session需要访问一个资源时, 该session需要持有该资源结构的锁. 在持有资源结构锁之前, 需要连接到资源结构的相应队列上.

  每个资源结构都有3种队列(enqueue):

  • Owner Linked List
  • Waiter Linked List
  • Convertor Linked List

  转换队列优先级比等待队列高

  

  图7: 资源锁队列

  锁请求过程同样是Hash cluster模型:

  

  图8: 锁资源分配

  ---

  分析这样一个场景:

  有4个session处理一个有父/子(外键)关联的子表, 并且子表的外键约束上没有索引

  • session 37: del父记录1的唯一子记录

  • session 36: del父记录2的唯一子记录

  • session 39: 试图以独占模式锁住子表(begin waiting...)

  • session 37: 试图del父记录1(由于无FK索引, begin waiting...)

  • session 35: 试图del父记录3的唯一子记录(begin waiting...)

      select
      	sid, type, id1, id2, lmode, request, ctime, block
      from
      	type = 'TM'
      and
      	id1 = 82772
      ;
    

  SID	TY	ID1	ID2	LMODE	REQUEST	CTIME	BLOCK
  37	TM	82772	0	3	5	66	1
  36	TM	82772	0	3	0	42	1
  39	TM	82772	0	0	6	27	0
  35	TM	82772	0	0	3	3	0

  LMODE:3 - SX

  LMODE:5 - SSX

  LMODE:6 - X

  如下图等待图形

  

  图9: TM资源锁等待

  分析:

  • SID 35处于等待队列的末尾, 因为SID 39卡在前面.
  • SID 39必须等待转换队列中的SID 37.
  • 而SID 37卡在了转换队列, 因为它想从锁模式3转换到锁模式5, 同时SID 36在拥有者队列中正以锁模式3持有(3和5模式不兼容)

  随着进程提交(回滚), 队列将以如下步骤向前移动:

  • 当SID 36 commit, 拥有者队列会变空, 此时SID 37会从转换者队列转移到拥有者队列, 获取锁模式5并把ctime列重置为0. SID 39和35仍然会卡在等待者队列.
  • 当SID 37 commit, 拥有者队列再次变空, 然后SID 39将会转移到拥有者队列, 获取锁模式6并把ctime列设置为0. SID 35处于等待者头部, 但无法加入到拥有者队列, 因为锁模式6已被持有, 与锁模式3不兼容.
  • 当SID 39 commit, 拥有者队列再一次变空, 然后SID 35会移动到拥有者队列, 得到锁模式3并把ctime设置为0.

参考: http://www.oraxperts.com/node/103