7.oracle的dump理解七 enqueue理论及dump enqueues

7.oracle的dump理解七 enqueue理论及dump enqueues

欢迎转载，转载请标明出处：http://blog.csdn.net/notbaron/article/details/51284555

前面几篇狠狠地学习了一把Oracle块相关知识，虽然没有完全掌握，但也是受益匪浅，感触良多。0和1虽然只有两种变化，但是通过数量堆叠和排序，也可以演绎如此缤纷的世界。

       此处省略1万字~

       现在我们来看下如何dump enqueues。

       可以使用oradebug命令来操作。

1     理论知识

1.1     关于锁，Oracle锁归因

Oracle中的任何一个锁都可以归于如下一个方面，蛤蟆此处就不翻译了。

•   Data Dictionary Locks (DDL)

–     Row cache locks

–     Library cache locks and pins

•   Data Manipulation Locks(DML)

–     Row locks

–     Table locks

•   Internal locks and latches

•   Distributed locks

•   Parallel Cache Management(PCM) locks

1.2     关于enqueue

Enqueue是Kernel Service Enqueues (KSQ) 层的东西。

可以在本地实例，也可以使跨多个实例。

Enqueue通过会话进行获取、转换和释放而不是进程。

有两种不同的形式：一种是客户端产生，例如DML锁（TM），另一种是 KSQ自己产生，例如媒介恢复enqueue.

enqueue 有6个锁模式，分别是： X 、 SSX、 S、SX、SS、NULL。

主要用于并发访问控制，像TMtable lock表锁 和 TX 事务锁都是 enqueue。enqueue lock被设计出来用于那些需要较长时间锁机制的场景。

当一个进程以某种模式持有某个enqueue ， 而另一个进程尝试以某种模式request 这个enqueue的兼容矩阵如下。

 

请求模式
持有模式	NULL	SS	SX	S	SSX	X
	NULL	成功	成功	成功	成功	成功	成功
	SS	成功	成功	成功	成功	成功	失败
	SX	成功	成功	成功	失败	失败	失败
	S	成功	成功	失败	成功	失败	失败
	SSX	成功	成功	失败	失败	失败	失败
	X	成功	失败	失败	失败	失败	失败

如下表更下清晰：

Enqueue Resource以2个 字母代表例如  TX和TM ，带有4个数字 例如 TM-00017927-00000000-00000000-00000000 称作 resource id 的4个部分，还有ID1和ID2。不同锁类型下的ID1和ID2有不同的含义。

内部一个Enqueue Resource  对应一个  KSQRS  结构，该KSQRS 结构  拥有三个列表：

§ owner list

§ waiter list

§ converter list

每个owner,waiter,converter有一个锁结构叫做ksglk.

1.3     Enqueue和lock关系

这个问题也曾深深的困扰着蛤蟆。

简单理解两个就是同一个东西。微观概念存在有一些差异是难免的，为了锁住共享资源只有一个LOCK实现起来很难，需要一些资源配合。

可以先记住如下：

enqueue resource 和enqueue lock 配合的enqueues锁机制来管理共享资源。

1.4        Enqueue hash chain

所有resource结构都在hash表上，不同的resource在不同的hash chain上，所以为了找到resource必然会用哈希函数。通过<Type-ID1-ID2来找到哈希桶（ksqht）,每个哈希桶包含一个哈希链。哈希链可以被一个或多个latches（enqueue hash chains latch）覆盖住。

如下图：

为了复用没有使用的资源结构，空闲的资源结构连接在free list上。类似buffer cache的LRU链表。

1.5     Enqueue Lock步骤

l  根据<Type-ID1-ID2>计算HASH值，确定链表

l  得到enqueue hash chains latch

l  定位此资源，如果不存在，在空闲资源列表中取一个放到此处

l  获取enqueues latch

l  获取空闲lock结构

l  将enqueue lock对应的信息填充进去

l  将lock结构挂到此enqueue resource结构式

l  释放enqueues latch

l  释放enqueue hash chains latch

1.6     相关参数

_ENQUEUE_HASH:size of hash table for resource structures

_ENQUEUE_HASH_CHAIN_LATCHES:number of latches protecting the hash chains of the resource structure

查询数据库资源(resources, locks, or processes)

如下：

select *from v$resource_limit;

processes           62 69          300           300    0

sessions             60 69          472           472    0

enqueue_locks    23 43         5860          5860    0

enqueue_resources  18    44         2296    UNLIMITED       0

ges_procs          0  0             0             0    0

ges_ress             0  0             0    UNLIMITED       0

ges_locks           0  0             0    UNLIMITED       0

ges_cache_ress   0  0             0    UNLIMITED       0

ges_reg_msgs     0  0             0    UNLIMITED       0

ges_big_msgs     0  0             0    UNLIMITED       0

ges_rsv_msgs     0  0             0             0    0

gcs_resources     0  0             0    UNLIMITED       0

gcs_shadows      0  0             0    UNLIMITED       0

smartio_overhead_memory    0     0             0    UNLIMITED       0

smartio_buffer_memory 0     0             0    UNLIMITED       0

smartio_metadata_memory    0     0             0    UNLIMITED       0

smartio_sessions 0  0             0    UNLIMITED       0

dml_locks          0  23         2076    UNLIMITED       0

temporary_table_locks   0     5     UNLIMITED       UNLIMITED       0

transactions        0  5           519    UNLIMITED       0

branches            0  0           519    UNLIMITED       0

cmtcallbk          0  2           519    UNLIMITED       0

max_rollback_segments 11    11          519         65535    0

sort_segment_locks 0     8     UNLIMITED       UNLIMITED       0

k2q_locks          0  0           944    UNLIMITED       0

max_shared_servers       1     1     UNLIMITED       UNLIMITED       0

parallel_max_servers     16    16          160         32767    0

2     DUMP ENQUEUES

理论更多可以参考Oracle Wait Interface和DSI 405。

ORADEBUG命令下DUMP Enqueues只有3种等级。

1=enqueueresource hash table

2=1+list ofcurrently used resources

3=2+activeenqueues on each resource

包含资源和队列。等级3是最常用的。大小取决于在V$LOCK上可见行的数量。通常小于1MB。

SQL> oradebug setmypid

SQL> oradebug tracefile_name

SQL> oradebug dump enqueues 1

3     TRACE 文件

3.1     DUMP等级1

在蛤蟆的环境下大概是370多行，大小26KB。

等级1是队列资源的HASH表。

有如下行：

Hash:      length: 979, at: 000007FF2D6E2978

表示HASH表的长度为979，地址为000007FF2D6E2978

查看隐藏参数得到如下：

_enqueue_hash                  979      enqueue hash table length

隐藏参数查询命令如下：

col nameformat a30

col valueformat a8

coldescription format a40 word_wrapped

setverify off

SELECTx.ksppinm name, y.ksppstvl value, x.ksppdesc description FROM x$ksppi x,x$ksppsv y WHERE x.inst_id = userenv('Instance') AND y.inst_id =userenv('Instance') AND x.indx = y.indx AND x.ksppinm LIKE'%&hidden_parameter_name%';

哈希表的长度决定了有多少个HASH链。

每个链描述如下：[2d6e2978,2d6e2978]

这样共979个。

3.2     DUMP等级2

大概是570多行，大小42KB。

除了等级1上的HASH表之外，还有18条使用的RESOURCE

可以通过如下命令查看。

select *from v$resource;

ADDR             TY        ID1        ID2    CON_ID

------------------ ---------- ---------- ----------

000007FF2D690E60PW          1          0          0

000007FF2D690EF0KT      17312          0          0

000007FF2D6912F8MR        201          0          0

000007FF2D691F70XR          4          0          0

000007FF2D692000RD          1          0          0

000007FF2D692378CF          0          0         0

000007FF2D6927F8RT          1          0          0

000007FF2D692888RS         25          1          0

000007FF2D6929A8MR          3          0          0

000007FF2D692B58MR          5          0          0

000007FF2D692BE8MR          7          0         0

000007FF2D692C90MR          8          0          0

000007FF2D692E40MR          1          0          0

000007FF2D692ED0MR          6          0          0

000007FF2D6958D0TA          6          2          0

000007FF2D697028TS          3         1          0

000007FF2D698378KD          0          0          0

000007FF2D69C968AE        133          0          0

找其中一个如下：

-------------------------------------------------------------------------

MR-00000005-00000000-00000000-00000000

res: 0x000007FF2D692B58 , flags: (0x12)ALO/-/-/-/-/-

 held counts: NULL=0 , SS=0 , SX=0 , S=1 , SSX=0 , X=0 (bmask: 0x10)

 lock value: 00000000 00000000 00000000 00000000

 htb(0x000007FF2D692B58): [2d6e98a8,2d6e98a8]

 own(0x000007FF2D692B68): [2d51dd68,2d51dd68]

 cnv(0x000007FF2D692B88): [2d692b88,2d692b88]

 wtr(0x000007FF2D692B78): [2d692b78,2d692b78]

比直接查看v$resrouce要详细很多，直接查看只有一行

其中：MR-00000005-00000000-00000000-00000000

代表EnqueueResource的字母和resourceid 的4个部分。

held counts:表示被不同模式持有的次数。

 htb(0x000007FF2D692B58):[2d6e98a8,2d6e98a8]

值2D692B58也是在前面DUMP 1中出现的哈希链中的一条。

说明这个resource挂载这个哈希链上，

  own(0x000007FF2D692B68): [2d51dd68,2d51dd68]

  cnv(0x000007FF2D692B88): [2d692b88,2d692b88]

  wtr(0x000007FF2D692B78): [2d692b78,2d692b78]

分别表示owner,convert,waiter三个ksglk结构，以及owner list,convert list和waiter list三个链。

3.3     DUMP等级3

大概是800多行，大小42KB。

增加了每个资源上活动的enqueue.

每个resource后面增加了如下内容：

lock summary:

 OWN: L1:S

 CNV:

 WTR:

  #of incomp w/ SS converters: 0

  #of incomp w/ SS waiters: 0

lock details:

  lock                     lst holdwait   sid:ser   owner     link

 -------------------------------------------------------------------------

L1:0x000007FF2D51DD58 OWN    S   --  358:4912  000007FF2DE6B258[2d692b68,2d692b68]

列出了LOCK概要和详细：

       包括LOCK的地址，列表是OWERN,WAITER还是CONVERTER，持有类型，会话ID，拥有者，所在链。