OCP知識點講解 之 隊列、資源與鎖

一、隊列與共用資源     共用資源可以被多個會話、進程同時訪問，因此它的訪問需要保護。Oracle中，除了PGA，所有的東西包括記憶體、磁碟、CPU、表、索引、事務等等，種類太多，一概用東西兩字來代表）都是共用資源。多個進程或會話對共用資源操作時，就需要排隊。這裡所需要排的隊就是隊列Enqueue）。訪問不同的共用資源，需要排不同的隊。可以這樣說，有多少種隊列，就有多少種需要保護的共用資源。隊列的名字一般是兩個位元組構成，如TM，TX，JQ，……。具體所有隊列的種類、名字，參見V$LOCK視圖介紹中的附表。
二、隊列標識     我們以TM為例，它是DML隊列鎖。在對錶作DML操作時，需要先在此排隊，正式點的說法是：需要先獲得TM隊列鎖。TM也被稱作表鎖，因為它主要是在對錶作操作是獲得的。如果資料庫中有1000個表，針對這一千個表，並非只有一個隊列，要是這樣的話也不太合理。1000個表，就應該有1000個TM隊列，這樣才附合常理。如果一千個隊列都叫TM，將來操作時不好區分，因此，需要為這一千個TM隊列分別名命，這個名字，也被稱為隊列標識。TM隊列的命名格式為：TM-OID-0。其中OID是Object ID，即對象ID。最後一部分一般都是0。假如AA表的OID是6636，它的隊列標識就是TM-6636-0。     每種隊列的命名格式各不相同，總的來說是“隊列名-ID1-ID2”，ID1和ID2分別是兩個參數，對於TM隊列來說，ID1是OID，ID2為0。
三、資源結構     繼續我們上面的假設，如資料庫中有一千個表，這就要對應一千個TM隊列。但只有當操作到哪個表了，才會為它建立相關的隊列資訊。比如會話發布了對AA表的更新操作，需要在SGA中為AA建立相關的TM隊列資訊。這些相關AA的TM資訊，也被稱為“資源結構”KSQRS，KSQ是核心服務隊列的簡寫，RS是Resource Structure的簡寫，即資源結構）。每一個資源結構維持一個所有者、等待者和轉換者的列表。如：650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/1944342604-0.jpg" border="0" alt="" />     資源結構前的<TM-432-0>即是隊列標識，也可以作為資源結構標識資源標識）。     每一個所有者、等待者和轉換者有一個鎖結構Ksqlk），簡單點說每一個所有者、等待者和轉換者有一個鏈表，此鏈表由會話、鎖模式等資訊構成，具體描述了什麼會話以什麼模式獲得此資源結構。具體如下：     1)如果會話獲得鎖，鎖結構將在所有者列表上     2)如果會話正在等待獲得鎖，鎖結構將在等待者列表上     3)如果鎖已被獲得，但會話正在等待它被轉換到一種不同的模式，鎖結構將在轉換者列表上     所有資源結構組成一個資源表，資源表和資源結構上的鎖都被分配在SGA中。資源表中總的行數由初始化參數ENQUEUE_RESOURCES決定，且資源表中的行可以在X$KSQRS中被看到。正在被使用的將在V$RESOURCE中顯示。還可以在v$resource_limit中看到資源結構數量的限制和使用方式：sid=9 pid=10> select * from v$resource_limit where resource_name = 'enqueue_resources';RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION   LIMIT_VALUE------------------------------ ------------------- --------------- -------------------- -------------enqueue_resources          32              32        968            UNLIMITED     可以看到，當前使用了32個資源結構，最多時使用了32個資源結構，初始化參數中分配了968個資源結構。最多使用是UNLIMITED，沒有限制。由於Oracle 9i採用的演算法，我們在X$KSQRS中看到的總行數並不是968，而是992。為確保重用，資源表中未用的資源結構被放置在一個串連列表，稱為：Resource Free List。我們發行就緒一些更新聲明，不要提交，這樣佔用的TM、TX資源結構一直不會釋放。觀察X$KSQRS，TM資源結構的佔用增多，但視圖的總行數不變，還是992。新增的TM、TX資源結構佔用了其他已經釋放的資源結構。
四、資源結構雜湊表     為了在資源表中快速找到某一資源結構，Oracle當然還是要使用HASH演算法。Oracle根據資源標識計算HASH值。當然，和Library cache一樣，資源表中已被佔用的資源結構的HASH值構成了一個個HASH Buckut。650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/19443415Z-1.jpg" border="0" alt="" />     就是HASH Bucket和資源結構的圖，可以看到和Library cache中的很像。HASH演算法嗎，所有的HASH演算法都會有很多共同點。從中可以看到，想訪問Hash Bucket，需要Enqueue hash chain閂，它需要保護中的HASH表，和每個Hash Bucket後的Hash鏈。它的數量由隱含參數_enqueue_hash_chain_latches控制。Enqueue hash chain閂類似於Buffer cache chain閂。它們都是一個閂要管理多個雜湊桶，不過Enqueue hash chain更特殊，在單CPU環境中，只有一個，卻要管理所有的雜湊桶，這是因為隊列的爭用，畢競比Buffer要小的多。     Oracle中所有關於HASH的演算法，都要有HASH表、HASH鏈和保護HASH鏈的閂，HASH表不需要保護，這是因為HASH表是大小固定的數組。每一個數組元素就是一個Hash Bucket。每個雜湊桶的雜湊值也都是事先定好的。因此不存在對雜湊桶的更改，如插入一個雜湊桶、修改一個雜湊桶的雜湊值或刪除一個未使用的雜湊桶等等，這些操作都是不存在的。因此，既然不會有修改操作，雜湊表就不需保護。需要保護的是每個雜湊桶後的鏈。每個桶後的鏈中，都可以掛多個對象，我們可能向鏈上添加或刪除對象，既然有修改，就需要保護。     隊列資源Hash表的長度由_enqueue_hash控制，其始值來源於SESSION參數，初始是375。我們的資源表共有992行，而雜湊桶只有375個，這必然會有多個資源結構排在某一個雜湊桶後面。如果曾經增加過ENQUEUE_RESOURCES的值，也就是說，資源結構比系統預設的還要更多一些，但控制雜湊表長度的_enqueue_hash參數值如果不跟著增加。這就意味著每個雜湊桶下要掛接更多的資源結構，這有可能因起Enqueue hash chain閂的競爭。如何觀察閂的使用方式這是下一章節的內容，這裡就不多說了。_enqueue_hash的初始值是根據Sessions參數來定的，計算公式如下：((sessions-10)*2)+55，預設 ((170-10)*2)+55，正好等於375，它並不隨ENQUEUE_RESOURCES的增加而增加。650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131229/19443432K-2.jpg" border="0" alt="" />     隊列、資源結構和鎖結構的關係如。是分別在兩個會話中發布如下聲明後的結果：     在會話10：sid=10 pid=11> insert into a1 values(1,1,1);已建立 1 行。     在會話12：sid=12 pid=12> insert into a1 values(2,2,2);已建立 1 行。     查看雜湊表視圖：     sid=9 pid=10> select * from v$resource where type ='TM';ADDR     TY        ID1        ID2-------- -- ---------- ----------7B6D5C40 TM       6657          0     可以看到，有一個TM隊列，地址是7B6D5C40，對象ID是6657，這個正是A1表。查看V$LOCK視圖：     sid=13 pid=13> select * from v$lock where sid>=8;ADDR  KADDR     SID   TY        ID1     ID2  LMODE    REQUEST      CTIME      BLOCK-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------7AF661FC 7AF66308        10 TX     458765       2212          6          0        452          07AF3A074 7AF3A088       10 TM       6657          0          3          0        452          07AF837AC 7AF838B8       12 TX     327686       2355          6          0         84          07AF3A17C 7AF3A190      12 TM       6657          0          3          0         84          0     上面的結果中顯示，TM-6657-0有兩個鎖，地址分別是7AF3A088、7AF3A190。     說明，中的資訊，部分來自於隊列結構的DUMP，聲明如下，有興趣可以自己試試。     sid=10 pid=11> alter session set events 'immediate trace name enqueues level 4';     雜湊表的長度，由_enqueue_hash設定，資源結構的數量也稱資源表的長度），由ENQUEUE_RESOURCES設定。鎖結構的的數量，也可以由DBA控制，隱含參數_enqueue_locks就是設定鎖結構數量的也稱隊列鎖：Enqueue Lock），預設值2230。可以被看到在X$KSQEQ中，正在被使用的在V$ENQUEUE_LOCK顯示。但是，有關TM、TX這兩個隊列的鎖和其他情況的隊列鎖不一樣，除非它們發生了Enqueue等待，否則它們並不在X$KSQEQ結構中顯示，因此在X$KSQEQ之上的V$ENQUEUE_LOCK也沒有正在使用中的TX、TM隊列鎖的情況。Oracle使用不同的結構來管理TX和TM排除。TX：X$KTCXB，核心事務控制事務對象，V$TRANSACTION_ENQUEUE的基礎視圖。它的尺寸由transactions初始化參數控制。有關TX的我們下面專門再說。再看TM：X$KTADM，核心事務訪問定義DML鎖。X$KTADM的尺寸由DML_LOCKS定義，也就是TM鎖的數量。X$KTADM對DBA意義不大，可以為我們提供鎖的模式、加鎖的時間、正在請求的模式、會話SID等資訊，資訊量並不比V$LOCK中多。通過上兩個X$視圖觀察正在使用中的TM、TX鎖的最好辦法是：set linesize 800col KTCXBNAM for a20select * from x$ktcxb where ktcxblkp in (select kaddr from v$lock where type='TX');select * from x$ktadm where ksqlkadr in ( select kaddr from v$lock where type='TM');我們也可以在V$RESOURCE_LIMIT中看到有關隊列鎖的使用方式：sid=9 pid=10> select * from v$resource_limit where resource_name like 'enqueue%';RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION   LIMIT_VALUE------------------------------ ------------------- --------------- -------------------- -------------enqueue_locks                26              30       2230                 2230enqueue_resources             26              26       1200            UNLIMITED注意enqueue_locks和transactions、DML_LOCKS的關係，enqueue_locks是總的隊列鎖的數量，transactions定義了在總的隊列鎖中，TX鎖的數量，DML_LOCKS是總隊列鎖中TM鎖的數量。也就是說transactions和DML_LOCKS是enqueue_locks的一部分。

<->

本文出自 “葉紹琛” 部落格，請務必保留此出處http://yeshaochen.blog.51cto.com/3155801/947045