关于 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