gc cr引起的数据库性能问题

业务场景:
1 业务表每天插入当天的数据，大概数据量为2000万
2 第二天清除前一天的2000多万数据
3 数据库删除前一天数据和插入当天数据进行时间隔离，防止性能问题。


产生的问题：
两个节点的RAC,节点1在delete数据(数据为2000多万)，节点2在insert update数据，由于节点1删数据慢了，时间上和节点2的操作重合。


导致节点2的效率特别低。由此引起了gc cr事件，并且由于并发量很大的原因，产生各种等待事件如下:
1 enq: TX index contention（索引争用）
   1.1 如出现enq: TX - index contention,说明此时正有会话正在操作分裂的索引块，而你所属会话要更新此数据块则发生此事件
   1.2 高并发会产生此事件                                                                                                                                                                     
   1.3 把索引和表存储在独立的表空间，加大索引的block size(注意：其它附加副作用，暂未测试)
   1.4 重构索引为反向键索引或全局hash index,说白了就是把索引块打散分布到多个数据块，不要集中存储；这样每个块竞争的机会就减少
   1.5 修正index pctfree为0,大大减少index contention, 但要注意表是否只能insert，如还伴随大量的update
2 enq: TX - row lock contention(行锁争用)
   2.1不同的session更新或删除同一条记录；
   2.2 唯一索引有重复索引；
   2.3 位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值；
   2.4 并发的对同一个数据块上的数据进行update操作；
   2.5 等待索引块完成分裂；


紧急解决过程:
1 kill节点1的delete会话
2 kill后发现有数据库有大量的回滚操作，又引起了transaction事件,删除该事件对应的会话。


事后处理方法:
 将业务表修改为日分区表，避免gc cr事件。每天对单分区进行truncate操作。