關於 truncate table 的一點學習劄記，truncate劄記

關於 truncate table 的一點學習劄記，truncate劄記

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

truncate table 與delete * from的不同

區別主要兩個1。 Truncate 是整體刪除， delete是逐條刪除2. truncate不寫伺服器log，delete寫伺服器log，這就是為什麼truncate要快過delete 所以，影響有：1。 truncate 快2。 truncate不啟用 trigger3。 truncate 重設 Identity
 
當執行TRUNCATE TABLE命令之後,以下哪種說法不正確（）

a