隊(duì)列用來有序地鎖定關(guān)系與非關(guān)系型的Oracle結(jié)構(gòu)。關(guān)系型結(jié)構(gòu)可能是Oracle的數(shù)據(jù)字典表或應(yīng)用程序表。例如，當(dāng)Oracle更新sys.col$表或一個(gè)應(yīng)用程序更新它的employee表，隊(duì)列將會(huì)被調(diào)用。如果一個(gè)服務(wù)器進(jìn)程被鎖定的表所阻止，不僅僅會(huì)post一個(gè)enqueue wait等待事件，還會(huì)在v$lock,dba_lock,v$enqueue_statistics與其它視圖中顯示鎖信息。非關(guān)系型結(jié)構(gòu)被鎖定是為了阻止不合適的更改比如library cache cursor。

創(chuàng)新互聯(lián)公司主要從事成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)川匯,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

顧名思義，隊(duì)列是非常有序的，并確保以非常確定的方式更改結(jié)構(gòu)。進(jìn)程的入隊(duì)列請求會(huì)被推送到適當(dāng)?shù)年?duì)列上，當(dāng)它需要處理時(shí)，它的入隊(duì)列條目會(huì)從隊(duì)列中彈出(也叫作dequeue)。這里并沒有什么令人興奮的地方，但是排隊(duì)不是為了冒險(xiǎn)，而是為了確保以一種非常有序的、類似會(huì)計(jì)的方式更改Oracle結(jié)構(gòu)。

Oracle維護(hù)了數(shù)量驚人的隊(duì)列。在Oracle 10gr2中有208種隊(duì)列，在Oracle 11gr1中有247種隊(duì)列。但不必驚慌，因?yàn)槟憧赡苤粫?huì)遇到幾個(gè)排隊(duì)的人。另外，如果您是一位經(jīng)驗(yàn)豐富的DBA，您已經(jīng)處理過使用enqueue的行級和表級鎖。

診斷Enqueue等待
當(dāng)解決隊(duì)列問題時(shí)，首先判斷隊(duì)列類型，然后確定所涉及的SQL，最后根據(jù)您對應(yīng)用程序和相關(guān)Oracle內(nèi)部的知識開發(fā)解決方案。在深入研究最常見的排隊(duì)等待(事務(wù)(TX)排隊(duì))之前，務(wù)必了解如何確定正在等待哪個(gè)排隊(duì)和oracle 10g之前和之后版本中的相關(guān)會(huì)話。

在Oracle 10g之前，所有隊(duì)列的等待事件都是enqueue。這確實(shí)很不幸，因?yàn)檫@要從v$lock或v$session_wait中取樣來確定隊(duì)列名稱。下面的SQL語句用來從v$session_wait中來確實(shí)enqueue名。會(huì)話4388已經(jīng)鎖表，沒有等待鎖，因此沒有顯示。隊(duì)列中的第一個(gè)會(huì)話是4387，緊接著是會(huì)話4393。判斷正在運(yùn)行的SQL與所涉及的表最簡單的方式就是從v$session中查詢會(huì)話的sql_address或sql_hash_values。對于TM隊(duì)列，表可以通過p2列(ID 1列)來識別。它包含object_id，可以使用它來從dba_objects中進(jìn)行查詢。這使得確定爭用對象非常簡單。

SQL> col sid format 9999 heading "Sid"
SQL> col enq format a4 heading "Enq."
SQL> col edes format a30 heading "Enqueue Name"
SQL> col md format a10 heading "Lock Mode" trunc
SQL> col p2 format 9999999 heading "ID 1"
SQL> col p3 format 9999999 heading "ID 2"
SQL> select sid,
  2         chr(bitand(p1, -16777216) / 16777215) ||
  3         chr(bitand(p1, 16711680) / 65535) enq,
  4         decode(chr(bitand(p1, -16777216) / 16777215) ||
  5                chr(bitand(p1, 16711680) / 65535),
  6                'TX',
  7                'Row related lock (row lock or ITL)',
  8                'TM',
  9                'Table related lock',
 10                'TS',
 11                'Tablespace and Temp Seg related lock',
 12                'TT',
 13                'Temporary Table',
 14                'ST',
 15                'Space Mgt (e.g., uet$, fet$)',
 16                'UL',
 17                'User Defined',
 18                chr(bitand(p1, -16777216) / 16777215) ||
 19                chr(bitand(p1, 16711680) / 65535)) edes,
 20         decode(bitand(p1, 65535),
 21                1,
 22                'Null',
 23                2,
 24                'Sub-Share',
 25                3,
 26                'Sub-Exlusive',
 27                4,
 28                'Share',
 29                5,
 30                'Share/Sub-Exclusive',
 31                6,
 32                'Exclusive',
 33                'Other') md,
 34         p2,
 35         p3
 36    from v$session_wait
 37   where event = 'enqueue'
 38     and state = 'WAITING'
 39  /
SQL>
Sid   Enq. Enqueue Name                   Lock Mode  ID 1     ID 2
----- ---- ------------------------------ ---------- -------- --------
4387  TM   Table related lock             Exclusive     49911        0
4393  TM   Table related lock             Sub-Exlusi    49911        0
SQL> @swswp enq%
Database: prod16 31-MAR-10 04:32pm
Report: swswp.sql OSM by OraPub, Inc. Page 1
Session Wait Real Time w/Parameters
Sess
ID    Wait Event                   P1           P2        P3
----- ---------------------------- ------------ --------- -----
4383  enq: TM – contention         1414332422   49911     0
4388  enq: TM – contention         1414332422   49911     0
2 rows selected.
SQL> l
1 select sid, event,
2 p1, p2, p3
3 from v$session_wait
4 where event like '&input%'
5 and state = 'WAITING'
6* order by event,sid,p1,p2

與latch等待事件一樣，從Oracle 10g開始，每一種隊(duì)列都有它自己的等待事件。這節(jié)省了診斷步驟，因?yàn)槲覀兛梢酝ㄟ^一個(gè)簡單的查詢確定所涉及的會(huì)話和隊(duì)列類型。會(huì)話4393已經(jīng)持有表鎖并且沒有等待所以沒有顯示，會(huì)話4383和4388正等待鎖表因此post一個(gè)TM隊(duì)列等待。通過使用P2列(49911)來與dba_objects視圖的object_id關(guān)聯(lián)進(jìn)行查詢來獲得被調(diào)用的表。

TX Enqueue等待
TX隊(duì)列等待是最常見的隊(duì)列等待事件。這也是最迷人的。想深入研究這個(gè)等待事件，因?yàn)樗鼘⑹鼓钊氲亓私釵racle如何管理事務(wù)并發(fā)性，這與塊克隆、undo、讀取一致性和相關(guān)事務(wù)列表有關(guān)。

TX隊(duì)列也叫作行級鎖隊(duì)列，實(shí)際上出現(xiàn)TX隊(duì)列有三個(gè)原因，并且只有一個(gè)實(shí)際上是行級鎖。每一個(gè)Oracle數(shù)據(jù)塊可以被抽象為三個(gè)區(qū)域:
.行數(shù)據(jù)包含真實(shí)的Oracle行記錄并且是每個(gè)數(shù)據(jù)塊最重要的一個(gè)部分。

.可變數(shù)據(jù)包含事務(wù)元數(shù)據(jù)

.可用空間數(shù)量可以通過行數(shù)據(jù)增長與可變數(shù)據(jù)增長而減小

相關(guān)事務(wù)列表(ITLs)
內(nèi)置在每個(gè)Oracle數(shù)據(jù)塊的可以數(shù)據(jù)區(qū)域的結(jié)構(gòu)叫作相關(guān)事務(wù)列表(ITLs)。這些結(jié)構(gòu)最主要是用來負(fù)責(zé)Oracle的行級鎖與讀一致性。從高度抽象的角度來看，可以認(rèn)為ITLs就像檢查框，每個(gè)檢查框與一個(gè)特定的事務(wù)相關(guān)。如果想要更新行記錄，但被鎖定的行已經(jīng)與其它事務(wù)的ITL關(guān)聯(lián)，你將會(huì)收到一個(gè)TX隊(duì)列等待，這確實(shí)是行級鎖。

每個(gè)Oracle數(shù)據(jù)塊都創(chuàng)建了特定數(shù)量的ITLs。ITLs的初始值是由表的initrans空間參數(shù)所控制的并且可以通過dba_tables視圖的ini_trans列來查看。從Oracle 9i開始，缺省的ini_trans值為1，然而通過簡單的塊dump可以清楚的看到創(chuàng)建了兩個(gè)ITL。使用兩個(gè)ITLs，單個(gè)數(shù)據(jù)塊可以同時(shí)并發(fā)地執(zhí)行兩個(gè)事務(wù)。

假設(shè)第三個(gè)事務(wù)想要修改塊中沒有被鎖定的行而只在兩個(gè)ITL存在時(shí)，第三個(gè)事務(wù)的服務(wù)器進(jìn)程將嘗試動(dòng)態(tài)創(chuàng)建一個(gè)額外的ITL。然而服務(wù)器進(jìn)程必須首先確保ITL的最大數(shù)(max_trans)不會(huì)被超過并且在數(shù)據(jù)塊中要有可用空間。如果服務(wù)器進(jìn)程不能創(chuàng)建額外的ITL，它將發(fā)出一個(gè)TX隊(duì)列等待事件，并且這個(gè)進(jìn)程將耐心等待。為了減小這種情況的出現(xiàn)，單個(gè)塊的ITLs的缺省值與最大值都可以設(shè)置為255。當(dāng)不超過這個(gè)值時(shí)可以執(zhí)行alter table命令來修改。

一旦在數(shù)據(jù)塊中創(chuàng)建了一個(gè)ITL后，唯一能獲得空間的方式是重新創(chuàng)建整個(gè)表。修改空間參數(shù)將不會(huì)影響已經(jīng)創(chuàng)建的ITL。這就是為什么缺省的ITLs為1(實(shí)際上創(chuàng)建了兩個(gè)ITL)并且最大值設(shè)置為255的原因。如果數(shù)據(jù)塊的并發(fā)請求更多的ITLs，Oracle寧愿消耗空間也不愿意發(fā)出TX隊(duì)列等待事件而讓事務(wù)等待。

初看，ITL的最大數(shù)是255可能看上去非常有限，但請考慮這種情況:想想在最高并發(fā)應(yīng)用程序中，在最高并發(fā)的數(shù)據(jù)庫中的最高并發(fā)表。也許有一個(gè)表可能有250個(gè)并發(fā)進(jìn)程正在更新，刪除與插入記錄。現(xiàn)在真正有多少進(jìn)程將會(huì)并發(fā)更新，刪除或插入記錄到一個(gè)數(shù)據(jù)塊中，而不是整個(gè)表或區(qū)，是單個(gè)塊。即使使用最高并發(fā)性的應(yīng)用程序，在一個(gè)塊中激活超過255個(gè)并發(fā)事務(wù)也是極不可能的。所以ITL的最大數(shù)255并沒有太大的限制。然而如果確實(shí)出現(xiàn)了問題，可以通過增加表的pct_free參數(shù)來減小數(shù)據(jù)塊的并發(fā)性或者為了減少存儲(chǔ)在塊中的行記錄可以增加固定長度的列。

Unod段的事務(wù)表
每個(gè)undo段在它的頭塊中包含一個(gè)結(jié)構(gòu)叫事務(wù)表。Oracle開發(fā)人員將事務(wù)表中的行稱作slots(插槽)。每一個(gè)已經(jīng)占用的slot都與正在或已經(jīng)在undo段中存儲(chǔ)undo信息的事務(wù)相關(guān)。如果一個(gè)事務(wù)已經(jīng)提交或者回滾，它確實(shí)是一個(gè)非活動(dòng)事務(wù)，否則它就是一個(gè)活動(dòng)事務(wù)。除了包含slot號與事務(wù)狀態(tài)，每個(gè)slot也包含一個(gè)序列號。為了區(qū)分不同的事務(wù)使用相同的slot并能讓slot重用，序列號可以增長。UBA是undo塊地址，提供到事務(wù)的undo的直接鏈接。SCN是當(dāng)相關(guān)事務(wù)開始時(shí)事務(wù)的系統(tǒng)改變號。

事務(wù)表與性能分析人員相關(guān)因?yàn)樗鼈兲峁┝耸聞?wù)號。每個(gè)事務(wù)有一個(gè)相關(guān)的事務(wù)號，并且事務(wù)號是基于事務(wù)的事務(wù)表?xiàng)l目生成的。事務(wù)號由三組數(shù)字組成。第一部分是事務(wù)表號，第二部分是slot號，最后是相關(guān)序列號。例如，一個(gè)事務(wù)號為00100.000.00007。ITLs與事務(wù)表之間的聯(lián)系是每個(gè)ITL條目關(guān)聯(lián)到一個(gè)特定的事務(wù)并且在ITL條目中包含事務(wù)號，比如00100.000.00007。

深入了解相關(guān)事務(wù)列表(ITL)
已經(jīng)了解了ITL與undo段事務(wù)表，現(xiàn)在是將它們作為單個(gè)工作單元組合在一起的時(shí)候了，并展示在事務(wù)活動(dòng)期間ITLs是如何變化的。深入了解相關(guān)事務(wù)列表可以讓你深入理解Oracle如何管理事務(wù)并發(fā)性，如何創(chuàng)建讀一致性塊以及為什么要小心“snapshot too old”錯(cuò)誤。

下面通過執(zhí)行命令alter system dump datafile 1 block 75847來dump數(shù)據(jù)塊。在執(zhí)行塊dump時(shí)，這個(gè)塊(1,75847)包含了許多行記錄并且有三個(gè)活動(dòng)事務(wù)更新四行不同的記錄。第一個(gè)與第三個(gè)事務(wù)顯示正在更新一行記錄，第二個(gè)事務(wù)正在更新二行記錄。

$ cat prod5_ora_21741.trc
...
Block header dump: 0x00412847
Object id on Block? Y
seg/obj: 0xff6b csc: 0x00.50fcb6 itc: 3 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x412848 ver: 0x01
Itl         Xid                 Uba         Flag  Lck      Scn/Fsc
0x01 0x0003.00d.00000318 0x00c3e3d0.0593.0c ----   1    fsc 0x0000.00000000
0x02 0x0008.01b.00000340 0x00c41bce.0481.24 ----   2    fsc 0x0000.00000000
0x03 0x0001.000.00000320 0x00c45fa0.0599.0b ----   1    fsc 0x0000.00000000
...

ITL條目包含以下內(nèi)容:
itl:這是事務(wù)的ITL號

xid:這是事務(wù)ID，它由事務(wù)表ID(0003)，事務(wù)表slot號(00d)與序列號(00000318)組成。事務(wù)ID是很重要的，因?yàn)樗糜诖_?？雌饋硐嚓P(guān)的undo信息是真正相關(guān)的。

uba:這是undo塊地址。這直接指向事務(wù)的最新更改undo，對于回滾事務(wù)和讀取一致性(克隆緩沖區(qū)構(gòu)造)都是必要的。

flag:事務(wù)的狀態(tài)它可以有許多值，以下是常見值
----- 意味著事務(wù)是活動(dòng)的，DML在執(zhí)行事務(wù)沒有提交或回滾

--U-- 意味著事務(wù)已經(jīng)提交，因此任何行數(shù)據(jù)都可以引用在活動(dòng)事務(wù)中沒有被使用的ITL并且它們沒有被鎖定。事務(wù)的行數(shù)據(jù)可能沒有被合并。例如，如果一個(gè)列被更新，在更改之前與之前的值可能保留在行數(shù)據(jù)中。

--C-- 意味著事務(wù)已經(jīng)提交，行數(shù)據(jù)已經(jīng)合并，并且行數(shù)據(jù)中的ITL條目已經(jīng)被刪除。任何塊touch可能觸發(fā)對這個(gè)flag的改變，包括select語句。我知道這很難相信。這種看似延遲的更改通常稱為延遲塊清除，或者簡單地稱為塊清除。

Lck:這是事務(wù)在某個(gè)時(shí)刻鎖定在這個(gè)塊中的行數(shù)。大于0的值不能夠說時(shí)行被鎖定。如果這個(gè)值為2，就像第二個(gè)事務(wù)一樣，這個(gè)事務(wù)關(guān)聯(lián)兩行記錄。鎖會(huì)保持到flag改變?yōu)镃----為止。這意味著在一個(gè)事務(wù)提交后且不再被認(rèn)為是活動(dòng)(--U--)狀態(tài)時(shí)，Lck值可能大于0

Scn/Fsc:SCN是系統(tǒng)改變號并用來判斷事務(wù)是何時(shí)結(jié)束的(提交或回滾)。上面的例子中SCN沒有被指泒，但在事務(wù)提交后，SCN被設(shè)置了如下所示。當(dāng)創(chuàng)建一個(gè)buffer的讀一致性版本判斷是否需要檢索undo時(shí)SCN是很重要的。FSC引用可用空間信用。它用于未提交的事務(wù)當(dāng)一個(gè)更新或刪除操作造成行記錄長度收縮使用。Oracle將保護(hù)這個(gè)空閑空間，以防事務(wù)回滾和需要重新填充空間。如果空閑空間用于其他用途，然后事務(wù)回滾，則可能需要遷移行!。在下面的dump結(jié)果中，前兩個(gè)事務(wù)(ITLs x01與x02)已經(jīng)提交標(biāo)記它們的事務(wù)為非活動(dòng)狀態(tài)。第三個(gè)事務(wù)，ITL x03，還沒有提交。在前兩個(gè)事務(wù)提交后，相同的塊dump命令，alter system dump datafile 1 block 75847。注意flag已經(jīng)改變了，一個(gè)SCN已經(jīng)指泒給事務(wù)了。

$ cat prod5_ora_21741.trc
...
Block header dump: 0x00412847
Object id on Block? Y
seg/obj: 0xff6b csc: 0x00.50fcb6 itc: 3 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x412848 ver: 0x01
Itl          Xid                Uba         Flag Lck      Scn/Fsc
0x01 0x0003.00d.00000318 0x00c3e3d0.0593.0c --U- 1   fsc 0x0000.0050fd6f
0x02 0x0008.01b.00000340 0x00c41bce.0481.24 --U- 2   fsc 0x0000.0050fd6b
0x03 0x0001.000.00000320 0x00c45fa0.0599.0b ---- 1   fsc 0x0000.00000000

兩個(gè)flags ----與--U-是必需的，因?yàn)榛顒?dòng)事或者過去的活動(dòng)事務(wù)中涉及的行可以在其行數(shù)據(jù)中具有有效的ITL條目。因?yàn)楹唵我眯袛?shù)據(jù)與查看ITL條目不能說明行當(dāng)前被活動(dòng)事務(wù)調(diào)用與鎖定。為了檢查行是否被鎖定，一個(gè)服務(wù)器進(jìn)程必須從行數(shù)據(jù)中得到ITL引用然后檢查數(shù)據(jù)塊的可變ITL區(qū)域中的flag。如果flag為 ----,那么服務(wù)器進(jìn)程知道行確實(shí)被一個(gè)活動(dòng)事務(wù)所調(diào)用且被鎖定。然而如果falg為--U,服務(wù)器進(jìn)程知道行沒有被鎖定。

塊清除進(jìn)程的部分工作將刪除非活動(dòng)事務(wù)行數(shù)據(jù)ITL條目，將它們各自的ITL條目在數(shù)據(jù)塊的可變部分的flag的狀態(tài)修改為C---，并合并行數(shù)據(jù)。

這是一種聰明的策略，因?yàn)镺racle可以快速使用最小的改變來記錄數(shù)據(jù)塊中的改變，但仍然在行級別維護(hù)并發(fā)控制。最終需要對塊進(jìn)行最后的更改，但這可能發(fā)生在工作負(fù)載較低的時(shí)期，比如基準(zhǔn)測試完成之后。

執(zhí)行查詢語句來touch塊1,75847后，再執(zhí)行dump命令的結(jié)果如下，數(shù)據(jù)塊(1,75847)在執(zhí)行查詢語句touch數(shù)據(jù)塊后事務(wù)flags從--U-變?yōu)榱薈---,指示塊清除已經(jīng)發(fā)生了。

$ cat prod5_ora_21741.trc
...
Block header dump: 0x00412847
Object id on Block? Y
seg/obj: 0xff6b csc: 0x00.510047 itc: 3 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x412848 ver: 0x01
Itl          Xid                Uba         Flag Lck     Scn/Fsc
0x01 0x0003.00d.00000318 0x00c3e3d0.0593.0c C--- 0     scn 0x0000.0050fd6f
0x02 0x0008.01b.00000340 0x00c41bce.0481.24 C--- 0     scn 0x0000.0050fd6b
0x03 0x0001.000.00000320 0x00c45fa0.0599.0b ---- 1     fsc 0x0000.00000000
...

現(xiàn)在我意識到這很有趣，但是我也理解一些讀者可能認(rèn)為這個(gè)block dump和ITL的東西并沒有那么強(qiáng)的關(guān)聯(lián)。但我不敢茍同。您不僅對TX排隊(duì)有了更全面的了解，而且還清楚地了解了如何排隊(duì)Oracle實(shí)現(xiàn)了它的專利行級鎖方案。

深入了解Buffer克隆
介紹塊克隆是因?yàn)樗cCBC latch競爭。現(xiàn)在將深入學(xué)習(xí)Oracle如何使用ITLs，undo塊,SCNs與其它有趣的Oracle技術(shù)。當(dāng)一個(gè)服務(wù)器進(jìn)程要定位一個(gè)請求的buffer并且發(fā)現(xiàn)請求的行在查詢開始后發(fā)生改變了，它必須為buffer創(chuàng)建一個(gè)時(shí)光倒流的鏡像。這就叫作當(dāng)前(CU)buffer的一致性讀(CR)buffer。一旦buffer被拷貝，合適的undo被應(yīng)用后，使被拷貝的buffer回退直到CR buffer被成功克隆好為止。

假設(shè)我們的查詢執(zhí)行時(shí)間是SCN 12330，查詢最終得到要訪問的buffer 7，678。然而，我們注意到存在一些ITL活動(dòng)事務(wù) 7.3.8當(dāng)前是活動(dòng)狀態(tài)并且buffer可能在我們查詢開始后發(fā)生了改變。事務(wù)5.2.6是非活動(dòng)狀態(tài)(flag為C，并指派了SCN，并且Lck為0），但是改變的提交時(shí)間在我們查詢開始之后并且影響這個(gè)當(dāng)前(CU)buffer。這些塊改變意味著在CU buffer在我們查詢在SCN 12330時(shí)間點(diǎn)開始后已經(jīng)發(fā)生改變了并且不能用于我們的查詢。我們需要一個(gè)一致性讀副本，它可以時(shí)光倒流回到SCN 12330時(shí)間點(diǎn)。因此CU buffer 7,678必須被克隆并應(yīng)用undo，來創(chuàng)建一個(gè)SCN12330時(shí)間點(diǎn)的CR buffer。

在執(zhí)行buffer克隆之前，必須找到一個(gè)不被頻繁訪問的free buffer然后使用7,678的CU buffer來替換它。服務(wù)器進(jìn)程將獲得LRU chain latch與相關(guān)的LRU chain，然后從LRU chain的LRU端開始掃描，查找不被頻繁訪問的free buffer。最終將找到一個(gè)不被頻繁訪問的free buffer并使用CU buffer 7,678的副本來替換它。當(dāng)然CBC結(jié)構(gòu)也將被更新來映射克隆buffer在buffer cache中的位置。

從與第一個(gè)ITL相關(guān)的活動(dòng)事務(wù)7.3.8開始。服務(wù)器進(jìn)程需要檢索在我們查詢開始時(shí)間scn 12330之后所有生成的undo記錄。事務(wù)7.3.8的最近生成的undo可以通過它的ITL的undo塊地址(UBA)所鏈接到的undo塊2,45中找到。服務(wù)器進(jìn)程然后必須訪問undo塊2,45。這需要請求CBC活動(dòng)并且也可能請求LRU活動(dòng)來執(zhí)行IO調(diào)用。一旦訪問到undo buffer 2,45，將會(huì)通過比較事務(wù)號來檢查確保我們使用正確的事務(wù)在工作。數(shù)據(jù)塊與undo塊事務(wù)號需要匹配(7.3.8)，因?yàn)槭聞?wù)是活動(dòng)的，所以undo信息應(yīng)該沒有鋪覆蓋。

undo塊2,45的SCN是12348，這意味著undo塊代表的塊改變出現(xiàn)在我們查詢開始時(shí)間scn 12330之后，因此，我們需要對克隆的CR buffer應(yīng)用undo數(shù)據(jù)，讓它回退到過去一點(diǎn)點(diǎn)。

undo塊2,45也鏈接到了另一個(gè)undo塊2,90。這是一種undo鏈并且可能持續(xù)一段時(shí)間，消耗大量的計(jì)算資源。服務(wù)器進(jìn)程現(xiàn)在必須訪問undo塊2,90(請求CBC活動(dòng)并且也可能請求LRU活動(dòng)來執(zhí)行IO調(diào)用）并且再次比較事務(wù)號來確保它們是否匹配。它們匹配，現(xiàn)在檢查SCN。undo塊2,90的SCN是12320，它在我們的查詢開始時(shí)間SCN 12330之前，因此我們不需要應(yīng)用undo。如果不應(yīng)用undo，我們的CR buffer將代表的是塊7,678在SCN 12320時(shí)間點(diǎn)的版本，這比我們要查詢的時(shí)間SCN 12330早了。

現(xiàn)在查看第二個(gè)ITL，它與事務(wù)5,2.6關(guān)聯(lián)。這個(gè)事務(wù)在SCN 12350時(shí)間點(diǎn)已經(jīng)提交了，在我們的查詢開始時(shí)間之后，因此我們需要應(yīng)用它的undo。從ITL條目來看，我們將得到ndo塊地址2,70并且訪問這個(gè)undo塊?，F(xiàn)在比較事務(wù)號，因?yàn)槭聞?wù)已經(jīng)提交，undo信息將不再受保護(hù)。增加undo保留期可以讓udno信息保留更長的境，但也不受保護(hù)。

假設(shè)另一個(gè)服務(wù)器進(jìn)程覆蓋了undo塊2,70中的相關(guān)事務(wù)undo信息。如果出現(xiàn)這種情況，服務(wù)器進(jìn)程的事務(wù)號將被記錄并且這里將記錄為5.2.6。通過事務(wù)號比較，我們注意到差異并且立即知道undo塊2,70中的undo不能應(yīng)用于我們的CR buffer。在這時(shí)，服務(wù)器進(jìn)程將會(huì)發(fā)出快照太舊的錯(cuò)誤信息并停止我們的查詢。很明顯，undo塊快照太舊因?yàn)楸黄渌M(jìn)程覆蓋了。

幸運(yùn)地是，事務(wù)號是匹配的。undo塊2,70中的undo是在SCN 12340時(shí)間點(diǎn)發(fā)生的改變，它在我們的查詢開始之后，因此我們應(yīng)用這個(gè)undo到我們的CR buffer。下一個(gè)undo鏈接是空的，因此沒有其它undo需要應(yīng)用了。

現(xiàn)在返回到ITL條目，這里沒有更多的ITL需要考慮，因此我們完成的數(shù)據(jù)塊的克隆。任何一個(gè)服務(wù)器進(jìn)程現(xiàn)在都可以訪問CR buffer 7,678它包含了SCN 12330時(shí)間所代表的內(nèi)容。

現(xiàn)在應(yīng)該很清楚為什么ITLs如此重要了，而且Oracle的讀取一致性模型雖然非常強(qiáng)大、必要且高效，但仍然相對昂貴，因?yàn)樗赡軙?huì)消耗大量CPU和IO，從而減慢應(yīng)用程序的響應(yīng)時(shí)間。Oracle非常清楚這一點(diǎn)，并且從Oracle 10gr2開始使用內(nèi)存優(yōu)化結(jié)構(gòu)來臨時(shí)存儲(chǔ)undo信息。這些對象不是段類型并且不受與段相關(guān)的CBC和LRU chain活動(dòng)的影響。在內(nèi)存中，undo被存儲(chǔ)在shared pool中。

新聞名稱：OracleEnqueueWaits
文章位置：http://chinadenli.net/article14/ppdhge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、網(wǎng)站設(shè)計(jì)、網(wǎng)站策劃、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站導(dǎo)航、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)