【 使用环境 】测试环境
【 OB or 其他组件 】ob
【 使用版本 】社区版4.1
【问题描述】delete删除表的部分数据很慢 删除150w数据用时420秒
【复现路径】每次删除数据很慢
【问题现象及影响】我们经常会重导数据，重新生成最新一版的数据，所以需要按照（分区键+半年度）属性删除表中的数据，然后重新导入一次。发现删除数据很慢，指定了分区属性好像也没快，请问怎么优化呢
【附件】
1 个赞
先count，然后计算循环多少次，delete limit 10000，一直循环单结束
具体排查原因可以提供一下
1、对应的gv$ob_sql_audit的记录
2、根据gv$ob_sql_audit里对应的traceid，在svr_ip的机器上找到对应的observer.log日志进行分析。
如果目前在测试，看看是否可以将现有的表结构调整为二级分区表：其中一级分区找个我们删除数据时参考的字段，二级分区以使用当前的分区键字段。
删除的SQL啥样的，是不是没索引可用，全表扫描了。
有索引，我们是按照学校字段 和 学期字段删除的，其中学校是分区键，学期是局部索引，如下
DELETE from dw_table_1 where school_code=‘school001’ and term_id=‘2221’
谢谢，正在重导数据，然后跟踪下日志。
删除的性能大概是什么样呢，比如一分钟能删除多少记录，我们这是分区内删除有索引
这样性能差不多
表的数据量1.6亿，删除150w用时420秒左右
1、看看删除数据的期间 observer.log日志里是否有 “report write throttle info” 关键字。
2、select * from gv$ob_units;
使用的是哪个租户，帮忙也标注一下。
3、show parameters like ‘memstore_limit_percentage’;
4、show parameters like ‘freeze_trigger_percentage’; （在对应的业务租户下查）
3个日志文件，是我们3个节点中的日志。没有您说的“report write throttle info” 关键字。日志文件请见附件
observer1.rar (978.3 KB)
observer2.rar (4.7 MB)
observer3.rar (5.0 MB)
执行删除的语句：DELETE /*+ ENABLE_PARALLEL_DML PARALLEL(10) */ from dw_ought_naire_question2 a where a.school_code=‘bj80z’ and a.school_term_id=‘2311’
加上 /*+ ENABLE_PARALLEL_DML PARALLEL(10) */ 和去掉好像区别不大。。。
1、对应的gv$ob_sql_audit的记录
select * from gv$ob_sql_audit where query_sql like ‘%xxx%’ and query_sql not like ‘%ob_sql_audit%’;
2、根据gv$ob_sql_audit里对应的traceid，在svr_ip的机器上找到对应的observer.log日志进行分析。’
建议把表改造成分区表，按照你删除业务数据的逻辑，进行分区，delete数据改为drop或者truncate分区表
看前边要求，大概是要二级分区才行
list_range，可以的。生产大批量删除，不会用delete
二级分区确实应该可以，对我们也挺合适的，truncate速度很快。我们现在的一级分区用的key模式的，truncate还不支持，得修改分区模式
按照学校字段 和 学期字段删除，这个清理逻辑下，二级分区很适合，只不过添加二级分区可能会比较麻烦，需要考虑好一级和二级分区的类型，实测一下吧。
rename表，create表，insert into select搞进去