大表之困惑 - 数据建模的前期规划十分重要

这几天被一个数据库中的大表所困扰，这是一个插入非常频繁的数据表，该表目前大约有20亿记录，是一个分区表：

SQL> SELECT TABLE_NAME,NUM_ROWS,BLOCKS,AVG_SPACE,SAMPLE_SIZE,LAST_ANALYZED
2  FROM DBA_TABLES WHERE OWNER='SMS' AND TABLE_NAME='SSMG';

TABLE_NAME                       NUM_ROWS     BLOCKS  AVG_SPACE SAMPLE_SIZE LAST_ANALYZE
------------------------------ ---------- ---------- ---------- ----------- ------------
SSMG                           2000426788   60053382          0   101416650 12-SEP-09

然而这个表上建有的都是全局索引，现在需要按照跟索引基本无关的条件进行删除，以下几个索引都无可利用：

SQL> select
2      INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,
3      NUM_ROWS,CLUSTERING_FACTOR,last_analyzed
4  from
5      dba_indexes t
6  where
7      table_name = 'SSMG'
8  and table_owner = 'SMS'
9  /

INDEX_NAME                   BLEVEL LEAF_BLOCKS DISTINCT_KEYS   NUM_ROWS CLUSTERING_FACTOR LAST_ANALYZE
------------------------ ---------- ----------- ------------- ---------- ----------------- ------------
IDX_SMS_DEST_MDN                3    12186077      19507227 2071388105        1816174507 12-SEP-09
IDX_SMS_SERVICE_ID              3     8184696            48 1990938187         113031962 12-SEP-09
UN_SMS                          4    21717598    1973096899 1973096899         138625843 12-SEP-09

客户写了个Loop循环，通过另外一个表的关联去判断删除，另外一个表具有400万记录，初步计算了一下程序效率，跑完一次大约要200天。

好了，现在的问题是，要么面对不可能，要么建个索引，加快处理，可是在20亿上建一个索引，即便是Online的方式，对应用的性能也会有几大的影响。

要么很复杂的去处理，要么很慢的去处理，当初如果多加个索引，该有多好啊！