大表直接drop还是truncate后再drop

1. drop 与 Truncate操作类似的地方.
drop 是直接处理数据字典,去掉object与其对应的data_object_id的对应关系..
truncate 操作是创建一个新的空的segment(对应于data object id), 并将此segment与现有对象关联起来.

2. drop 与 truncate 操作都会触发object checkpoint操作, 如果buffer Cache很大的话, 这两个操作都可能会出现较长时间的等待, 在Oracle 10gR2以后, Oracle对Buffer header做了些许变更, 以提高Fast Object Checkpoint的速度.

http://oracledoug.com/serendipit ... ect-Path-Reads.html 
comment #9 By Jonathan Lewis

Re: KO - I think that appeared in 10.2. There is a new entry in the buffer header structure which allows for a linked list to be built between buffer headers of the same object. This, of course, means yet another little overhead when reading a block into the buffer in the first place. But it is useful for truncates, drops, and shrinks, as it avoids a massive scanning process if you drop a large object which has not been subject to much update.

3. 对于drop 与 Truncate 操作还涉及另外一块事情: 空间的回收.
对于使用Local Management的tablespace ,需要修改这个segment 涉及到的所有数据文件的bitmap 内容的修改.. 一般情况下, 速度都还可以..

如果是基于字典管理的表空间.. 由于所有的回收操作都是基于uet$,fet$表操作的,,所有如果使用的空间量非常大, 回收的操作将非常慢,,我层听说,,有人删除一个表要等待好几个小时甚至1-2天的情况..

解决办法是:

1. truncate table xxx reuse storage;
   
2. alter table xxx deallocate unused keep 2000m;
   
3. alter table xxx deallocate unused keep 1500m;
   
4. alter table xxx deallocate unused keep 1000m;
   
5. alter table xxx deallocate unused keep 500m;

复制代码

因为, 在数据字典管理的表空间中,所有涉及到空间管理的操作,都需要持有一个ST lock,如果单个操作执行的时间过长, 可能导致整个系统的空间分配操作都无法继续, 这对于绝大部分的OLTP应用,应该都是不可接受的事情..

ST Enqueue - This type of enqueue is used for space management and allocation for dictionary-managed tablespaces