0

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

问题归档 2019-04-14
54
摘要:分区表有200多G,通过truncate删除其中的一个分区使用了updateglobalindexes选项,执行了3个小时没执行完成,分区...

问题描述

分区表有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有一定量的影响。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部
暂无课程,敬请期待...