码迷,mamicode.com
首页 > 其他好文 > 详细

关于 truncate table 的一点学习札记

时间:2014-07-28 16:05:03      阅读:287      评论:0      收藏:0      [点我收藏+]

标签:des   使用   os   数据   io   for   art   问题   

---以下整理笔记来之 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 的一点学习札记,布布扣,bubuko.com

关于 truncate table 的一点学习札记

标签:des   使用   os   数据   io   for   art   问题   

原文地址:http://blog.csdn.net/lixora/article/details/38226955

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!