latch学习

低级的机制，用于串行级访问控制对于比如cache buffer header等内存结构

1，仅仅是一种简单的内存结构
2,通常大小在100-200b
3,被封装成一个个小型的状态对象结构
4,固定在固定sga（父latch)或者共享池中
5,它是通过硬件原子cas(比较与交换）的指令来实现,比如在intel平台是lock CMPXCHG
6,从oracle8后开始共享
    用于一些高级ops特性
    比如，当检查buffer chain时，用于cache buffers chains latch的获取



什么是latch 竞争
我想得到一个latch,但此时已经有人在使用或占用它了
 以上情况可分两种分支：
    如果gets(请求）是采用非等待模式，返回给调用者失败信息
    如果gets(请求）采用乐意等待模式，继续尝试gets

多次尝试gets,这种情况就叫spinning


仍旧得不到latch,就沉睡一些时间
 在latch 世界中，10ms是一个相当长的时间
 _max_exponential_sleep
 _max_sleep_holding_latch


可能被释放latch的进程所唤醒
   不用于所有的latch,因为它需要latch waiter列表的扫描
   通过使用_latch_wait_posting参数来控制


v$session_event

v$session_wait

v$latch/v$latch_misses

v$latchholder


latch troubleshoting

1, 确认哪些会话有问题
2,找到会话等待最多的latch是什么
3,识别出竞争中相关的子latch
4,确认kernel码层次等待latch获取是已经完成了吗
    statspack,awr or v$latch_misses
    x$ksuprlat or x$ksupr if problem with some sessions




kgx=kernel generic mutex

自oracle10.2引入
   从物理上像latch（一块或一片内存）
      更加轻量级
      更小

能内嵌到其它结构中（KGL HD)

客户端可以定义很灵活的spin/yield/wait策略

不计算gets,spingets,yields,仅仅只统计出来waits


kgx mutexes不是os mutexes啊，切记哟


library cache的mutexes
用于保护v$sqlstats buckets
   oradebug dump cursor_stats 1

用于pinning library cache cursors和父级检验（查）
   假如_kks_use_mutex_pin=true（默认从10.2.0.2)
   oradebug dump librarycache level 10

在11g中mutexes用于代替library cache latches
   11g中有131072 mutexes代替67之多的library cache latches

在11g中知名（已知）的mutex 类型：
   cursor parent
   cursor pin
   cursor stat
   library cache
   hash table


v$session_wait
         mutex睡眠次数很好表示出.p1,p2,p3的值表示在处于竞争状态的library cache 对象的hash value是什么，持有mutex的会话是哪个？
         v$event_name和v$session_wait的text列有p1,p2,p3含义的描述
  有如下一些等待事件：
     cursor:mutex S
     cursor:mutex X
     library cache:mutex S
     library cache:mutex X


v$mutex_sleep
   显示等待时间，以及对于各种类型的mutex和位置的睡眠次数
v$mutex_sleep_history
   显示最近每个mutex睡眠的发生情况
   根据每个可循环使用的buffer，会有更加详细的内容


systemstate dumps
   10