今天客户把硬件、软件和应用的厂商全叫去,处理昨天出现IO100%的情况。
硬件说没有问题,有事就走了。
db的情况,昨天同事大概确定db上主要就是enq: TX - index contention等待事件(index split),由一条SQL ordered by Elapsed Time排第一的Insert语句引起。但今天到现场后发
现,不只是故障时间内有此等待事件,其它时间此事件也是top 5。只是故障时平均等待时间增加了10ms左右。
业务不是很熟,应用厂商最后查找到应用系统的一个组件在故障时间发送日志时,每条多出50条记录。每分钟产生多余的2000条左右的日志(这些都是可以从数据表中查到的,但
是没人去查,费了半天的功夫,还一直说是10g的一个Bug),产生了更多的enq: TX - index contention。
这是一类表,1日插入到01表,2日插入到02表,以此类推…每天3000万左右的数据量插入到相应的表。同事也是和网上的一些解决方法是一样的,重建索引、修改index block
pctfree。我个人的一些想法,不对请拍砖:
- 此类表都建有8个索引,是否考虑下是不是所有索引都是必要的,或合适的,其中一个索引的列值只有4个不同的值。
- 当时考虑一个月数据量大,把每天的数据拆分,但数据量也有3000万左右,是否考虑此类表建成分区表。