关于 truncate table 的一点学习札记

---以下整理笔记来之 itpub 的各位前辈的语录，这里做了一个汇总，仅供学习。

 

truncate table后，oracle会回收表和其表中所在的索引到initial 大小，也就是初始分配的segments大小

truncate和drop一样都是ddl语句, 操作立即生效,原数据不放到rollback segment中,不能回滚

truncate table执行很慢可能有以下几个原因：

首先要明白truncate table是DDL操作，会重置HWM。

1.查看是不是DML操作锁定了某些记录

2.segment header竞争

truncate 表慢可能跟extent的数量有关系

 比如说，你一个表 size 100M,每个10M ,10个extent

而又一个表 size 50M ,每个8K,6400个extent

那么，第二个表的truncate就会比第一个慢上好多

通常来说是由于extent 太多，truncate时在做回收extent的动作

这也是 local management比 dictionary management好的其中一点。

 如果担心下次碰到同样问题

 可以考虑使用

truncate table test reuse STORAGE 的语句，可以避免hung在回收extent上。

就要用到 分次回收 的方式了

 比如说，100M的表，每次回收 20M,在感觉上可能好点。

truncate table t4 reuse STORAGE ;

 alter table test_tun deallocate unused keep 80M;

 alter table test_tun deallocate unused keep 60M;

 alter table test_tun deallocate unused keep 40M;

 alter table test_tun deallocate unused keep 20M;

 truncate table test_tun  drop storage;

如果truncate table 非常慢 ，可以按照以下方法来诊断：

1.请查询 相应的session 在 v$session_wait 视图中的等待事件

2.可以用oradebug hanganalyze分析系统挂起的原因

3.如果为了试验目的，更可以做个10046 level 8的event

 

###################

### BUG lists

###################

truncate的时候，dbwr占用cpu高不高？可以试一下下面文档中的workround （alter system flush buffer_cache; 后再truncate），如果生效应该就是了，你可以升到10.2.0.4.3

是不是这个bug不好说,如果日志的大小不足导致日志切换hang住,引起dbwr的等待,出现不少free buffer busy的等待,而truncate又要做checkpoint,所以这时候前台进程也要等待dbwr,导致enqueue RO的wait变长

 ---------------------------------------------

 Bug 8544896  Waits for "enq: RO - fast object reuse" with high DBWR CPU

 This note gives a brief overview of bug 8544896.

 The content was last updated on: 08-JAN-2010

 Click here for details of each of the sections below.

 Affects:

 Product (Component) Oracle Server (Rdbms)

 Range of versions believed to be affected Versions >= 10.2.0.4 

 Versions confirmed as being affected 10.2.0.4

 Platforms affected Generic (all / most platforms affected)

 It is believed to be a regression in default behaviour thus:

    Regression introduced in 10.2.0.4

 Fixed:

 This issue is fixed in 10.2.0.4.3 (Patch Set Update)

 Symptoms: Related To:

 Performance Affected (General)

 Performance Of Certain Operations Affected

 Waits for "enq: RO - fast object reuse"

 Truncate

 _DB_FAST_OBJ_TRUNCATE

 Description

 This problem is introduced in 10.2.0.4.

 Sessions can wait on "enq: RO - fast object reuse" while DBWR consumes

 lots of CPU when performing truncate type operations.

 Workaround

 Flush the buffer cache before truncating

 OR

 set _db_fast_obj_truncate = FALSE.

 Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. Always consult with Oracle Support for advice.

 References

 Bug:8544896 (This link will only work for PUBLISHED bugs)

 Note:245840.1 Information on the sections in this article