Part1问题报错
业务方面反馈操作异常缓慢，观看awr报告发现有大量的update语句堵塞卡住了，等待事件包括 enq: TX - allocate ITL entry。也从 segments BY ITL WAITS发现了具体的数据库对象。
Part2问题解决
2.1Mos解决方案
1、等待事件 enq: TX - allocate ITL entry 出现并占比很高
2、通过报告 ITL Waits定位数据库对象 ZJ2025
3、查询数据库的对象信息 （pctfree 10 initrans 1） 、表和索引信息（segments）
4、尝试操作（修改表属性、move移动表、重建索引）
5、检查对象是否正常（表是否修改成功、索引是否可用）
2.2实操步骤
#数据库信息
用户
密码：
连接串：
#查询数据库对象
select owner,segment_name,segment_type,round(bytes/1024/1024/1024,2) from dba_segments where segment_name='ZJ_2025';
OWNER SEGMENT_NAME SEGMENT_TYPE ROUND(BYTES/1024/1024/1024,2)
------------------ ------------------ -----------------------------
TR_9999 ZJ_2025 TABLE 2.53
#查询数据库建表语句
SELECT u.table_name, DBMS_METADATA.GET_DDL('TABLE', u.table_name) table_ddl FROM user_tables u WHERE table_name in ('ZJ_2025');
##就是截取了这一部分
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
#修改对象
alter table TR_9999.ZJ_2025 pctfree 20 initrans 50;
#重新移动表生效
alter table TR_9999.ZJ_2025 move tablespace TR_DATA9 online;
##重建失效索引
select 'ALTER INDEX ' || owner ||'.'|| index_name || ' REBUILD tablespace TR_DATA9 parallel 12 online;'from dba_indexes where owner='TR_9999' and status = 'UNUSABLE';
##查询是否还有失效索引
select owner,index_name,table_name,status from dba_indexes where owner='TR_9999' and status = 'UNUSABLE';
#初选表属性是否修改
SELECT u.table_name, DBMS_METADATA.GET_DDL('TABLE', u.table_name) table_ddl FROM user_tables u WHERE table_name in ('ZJ_2025');
PCTFREE 20 PCTUSED 40 INITRANS 50 MAXTRANS 255
数据块的可用空间,这个是是百分比
PCTFREE 20
事务槽是 50，最大可以255，这个是条数
INITRANS 50 MAXTRANS 255
Part3问题原理
3.1等待事件解析
队列锁：事务锁 - 分配事务槽等待（enq: TX - allocate ITL entry）
3.2专有名词解析
ITL（事务槽）
Interested Transaction List (ITL) 是 Oracle 数据块中的一个关键数据结构，用于管理并发事务对块内数据的访问。每个数据块都包含一个 ITL 条目列表，记录哪些事务正在访问该块中的行。
3.3构成问题原因
数据块内并发事务的需求超过了该数据块所能提供的ITL槽数量。 表/索引的初始设置不合理（最常见）： INITRANS 设置过低：在创建表或索引时，INITRANS 参数定义了数据块初始分配的ITL槽数量。默认是1（对于表）或2（对于索引）。如果初始值设得太小，在高并发环境下很容易就不够用。
高并发DML操作： 多个会话同时对同一个数据块中的不同行进行修改。这在频繁更新的表上很容易发生，特别是当这些行的数据聚集在少数几个数据块中时（例如，通过序列填充的主键，但数据插入无序，导致数据分散）。
长时间未提交的事务： 如果一个事务占着一个ITL槽但长时间既不提交也不回滚，那么这个ITL槽就会被一直占用，无法释放给其他事务使用。这会加剧ITL槽的短缺。
索引块分裂： 索引块的分裂过程本身也需要ITL槽。在高并发插入导致索引频繁分裂时，也可能引发索引块上的ITL争用。
3.4问题解决
增加目标数据块可用的ITL槽数量（DBA操作）或减少对同一数据块的并发访问（业务优化逻辑）。
3.5优缺点
如果把表的空闲可用空间（PCTFREE）修改的大一点， 缺点：那同样的数据量需要更多的块来存放，全表扫描会耗费更多的资源，类似于高水位线的感觉。 优点：可以把对数据库表修改块的并行提高上去。提高效率。
Part4事后对比
修改以后，通过两天同一个时间段的awr报告对比，发现 ZJ_2025的占比已经消失，优化成功。
Part5文档借鉴
1472175.1.pdf
