大表直接drop仍是truncate后再drop
日期：2014-05-16 浏览次数：20457 次
大表直接drop还是truncate后再drop
3. 对于drop 与 Truncate 操作还涉及另外一块事情: 空间的回收.
对于使用Local Management的tablespace ,需要修改这个segment 涉及到的所有数据文件的bitmap 内容的修改.. 一般情况下, 速度都还可以..
如果是基于字典管理的表空间.. 由于所有的回收操作都是基于uet$,fet$表操作的,,所有如果使用的空间量非常大, 回收的操作将非常慢,,我层听说,,有人删除一个表要等待好几个小时甚至1-2天的情况..
解决办法是:
复制代码
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天的情况..
解决办法是:
- truncate table xxx reuse storage;
- alter table xxx deallocate unused keep 2000m;
- alter table xxx deallocate unused keep 1500m;
- alter table xxx deallocate unused keep 1000m;
- alter table xxx deallocate unused keep 500m;
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
