总结 从最初几乎每次都因为抱 ORA-01555 错误而无法完成的一个 DELETE 语句,到删除 100 万记录需要 20 多个小时,再发展到现在的删除 90 万记录只" name="description" />

如何给Large Delete操作提速近千倍?(七)

发表于:2007-06-07来源:作者:点击数: 标签:
本文已经发表在ITPUB优化技术丛书,未经许可,不得转载。 1.1. MI LY: 黑体; mso-ascii-font-family: Arial">总结 从最初几乎每次都因为抱 ORA-01555 错误而无法完成的一个 DELETE 语句,到删除 100 万记录需要 20 多个小时,再发展到现在的删除 90 万记录只
本文已经发表在ITPUB优化技术丛书,未经许可,不得转载。

 

 

1.1. MILY: 黑体; mso-ascii-font-family: Arial">总结

       从最初几乎每次都因为抱ORA-01555错误而无法完成的一个DELETE语句,到删除100万记录需要20多个小时,再发展到现在的删除90万记录只需要不到3分钟,速度提高了近千倍,这里主要的思想是:

1,  避开繁琐的查询条件(即避开了庞大到上百万个元素的in-list

2,  使用原子级的处理方式(使用两个原子级的处理,将原子级的处理保持在毫秒级)

3,  使用bulk bindsforall)的特性,批量处理,大大降低了主机的资源压力(以10000为单位,批量处理。)

 

 

优化是一件很灵活的事情,没有千篇一律的规律,只有灵活的拆分、组合一些优化方法来达到我们的目的,如果一定生搬硬套,那么很可能会把本来简单的事情搞的复杂而无法处理了。这里就本文的优化思路和方法提几点注意事项:

1,  对于有些条件负责的操作,需要做更多的逻辑拆分工作,以便拆分得更小

2,  对于insertupdate测试速度一般达不到本问中提高近千倍得速度

3,  对于CTAScreate table as select)操作,不要使用这个方法来做,很多情况下,直接做(如果可以的话,最好加NOLOGGING选项)更快

 

 

 

 


原文转自:http://www.ltesting.net