drop表分区导致系统大量cursor: pin S wait on X的等待

      经过初步的测试分析，推测和BUG 11855965有关。由于表上有一个实体化视图LOG，当drop 分区的时候，如果该LOG中有数据，会对该LOG进行删除清理，因此drop分区的操作就会耗费较长的时间。如果在这个时段，对表有并发操作，就会产生类似的情况。详见下面的分析过程。

由于无法在生产环境操作，因此在自己的测试环境模拟DROP 表分区，当MVLOG里面有大量数据的时候，效率是否有所不同。

1.1 MVLOG里面没有数据，drop一个分区需要的时间（数据量相同，都是100000条数据）

SSQL> alter table test drop partition part3;

 

Table altered.

 

Elapsed: 00:00:00.26

 

1.2   新增加一个分区，并插入100000条数据

 alter table test add partition part5 VALUES LESS THAN (300000) ;

 

SQL> begin                                   

  2  for i in 200000 .. 299999 loop

  3  insert into test values(i);

  4  end loop;

  5  end;

/

Commit;

 

 SQL>select count(*) from MLOG$_TEST    ----检查mvlog里面的数据

SQL> /

 

  COUNT(*)

----------

    100000

      

1.3   再一次进行drop分区的操作

SQL> alter table test drop partition part4;

 

Table altered.

 

Elapsed: 00:00:09.62

       可以看到drop分区的操作时间被大大增加，由不到1秒钟增加到9秒钟。

通过该测试证明，如果表上的MVLOG里面有大量的数据没有被刷新，则对该表进行truncate或者drop等ddl操作的时候，会对MVLOG进行清理，因此会增加操作的时间。如果其他session此时有并发操作，可能就会引起阻塞，进而导致应用超时。