"ORACLE数据库流水表A发生ITL事务槽同抢等待"事故分析

[千舟9]

1. 问题现象
*年*月*日*行内性能监控系统发出告警-*系统出现大量交易延迟或超时，从weblogic容器可观测到数据库连接池拥塞，DBA分析发现ORACLE数据库流水表A发生ITL事务槽同抢等待。

2.原因分析
事故发生后，DBA也一筹莫展，只能将问题表rename，然后重建一张空表，让系统恢复运行。事后几天内DBA和相关专家也无法对此问题定论，此时相关人员将焦点渐渐转移到应用层面（其实是属于无奈），怀疑应用使用了特殊的用法，从而引发了数据库问题？？

经过对*系统反复压力验证测试，发现应用不存在问题和瓶颈，但在ORACLE数据库中，*系统的表A有大量记录在update后发生了行链接（即：一条记录跨BLOCK），大量记录的行链接在一定程度上肯定会影响数据库的效率。进一步对*系统业务流程分析该系统的数据模型本身有其特殊性，交易请求数据在INSERT到表A时有600个字节，交易处理完成后交易结果数据有近500多个字节UPDATE到表A，表A的初始事务槽为2，PCTFREE为块大小（8K）的10%，在交易密度较高的场景下，同一块内写入10条交易请求数据后，更新两条交易结果即可将PCTFREE空间分配完，对其它8条记录更新交易结果数据时则会发生行链接，PCTFREE空间分配完也导致同一BLOCK内无法申请更多的ITL槽位，从而引发ITL槽等待。
在绝大多数情况下ITL槽等待对应用的影响不明显，如果在同一并发时间点行链接的数据被随机分配到同一个BLOCK ,或占用其它块的PTCFREE空间时，则可能引起连锁性的行链接和大量的ITL槽等待。

3.处理方案
按实际数据模型特征调整表A的以下参数：
Pctfree 调整为50%
Initrans 调整为 5~10
[
ORACCLE数据库对update数据所需的空间会从PCTFREE空间中分配，ITL事务槽的空间也会从PCTFREE空间中分配。
所以对数据模型特征特殊的表，在建表时需充分考虑PCTFREE、INITRANS这两项参数的设置。
]