Tam*_*ege 20 sql oracle transactions commit rollback
我们在公司使用的内部应用程序框架使得必须将每个SQL查询都放入事务中,即使我知道没有任何命令会在数据库中进行更改.在会话结束时,在关闭连接之前,我提交事务以正确关闭它.我想知道如果我把它卷回来是否有任何特别的区别,特别是在速度方面.
请注意我使用的是Oracle,但我猜其他数据库也有类似的行为.此外,我无法对开始交易的要求做任何事情,代码库的那部分不在我手中.
S.L*_*ott 12
数据库通常保留前映像日志(事务之前的日志)或后映像日志(事务完成时将会是什么.)如果它保留了前映像,则必须在回滚时恢复.如果它保留了后映像,则必须在提交时替换数据.
Oracle有一个日志和回滚空间.事务日志累积了后来由DB编写者编写的块.由于这些是非同步的,因此几乎没有任何DB编写器对您的事务有任何影响(如果队列填满,那么您可能需要等待.)
即使对于仅查询事务,我也愿意打赌在Oracle的回滚区域中存在一些事务性记录保留.我怀疑在确定没有什么可以实际回滚之前,回滚需要在Oracle上做一些工作.我认为这与您的交易同步.在回滚完成之前,您无法真正释放任何锁定.[是的,我知道你没有在你的事务中使用任何东西,但锁定问题是为什么我认为必须完全释放回滚然后释放所有锁,然后你的回滚就完成了.]
另一方面,提交或多或少是预期的结果,我怀疑丢弃回滚区域可能会稍快一些.您没有创建任何事务条目,因此数据库编写器甚至不会醒来检查并发现无事可做.
我也期望虽然提交可能会更快,但差异很小.如此轻微,您可能无法在并排比较中测量它们.
我同意之前的答案,即在这种情况下COMMIT和ROLLBACK之间没有区别.确定没有任何COMMIT需要的CPU时间与确定ROLLBACK没有任何内容所需的CPU时间之间可能存在微不足道的差异.但是,如果这是一个可以忽略不计的差异,我们可以放心地忘记它.
但是,值得指出的是,在单个事务的上下文中执行大量查询的会话与在一系列事务的上下文中执行相同查询的会话之间存在差异.
如果客户端启动事务,执行查询,执行COMMITOR ROLLBACK,然后启动第二个事务并执行第二个查询,则无法保证第二个查询将观察到与第一个查询相同的数据库状态.有时,维护单一一致的数据视图至关重要.有时,获取更新的数据视图至关重要.这取决于你在做什么.
我知道,我知道,OP没有问这个问题.但有些读者可能会在他们的脑海里问这个问题.