国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費(fèi)電子書等14項(xiàng)超值服

開通VIP
DB2和 Oracle的并發(fā)控制(鎖)比較

2005 年 12 月 26 日

在實(shí)際的生產(chǎn)運(yùn)行環(huán)境中,筆者在國(guó)內(nèi)很多客戶現(xiàn)場(chǎng)都看到開發(fā)人員和系統(tǒng)管理人員遇到很多有關(guān)于鎖而引起的性能問題,進(jìn)而被多次問起DB2和Oracle中鎖的區(qū)別比較問題,筆者根據(jù)自己在工作中對(duì)DB2和Oracle數(shù)據(jù)庫(kù)的使用經(jīng)驗(yàn)積累寫下這篇文章。

1 引言

在關(guān)系數(shù)據(jù)庫(kù)(DB2,Oracle,Sybase,Informix和SQL Server)最小的恢復(fù)和交易單位為一個(gè)事務(wù)(Transactions),事務(wù)具有ACID(原子性,一致性,隔離性和永久性)特征。關(guān)系數(shù)據(jù)庫(kù)為了確保并發(fā)用戶在存取同一數(shù)據(jù)庫(kù)對(duì)象時(shí)的正確性(即無丟失更新、可重復(fù)讀、不讀"臟"數(shù)據(jù),無"幻像"讀),數(shù)據(jù)庫(kù)中引入了并發(fā)(鎖)機(jī)制。基本的鎖類型有兩種:排它鎖(Exclusive locks記為X鎖)和共享鎖(Share locks記為S鎖)。

排它鎖:若事務(wù)T對(duì)數(shù)據(jù)D加X鎖,則其它任何事務(wù)都不能再對(duì)D加任何類型的鎖,直至T釋放D上的X鎖;一般要求在修改數(shù)據(jù)前要向該數(shù)據(jù)加排它鎖,所以排它鎖又稱為寫鎖。

共享鎖:若事務(wù)T對(duì)數(shù)據(jù)D加S鎖,則其它事務(wù)只能對(duì)D加S鎖,而不能加X鎖,直至T釋放D上的S鎖;一般要求在讀取數(shù)據(jù)前要向該數(shù)據(jù)加共享鎖,所以共享鎖又稱為讀鎖。







2 DB2 多粒度封鎖機(jī)制介紹

2.1 鎖的對(duì)象

DB2支持對(duì)表空間、表、行和索引加鎖(大型機(jī)上的數(shù)據(jù)庫(kù)還可以支持對(duì)數(shù)據(jù)頁加鎖)來保證數(shù)據(jù)庫(kù)的并發(fā)完整性。不過在考慮用戶應(yīng)用程序的并發(fā)性的問題上,通常并不檢查用于表空間和索引的鎖。該類問題分析的焦點(diǎn)在于表鎖和行鎖。

2.2 鎖的策略

DB2可以只對(duì)表進(jìn)行加鎖,也可以對(duì)表和表中的行進(jìn)行加鎖。如果只對(duì)表進(jìn)行加鎖,則表中所有的行都受到同等程度的影響。如果加鎖的范圍針對(duì)于表及下屬的行,則在對(duì)表加鎖后,相應(yīng)的數(shù)據(jù)行上還要加鎖。究竟應(yīng)用程序是對(duì)表加行鎖還是同時(shí)加表鎖和行鎖,是由應(yīng)用程序執(zhí)行的命令和系統(tǒng)的隔離級(jí)別確定。

2.2.1 DB2表鎖的模式

DB2在表一級(jí)加鎖可以使用以下加鎖方式:


表一:DB2數(shù)據(jù)庫(kù)表鎖的模式

下面對(duì)幾種表鎖的模式進(jìn)一步加以闡述:

IS、IX、SIX方式用于表一級(jí)并需要行鎖配合,他們可以阻止其他應(yīng)用程序?qū)υ摫砑由吓潘i。

  • 如果一個(gè)應(yīng)用程序獲得某表的IS鎖,該應(yīng)用程序可獲得某一行上的S鎖,用于只讀操作,同時(shí)其他應(yīng)用程序也可以讀取該行,或是對(duì)表中的其他行進(jìn)行更改。
  • 如果一個(gè)應(yīng)用程序獲得某表的IX鎖,該應(yīng)用程序可獲得某一行上的X鎖,用于更改操作,同時(shí)其他應(yīng)用程序可以讀取或更改表中的其他行。
  • 如果一個(gè)應(yīng)用程序獲得某表的SIX鎖,該應(yīng)用程序可以獲得某一行上的X鎖,用于更改操作,同時(shí)其他應(yīng)用程序只能對(duì)表中其他行進(jìn)行只讀操作。

S、U、X和Z方式用于表一級(jí),但并不需要行鎖配合,是比較嚴(yán)格的表加鎖策略。

  • 如果一個(gè)應(yīng)用程序得到某表的S鎖。該應(yīng)用程序可以讀表中的任何數(shù)據(jù)。同時(shí)它允許其他應(yīng)用程序獲得該表上的只讀請(qǐng)求鎖。如果有應(yīng)用程序需要更改讀該表上的數(shù)據(jù),必須等S鎖被釋放。
  • 如果一個(gè)應(yīng)用程序得到某表的U鎖,該應(yīng)用程序可以讀表中的任何數(shù)據(jù),并最終可以通過獲得表上的X鎖來得到對(duì)表中任何數(shù)據(jù)的修改權(quán)。其他應(yīng)用程序只能讀取該表中的數(shù)據(jù)。U鎖與S鎖的區(qū)別主要在于更改的意圖上。U鎖的設(shè)計(jì)主要是為了避免兩個(gè)應(yīng)用程序在擁有S鎖的情況下同時(shí)申請(qǐng)X鎖而造成死鎖的。
  • 如果一個(gè)應(yīng)用程序得到某表上的X鎖,該應(yīng)用程序可以讀或修改表中的任何數(shù)據(jù)。其他應(yīng)用程序不能對(duì)該表進(jìn)行讀或者更改操作。
  • 如果一個(gè)應(yīng)用程序得到某表上的Z鎖,該應(yīng)用程序可以讀或修改表中的任何數(shù)據(jù)。其他應(yīng)用程序,包括未提交讀程序都不能對(duì)該表進(jìn)行讀或者更改操作。

IN鎖用于表上以允許未提交讀這一概念。

2.2.2 DB2行鎖的模式

除了表鎖之外,DB2還支持以下幾種方式的行鎖。


表二:DB2數(shù)據(jù)庫(kù)行鎖的模式

2.2.3 DB2鎖的兼容性


表三:DB2數(shù)據(jù)庫(kù)表鎖的相容矩陣


表四:DB2數(shù)據(jù)庫(kù)行鎖的相容矩陣

下表是筆者總結(jié)了DB2中各SQL語句產(chǎn)生表鎖的情況(假設(shè)缺省的隔離級(jí)別為CS):



2.3 DB2鎖的升級(jí)

每個(gè)鎖在內(nèi)存中都需要一定的內(nèi)存空間,為了減少鎖需要的內(nèi)存開銷,DB2提供了鎖升級(jí)的功能。鎖升級(jí)是通過對(duì)表加上非意圖性的表鎖,同時(shí)釋放行鎖來減少鎖的數(shù)目,從而達(dá)到減少鎖需要的內(nèi)存開銷的目的。鎖升級(jí)是由數(shù)據(jù)庫(kù)管理器自動(dòng)完成的,有兩個(gè)數(shù)據(jù)庫(kù)的配置參數(shù)直接影響鎖升級(jí)的處理:

locklist--在一個(gè)數(shù)據(jù)庫(kù)全局內(nèi)存中用于鎖存儲(chǔ)的內(nèi)存。單位為頁(4K)。

maxlocks--一個(gè)應(yīng)用程序允許得到的鎖占用的內(nèi)存所占locklist大小的百分比。

鎖升級(jí)會(huì)在這兩種情況下被觸發(fā):

  • 某個(gè)應(yīng)用程序請(qǐng)求的鎖所占用的內(nèi)存空間超出了maxlocks與locklist的乘積大小。這時(shí),數(shù)據(jù)庫(kù)管理器將試圖通過為提出鎖請(qǐng)求的應(yīng)用程序申請(qǐng)表鎖,并釋放行鎖來節(jié)省空間。
  • 在一個(gè)數(shù)據(jù)庫(kù)中已被加上的全部鎖所占的內(nèi)存空間超出了locklist定義的大小。這時(shí),數(shù)據(jù)庫(kù)管理器也將試圖通過為提出鎖請(qǐng)求的應(yīng)用程序申請(qǐng)表鎖,并釋放行鎖來節(jié)省空間。
  • 鎖升級(jí)雖然會(huì)降低OLTP應(yīng)用程序的并發(fā)性能,但是鎖升級(jí)后會(huì)釋放鎖占有內(nèi)存并增大可用的鎖的內(nèi)存空間。

鎖升級(jí)是有可能會(huì)失敗的,比如,現(xiàn)在一個(gè)應(yīng)用程序已經(jīng)在一個(gè)表上加有IX鎖,表中的某些行上加有X鎖,另一個(gè)應(yīng)用程序又來請(qǐng)求表上的IS鎖,以及很多行上的S鎖,由于申請(qǐng)的鎖數(shù)目過多引起鎖的升級(jí)。數(shù)據(jù)庫(kù)管理器試圖為該應(yīng)用程序申請(qǐng)表上的S鎖來減少所需要的鎖的數(shù)目,但S鎖與表上原有的IX鎖沖突,鎖升級(jí)不能成功。

如果鎖升級(jí)失敗,引起鎖升級(jí)的應(yīng)用程序?qū)⒔拥揭粋€(gè)-912的SQLCODE。在鎖升級(jí)失敗后,DBA應(yīng)該考慮增加locklist的大小或者增大maxlocks的百分比。同時(shí)對(duì)編程人員來說可以在程序里對(duì)發(fā)生鎖升級(jí)后程序回滾后重新提交事務(wù)(例如:if sqlca.sqlcode=-912 then rollback and retry等)。







3 Oracle 多粒度鎖機(jī)制介紹

根據(jù)保護(hù)對(duì)象的不同,Oracle數(shù)據(jù)庫(kù)鎖可以分為以下幾大類:

(1) DML lock(data locks,數(shù)據(jù)鎖):用于保護(hù)數(shù)據(jù)的完整性;

(2) DDL lock(dictionary locks,字典鎖):用于保護(hù)數(shù)據(jù)庫(kù)對(duì)象的結(jié)構(gòu)(例如表、視圖、索引的結(jié)構(gòu)定義);

(3) Internal locks 和latches(內(nèi)部鎖與閂):保護(hù)內(nèi)部數(shù)據(jù)庫(kù)結(jié)構(gòu);

(4) Distributed locks(分布式鎖):用于OPS(并行服務(wù)器)中;

(5) PCM locks(并行高速緩存管理鎖):用于OPS(并行服務(wù)器)中。

在Oracle中最主要的鎖是DML(也可稱為data locks,數(shù)據(jù)鎖)鎖。從封鎖粒度(封鎖對(duì)象的大小)的角度看,Oracle DML鎖共有兩個(gè)層次,即行級(jí)鎖和表級(jí)鎖。

3.1 Oracle的TX鎖(行級(jí)鎖、事務(wù)鎖)

許多對(duì)Oracle不太了解的技術(shù)人員可能會(huì)以為每一個(gè)TX鎖代表一條被封鎖的數(shù)據(jù)行,其實(shí)不然。TX的本義是Transaction(事務(wù)),當(dāng)一個(gè)事務(wù)第一次執(zhí)行數(shù)據(jù)更改(Insert、Update、Delete)或使用SELECT… FOR UPDATE語句進(jìn)行查詢時(shí),它即獲得一個(gè)TX(事務(wù))鎖,直至該事務(wù)結(jié)束(執(zhí)行COMMIT或ROLLBACK操作)時(shí),該鎖才被釋放。所以,一個(gè)TX鎖,可以對(duì)應(yīng)多個(gè)被該事務(wù)鎖定的數(shù)據(jù)行(在我們用的時(shí)候多是啟動(dòng)一個(gè)事務(wù),然后SELECT… FOR UPDATE NOWAIT)。

在Oracle的每行數(shù)據(jù)上,都有一個(gè)標(biāo)志位來表示該行數(shù)據(jù)是否被鎖定。Oracle不像DB2那樣,建立一個(gè)鏈表來維護(hù)每一行被加鎖的數(shù)據(jù),這樣就大大減小了行級(jí)鎖的維護(hù)開銷,也在很大程度上避免了類似DB2使用行級(jí)鎖時(shí)經(jīng)常發(fā)生的鎖數(shù)量不夠而進(jìn)行鎖升級(jí)的情況。數(shù)據(jù)行上的鎖標(biāo)志一旦被置位,就表明該行數(shù)據(jù)被加X鎖,Oracle在數(shù)據(jù)行上沒有S鎖。

3.2 TM鎖(表級(jí)鎖)

3.2.1 意向鎖的引出

表是由行組成的,當(dāng)我們向某個(gè)表加鎖時(shí),一方面需要檢查該鎖的申請(qǐng)是否與原有的表級(jí)鎖相容;另一方面,還要檢查該鎖是否與表中的每一行上的鎖相容。比如一個(gè)事務(wù)要在一個(gè)表上加S鎖,如果表中的一行已被另外的事務(wù)加了X鎖,那么該鎖的申請(qǐng)也應(yīng)被阻塞。如果表中的數(shù)據(jù)很多,逐行檢查鎖標(biāo)志的開銷將很大,系統(tǒng)的性能將會(huì)受到影響。為了解決這個(gè)問題,可以在表級(jí)引入新的鎖類型來表示其所屬行的加鎖情況,這就引出了"意向鎖"的概念。

意向鎖的含義是如果對(duì)一個(gè)結(jié)點(diǎn)加意向鎖,則說明該結(jié)點(diǎn)的下層結(jié)點(diǎn)正在被加鎖;對(duì)任一結(jié)點(diǎn)加鎖時(shí),必須先對(duì)它的上層結(jié)點(diǎn)加意向鎖。如:對(duì)表中的任一行加鎖時(shí),必須先對(duì)它所在的表加意向鎖,然后再對(duì)該行加鎖。這樣一來,事務(wù)對(duì)表加鎖時(shí),就不再需要檢查表中每行記錄的鎖標(biāo)志位了,系統(tǒng)效率得以大大提高。

3.2.2 意向鎖的類型

由兩種基本的鎖類型(S鎖、X鎖),可以自然地派生出兩種意向鎖:

意向共享鎖(Intent Share Lock,簡(jiǎn)稱IS鎖):如果要對(duì)一個(gè)數(shù)據(jù)庫(kù)對(duì)象加S鎖,首先要對(duì)其上級(jí)結(jié)點(diǎn)加IS鎖,表示它的后裔結(jié)點(diǎn)擬(意向)加S鎖;

意向排它鎖(Intent Exclusive Lock,簡(jiǎn)稱IX鎖):如果要對(duì)一個(gè)數(shù)據(jù)庫(kù)對(duì)象加X鎖,首先要對(duì)其上級(jí)結(jié)點(diǎn)加IX鎖,表示它的后裔結(jié)點(diǎn)擬(意向)加X鎖。

另外,基本的鎖類型(S、X)與意向鎖類型(IS、IX)之間還可以組合出新的鎖類型,理論上可以組合出4種,即:S+IS,S+IX,X+IS,X+IX,但稍加分析不難看出,實(shí)際上只有S+IX有新的意義,其它三種組合都沒有使鎖的強(qiáng)度得到提高(即:S+IS=S,X+IS=X,X+IX=X,這里的"="指鎖的強(qiáng)度相同)。所謂鎖的強(qiáng)度是指對(duì)其它鎖的排斥程度。

這樣我們又可以引入一種新的鎖的類型:

共享意向排它鎖(Shared Intent Exclusive Lock,簡(jiǎn)稱SIX鎖):如果對(duì)一個(gè)數(shù)據(jù)庫(kù)對(duì)象加SIX鎖,表示對(duì)它加S鎖,再加IX鎖,即SIX=S+IX。例如:事務(wù)對(duì)某個(gè)表加SIX鎖,則表示該事務(wù)要讀整個(gè)表(所以要對(duì)該表加S鎖),同時(shí)會(huì)更新個(gè)別行(所以要對(duì)該表加IX鎖)。

這樣數(shù)據(jù)庫(kù)對(duì)象上所加的鎖類型就可能有5種:即S、X、IS、IX、SIX。

具有意向鎖的多粒度封鎖方法中任意事務(wù)T要對(duì)一個(gè)數(shù)據(jù)庫(kù)對(duì)象加鎖,必須先對(duì)它的上層結(jié)點(diǎn)加意向鎖。申請(qǐng)封鎖時(shí)應(yīng)按自上而下的次序進(jìn)行;釋放封鎖時(shí)則應(yīng)按自下而上的次序進(jìn)行;具有意向鎖的多粒度封鎖方法提高了系統(tǒng)的并發(fā)度,減少了加鎖和解鎖的開銷。

3.3 Oracle的TM鎖(表級(jí)鎖)

Oracle的DML鎖(數(shù)據(jù)鎖)正是采用了上面提到的多粒度封鎖方法,其行級(jí)鎖雖然只有一種(即X鎖),但其TM鎖(表級(jí)鎖)類型共有5種,分別稱為共享鎖(S鎖)、排它鎖(X鎖)、行級(jí)共享鎖(RS鎖)、行級(jí)排它鎖(RX鎖)、共享行級(jí)排它鎖(SRX鎖),與上面提到的S、X、IS、IX、SIX相對(duì)應(yīng)。需要注意的是,由于Oracle在行級(jí)只提供X鎖,所以與RS鎖(通過SELECT … FOR UPDATE語句獲得)對(duì)應(yīng)的行級(jí)鎖也是X鎖(但是該行數(shù)據(jù)實(shí)際上還沒有被修改),這與理論上的IS鎖是有區(qū)別的。鎖的兼容性是指當(dāng)一個(gè)應(yīng)用程序在表(行)上加上某種鎖后,其他應(yīng)用程序是否能夠在表(行)上加上相應(yīng)的鎖,如果能夠加上,說明這兩種鎖是兼容的,否則說明這兩種鎖不兼容,不能對(duì)同一數(shù)據(jù)對(duì)象并發(fā)存取。

下表為Oracle數(shù)據(jù)庫(kù)TM鎖的兼容矩陣(Y=Yes,表示兼容的請(qǐng)求; N=No,表示不兼容的請(qǐng)求;-表示沒有加鎖請(qǐng)求):


表五:Oracle數(shù)據(jù)庫(kù)TM鎖的相容矩陣

一方面,當(dāng)Oracle執(zhí)行SELECT…FOR UPDATE、INSERT、UPDATE、DELETE等DML語句時(shí),系統(tǒng)自動(dòng)在所要操作的表上申請(qǐng)表級(jí)RS鎖(SELECT…FOR UPDATE)或RX鎖(INSERT、UPDATE、DELETE),當(dāng)表級(jí)鎖獲得后,系統(tǒng)再自動(dòng)申請(qǐng)TX鎖,并將實(shí)際鎖定的數(shù)據(jù)行的鎖標(biāo)志位置位(指向該TX鎖);另一方面,程序或操作人員也可以通過LOCK TABLE語句來指定獲得某種類型的TM鎖。下表是筆者總結(jié)了Oracle中各SQL語句產(chǎn)生TM鎖的情況:


表六:Oracle數(shù)據(jù)庫(kù)TM鎖小結(jié)

我們可以看到,通常的DML操作(SELECT…FOR UPDATE、INSERT、UPDATE、DELETE),在表級(jí)獲得的只是意向鎖(RS或RX),其真正的封鎖粒度還是在行級(jí);另外,Oracle數(shù)據(jù)庫(kù)的一個(gè)顯著特點(diǎn)是,在缺省情況下,單純地讀數(shù)據(jù)(SELECT)并不加鎖,Oracle通過回滾段(Rollback segment)來保證用戶不讀"臟"數(shù)據(jù)。這些都提高了系統(tǒng)的并發(fā)程度。

由于意向鎖及數(shù)據(jù)行上鎖標(biāo)志位的引入,減小了Oracle維護(hù)行級(jí)鎖的開銷,這些技術(shù)的應(yīng)用使Oracle能夠高效地處理高度并發(fā)的事務(wù)請(qǐng)求。





回頁首


4 DB2多粒度封鎖機(jī)制的監(jiān)控

在DB2中對(duì)鎖進(jìn)行監(jiān)控主要有兩種方式,第一種方式是快照監(jiān)控,第二種是事件監(jiān)控方式。

4.1 快照監(jiān)控方式

當(dāng)使用快照方式進(jìn)行鎖的監(jiān)控前,必須把監(jiān)控鎖的開關(guān)打開,可以從實(shí)例級(jí)別和會(huì)話級(jí)別打開,具體命令如下:


db2 update dbm cfg using dft_mon_lock on(實(shí)例級(jí)別)
db2 update monitor switches using lock on(會(huì)話級(jí)別,推薦使用)

當(dāng)開關(guān)打開后,可以執(zhí)行下列命令來進(jìn)行鎖的監(jiān)控

db2 get snapshot for locks on ebankdb(可以得到當(dāng)前數(shù)據(jù)庫(kù)中具體鎖的詳細(xì)信息)
db2 get snapshot for locks on ebankdb
Fri Aug 15 15:26:00 JiNan 2004(紅色為鎖的關(guān)鍵信息)


                                     Database Lock Snapshot                        Database name                              = DEV                        Database path                              = /db2/DEV/db2dev/NODE0000/SQL00001/                        Input database alias                       = DEV                        Locks held                                 = 49                        Applications currently connected           = 38                        Agents currently waiting on locks          = 6                        Snapshot timestamp                         = 08-15-2003 15:26:00.951134                        Application handle                         = 6                        Application ID                             = *LOCAL.db2dev.030815021007                        Sequence number                            = 0001                        Application name                           = disp+work                        Authorization ID                           = SAPR3                        Application status                         = UOW Waiting                        Status change time                         =                        Application code page                      = 819                        Locks held                                 = 0                        Total wait time (ms)                       = 0                        Application handle                         = 97                        Application ID                             = *LOCAL.db2dev.030815060819                        Sequence number                            = 0001                        Application name                           = tp                        Authorization ID                           = SAPR3                        Application status                         = Lock-wait                        Status change time                         = 08-15-2003 15:08:20.302352                        Application code page                      = 819                        Locks held                                 = 6                        Total wait time (ms)                       = 1060648                        Subsection waiting for lock              = 0                        ID of agent holding lock                 = 100                        Application ID holding lock              = *LOCAL.db2dev.030815061638                        Node lock wait occurred on               = 0                        Lock object type                         = Row                        Lock mode                                = Exclusive Lock (X)                        Lock mode requested                      = Exclusive Lock (X)                        Name of tablespace holding lock          = PSAPBTABD                        Schema of table holding lock             = SAPR3                        Name of table holding lock               = TPLOGNAMES                        Lock wait start timestamp                = 08-15-2003 15:08:20.302356                        Lock is a result of escalation           = NO                        List Of Locks                        Lock Object Name            = 29204                        Node number lock is held at = 0                        Object Type                 = Table                        Tablespace Name             = PSAPBTABD                        Table Schema                = SAPR3                        Table Name                  = TPLOGNAMES                        Mode                        = IX                        Status                      = Granted                        Lock Escalation             = NO                        

db2 get snapshot for database on dbname |grep -i locks(UNIX,LINUX平臺(tái))


                        Locks held currently                       = 7                        Lock waits                                 = 75                        Time database waited on locks (ms)         = 82302438                        Lock list memory in use (Bytes)            = 20016                        Deadlocks detected                         = 0                        Lock escalations                           = 8                        Exclusive lock escalations                 = 8                        Agents currently waiting on locks          = 0                        Lock Timeouts                              = 20                        

db2 get snapshot for database on dbname |find /i "locks"(NT平臺(tái))
db2 get snapshot for locks for applications agentid 45(注:45為應(yīng)用程序句柄)


                         Application handle                         = 45                        Application ID                             = *LOCAL.db2dev.030815021827                        Sequence number                            = 0001                        Application name                           = tp                        Authorization ID                           = SAPR3                        Application status                         = UOW Waiting                        Status change time                         =                        Application code page                      = 819                        Locks held                                 = 7                        Total wait time (ms)                       = 0                        List Of Locks                        Lock Object Name            = 1130185838                        Node number lock is held at = 0                        Object Type                 = Key Value                        Tablespace Name             = PSAPBTABD                        Table Schema                = SAPR3                        Table Name                  = TPLOGNAMES                        Mode                        = X                        Status                      = Granted                        Lock Escalation             = NO                        Lock Object Name            = 14053937                        Node number lock is held at = 0                        Object Type                 = Row                        Tablespace Name             = PSAPBTABD                        Table Schema                = SAPR3                        Table Name                  = TPLOGNAMES                        Mode                        = X                        Status                      = Granted                        Lock Escalation             = NO                        

也可以執(zhí)行下列表函數(shù)(注:在DB2 V8之前只能通過命令,DB2 V8后可以通過表函數(shù),推薦使用表函數(shù)來進(jìn)行鎖的監(jiān)控)

db2 select * from table(snapshot_lock(‘DBNAME‘,-1)) as locktable監(jiān)控鎖信息
db2 select * from table(snapshot_lockwait(‘DBNAME‘,-1) as lock_wait_table監(jiān)控應(yīng)用程序鎖等待的信息

4.2 事件監(jiān)控方式:

當(dāng)使用事件監(jiān)控器進(jìn)行鎖的監(jiān)控時(shí)候,只能監(jiān)控死鎖(死鎖的產(chǎn)生是因?yàn)橛捎阪i請(qǐng)求沖突而不能結(jié)束事務(wù),并且該請(qǐng)求沖突不能夠在本事務(wù)內(nèi)解決。通常是兩個(gè)應(yīng)用程序互相持有對(duì)方所需要的鎖,在得不到自己所需要的鎖的情況下,也不會(huì)釋放現(xiàn)有的鎖)的情況,具體步驟如下:

db2 create event monitor dlock for deadlocks with details write to file ‘$HOME/dir‘
db2 set event monitor dlock state 1
db2evmon -db dbname -evm dlock看具體的死鎖輸出(如下圖)


                              Deadlocked Connection ...                        Deadlock ID:   4                        Participant no.: 1                        Participant no. holding the lock: 2                        Appl Id: G9B58B1E.D4EA.08D387230817                        Appl Seq number: 0336                        Appl Id of connection holding the lock: G9B58B1E.D573.079237231003                        Seq. no. of connection holding the lock: 0126                        Lock wait start time: 06/08/2005 08:10:34.219490                        Lock Name       : 0x000201350000030E0000000052                        Lock Attributes : 0x00000000                        Release Flags   : 0x40000000                        Lock Count      : 1                        Hold Count      : 0                        Current Mode    : NS  - Share (and Next Key Share)                        Deadlock detection time: 06/08/2005 08:10:39.828792                        Table of lock waited on      : ORDERS                        Schema of lock waited on     : DB2INST1                        Tablespace of lock waited on : USERSPACE1                        Type of lock: Row                        Mode of lock: NS  - Share (and Next Key Share)                        Mode application requested on lock: X   - Exclusive                        Node lock occured on: 0                        Lock object name: 782                        Application Handle: 298                        Deadlocked Statement:                        Type     : Dynamic                        Operation: Execute                        Section  : 34                        Creator  : NULLID                        Package  : SYSSN300                        Cursor   : SQL_CURSN300C34                        Cursor was blocking: FALSE                        Text     : UPDATE ORDERS  SET TOTALTAX = ?, TOTALSHIPPING = ?,                        LOCKED = ?, TOTALTAXSHIPPING = ?, STATUS = ?, FIELD2 = ?, TIMEPLACED = ?,                        FIELD3 = ?, CURRENCY = ?, SEQUENCE = ?, TOTALADJUSTMENT = ?, ORMORDER = ?,                        SHIPASCOMPLETE = ?, PROVIDERORDERNUM = ?, TOTALPRODUCT = ?, DESCRIPTION = ?,                        MEMBER_ID = ?, ORGENTITY_ID = ?, FIELD1 = ?, STOREENT_ID = ?, ORDCHNLTYP_ID = ?,                        ADDRESS_ID = ?, LASTUPDATE = ?, COMMENTS = ?, NOTIFICATIONID = ? WHERE ORDERS_ID = ?                        List of Locks:                        Lock Name                   : 0x000201350000030E0000000052                        Lock Attributes             : 0x00000000                        Release Flags               : 0x40000000                        Lock Count                  : 2                        Hold Count                  : 0                        Lock Object Name            : 782                        Object Type                 : Row                        Tablespace Name             : USERSPACE1                        Table Schema                : DB2INST1                        Table Name                  : ORDERS                        Mode                        : X   - Exclusive                        Lock Name                   : 0x00020040000029B30000000052                        Lock Attributes             : 0x00000020                        Release Flags               : 0x40000000                        Lock Count                  : 1                        Hold Count                  : 0                        Lock Object Name            : 10675                        Object Type                 : Row                        Tablespace Name             : USERSPACE1                        Table Schema                : DB2INST1                        Table Name                  : BKORDITEM                        Mode                        : X   - Exclusive(略去后面信息)                        







5 Oracle 多粒度封鎖機(jī)制的監(jiān)控

為了監(jiān)控Oracle系統(tǒng)中鎖的狀況,我們需要對(duì)幾個(gè)系統(tǒng)視圖有所了解:

5.1 v$lock視圖

v$lock視圖列出當(dāng)前系統(tǒng)持有的或正在申請(qǐng)的所有鎖的情況,其主要字段說明如下:


表七:v$lock視圖主要字段說明

其中在TYPE字段的取值中,本文只關(guān)心TM、TX兩種DML鎖類型;

5.2 v$locked_object視圖

v$locked_object視圖列出當(dāng)前系統(tǒng)中哪些對(duì)象正被鎖定,其主要字段說明如下:


表八:v$locked_object視圖字段說明

5.3 Oracle鎖監(jiān)控腳本

根據(jù)上述系統(tǒng)視圖,可以編制腳本來監(jiān)控?cái)?shù)據(jù)庫(kù)中鎖的狀況。

5.3.1 showlock.sql

第一個(gè)腳本showlock.sql,該腳本通過連接v$locked_object與all_objects兩視圖,顯示哪些對(duì)象被哪些會(huì)話鎖?。?/p>

                        /* showlock.sql */                        column o_name format a10                        column lock_type format a20                        column object_name format a15                        select rpad(oracle_username,10) o_name,session_id sid,                        decode(locked_mode,0,‘None‘,1,‘Null‘,2,‘Row share‘,                        3,‘Row Exclusive‘,4,‘Share‘,5,‘Share Row Exclusive‘,6,‘Exclusive‘) lock_type,                        object_name ,xidusn,xidslot,xidsqn                        from v$locked_object,all_objects                        where v$locked_object.object_id=all_objects.object_id;                        5.3.2	showalllock.sql                        

第二個(gè)腳本showalllock.sql,該腳本主要顯示當(dāng)前所有TM、TX鎖的信息;


                        /* showalllock.sql */                        select sid,type,id1,id2,                        decode(lmode,0,‘None‘,1,‘Null‘,2,‘Row share‘,                        3,‘Row Exclusive‘,4,‘Share‘,5,‘Share Row Exclusive‘,6,‘Exclusive‘)                        lock_type,request,ctime,block                        from v$lock                        where TYPE IN(‘TX‘,‘TM‘);                        





回頁首


6 DB2 多粒度封鎖機(jī)制示例

以下示例均運(yùn)行在DB2 UDB中,適用所有數(shù)據(jù)庫(kù)版本。首先打開三個(gè)命令行窗口(DB2 CLP),其中兩個(gè)(以下用SESS#1、SESS#2表示)以db2admin用戶連入數(shù)據(jù)庫(kù),以操作SAMPLE庫(kù)中提供的示例表(employee);另一個(gè)(以下用SESS#3表示)以db2admin用戶連入數(shù)據(jù)庫(kù),對(duì)執(zhí)行的每一種類型的SQL語句監(jiān)控加鎖的情況;希望讀者通過這種方式對(duì)每一種類型的SQL語句監(jiān)控加鎖的情況。(因?yàn)槭纠艽?,筆者在此就不做了,建議讀者用類似方法驗(yàn)證加鎖情況)


                        /home/db2inst1>db2 +c update employee set comm=9999(SESS#1)                        /home/db2inst1>db2 +c select * from employee(SESS#2處于lock wait)                        /home/db2inst1>db2 +c get snapshot for locks on sample(SESS#3監(jiān)控加鎖情況)                        

注:db2 +c為不自動(dòng)提交(commit)SQL語句,也可以通過 db2 update command options using c off關(guān)閉自動(dòng)提交(autocommit,缺省是自動(dòng)提交)







7 總結(jié)

總的來說,DB2的鎖和Oracle的鎖主要有以下大的區(qū)別:

1.Oracle通過具有意向鎖的多粒度封鎖機(jī)制進(jìn)行并發(fā)控制,保證數(shù)據(jù)的一致性。其DML鎖(數(shù)據(jù)鎖)分為兩個(gè)層次(粒度):即表級(jí)和行級(jí)。通常的DML操作在表級(jí)獲得的只是意向鎖(RS或RX),其真正的封鎖粒度還是在行級(jí);DB2也是通過具有意向鎖的多粒度封鎖機(jī)制進(jìn)行并發(fā)控制,保證數(shù)據(jù)的一致性。其DML鎖(數(shù)據(jù)鎖)分為兩個(gè)層次(粒度):即表級(jí)和行級(jí)。通常的DML操作在表級(jí)獲得的只是意向鎖(IS,SIX或IX),其真正的封鎖粒度也是在行級(jí);另外,在Oracle數(shù)據(jù)庫(kù)中,單純地讀數(shù)據(jù)(SELECT)并不加鎖,這些都提高了系統(tǒng)的并發(fā)程度,Oracle強(qiáng)調(diào)的是能夠"讀"到數(shù)據(jù),并且能夠快速的進(jìn)行數(shù)據(jù)讀取。而DB2的鎖強(qiáng)調(diào)的是"讀一致性",進(jìn)行讀數(shù)據(jù)(SELECT)時(shí)會(huì)根據(jù)不同的隔離級(jí)別(RR,RS,CS)而分別加S,IS,IS鎖,只有在使用UR隔離級(jí)別時(shí)才不加鎖。從而保證不同應(yīng)用程序和用戶讀取的數(shù)據(jù)是一致的。

2. 在支持高并發(fā)度的同時(shí),DB2和Oracle對(duì)鎖的操縱機(jī)制有所不同:Oracle利用意向鎖及數(shù)據(jù)行上加鎖標(biāo)志位等設(shè)計(jì)技巧,減小了Oracle維護(hù)行級(jí)鎖的開銷,使其在數(shù)據(jù)庫(kù)并發(fā)控制方面有著一定的優(yōu)勢(shì)。而DB2中對(duì)每個(gè)鎖會(huì)在鎖的內(nèi)存(locklist)中申請(qǐng)分配一定字節(jié)的內(nèi)存空間,具體是X鎖64字節(jié)內(nèi)存,S鎖32字節(jié)內(nèi)存(注:DB2 V8之前是X鎖72字節(jié)內(nèi)存而S鎖36字節(jié)內(nèi)存)。

3. Oracle數(shù)據(jù)庫(kù)中不存在鎖升級(jí),而DB2數(shù)據(jù)庫(kù)中當(dāng)數(shù)據(jù)庫(kù)表中行級(jí)鎖的使用超過locklist*maxlocks會(huì)發(fā)生鎖升級(jí)。

4. 在Oracle中當(dāng)一個(gè)session對(duì)表進(jìn)行insert,update,delete時(shí)候,另外一個(gè)session仍然可以從Orace回滾段或者還原表空間中讀取該表的前映象(before image); 而在DB2中當(dāng)一個(gè)session對(duì)表進(jìn)行insert,update,delete時(shí)候,另外一個(gè)session仍然在讀取該表數(shù)據(jù)時(shí)候會(huì)處于lock wait狀態(tài),除非使用UR隔離級(jí)別可以讀取第一個(gè)session的未提交的值;所以O(shè)racle同一時(shí)刻不同的session有讀不一致的現(xiàn)象,而DB2在同一時(shí)刻所有的session都是"讀一致"的。







8 結(jié)束語

DB2中關(guān)于并發(fā)控制(鎖)的建議

1.正確調(diào)整locklist,maxlocks,dlchktime和locktimeout等和鎖有關(guān)的數(shù)據(jù)庫(kù)配置參數(shù)(locktimeout最好不要等于-1)。如果鎖內(nèi)存不足會(huì)報(bào)SQL0912錯(cuò)誤而影響并發(fā)。

2.寫出高效而簡(jiǎn)潔的SQL語句(非常重要)。

3.在業(yè)務(wù)邏輯處理完后盡可能快速commit釋放鎖。

4.對(duì)引起鎖等待(SQL0911返回碼68)和死鎖(SQL0911返回碼2)的SQL語句創(chuàng)建最合理的索引(非常重要,盡量創(chuàng)建復(fù)合索引和包含索引)。

5.使用 altER TABLE 語句的 LOCKSIZE 參數(shù)控制如何在持久基礎(chǔ)上對(duì)某個(gè)特定表進(jìn)行鎖定。檢查syscat.tables中l(wèi)ocksize字段,盡量在符合業(yè)務(wù)邏輯的情況下,每個(gè)表中該字段為"R"(行級(jí)鎖)。

6.根據(jù)業(yè)務(wù)邏輯使用正確的隔離級(jí)別(RR,RS,CS和UR)。

7.當(dāng)執(zhí)行大量更新時(shí),更新之前,在整個(gè)事務(wù)期間鎖定整個(gè)表(使用 SQL LOCK TABLE 語句)。這只使用了一把鎖從而防止其它事務(wù)進(jìn)行這些更新,但是對(duì)于其他用戶它的確減少了數(shù)據(jù)并發(fā)性。







免責(zé)聲明和公開聲明

本文所述觀點(diǎn)是基于作者個(gè)人對(duì)相關(guān)產(chǎn)品的理解,并不代表 IBM 的官方觀點(diǎn),IBM 不對(duì)本文中的信息負(fù)責(zé)。













關(guān)于作者

牛新莊博士是IBM官方高級(jí)培訓(xùn)講師,于2002年獲IBM杰出軟件專家獎(jiǎng),是《程序員》,《電腦編程與維護(hù)》等雜志數(shù)據(jù)庫(kù)專欄作家,是很多公司的技術(shù)顧問,他擁有OCP,AIX,DB2,HP-UX,MQ,CICS和WebSphere等二十多項(xiàng)國(guó)際認(rèn)證。曾經(jīng)幫助工農(nóng)商建招交六大行、上海移動(dòng)、青島海爾、云南紅塔、江蘇電力公司等公司做過問題診斷、性能調(diào)優(yōu)和技術(shù)支持,他經(jīng)常往返于國(guó)內(nèi)大中城市解決數(shù)據(jù)庫(kù)技術(shù)難題,有著豐富的理論和實(shí)踐經(jīng)驗(yàn)。

本站僅提供存儲(chǔ)服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊舉報(bào)。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
Oracle數(shù)據(jù)完整性和鎖機(jī)制
6.2.7 鎖升級(jí)
oracle數(shù)據(jù)庫(kù)有把TX鎖,如何定位鎖在哪?
事務(wù)的樂觀鎖和悲觀鎖
Oracle的鎖機(jī)制歸納總結(jié) - kingsui - ITeye技術(shù)網(wǎng)站
數(shù)據(jù)庫(kù)中Select For update語句的解析
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長(zhǎng)圖 關(guān)注 下載文章
綁定賬號(hào)成功
后續(xù)可登錄賬號(hào)暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服