---下面整理筆記來之 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