enq: TX - allocate ITL entry等待事件深入剖析

IT那活兒發(fā)布于2023-01-11 13:20 / 3873人閱讀

點(diǎn)擊上方“IT那活兒”，關(guān)注后了解更多精彩內(nèi)容！！！

系統(tǒng)配置

oracle數(shù)據(jù)庫 12.2的雙節(jié)點(diǎn)RAC ，操作系統(tǒng)：AIX Version 7.2

DB patch ：

25294150;

25319173;

29314424;OCW APR 2019 RELEASE UPDATE 12.2.0.1.190416 (29314424)

29314339;Database Apr 2019 Release Update : 12.2.0.1.190416 (29314339)

其他信息暫不統(tǒng)計(jì)。

現(xiàn)象分析

節(jié)點(diǎn)2在2021-09-01 14:03:39出現(xiàn)異常等待事件enq: TX - allocate ITL entry

等待事件分析

依據(jù)等待事件 enq: TX - allocate ITL entry 分析來自Doc ID 1472175.1

導(dǎo)致原因：

默認(rèn)情況下，表的 INITRANS 值為 1，索引的值為 2。這定義了一個稱為感興趣交易列表 (ITL) 的內(nèi)部塊結(jié)構(gòu)。為了修改一個塊中的數(shù)據(jù)，一個進(jìn)程需要使用一個空的ITL槽來記錄該事務(wù)有興趣修改該塊中的一些數(shù)據(jù)。如果空閑 ITL 插槽不足，則將在塊中保留的空閑空間中使用新插槽。如果這用完并且太多并發(fā) DML 事務(wù)正在競爭同一個數(shù)據(jù)塊，我們會觀察到針對以下等待事件的爭用 - “enq：TX - 分配 ITL 條目”。

ITL原理:

ITL(Interested Transaction List)是Oracle數(shù)據(jù)塊內(nèi)部的一個組成部分，用來記錄該塊所有發(fā)生的事務(wù)，一個itl可以看作是一個記錄，在一個時間，可以記錄一個事務(wù)（包括提交或者未提交事務(wù)）。當(dāng)然，如果這個事務(wù)已經(jīng)提交，那么這個itl的位置就可以被反復(fù)使用了，因?yàn)閕tl類似記錄，所以，有的時候也叫itl槽位。Oracle的每個數(shù)據(jù)塊中都有一個或者多個事務(wù)槽，每一個對數(shù)據(jù)塊的并發(fā)訪問事務(wù)都會占用一個事務(wù)槽。表和索引的事務(wù)槽ini_trans是1、max_trans是255，在oracle10g中，不能修改max_trans這個參數(shù)，因?yàn)閛racle10g忽略了這個參數(shù)。如果一個事務(wù)一直沒有提交，那么，這個事務(wù)將一直占用一個itl槽位，itl里面記錄了事務(wù)信息，回滾段的嵌入口，事務(wù)類型等等。如果這個事務(wù)已經(jīng)提交，那么，itl槽位中還保存的有這個事務(wù)提交時候的SCN號。如dump一個塊，就可以看到itl信息：

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.002.0000158e 0x0080104d.00a1.6e --U- 734 fsc 0x0000.6c9deff0
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

如在并發(fā)量特別大的系統(tǒng)中，最好分配足夠的itl個數(shù)（10g之前的版本），其實(shí)它并浪費(fèi)不了太多的空間，或者，設(shè)置足夠的pctfree，保證itl能擴(kuò)展，但是pctfree有可能是被行數(shù)據(jù)給消耗掉的，如update可能一下占滿塊空間，所以，也有可能導(dǎo)致塊內(nèi)部的空間不夠而導(dǎo)致itl等待，所以在通常情況下，10g版本后引起itl等待的原因往往是因?yàn)閴K的空間不足導(dǎo)致，并不是tran事務(wù)槽數(shù)量不足，在正常情況下2k的數(shù)據(jù)塊最多可以擁有41個itl，4k數(shù)據(jù)塊最多擁有83，8k最多用友169個itl（以itl 24byte為單位）。INITRANS不足的問題不會出現(xiàn)在索引數(shù)據(jù)塊上，當(dāng)發(fā)現(xiàn)沒有足夠空間分配ITL slot時，無論是枝點(diǎn)塊還是葉子塊，數(shù)據(jù)塊會發(fā)生分裂(Index Block Split)。

有一種特殊情況也會引起ITL的等待，就是在索引上的遞歸事務(wù)itl爭用，這種情況比較特殊。在索引的枝節(jié)點(diǎn)上，有且只有一個ITL slot，它是用于當(dāng)發(fā)生節(jié)點(diǎn)分裂的遞歸事務(wù)(Recursive Transaction)。在葉子節(jié)點(diǎn)上，第一條ITL Slot也是用于分裂的遞歸事務(wù)的。在一個用戶事務(wù)中，如果發(fā)生多次分裂，每一次分裂都是由一個多帶帶的遞歸事務(wù)控制的，如果下層節(jié)點(diǎn)分裂導(dǎo)致其父節(jié)點(diǎn)分裂，它們的分裂則由同一個遞歸事務(wù)控制。當(dāng)2個事務(wù)同時需要分裂一個枝節(jié)點(diǎn)或者葉子節(jié)點(diǎn)時，或者枝節(jié)點(diǎn)下的2個子節(jié)點(diǎn)分別被2個事務(wù)分裂，就會造成這種ITL等待。

此問題的主要解決方案是通過重新創(chuàng)建表或索引并更改 INITRANS 或 PCTFREE 參數(shù)來增加表或索引的 ITL 功能，以便能夠處理更多并發(fā)事務(wù)。這反過來將有助于減少“enq：TX - 分配 ITL 條目”等待事件。

實(shí)驗(yàn)論證

實(shí)驗(yàn)一：

數(shù)據(jù)塊上的initrans不能擴(kuò)展分配slot導(dǎo)致的itl爭用測試。

數(shù)據(jù)塊沒有空間留給itl slot擴(kuò)展時候的測試，創(chuàng)建表luda，指定pctfree為0，同時指定initrans為1然后填滿相關(guān)數(shù)據(jù)塊，再對塊滿的數(shù)據(jù)進(jìn)行更新模擬出itl的等待。

1. 創(chuàng)建表luda，并指定pctfree為0，initrans為1

create table luda(a int) pctfree 0 initrans 1;
Table created.

2. 向表中插入數(shù)據(jù)

idle 06:51:17> begin
for i in 1..20000 loop
insert into luda values(i);
end loop;
end;
/ 2    3    4    5    6

PL/SQL procedure successfully completed.

commit ;


select f,b,count(*) from (select dbms_rowid.rowid_relative_fno(rowid) f,dbms_rowid.rowid_block_number(rowid) b from luda) group by f,b order by 3;

F B COUNT(*)
---------- ---------- ----------
1 94028 182
1 94026 734
1 94017 734
1 94021 734
1 94023 734
1 93997 734
1 93998 734
1 94014 734
1 94024 734
1 93995 734
1 94025 734
1 94016 734
1 94009 734
1 94012 734
1 94015 734
1 93994 734
1 93999 734
1 94008 734
1 94019 734
1 94011 734
1 94018 734
1 94027 734
1 93993 734
1 94013 734
1 94020 734
1 94022 734
1 93996 734
1 94010 734

插入數(shù)據(jù)后可以發(fā)現(xiàn)該表有28個數(shù)據(jù)塊，填滿了除了94028塊意外的其他數(shù)據(jù)塊。

3. 導(dǎo)出已經(jīng)填滿的數(shù)據(jù)塊93997.

alter system dump datafile 1 block 93997;

Block header dump: 0x00416f2d
Object id on Block? Y
seg/obj: 0x15b03 csc: 0x00.304755 itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.020.0000033c 0x00c0008a.00de.2d --U- 734 fsc 0x0000.00304794
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00416f2d

//發(fā)現(xiàn)initrans為1的情況下默認(rèn)是有2個事務(wù)槽，itc=2

data_block_dump,data header at 0x7f7c688a4a5c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x7f7c688a4a5c
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xb95
avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734        offs=0
0x12:pri[0] offs=0x1f99
0x14:pri[1] offs=0x1f92
0x16:pri[2] offs=0x1f8b
0x18:pri[3] offs=0x1f84
0x1a:pri[4] offs=0x1f7d
0x1c:pri[5] offs=0x1f76
0x1e:pri[6] offs=0x1f6f
0x20:pri[7] offs=0x1f68
0x22:pri[8] offs=0x1f61
0x24:pri[9] offs=0x1f5a
0x26:pri[10] offs=0x1f53
0x28:pri[11] offs=0x1f4c
0x2a:pri[12] offs=0x1f45
0x2c:pri[13] offs=0x1f3e
0x2e:pri[14] offs=0x1f37
0x30:pri[15] offs=0x1f30
0x32:pri[16] offs=0x1f29
0x34:pri[17] offs=0x1f22
0x36:pri[18] offs=0x1f1b
0x38:pri[19] offs=0x1f14
0x3a:pri[20] offs=0x1f0d
0x3c:pri[21] offs=0x1f06
0x3e:pri[22] offs=0x1eff
0x40:pri[23] offs=0x1ef8
0x42:pri[24] offs=0x1ef1
0x44:pri[25] offs=0x1eea
0x46:pri[26] offs=0x1ee3
0x48:pri[27] offs=0x1edc
0x4a:pri[28] offs=0x1ed5
0x4c:pri[29] offs=0x1ece
0x4e:pri[30] offs=0x1ec7
0x50:pri[31] offs=0x1ec0
0x52:pri[32] offs=0x1eb9
0x54:pri[33] offs=0x1eb2
0x56:pri[34] offs=0x1eab
0x58:pri[35] offs=0x1ea4
0x5a:pri[36] offs=0x1e9d
0x5c:pri[37] offs=0x1e96
0x5e:pri[38] offs=0x1e8f
0x60:pri[39] offs=0x1e88
0x62:pri[40] offs=0x1e81
0x64:pri[41] offs=0x1e7a
0x66:pri[42] offs=0x1e73
0x68:pri[43] offs=0x1e6c
0x6a:pri[44] offs=0x1e65
0x6c:pri[45] offs=0x1e5e
0x6e:pri[46] offs=0x1e57
0x70:pri[47] offs=0x1e50
0x72:pri[48] offs=0x1e49
0x74:pri[49] offs=0x1e42
0x76:pri[50] offs=0x1e3b
0x78:pri[51] offs=0x1e34
0x7a:pri[52] offs=0x1e2d
0x7c:pri[53] offs=0x1e26
0x7e:pri[54] offs=0x1e1f
0x80:pri[55] offs=0x1e18
0x82:pri[56] offs=0x1e11
0x84:pri[57] offs=0x1e0a
0x86:pri[58] offs=0x1e03
0x88:pri[59] offs=0x1dfc
0x8a:pri[60] offs=0x1df5
0x8c:pri[61] offs=0x1dee
0x8e:pri[62] offs=0x1de7
0x90:pri[63] offs=0x1de1
0x92:pri[64] offs=0x1dda
0x94:pri[65] offs=0x1dd3
0x96:pri[66] offs=0x1dcc
0x98:pri[67] offs=0x1dc5
0x9a:pri[68] offs=0x1dbe
0x9c:pri[69] offs=0x1db7
0x9e:pri[70] offs=0x1db0
0xa0:pri[71] offs=0x1da9
0xa2:pri[72] offs=0x1da2
0xa4:pri[73] offs=0x1d9b

4. 塊滿的情況測試slot的分配，根據(jù)前面的查詢結(jié)果我們知道單個塊的存儲行數(shù)為734行，也可以通過dump中的nrow=734得知，所以我們在這部測試中依次更新第100，200，300行的數(shù)據(jù)。

session 1 更新第100行的數(shù)據(jù)：

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and 
dbms_rowid.ROWID_ROW_NUMBER(rowid)=100;
1 row updated.

session 2更新第200行的數(shù)據(jù)：

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and 
dbms_rowid.ROWID_ROW_NUMBER(rowid)=200;

session 3更新第300行的數(shù)據(jù)，先查看此時的SID，并且在執(zhí)行過程中session 3 hang住：

SQL> select sid from v$mystat where rownum=1;

SID
----------
172

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=300;

--此時進(jìn)程hang住

SQL> select sid,event from v$session where sid=158;

SID EVENT
---------- ----------------------------------------------------------------
172 enq: TX - allocate ITL entry

1 row updated.

此時dump次數(shù)據(jù)塊：

alter system dump datafile 1 block 93997；

Block header dump: 0x0040ee92
Object id on Block? Y
seg/obj: 0xcb0a csc: 0x00.bb97e itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01   0x0001.020.0000033c 0x00c0008a.00de.2d ---- 1 fsc 0x0000.00304794
0x02   0x0000.000.00000000  0x00000000.0000.00 ---- 1 fsc 0x0000.00000000

--通過此時的dump我們也可以發(fā)現(xiàn)原先為被占用的2個事務(wù)槽已經(jīng)被占用而且事務(wù)未提交。

data_block_dump,data header at 0xd77645c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x0d77645c
bdba: 0x0040ee92
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xbf8
avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734 offs=0

從以上驗(yàn)證了空間不足的情況下會導(dǎo)致itl無法分配引起enq: TX – allocate ITL entry等待事件的產(chǎn)生。

實(shí)驗(yàn)二：

當(dāng)一個事務(wù)需要修改一個數(shù)據(jù)塊時，需要在數(shù)據(jù)塊頭部獲取一個可用的ITL槽，用于記錄事務(wù)的id,使用undo數(shù)據(jù)塊地址,scn等信息。如果事務(wù)申請不到新的可用ITL槽時，就會產(chǎn)生enq: TX - allocate ITL entry等待。

發(fā)生這個等待時，要么是塊上的已分配ITL個數(shù)(通過ini_trans參數(shù)控制)達(dá)到了上限255(10g以后沒有了max_trans限制參數(shù)，無法指定小于255的值)，要么是這個塊中沒有更多的空閑空間來容納一個ITL了(每個ITL占用24bytes)。

默認(rèn)情況下創(chuàng)建的表ITL槽數(shù)最小為1+1,pctfree為10，那么如果是這樣一種情況，如果表中經(jīng)常執(zhí)行update語句，然后塊中剩余的10%空間所剩無幾，而且業(yè)務(wù)的并發(fā)量還很大，此時就很容易遇到enq: TX - allocate ITL entry等待。

1. 問題模擬：

create table ttitl as select * from dba_objects;

select t.object_id,t.object_name,dbms_rowid.rowid_relative_fno(t.rowid),dbms_rowid.rowid_block_number(t.rowid) from ttitl t where dbms_rowid.rowid_block_number(t.rowid)=143612;

通過幾個更新語句將默認(rèn)的ITL槽占滿

update ttitl set object_name=xxxxxxxxxxx where object_id=20;
alter system dump datafile 4 block 143612;

我們要拿4號文件的143612塊做實(shí)驗(yàn)，目前塊中擁有92行數(shù)據(jù)，現(xiàn)在還需要看塊上還存在多少剩余空間? 答案是通過fseo-fsbo或者bbed得到。

fsbo=0xc8 --=======>>>>>>fsbo代表 Free Space Begin offset 空閑 空間的起始偏儀量
fseo=0x342 --=======>>>>>>fseo代表Free Space End offset 空閑空間的結(jié)束偏儀量
0x342-0xc8=0x27A
834-200=634

產(chǎn)生一個事務(wù)后

fsbo=0xc8
fseo=0x32a
0x32a-0xc8=0x262=610
634-610=24bytes

也正驗(yàn)證了一個itl槽占24bytes的說法

按照這個方式計(jì)算，這個塊上還能夠存在很多事務(wù)，610/24=25,該塊上還能增加25個事務(wù)呢
現(xiàn)在通過update方式將塊上的空閑空間縮小

update ttitl set 
object_name=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
where object_id>60;

現(xiàn)在通過BBED和重新dump該塊發(fā)現(xiàn)此塊空閑空間已經(jīng)只剩19bytes了。

[oracle@test ~]$ cat par.txt
blocksize=8192
listfile=filelist.txt
mode=edit
[oracle@test ~]$ cat filelist.txt
1 /u01/app/oracle/oradata/orcl/system01.dbf 933232640
2 /u01/app/oracle/oradata/orcl/mctpsys.dbf 10485760
3 /u01/app/oracle/oradata/orcl/sysaux01.dbf 618659840
4 /u01/app/oracle/oradata/orcl/users01.dbf 2246574080
5 /u01/app/oracle/oradata/orcl/example01.dbf 104857600
6 /u01/app/oracle/oradata/orcl/users02.dbf 52428800
7 /u01/app/oracle/oradata/orcl/mgmt.dbf 1363148800
8 /u01/app/oracle/oradata/orcl/mgmt_deepdive.dbf 209715200
9 /u01/app/oracle/oradata/orcl/mgmt_ecm_depot1.dbf 41943040
10 /u01/app/oracle/oradata/orcl/EPMRANGE1.dbf 6442450944
11 /u01/app/oracle/oradata/orcl/EPMIDX.dbf 4294967296
12 /u01/app/oracle/oradata/orcl/EPMDAT1.dbf 209715200
13 /u01/app/oracle/oradata/orcl/undotbs02.dbf 5368709120
14 /u01/app/oracle/oradata/orcl/mctpsys1.dbf 314572800
15 /u01/app/oracle/oradata/orcl/mctpsys2.dbf 1073741824
16 /u01/app/oracle/oradata/orcl/rmantbs.dbf 209715200
17 /u01/app/oracle/oradata/orcl/ggs1.dbf 524288000
18 /u01/app/oracle/oradata/orcl/ZZZ1.DBF 20971520
[oracle@test ~]$ bbed parfile=par.txt
Password: blockedit

BBED> set dba 4,143612
     DBA 0x010230fc (16920828 4,143612)

BBED> map
File: /u01/app/oracle/oradata/orcl/users01.dbf (4)
Block: 143612                                Dba:0x010230fc
------------------------------------------------------------
KTB Data Block (Table/Cluster)

struct kcbh, 20 bytes @0 

struct ktbbh, 120 bytes @20 

struct kdbh, 14 bytes @148 

struct kdbt[1], 4 bytes @162 

sb2 kdbr[91] @166 

ub1 freespace[19] @348 --====>>>>>>>>>>>>>塊上的空閑空間為19bytes 

ub1 rowdata[7821] @367 

ub4 tailchk @8188

--摘自datafile dump日志

fsbo=0xc8
fseo=0xdb
0xdb-0xc8=0x13=19

這塊上只有19bytes字節(jié)的空間了，看來是無法再容納一個ITL槽了，再新產(chǎn)生一個事務(wù)

update ttitl set object_name=I_FILE1 where object_id=41;

此時可以看到enq: TX - allocate ITL entry等待，直至塊上的其它事務(wù)提交或回滾后，此會話才能繼續(xù)，否則一直處于等待狀態(tài)。

SQL> select sid,serial#,status,username,event,seconds_in_wait,sql_id from v$session where serial#<>1 and sql_id is not null and event not like %SQL*Net message% and event not like Streams AQ% order by 7;

       SID    SERIAL# STATUS   USERNAME   EVENT                        SECONDS_IN_WAIT SQL_ID
---------- ---------- -------- ---------- ---------------------------------------- --------------- -------------
       528     39292 ACTIVE   TT       enq: TX - allocate ITL entry                    4 512zw5fc3bztt

--記錄一下enq鎖的p1 p2 p3值的含義

select * from v$session where event like enq%;
EVENT# 189
EVENT enq: TX - allocate ITL entry
P1TEXT name|mode
P1 1415053316
P1RAW 0000000054580004
P2TEXT usn<<16 | slot
P2 131084
P2RAW 000000000002000C
P3TEXT sequence
P3 88864
P3RAW 0000000000015B20

--P1值與鎖名稱和鎖模式有關(guān)1415053316轉(zhuǎn)換成16進(jìn)制后為54580004,其中54代表字母T,58代表字母X,合一起就是鎖的name。

SQL> select dump(T,16),dump(X,16) from dual;

DUMP(T,16) DUMP(X,16)
---------------- ----------------
Typ=96 Len=1: 54 Typ=96 Len=1: 58

--P1值的后4位0004代表申請鎖的模式

SQL> select * from v$lock where sid=528;

ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
---------------- ---------------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
00000000DEC35368 00000000DEC35388 528 TX 131084      88864          0          4        129          0
00000000DD5099A8 00000000DD5099D0 528 TM 1519283          0          3          0       1294          0

--P2和P3值與事務(wù)相關(guān)，比如上面的P2值131084代表XIDUSN和XIDSLOT，

select 131084/45536 as usn,round(mod(131084,45536)) slot from dual;

--P3值88864代表xidsqn

ADDR XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC STATUS START_TIME START_SCNB START_SCNW START_UEXT START_UBAFIL START_UBABLK START_UBASQN START_UBAREC SES_ADDR FLAG SPACE RECURSIVE NOUNDO PTX NAME PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN PTX_XIDSLT PTX_XIDSQN DSCN-B DSCN-W USED_UBLK USED_UREC LOG_IO PHY_IO CR_GET CR_CHANGE START_DATE DSCN_BASE DSCN_WRAP START_SCN DEPENDENT_SCN XID PRV_XID PTX_XID
---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------- ------------ ------------ ------------ ------------ ---------------- ---------- ----- --------- ------ --- -------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ------------- ---------------- ---------------- ----------------
00000000DD61F730 6         29      74079         19       9504      19040         51 ACTIVE 04/20/15 10:30:56    3585075880       2902         18           19         9504        19040           51 00000000DF221CA0 7683 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0   &

對于ITL事務(wù)槽來說，除去其初始分配的事務(wù)槽（可以理解為固定存在的事務(wù)槽），在一個BLOCK寫滿的情況下，繼續(xù)擴(kuò)展ITL事務(wù)槽需要占用PCTFREE參數(shù)指定的預(yù)留空間。例如PCTFREE值設(shè)定為10%，而一個塊的大小是8KB也就是8192B，則預(yù)留的空間約為819.2B，而一個ITL事務(wù)槽的大小為24B（ITL事務(wù)槽大小參考文獻(xiàn)，最開始查看一些文章有說大小是46B的，但是實(shí)際測試不相符），由此我們可以大致推斷其最多可擴(kuò)展的ITL事務(wù)槽數(shù)量。而在實(shí)際生產(chǎn)環(huán)境中，update語句更新該數(shù)據(jù)塊中的字段，使其字段長度增加，也會占用PCTFREE預(yù)留空間,導(dǎo)致ITL事務(wù)槽的可擴(kuò)展數(shù)量減少。

從根本上來說enq: TX - allocate ITL entry等待事件的產(chǎn)生是由于當(dāng)前BLOCK沒有足夠的空間去擴(kuò)展事務(wù)槽，或者由于多個長事務(wù)導(dǎo)致的ITL事務(wù)槽長時間占用，從而引起事務(wù)槽爭用。

2. 一般常用解決辦法：

Increase INITRANS

1) Depending on the number of transactions in the table we need to alter the value of INITRANS. here it has been changed to 50:

alter table INITRANS 50;

2) Then re-organize the table using move (alter table move;)

3) Then rebuild all the indexes of this table as below

alter index rebuild INITRANS 50;

Increase PCTFREE

If the issue is not resolved by increasing INITRANS then try increasing PCTFREE. Increasing PCTFREE holds more space back and so spreads the same number of rows over more blocks. This means that there are more ITL slots available, overall.

1) Spreading rows into more number of blocks will also helps to reduce this wait event.

alter table

PCTFREE 20;

2) Then re-organize the table using move (alter table move;)

3) Rebuild index alter index index_name rebuild PCTFREE 20;

A Combination of increasing both INITRANS and PCTFREE

1) Set INITRANS to 50 and pct_free to 20 alter table PCTFREE 20 INITRANS 50;

2) Re-organize the table using move (alter table move;)

3) Then rebuild all the indexes of the table as below alter index rebuild PCTFREE 20 INITRANS 50;

END

更多精彩干貨分享

點(diǎn)擊下方名片關(guān)注

IT那活兒