由于历史的原因, 居然有机会清理4TeraBytes大小的表, 而且这个表是在字典管理表空间(DMT)上的, 新建的都不会再用字典管理表空间了, 估计在其他地方是不可能遇到的了. 用最吐的CTAS方法将数据归档了一部份, 并重新设计分区的逻辑, 完成后就得将这个表删除以释放空间.
心中很是担心害怕, 不过也没有办法, 只能继续. 大致经过了如下步骤:
drop index ...;
truncate table ... reuse storage;
alter table ... deallocate unused keep 2000000m;
alter table ... deallocate unused keep 1500000m;
alter table ... deallocate unused keep 1000000m;
alter table ... deallocate unused keep 500000m;
alter table ... deallocate unused keep 0;
drop table ...;
发现KEEP的最大值只能是2000000m, 再加1M都不行了. 整个过程进行了大约1.5个小时, 每条命令后还加入了表空间COALESCE, 全程盯着数据库的Load, 累!
还好安全地完成任务! 为了防止出现ST Enqueue, 可以对那个时间段修改比较忙的表事先分配几个Extent.
留言 (5)
这个表够大
Posted by Thomas Zhang | Dec 11, 2007 7:05 PM
好牛的表。。。。-_-||是不是历史记录表？没用分区么？
如果是LTM的表，还能用deallocate吗？记得数据字典管理的大表做drop可以用deallocate，LTM的大表drop时需不需要这样做呢？
Posted by 小荷 | Dec 12, 2007 9:09 AM
LMT的特大表，也应当这样做, 只是不需要COALESCE表空间这一步.
Posted by anysql | Dec 12, 2007 9:15 AM
还是挺快的，才1.5小时
眼睛不是太疼的
Posted by boypoo | Dec 13, 2007 2:05 PM
怎么看不懂？是什么意思？
为了防止出现ST Enqueue, 可以对那个时间段修改比较忙的表事先分配几个Extent,怎么做?
Posted by aigo_h | May 8, 2008 4:14 PM