关于enq: TX - allocate ITL entry的问题分析

简介: 今天发现系统在下午1点左右的时候负载比较高,就抓取了一个最新的awr报告. Snap Id Snap Time Sessions Curs...
今天发现系统在下午1点左右的时候负载比较高,就抓取了一个最新的awr报告.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 20892 26-Nov-14 13:20:17 3623 5.4
End Snap: 20893 26-Nov-14 13:30:17 3602 5.4
Elapsed:   10.01 (mins)    
DB Time:   365.56 (mins)    

来看看是否有top的等待事件,对于其它的几个等待事件都很熟悉了。有些问题早已进行了建议,还在修改中,但是对于第3个等待事件" enq: TX - allocate ITL entry" 还是比较陌生的。准备来做一个深入的分析。
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU   7,322   33.38  
db file sequential read 3,833,628 5,031 1 22.94 User I/O
enq: TX - allocate ITL entry 187 3,607 19287 16.44 Configuration
direct path read temp 1,017,363 1,640 2 7.48 User I/O
read by other session 3,873,525 1,612 0 7.35 User I/O

因为得到的是最新的awr报告。所以就在sqllplus上简单排查了一把。可以看到有两个session都持有这个等待事件。
SQL>    select EVENT,sid,serial# from v$session where event='enq: TX - allocate ITL entry';
EVENT                                                                   SID    SERIAL#
---------------------------------------------------------------- ---------- ----------
enq: TX - allocate ITL entry                                           5592      25063
enq: TX - allocate ITL entry                                          11533      51179

查看一下session的明细信息。可以看到这个session都是来自同一个客户端。

       SID    SERIAL# USERNAME        OSUSER          MACHINE              PROCESS         TERMINAL        TYPE       LOGIN_TIME
---------- ---------- --------------- --------------- -------------------- --------------- --------------- ---------- -------------------
       5592      25063   APPC         pappwrk01         prod_client_db              1234            unknown         USER       2014-11-26 13:03:45
     11533      51179   APPC          pappwrk01        prod_client_db              1234            unknown         USER       2014-11-26 13:03:46

查看这个session正在执行的sql语句,发现都是对同一个表的update。语句类似
UPDATE DIRECT_DEBIT_REQUEST SET DIRECT_DEBIT_REQUEST.ACCOUNT_ID=..........

到这个地方,问题似乎很清晰了,就是由于表DIRECT_DEBIT_REQUEST的ITL的设置不能够满足并发事务的需求而导致的等待。数据块是oracle能够发出的最小I/O单位。在数据块中,数据块头部的ITL信息是至关重要的。
每当一个事务需要修改一个数据块时,需要在数据块头部获得一个可用的ITL槽,其中记录了当前事务的id,使用的undo数据块地址,还有对应的scn,事务是否提交等信息。如果一个新的事务发现ITL槽已经被使用,会重新
申请一个新的ITL槽,这个过程是动态的,进一步来说,ITL槽的设置是由ini_trans,max_trans来决定的,在10g之后,max_trans参数被忽略了。
SQL> create table trans_test(id number,name varchar2(100)) initrans 1 maxtrans 1;
Table created.

SQL> set linesize  100
SQL> col table_name format a30
SQL> select ini_trans,max_trans,table_name from user_tables where table_name='TRANS_TEST';
 INI_TRANS  MAX_TRANS TABLE_NAME
---------- ---------- ------------------------------
         1         255 TRANS_TEST
关于这个参数的解释在oracle sql reference中有详细的解释。

MAXTRANS Parameter

In earlier releases, the MAXTRANS parameter determined the maximum number of concurrent update transactions allowed for each data block in the segment. This parameter has been deprecated. Oracle now automatically allows up to 255 concurrent update transactions for any data block, depending on the available space in the block.

Existing objects for which a value of MAXTRANS has already been set retain that setting. However, if you attempt to change the value for MAXTRANS, Oracle ignores the new specification and substitutes the value 255 without returning an error.

对于initrans,maxtrans的默认值,表级为1,索引级为2.  一般来说不需要做特别的设置。可以根据业务的需要来配置。
来继续回到awr报告。可以在" Segments by ITL Waits"里面得到一个全面的信息。
Owner Tablespace Name Object Name Subobject Name Obj. Type ITL Waits % of Capture
APPO INDXH01 MST_LOG_1IX I2 INDEX PARTITION 12 66.67
APPO DATAS01 DIRECT_DEBIT_REQUEST   TABLE 3 16.67
APPO INDXS01 PAYMENT_2IX A23_B2 INDEX PARTITION 1 5.56
APPO INDXH01 ACTIVITY_HISTORY_1IX C90 INDEX PARTITION 1 5.56
SYS SYSAUX WRH$_SQL_PLAN_PK   INDEX 1 5.56

从上面的列表我们可以清晰的看到对于ITL wait的情况,可以说明两点。
首先是我们在发现问题的时候,可能有些操作已经结束了,我们分析的结果不一定是最全面的信息。就如我们上面所做的分析。定位到问题的是表DIRECT_DEBIT_REQUEST,其实在问题时间段内,一个大的分区索引占用了高达
67%左右的ITL wait。
其次是我们通过awr报告得到了一些详细的信息。但是还是不能够对问题做最终的结论,不能头痛医头,脚痛医脚,如果能够以点带面来排查问题,可能最后的效率要高很多。

对于这个等待事件,处理的思路在metalink上也给出了详尽的解释。可以参见
Troubleshooting waits for 'enq: TX - allocate ITL entry' (Doc ID 1472175.1) To BottomTo Bottom


解决思路有3种

Increase INITRANS

A)

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


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 :
B)

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

alter table

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

3) Rebuild index

alter index index_name  rebuild PCTFREE 40;

 

A Combination of increasing both INITRANS and PCTFREE


1) Set INITRANS to 50  pct_free to 40

alter table PCTFREE 40  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 40 INITRANS 50;

                             
在这个基础上更近一步,我查找产品部的文档,发现在项目开始已经对initrans的设置做了建议,但是对于这个问题,不知道什么原因最后给漏掉了。这样下来需要对一些重要的表都需要做initrans的改动。本来从awr报告中得到的
的信息显示4个对象(表&索引)可能存在initrans设置不足的情况,如果结合项目的情况来看,需要做的变更可能就是上百个对象。需要好好评估。
以下的标准可以参考以下。
对于大表,数据千万级以上的表,initrans建议设置为8~16
对于中级表,数据量在百万到千万级,initrans建议设置为4~8
对于普通的表,initrans建议设置为1~4
阅读(24697) | 评论(1) | 转发(4) |
给主人留下些什么吧!~~
img_711f8fa62c4bea7e18af525a511ab553.jpg

jeanron1002014-11-27 14:56:26

对于有些朋友的反馈,说对于initrans的设置需要机遇并发数来判定,这个没有问题,根据表的segment size来划分也是一种思路,不是绝对。

评论热议
请登录后评论。

登录 注册

目录
相关文章
|
监控 数据安全/隐私保护 Python
ERP系统中的资产管理模块详解
【7月更文挑战第25天】 ERP系统中的资产管理模块详解
1108 4
|
消息中间件 SpringCloudAlibaba Java
第十章 SpringCloud Alibaba 之 Nacos discovery
第十章 SpringCloud Alibaba 之 Nacos discovery
642 1
|
4天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1106 0
|
3天前
|
机器学习/深度学习 人工智能 前端开发
通义DeepResearch全面开源!同步分享可落地的高阶Agent构建方法论
通义研究团队开源发布通义 DeepResearch —— 首个在性能上可与 OpenAI DeepResearch 相媲美、并在多项权威基准测试中取得领先表现的全开源 Web Agent。
533 10
|
13天前
|
人工智能 运维 安全
|
12天前
|
人工智能 测试技术 API
智能体(AI Agent)搭建全攻略:从概念到实践的终极指南
在人工智能浪潮中,智能体(AI Agent)正成为变革性技术。它们具备自主决策、环境感知、任务执行等能力,广泛应用于日常任务与商业流程。本文详解智能体概念、架构及七步搭建指南,助你打造专属智能体,迎接智能自动化新时代。
|
4天前
|
弹性计算 Kubernetes jenkins
如何在 ECS/EKS 集群中有效使用 Jenkins
本文探讨了如何将 Jenkins 与 AWS ECS 和 EKS 集群集成,以构建高效、灵活且具备自动扩缩容能力的 CI/CD 流水线,提升软件交付效率并优化资源成本。
303 0
|
11天前
|
人工智能 异构计算
敬请锁定《C位面对面》,洞察通用计算如何在AI时代持续赋能企业创新,助力业务发展!
敬请锁定《C位面对面》,洞察通用计算如何在AI时代持续赋能企业创新,助力业务发展!
|
12天前
|
机器学习/深度学习 人工智能 自然语言处理
B站开源IndexTTS2,用极致表现力颠覆听觉体验
在语音合成技术不断演进的背景下,早期版本的IndexTTS虽然在多场景应用中展现出良好的表现,但在情感表达的细腻度与时长控制的精准性方面仍存在提升空间。为了解决这些问题,并进一步推动零样本语音合成在实际场景中的落地能力,B站语音团队对模型架构与训练策略进行了深度优化,推出了全新一代语音合成模型——IndexTTS2 。
807 23

热门文章

最新文章