暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

truncate 分区表的时候非常慢3个小时没跑完会是什么原因

原创 问题归档 2019-04-14
2220

问题描述

分区表有200多G,通过truncate 删除其中的一个分区 使用了  update global indexes选项,执行了3个小时没执行完成,分区表存在 global 索引,最终导致业务无法操作,kill掉truncate 分区表的session 恢复操作,请问 1、这3个小时是在等待   update global indexes 嘛?2、kill 了 truncate session,业务恢复,表数据也没有删除,不是 truncate 不走 undo嘛,为什么 kill session 之后 能回滚了呢

专家解答

1、从描述看,很大可能是阻塞在update global indexes上面了;可以结合ash看看

2、Truncate是DDL,记录不计redo,但是medata还是有undo的,你这个操作失败,自然就回滚了。


这种操作最好在业务低峰进行,如果可以接受索引暂时失效,truncate后并行重新global indexes是更好的选择


truncate的时候做update global indexes不是一个好的选择。这3个小时就是在等待   update global indexes操作,这个操作是非常慢的,尤其当global index还不止是一个的时候会更慢。


可以使用缓和一些的操作来进行,比如delete后shrink分区,global indexes不更新也不会有什么性能问题,实际分区所占的空间也会释放出来。

实在看这个分区碍眼的话,找停机时间再做truncate操作。


缓和方式的代价就是会产生相对较多的redo日志,对IO有一定量的影响。

最后修改时间:2019-04-14 14:35:08
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论