鎖的總結筆記

鎖的總結筆記[@more@]

資料字典鎖

資料字典鎖是保護的是在資料字典中定義的資料庫物件被引用時，保持資料的一致性，主要是保護這些物件在使用的時候，不被刪除，改變。為事務提供一致性的物件定義檢視。主要有三種型別的資料字典鎖：

n 行快取鎖

n 庫快取鎖

n 庫快取pins

1、 儲存的是資料字典行

2、 是共享池的一部分

3、 可以減少對SYSSTEM表空間的IO爭用

4、 使用行快取鎖來實現資料字典行的find-grain鎖

鎖的應用：

1、 這些快取的行為資源結構

2、 鎖結構是從共享池中被動態分配；

3、 型別QA。。。QZ

引數_row_cache_instance_locks定義的是行快取鎖的數目。這個鎖的請求被放置在佇列中，而引起row cache lock的等待事件。

等待事件row cache lock

這個等待事件是由等待row cache鎖而引起來的，等待週期是3秒。 當鎖在請求的時候得不到響應的時候，這個會話將sleep3秒，然後再重新試，如果經過了1000次的嘗試的時候仍然得到布料這個鎖的時候，這個鎖在等待超時1000次後就被拋棄。並在警告檔案中寫入“Waited too long for row cache enqueue lock”。

這個等待在RAC環境上是比較常見的，但是在單例項的資料庫中相對比較少見，主要是一些資源衝突的結果。

MODE 0 ：NULL lock

MODE 3 ：SHARE

MODE 5 ：exclusive

MODE 10 ：fail to acquire instance lock

引數的含義：

P1 ：cache id (cache# in v$rowcache)

P2 ：mode that is held

P3 ：mode that is requested

庫快取鎖（breakable parse locks）透過請求鎖物件的控制程式碼，來控制多客戶的庫快取的併發行。主要是當一個客戶請求到一個資源的話，其他的客戶就禁止連線。

在解析呼叫的過程中，這些鎖被請求時候，

1、 在父和子的控制程式碼為排他模式

2、 所依賴的關係為共享模式

鎖被保留為NULL模式的話，

在系統中鎖結構映像到例項的鎖，可以參考x$kgllk。這個表包含著所有會話的所有的庫物件鎖（held&requested）。比v$lock檢視更詳細，

鎖的應用

1. 這些資源結構只是一個控制程式碼；

2. 鎖結構被動態分配在共享池上；

3. 型別LA...LP

等待事件：library cache lock

這個時間描述的是請求庫快取鎖的等待事件。

等待週期為3秒，PMON僅為1秒。

等待事件引數：

P1 ：物件的控制程式碼地址；

P2 ：鎖結構地址；

P3 ：100*mode requested + namespace#

Mode 1 ：null mode

Mode 2 ：share mode

Mode 3 ：exclusive mode

這個等待事件應該是比較少。

pins

庫快取pins是請求到庫快取資料堆，為了管理快取的一致性。這個控制程式碼上的鎖首先被請求。在呼叫執行的過程中，pin被請求。Pin一個物件將會造成這個物件的資料堆將被載入到記憶體中，如果客戶去修改或者檢查這個物件的時候，在請求鎖住相關控制程式碼之後，客戶必須請求pin在相應的合適物件堆上。這個等待事件的產生的原因就是在客戶請求pin一個堆的時候，而這個堆被其他的會話把持，並且請求的pin和當前的pin並不是相容。

n 在共享模式

讀取資料堆

對依賴的物件保護不被修改

n 在排他模式

去修改資料堆

鎖的應用

物件的控制程式碼就是一個資源結構

Pin在共享池中被分配

型別NA...NZ

等待事件：library cache pin

等待週期為3秒，PMON僅為1秒。

等待事件引數：

P1 ：物件的控制程式碼地址；

P2 ：pin地址；

P3 ：100*mode requested + namespace#

Mode 2 ：share mode

Mode 3 ：exclusive mode

這個等待事件應該是比較少，除了在pipe和sequence。檢視x$kglpn包含的是等待和保持library cache pin的列表。

這裡約總結一下 library cache lock和library cache pin的區別和聯絡；

library cache lock

	library cache lock	library cache pin
	請求的是庫快取物件的控制程式碼	請求的是庫快取資料堆
	先控制程式碼請求	後庫快取資料堆請求

由上可見這兩個鎖是一個先後的順序進行請求的，先鎖住所要請求物件的控制程式碼，然後再鎖住庫快取物件的資料堆，這個可能就要和上述的enqueue相關的內容相對應了，在哪裡介紹了有resource structure，這裡的資源控制程式碼應該就是這裡的控制程式碼了，library cache lock這個事件在找到這個資源控制程式碼以後將這個鎖住，然後找到相應的資料堆的位置，再使用library cache pin將這個資料堆鎖住。

對資料堆操作的時候，當只是讀取資料堆的資料的時候，就是使用的是共享模式，當需要修改資料堆內容的時候，就需要使用排他模式進行library cache pin鎖了。而一般等待得產生主要是在產生排他鎖的時候，在訪問、執行library cache上的資源時獲得的都是共享pin，編譯就產生排他鎖了。

鎖

表鎖，能夠保證在執行整個事務的時候物件定義的一致性；

行鎖，能夠保證在執行整個事務的時候資料的一致性；

這裡所說的事務主要是指在解析和執行SQL階段的過程。

應用：

表鎖是被應用為TM佇列；每一個遊標都維護著表鎖結構的列表，這個列表是解析這個語句時候建立的。在第一次執行這個遊標的時候，將會獲得所有表的鎖，這些鎖將在事務的結束或者放棄的時候被釋放。

TM佇列等的引數：

P1 ：name | mode

P2 ：object ID

P3 ：0

DML表鎖失效

可能的效能提高

n 減少鎖負擔

n 防止阻塞的鎖

n 不需要維護外來鍵索引

n 不能使用drop和alter語句

有兩種方式實現：

1、 設定dml_locks為0；

2、 使用alter table 命令來使得表鎖失效；

DML行鎖

鎖的應用時在行級鎖和事務鎖聯合一起使用的，行級鎖主要是在每一行的頭部的鎖位元組和ITL上應用的。事務鎖使用的是TX佇列。

事務鎖

事務鎖是反映一個活動的事務，這些事務鎖被列在回滾段頭塊的事務表中，在ITL中有事務的標識，可以透過這個標識來指向對於地事務表的入口。這些鎖被作為TX佇列被應用。

TX佇列等待得引數：

P1 ：name | mode

P2 ：rbs# |wrap#

P3 ：slot#

事務的標識（XID）

這個事務標識在整個系統中具有唯一性，被用於在資料快或者索引塊的ITL中使用。

有三部分組成：

n Rollback/undo segment number

n Transaction table slot number

n Sequence number or wrap#

XID = usn# .slot# .wrap

找到被鎖的行

在檢視v$session中可以找到我們需要找到的悲鎖的行。

ROW_WAIT_OBJ# NUMBER Y

ROW_WAIT_FILE# NUMBER Y

ROW_WAIT_BLOCK# NUMBER Y

ROW_WAIT_ROW# NUMBER Y

SQL> SELECT ROW_WAIT_OBJ# ,ROW_WAIT_FILE#,ROW_WAIT_BLOCK#, ROW_WAIT_ROW# FROM v$session where sid=12; ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# ------------- -------------- --------------- ------------- 6617 1 21578 0

鎖

這個鎖的主要目的是為了保護在快取中的資料快的一致性。主要是用於：

1、 buffer header可以作為一個資源結構；

2、 會話使用buffer handle來聯絡buffer；

3、 Buffer handle 可以看作一個鎖結構；

4、 在共享池中Buffer handle被動態分配；

這裡可以看到鎖與佇列的關係了；

對於每一個資料庫快取中的每一個快取，都有一個快取頭。這些快取頭是由一個 固定的陣列構成，在buffer lock中buffer header扮演著一個resource structue的角色。會話操作快取頭。

Buffer lock正常情況下，是在共享和排他的模式下工作。

等待事件：buffer busy wait

這個事件產生的原因是因為一個會話正在請求一個buffer，而這個buffer正在被讀或者被修改。

引數：

P1 : absolute file number

P2 : block number

P3 : ID(reason code)

超時時間正常委1秒，但是如果在前一個等待由於是排他的buffer lock，這時候超時將被增加到3秒。

Buffer lock爭用

透過查詢檢視v$waitstat可以檢視到爭用確切的位置。這個檢視主要存放市的是塊爭用的統計資訊。

SQL> select class from v$waitstat; CLASS ------------------ data block sort block save undo block segment header save undo header free list extent map 1st level bmb 2nd level bmb 3rd level bmb bitmap block bitmap index block file header block unused system undo header system undo block undo header undo block 18 rows selected SQL>

X$kcbfwait

資料塊的爭用

1、 如果等待是因為讀產生的，則考慮去除一些沒有選擇性的索引。（這裡是為什麼，沒有理解）

2、 如果等待是因為修改產生的，則：

減少行密度；

n 改變引數pctfree、pctused；

n 增加initrans;

n 使用MINIMIZE RECORDS_PER_BLOCK減少每個塊中的行數；

n 減少db_block_size;

避免right-hand index （這裡是什麼意思，不太明白）

回滾段爭用

Undo header 的等待意義就是需要更多的回滾段；

Undo block 的等待表示回滾段的不合適的快取；

System undo block和system undo header的等待表示系統RBU出現問題

Save undo block和 save undo header 的等待表示延遲RBU出現問題

為了減少在undo header塊上的buffer busy waits的數目：

n 新增更多的回滾段

n 減少transactions_per_roolback_segment，但是這樣會造成需要更多的回滾段

減少undo block上的快取忙等待：

n 使得在單個例項上的回滾段更大；

SELECT sum(waits)* 100 /sum(gets) "Ratio", sum(waits) "Waits", sum(gets) "Gets" FROM v$rollstat;

這個比率應該小於5％，如果大於應該增加回滾段的數量。

索引塊的爭用

這個和資料塊爭用相似，但是有兩個意外：

n Index block split

n Bitmap index update

Free list爭用

主要是發生在多會話試圖並行分配或者撤銷資料塊。出現這個問題時候，在我們檢視檢視v$waitstat時候是表現為segment header block和free-list block的等待。

解決FREE list 爭用

n 查詢v$session_wait (get file /block)

n 查詢dba_extents(get object name)

n Get free lists for segment

n 重建問題物件或者動態分配更多的free list

Alter table tab1 storage (freelists n);

n 使用ASSM段

等待事件：write complete waits

這個事件產生的原因是因為等待一個buffer lock，主要是因為這個buffer由於老化被寫。超時為1秒。這個事件是一個等待IO完成。在DBWn將老化的buffer寫到磁碟的時候，將在這些buffer上標識為“正在被寫”。當所有的IO完成以後，這個標識將被清除。這個事件write complete waits就是發生在這個標識被設定的階段上產生的。

解決的方法：

n 提高DBMn的頻寬

1) 增加磁碟的spindles的數量

2) 使用RAID1（條帶化），不是使用RAID5

3) 使用非同步IO，多個writers

n 減少批次寫的大小

1) 寫批處理大小是被以下的公式控制：db_files*db_file_simultaneous_writes/2

2) 這個只能用於沒有free buffer waits

引數：

P1 ：absolute file number

P2 ：block number

P3 ：ID(reason code)

有兩種型別

n 永久表空間的臨時表鎖（TS）；

n 臨時表空間的排序段鎖；（SS）

保持磁碟排序空間使用的跟蹤，是被用於在SGA中的固定陣列，是由sessions引數來定義大小，並不是和鎖衝突，等待或者死鎖相關。

這個排序鎖（TS，SS佇列）並沒有鎖的衝突，不能將sort locks和space transaction enqueue(ST)混淆，ST的爭用經常是和磁碟排序相關，因為在排序時候，需要增加，擴充套件和deallocation臨時段。

ORA-1575

ORA-1575是空間管理佇列（ST）的超時等待引起來的；減少這個錯誤的方法如下：

1、 使用本地管理表空間；

2、 使用臨時表空間存放排序段；

3、 增加sort_area_size，用以減少磁碟排序；

4、 使用合適的extent大小，設定引數pctincrease為0；

SMON功能

1) 合併free extents（5 minutes）

2) 清除臨時段(2 hours)

3) 清除在obj$中不存在地物件(12 hours)

4) 如果online builder crashes,清除ind$(1 hours)

5) 縮小回滾段(12 hours)

6) 在啟動時候事務恢復

7) 事務回滾（由PMON呼叫）

合併自由空間

SMON每5分鐘合併一次表空間，這個功能實現有一個前提，主要是在系統管理表空間（即字典管理表空間）和pctincrease > 0。在每一次合併得時候ST佇列將被把持，如果不需要後臺合併的發生，可以透過設定事件10269來禁止後臺合併得發生。

臨時段的清除

SMON每兩個小時執行這個任務，

總結一下：

Data dictionary locks目的主要是保持資料字典的一致性，由以下三種型別組成：

Row cache locks

這個鎖主要是針對row cache，將cache row作為資源結構來管理。這個鎖等待會引起row cache lock這個等待事件。

Library cache lock

這個鎖是請求庫快取物件的控制程式碼。將object handle作為資源結構。這個鎖等待會引起library cache lock這個等待事件。

Library cache pin

這個鎖是請求庫快取資料堆。將object handle作為資源結構。這個鎖等待會引起library cache pin這個等待事件。

DML鎖

有兩種：

Table lock

Row lock

事務鎖

Buffer lock