现在的位置: 首页 > 综合 > 正文

事务提交的频率

2013年10月14日 ⁄ 综合 ⁄ 共 704字 ⁄ 字号 评论关闭

看看在看文档的时候突然想起了一个问题。

曾经面试过的一个公司,提问我这么一个问题:你要执行insert into或者update数据量在1W(以上)的大量记录的语句,如何处置commit?当时的我刚刚参加工作,刚刚接触到oracle一段时间,也刚刚阅读了"大量"的oracle基础知识、。。。。。。,然后我答到:最后是立即提交。汗,多么幼稚的答案,如果是1w条的insert语句,在每个语句之后插入commit,手估计都要抽筋了吧,虽然有编辑器的宏等等高级功能。总之,这个答案是失败的答案。

那么,比较正确和合理的答案是什么呢?比较正确和合理的答案就是最简单的做法,在事务结束之后执行提交,不要在事务之间提交,不要使用过程性循环处理语句。

举个例子,就很好说明了:你要执行1张表中的1w条记录,如果你在每100条之后执行一个commit,在执行第101条的update时候,事务失败了。

这个时候第100条之前的记录已经被update并且被commit了,这个事务是失败的,但是又有你不知道的100条记录被update且commit了,这个时候应该是很郁闷了吧,不知道如何重新启动这个事务了。你知道你失败了,但是不知道从哪里爬起来。!

其次,分开提交,比单个sql语句更慢。

第3,已经被commit的undo会有被覆盖的风险,而根据事务一致性和多版本能控制的特性,update是一边查询一边修改的执行,如果构造此次事务的undo空间被覆盖,你将收到经典的ORA-01555:snapshot too old的错误。

第4。。。我也不知道。

以上3点足够我们放弃这个误导性的观点:过程性循环性处理大更新的提交工作。

-The End-

抱歉!评论已关闭.