探索系列——神人steve adams之著oracle8i interal service(八)
locks
oracle透過latch保護短暫或間歇訪問的資料結構.但latch不適用於保護較長時間訪問的資源,比如database tables.locks允許多個會話加入到一個佇列中,如果所訪問的資源暫時不可用.
這樣就避免了spinning.locks也允許多個會話共享資源,前提是它們的活動是相互包容的.
lock usage
oracle根據不同的目的或用途,分為不同的lock。下面介紹幾類便於大家調優的locks.
transaction locks and row-level locks
oracle自我標榜的row-level locks實現機制是很微妙的。當一個事務修改一行記錄時,會在對應資料塊的塊頭的itl記錄一條記錄(或entry),並且每個row header(行頭,就是記錄頭)
被修改指向itl的記錄。
一旦發生變改,沒有lock時。未提交事務的itl記錄和所引用它的行頭,會對所修改的行構建一個隱式的lock.
當另一個事務也想修改以上相同的行(記錄)時,發現有一個未提交的事務修改了這個行,於是這個事務就會發生等待,不是等待row-level lock,而是在等待阻塞事務所產生的事務鎖(記得:這個事務鎖是以上未提交事務所產生的)。
當阻塞事務提交或rollback,它的事務鎖將會release。因此它產生的隱式row-level locks也就release了,這樣被阻塞的事務也可以繼續進行了。注意:如果rollback到某個savepoint時,不會free先前被阻塞事務(這個事務等待一個行級鎖).
buffer locks
row-level locks保護最低階可行粒度(級別)的資料完整性,會在一個事務期間強制保持它。但是,oracle在訪問或修改cache中的一些blocks,也需要持有短暫的塊級lock.使用buffer locks實現database buffer cache中blocks提供一種簡單的讀寫的鎖定.
雖然它們很少被提及並經常被授予,但它們對於資料完整性很重要,它在某些效能調優情形下很重要.
data dictionary locks
data dictionary中的資料物件的定義,在引用時,也要保護.在使用這些資料物件的定義時,有必要防止這些物件被刪除,它們的物件定義資訊被改變。當所依賴的sql被解析或執行時,
dictionary locks必須持有,在依賴的事務期間必須持有.
多種不同型別的locks用於dictionary locking.data dictionary rows用row cache enqueue locks來鎖定它.所依賴的sql用library cache pins保護它(也就是lock it),
對應或依賴的事務持有dml locks(data maninpulation language)。從邏輯上講,dml locks和library cache pins從屬於或依賴於它對應的row cache enqueue locks.
但是這種依賴性是隱式的,使用者看不到,但從結構方面是顯式的.( 這裡依賴比較複雜,多看幾次,理下思路).
lock modes
locks用於複合和簡單的物件。複合物件的典型例子和組成部分是一個表和它的記錄。一個cache buffer就是一個簡單的例子.
簡單物件可能採用下列的模式鎖定:
exclusive
一個會話要修改一個簡單物件,在所訪問的資源需要一個排它鎖(exclusive lock)防止任何併發的訪問.
shared
如果一個會話需要檢查一個簡單物件時,在所訪問的資源上加上shared lock,有效確信資料結構不會被其它會話修改,此時是允許併發的共享訪問的.
null
如果一個會話在快取中儲存了一個物件的資訊.這時會以佔位符的方式持有null mode lock,甚至這個資源並沒有積極被使用。a null mode lock不禁止任何併發的訪問,但如果這些資源
無效了,null mode lock對於這個會話起到一個觸發器,通知這個會話的private cached information無效。記得:持有一個null mode lock和完全不持有一個lock的具有重要的區別.
對於複合的物件持有鎖有如下模式:
sub-shared
如果一個會話需要以shared 模式訪問一個複合物件的部分,如果此時對整個複合物件加一個共享鎖,這樣會產生過度的限制作用,因為它阻止exclusive模式訪問複合物件的其它部分。這種情況下,採用sub-shared lock就合適.
sub-exclusive
如果一個會話需要exclusive模式訪問複合物件的部分,此時sub-exclusive lock會有效起到作用
shared-sub-exclusive
當一個會話需要exclusive 模式訪問複合物件的部分同時需要以共享模式訪問整個複合資源,採用shared-sub-exclusive最好
以上lock modes適用於本地鎖和ops例項的例項鎖instance locks.
local lock modes instance lock modes
name symbol number name symbol number
no lock nlck 0
null n 1 null nl 0
sub-shared ss 2 concurrent read cr 1
sub-exclusive sx 3 concurrent write cw 2
shared s 4 protected read pr 3
shared-sub-exclusive ssx 5 protected write pw 4
exclusive x 6 exclusive ex 5
euqueue locks
oracle一些locks叫作euqueue locks.把對一個lock的請求放入一個佇列,就是把這些請求放入它請求資源的陣列中.當引用或查閱一個特有的enqueue resource,比如cf(controfile)enqueue時,就是一個名詞.
oracle使用兩類local locks---一類用於lock和resource data structures在共享池中分配,另一類用於固定的佇列及資源資料結構.
euqueue resources
入隊資源的固定佇列(陣列)透過enqueue_resources來定義它的大小.佇列中的slots數量會隨時時間而變,檢視v$resource就可以了.v$resource的每條記錄代表每個資源,這個資源當時被一或多個會話以任何模式鎖定。
因為一旦對這些資源的鎖定release了,因此這些資源不會持續性的存在.
v$resource每條記錄透過一個兩個字元(表示資源型別)來標識這個資源,這兩個數字編號的列可用於資源記錄進行編碼或者對透過其資源上面的鎖保護的活動,這一切依賴於資源型別。比如,tx型別的資源,表示rollback segment的事務表transaction table
的記錄。第一個標識的最高排序2 bytes包含rollback segment的編號,最低排序的2 bytes包含事務表的slot編號,但第二個標識包含rollback segment wrap或序列號.
所有入隊操作訪問入隊資源結構(透過一個hash table).hash table是基於資源型別和編號標識。enqueue hash table的長度是用_enqueue_hash來設定。這個引數的預設值源於processes引數:
45 + 2*(processes+processes/10)
因為_enqueue_hash是直接源於processes而非enqueue_resources,如果enqueue_resources遠遠大於預設值,顯式配置_enqueue_hash很有必要。否則會產生過長的enqueue hash chains。對於所有的hash tables,如果要調節buckets的數目,最好配置為質數.
訪問enqueue hash chains是在enqueue hash chains latches保護情況下進行。child enqueue hash chains latches的數量,透過_enqueue_hash_chain_latches來設定,預設為cpu_count.在一個高併發的環境下,如果由於訪問hash chains變得過度大,會產生對於enqueue hash chains latches的sleeps.但是對於這些latches的sleeps正常應該是競爭高階latch的次級結果,而不是源於
過長的hash chains.
hash tables and prime numbers
oracle在內部使用hash tables便於有效定位或查詢物件.比如,用它查詢或定位buffer cache的database blocks,用另一個hash table定位library cache的指定物件.
透過hash table定位一個物件,oracle採用一個演算法轉換物件名字或標識為一個編號。這個編號可能遠遠大於hash table的大小,透過取模function建立index和hash table的對應關係
多個物件可能同時對映到hash table entry.這叫作一個hash 衝突。oracle通常用衝突chains來處理它。這意味著發生衝突的物件透過一系列的指標把這些物件連結起來。這些物件被分配到相同的hash bucket.
基於hash訪問的效能與hash chains的長度有很大關係,因為它們必須以線性被訪問.因此hash tables必須非常大,以此確信平均hash chain的長度要適度.
如果以不均勻方式分配物件到hash buckets,可能會產生太長的hash chains.如果被hash的物件名字的模式用hash function不能乾地隨機化處理.產生這種情況很正常吧.
設定hash buckets的數量為質數,你就能極大減少導致hash collisions的hash values模式的可能性(適用於取模function).
enqueue locking
除了enqueue resources,第二個固定的佇列用於排隊鎖定--也就是說,enqueue locks保護它們本身。enqueue locks固定佇列的大小,透過_enqueue_locks來設定,查詢v$enqueue_lock來檢視活動的記錄數.
每個會話等待或持有一個資源的鎖時,會使用一個enqueue lock structure.如果一或多個會話等待這個資源的locks時,它們的enqueue lock structures會透過一個雙向連結列表,放在一起,以及enqueue resource structure(以列表頭).會根據對locks維護和服務的次序來實現連結串列。比如,
以共享模式持有一個lock,第一個等待者需要以排它模式訪問這個資源,此時其它會話(需要以共享模式訪問資源)必須入隊(對於所要請求的資源),而不管它們的請求是否與目前被鎖定的資源(鎖)的模式是否匹配.
同樣的,雙向連結列表用於連線enqueue lock structures(用於會話持有一個資源的鎖)和(會話等待改變持有鎖的模式)
改變一個鎖的模式操作叫作:入隊轉變。比如,一個事務以sub-share mode對一個表持有一個lock,需要更新一個表的記錄,此時enqueue lock必須轉變為sub-exclusive mode.但是目前資源以不相容模式(鎖)被另一個會話持有,此時這個轉變不能馬上繼續進行下去,enqueue lock structure被放在convertion queue中。
在新的入隊請求之前,入隊轉換須以次序進行.
在入隊操作期間,對於入隊資源和入隊鎖固定自由列表(enqueue locks fixed array free lists)的修改,是在enqueue latch的保護下進行.這是一個enqueue latch。它們經常持有或release兩次(在單一的入隊操作期間)。但是,相關的enqueue hash chains latch會在這個入隊操作期間持有.
enqueue waits
只要入隊請求或入隊轉變不能及時或馬上被授予(響應),會產生enqueue waits.因為另一個會話以不相容模式持有鎖.這個被阻塞程式記錄一個入隊等待enqueue wait.
wait parameters(enqueue waits)
引數 描述
p1 高次序2 bytes包含資源型別的ascii 編碼.低次序2 bytes包含請求鎖的模式
p2 資源的id1標識
p3 資源的id2標識
oracle透過latch保護短暫或間歇訪問的資料結構.但latch不適用於保護較長時間訪問的資源,比如database tables.locks允許多個會話加入到一個佇列中,如果所訪問的資源暫時不可用.
這樣就避免了spinning.locks也允許多個會話共享資源,前提是它們的活動是相互包容的.
lock usage
oracle根據不同的目的或用途,分為不同的lock。下面介紹幾類便於大家調優的locks.
transaction locks and row-level locks
oracle自我標榜的row-level locks實現機制是很微妙的。當一個事務修改一行記錄時,會在對應資料塊的塊頭的itl記錄一條記錄(或entry),並且每個row header(行頭,就是記錄頭)
被修改指向itl的記錄。
一旦發生變改,沒有lock時。未提交事務的itl記錄和所引用它的行頭,會對所修改的行構建一個隱式的lock.
當另一個事務也想修改以上相同的行(記錄)時,發現有一個未提交的事務修改了這個行,於是這個事務就會發生等待,不是等待row-level lock,而是在等待阻塞事務所產生的事務鎖(記得:這個事務鎖是以上未提交事務所產生的)。
當阻塞事務提交或rollback,它的事務鎖將會release。因此它產生的隱式row-level locks也就release了,這樣被阻塞的事務也可以繼續進行了。注意:如果rollback到某個savepoint時,不會free先前被阻塞事務(這個事務等待一個行級鎖).
buffer locks
row-level locks保護最低階可行粒度(級別)的資料完整性,會在一個事務期間強制保持它。但是,oracle在訪問或修改cache中的一些blocks,也需要持有短暫的塊級lock.使用buffer locks實現database buffer cache中blocks提供一種簡單的讀寫的鎖定.
雖然它們很少被提及並經常被授予,但它們對於資料完整性很重要,它在某些效能調優情形下很重要.
data dictionary locks
data dictionary中的資料物件的定義,在引用時,也要保護.在使用這些資料物件的定義時,有必要防止這些物件被刪除,它們的物件定義資訊被改變。當所依賴的sql被解析或執行時,
dictionary locks必須持有,在依賴的事務期間必須持有.
多種不同型別的locks用於dictionary locking.data dictionary rows用row cache enqueue locks來鎖定它.所依賴的sql用library cache pins保護它(也就是lock it),
對應或依賴的事務持有dml locks(data maninpulation language)。從邏輯上講,dml locks和library cache pins從屬於或依賴於它對應的row cache enqueue locks.
但是這種依賴性是隱式的,使用者看不到,但從結構方面是顯式的.( 這裡依賴比較複雜,多看幾次,理下思路).
lock modes
locks用於複合和簡單的物件。複合物件的典型例子和組成部分是一個表和它的記錄。一個cache buffer就是一個簡單的例子.
簡單物件可能採用下列的模式鎖定:
exclusive
一個會話要修改一個簡單物件,在所訪問的資源需要一個排它鎖(exclusive lock)防止任何併發的訪問.
shared
如果一個會話需要檢查一個簡單物件時,在所訪問的資源上加上shared lock,有效確信資料結構不會被其它會話修改,此時是允許併發的共享訪問的.
null
如果一個會話在快取中儲存了一個物件的資訊.這時會以佔位符的方式持有null mode lock,甚至這個資源並沒有積極被使用。a null mode lock不禁止任何併發的訪問,但如果這些資源
無效了,null mode lock對於這個會話起到一個觸發器,通知這個會話的private cached information無效。記得:持有一個null mode lock和完全不持有一個lock的具有重要的區別.
對於複合的物件持有鎖有如下模式:
sub-shared
如果一個會話需要以shared 模式訪問一個複合物件的部分,如果此時對整個複合物件加一個共享鎖,這樣會產生過度的限制作用,因為它阻止exclusive模式訪問複合物件的其它部分。這種情況下,採用sub-shared lock就合適.
sub-exclusive
如果一個會話需要exclusive模式訪問複合物件的部分,此時sub-exclusive lock會有效起到作用
shared-sub-exclusive
當一個會話需要exclusive 模式訪問複合物件的部分同時需要以共享模式訪問整個複合資源,採用shared-sub-exclusive最好
以上lock modes適用於本地鎖和ops例項的例項鎖instance locks.
local lock modes instance lock modes
name symbol number name symbol number
no lock nlck 0
null n 1 null nl 0
sub-shared ss 2 concurrent read cr 1
sub-exclusive sx 3 concurrent write cw 2
shared s 4 protected read pr 3
shared-sub-exclusive ssx 5 protected write pw 4
exclusive x 6 exclusive ex 5
euqueue locks
oracle一些locks叫作euqueue locks.把對一個lock的請求放入一個佇列,就是把這些請求放入它請求資源的陣列中.當引用或查閱一個特有的enqueue resource,比如cf(controfile)enqueue時,就是一個名詞.
oracle使用兩類local locks---一類用於lock和resource data structures在共享池中分配,另一類用於固定的佇列及資源資料結構.
euqueue resources
入隊資源的固定佇列(陣列)透過enqueue_resources來定義它的大小.佇列中的slots數量會隨時時間而變,檢視v$resource就可以了.v$resource的每條記錄代表每個資源,這個資源當時被一或多個會話以任何模式鎖定。
因為一旦對這些資源的鎖定release了,因此這些資源不會持續性的存在.
v$resource每條記錄透過一個兩個字元(表示資源型別)來標識這個資源,這兩個數字編號的列可用於資源記錄進行編碼或者對透過其資源上面的鎖保護的活動,這一切依賴於資源型別。比如,tx型別的資源,表示rollback segment的事務表transaction table
的記錄。第一個標識的最高排序2 bytes包含rollback segment的編號,最低排序的2 bytes包含事務表的slot編號,但第二個標識包含rollback segment wrap或序列號.
所有入隊操作訪問入隊資源結構(透過一個hash table).hash table是基於資源型別和編號標識。enqueue hash table的長度是用_enqueue_hash來設定。這個引數的預設值源於processes引數:
45 + 2*(processes+processes/10)
因為_enqueue_hash是直接源於processes而非enqueue_resources,如果enqueue_resources遠遠大於預設值,顯式配置_enqueue_hash很有必要。否則會產生過長的enqueue hash chains。對於所有的hash tables,如果要調節buckets的數目,最好配置為質數.
訪問enqueue hash chains是在enqueue hash chains latches保護情況下進行。child enqueue hash chains latches的數量,透過_enqueue_hash_chain_latches來設定,預設為cpu_count.在一個高併發的環境下,如果由於訪問hash chains變得過度大,會產生對於enqueue hash chains latches的sleeps.但是對於這些latches的sleeps正常應該是競爭高階latch的次級結果,而不是源於
過長的hash chains.
hash tables and prime numbers
oracle在內部使用hash tables便於有效定位或查詢物件.比如,用它查詢或定位buffer cache的database blocks,用另一個hash table定位library cache的指定物件.
透過hash table定位一個物件,oracle採用一個演算法轉換物件名字或標識為一個編號。這個編號可能遠遠大於hash table的大小,透過取模function建立index和hash table的對應關係
多個物件可能同時對映到hash table entry.這叫作一個hash 衝突。oracle通常用衝突chains來處理它。這意味著發生衝突的物件透過一系列的指標把這些物件連結起來。這些物件被分配到相同的hash bucket.
基於hash訪問的效能與hash chains的長度有很大關係,因為它們必須以線性被訪問.因此hash tables必須非常大,以此確信平均hash chain的長度要適度.
如果以不均勻方式分配物件到hash buckets,可能會產生太長的hash chains.如果被hash的物件名字的模式用hash function不能乾地隨機化處理.產生這種情況很正常吧.
設定hash buckets的數量為質數,你就能極大減少導致hash collisions的hash values模式的可能性(適用於取模function).
enqueue locking
除了enqueue resources,第二個固定的佇列用於排隊鎖定--也就是說,enqueue locks保護它們本身。enqueue locks固定佇列的大小,透過_enqueue_locks來設定,查詢v$enqueue_lock來檢視活動的記錄數.
每個會話等待或持有一個資源的鎖時,會使用一個enqueue lock structure.如果一或多個會話等待這個資源的locks時,它們的enqueue lock structures會透過一個雙向連結列表,放在一起,以及enqueue resource structure(以列表頭).會根據對locks維護和服務的次序來實現連結串列。比如,
以共享模式持有一個lock,第一個等待者需要以排它模式訪問這個資源,此時其它會話(需要以共享模式訪問資源)必須入隊(對於所要請求的資源),而不管它們的請求是否與目前被鎖定的資源(鎖)的模式是否匹配.
同樣的,雙向連結列表用於連線enqueue lock structures(用於會話持有一個資源的鎖)和(會話等待改變持有鎖的模式)
改變一個鎖的模式操作叫作:入隊轉變。比如,一個事務以sub-share mode對一個表持有一個lock,需要更新一個表的記錄,此時enqueue lock必須轉變為sub-exclusive mode.但是目前資源以不相容模式(鎖)被另一個會話持有,此時這個轉變不能馬上繼續進行下去,enqueue lock structure被放在convertion queue中。
在新的入隊請求之前,入隊轉換須以次序進行.
在入隊操作期間,對於入隊資源和入隊鎖固定自由列表(enqueue locks fixed array free lists)的修改,是在enqueue latch的保護下進行.這是一個enqueue latch。它們經常持有或release兩次(在單一的入隊操作期間)。但是,相關的enqueue hash chains latch會在這個入隊操作期間持有.
enqueue waits
只要入隊請求或入隊轉變不能及時或馬上被授予(響應),會產生enqueue waits.因為另一個會話以不相容模式持有鎖.這個被阻塞程式記錄一個入隊等待enqueue wait.
wait parameters(enqueue waits)
引數 描述
p1 高次序2 bytes包含資源型別的ascii 編碼.低次序2 bytes包含請求鎖的模式
p2 資源的id1標識
p3 資源的id2標識
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9240380/viewspace-660566/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 探索系列_神人steve adams之著oracle8i interal service(一)Oracle
- 探索系列_神人steve adams之著oracle8i interal service(二)Oracle
- 探索系列_神人steve adams之著oracle8i interal service(三)Oracle
- 探索系列_神人steve adams之著oracle8i interal service(四)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(五)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(六)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(七)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(九)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十一)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十二)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十三)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十四)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十五)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十六)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十七)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十八)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(十九)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(二十)Oracle
- 探索系列——神人steve adams之著oracle8i interal service(二十一)Oracle
- Steve Adams的《Oracle8i internal services for waits, latches, locks》試譯OracleAI
- script--by Steve Adams
- script--by Steve Adams--hidden_parameters.sqlSQL
- Oracle 12c系列(八)|RMAN (FROM SERVICE)Oracle
- Android探索之Service全面回顧及總結Android
- OpenvSwitch系列之八 vxlan隧道
- 探索C#之系列目錄導航C#
- 深入Weex系列(八)之Weex SDK架構分析架構
- 沒閒著系列 18
- 螞蟻金服 Service Mesh 實踐探索
- 深入剖析Redis系列(八) - Redis資料結構之集合Redis資料結構
- 探索es6系列之—-Generator生成器函式函式
- Android之ServiceAndroid
- ClickHouse學習系列之八【資料匯入遷移&同步】
- 前端獵奇系列之探索Python來反補JavaScript——上篇前端PythonJavaScript
- 跟著圖靈聽課去!(八月)圖靈
- [ Office 365 開發系列 ] Graph Service
- [微信小程式系列] 動畫案例之圓點沿著圓圈運動微信小程式動畫