ORACLE TRUNCATE执行过慢
问题描述:
TRUNCATE TABLE VMSBUSI.VMS_MAILBOX_INFO; VMS_MAILBOX_INFO表中只有35条记录,TRUNCATE表要用1分钟左右。
问题解决:
这些索引基本上每个都是1G左右,且都是初始EXTENT的大小。显然导致问题的原因已经明确了,表包含了多个索引,且每个索引的初始段太大,因此TRUNCATE执行的时候对索引执行大量的db file sequence wait的操作,从而导致了TRUNCATE语句性能问题。
网上链接:
http://yangtingkun.itpub.net/post/468/501762
现在在处理一批数据,小表还好,大表动辄上千万,删的时候确实太慢,经领导指导,总结以下几条经验。
1,在每条语句后面添加commit;
2,添加足够的redo日志组; alter database add logfile group 4 '路径/redo04.log' size 500M;
3,删除数据时会遇到无法扩展undo表空间,为undo表空间添加足够的数据文件;
4,删除无关的索引,保留与其他表有关联的和主键索引;
5,经常查看后台session,避免死锁
6,排查是否有触发器
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了