Oracle的commit详解(转)

时间:2022-08-04 15:41:01

java通过jdbc thin方式连接数据库后,对数据库操作时会出现以下两种情况,我这可能记录不全:

1.在sqlplus中查询得到和java终端中输出的查询结果不同

2.执行某些sql语句卡住不动

这些情况只需要在sqlplus中执行 SQL>commit; 就可以完美解决

SQL> commit;

提交完成。

原文链接:http://blog.csdn.net/hzhsan/article/details/9719307

解释了执行executeUpdate语句卡住不动的原因:http://blog.csdn.net/tony_bupt/article/details/9144801

----------------------------------------------------转载的内容:

它执行的时候,你不会有什么感觉。commit在数据库编程的时候很常用,当你执行DML操作时,数据库并不会立刻修改表中数据,这时你需要commit,数据库中的数据就立刻修改了,如果在没有commit之前,就算你把整个表中数据都删了,如果rollback的话,数据依然能够还原。听我这么说,你或许感觉commit没什么用,其实不然。当你同时执行两条或两条以上的sql语句时,问题就出现了。举一个例子,你去银行转账,你转的时候银行的数据库会update你银行账户里面的数据,同时对另一个人得账户也进行update操作。这两个程序都必须全部正确执行,才能commit,否则rollback。如果只是完成一条,要么你郁闷,要么银行郁闷,第一种情况是,你的账户的钱没少,转账人得账户上的钱多了,银行郁闷了。第二种情况你的银行账户的钱少了,他的却没多,你就好郁闷了。Oracle好好学吧!sql不难,plsql努努力也能熬过去,等到优化那,哎!DBA不是那么好当的。还有就是commit算是显式提交,还有隐式提交,并不是,不commit的话,你的全部努力就都白费了。

   这个命令是将数据写到数据库中。如果不执行COMMIT这个命令,那么在你这个session之外的其他session查询的数据是你修改数据之前的数据。而COMMIT之后人家查询的是你修改的数据。你可以打开两个sqlplus比较做一下测试。一目了然。 
commit的提交针对的是:DML
Data Manipulation Language(DML) 需要提交,这部分是对数据管理操作,比如Insert(插入)、Update(修改)、Delete(删除),
Data Definition Language(DDL) 不需要提交,这部分是对数据结构定义,比如 Create(创建)、Alter(修改)、Drop(删除)
 
   oracle的commit就是提交数据(这里是释放锁不是锁表),在未提交前你前面的操作更新的都是内存,没有更新到物理文件中。执行commit从用户角度讲就是更新到物理文件了,事实上commit时还没有写date file,而是记录了redo log file,要从内存写到data物理文件,需要触发检查点,由DBWR这个后台进程来写,这里内容有点多的,如果不深究的话你就理解成commit即为从内存更新到物理文件。锁有很多种,一般我们关注的都是DML操作产生的,比如insert,delete,update,select...for update都会同时触发表级锁和行级锁 

补充:对的,insert以后commit之前是锁表的状态,其他事务无法对该表进行操作。
如果不提交的话,那么这个表就被锁了 
 COMMIT通常是一个非常快的操作,而不论事务大小如何。你可能认为,一个事务越大(换句话说,它影响的数据越多),COMMIT需要的时间就越长。不是这样的。不论事务有多大,COMMIT的响应时间一般都很“平”(flat,可以理解为无高低变化)。这是因为COMMIT并没有太多的工作去做,不过它所做的确实至关重要。

  这一点很重要,之所以要了解并掌握这个事实,原因之一是:这样你就能心无芥蒂地让事务有足够的大小。一种错误的信念认为分批提交可以节省稀有的系统资源,而实际上这只是增加了资源的使用。如果只在必要时才提交(即逻辑工作单元结束时),不仅能提高性能,还能减少对共享资源的竞争(日志文件、各种内部闩等)。

  分批提交COMMIT的开销存在两个因素:

  显然会增加与数据库的往返通信。如果每个记录都提交,生成的往返通信量就会大得多。

  每次提交时,必须等待redo写至磁盘。这会导致“等待”。在这种情况下,等待称为“日志文件同步”(log file sync)。

  为什么COMMIT的响应时间相当“平”,而不论事务大小呢?在数据库中执行COMMIT之前,困难的工作都已经做了。我们已经修改了数据库中的数据,所以99.9%的工作都已经完成。例如,已经发生了以下操作:

  已经在SGA中生成了undo块。

  已经在SGA中生成了已修改数据块。

  已经在SGA中生成了对于前两项的缓存redo。

  取决于前三项的大小,以及这些工作花费的时间,前面的每个数据(或某些数据)可能已经刷新输出到磁盘。

  已经得到了所需的全部锁。

  执行COMMIT时,余下的工作只是:

  为事务生成一个SCN。如果你还不熟悉SCN,起码要知道,SCN是Oracle使用的一种简单的计时机制,用于保证事务的顺序,并支持失败恢复。SCN 还用于保证数据库中的读一致性和检查点。可以把SCN看作一个钟摆,每次有人COMMIT时,SCN都会增1.

  LGWR将所有余下的缓存重做日志条目写到磁盘,并把SCN记录到在线重做日志文件中。这一步就是真正的COMMIT。如果出现了这一步,即已经提交。事务条目会从V$TRANSACTION中“删除”,这说明我们已经提交。

  V$LOCK中记录这我们的会话持有的锁,这些所都将被释放,而排队等待这些锁的每一个人都会被唤醒,可以继续完成他们的工作。

  如果事务修改的某些块还在缓冲区缓存中,则会以一种快速的模式访问并“清理”。块清除(Block cleanout)是指清除存储在数据库块首部的与锁相关的信息。实质上讲,我们在清除块上的事务信息,这样下一个访问这个块的人就不用再这么做了。我们采用一种无需生成重做日志信息的方式来完成块清除,这样可以省去以后的大量工作(在下面的“块清除”一节中将更全面地讨论这个问题)。

  可以看到,处理COMMIT所要做的工作很少。其中耗时最长的操作要算LGWR执行的活动(一般是这样),因为这些磁盘写是物理磁盘I/O。不过,这里LGWR花费的时间并不会太多,之所以能大幅减少这个操作的时间,原因是LGWR一直在以连续的方式刷新输出重做日志缓冲区的内容。在你工作期间,LGWR并非缓存这你做的所有工作;实际上,随着你的工作的进行,LGWR会在后台增量式地刷新输出重做日志缓冲区的内容。这样做是为了避免COMMIT等待很长时间来一次性刷新输出所有的redo。

  因此,即使我们有一个长时间运行的事务,但在提交之前,它生成的许多缓存重做日志已经刷新输出到磁盘了(而不是全部等到提交时才刷新输出)。这也有不好的一面,COMMIT时,我们必须等待,直到尚未写出的所有缓存redo都已经安全写到磁盘上才行。也就是说,对LGWR的调用是一个同步(synchronous)调用。尽管LGWR本身可以使用异步I/O并行地写至日志文件,但是我们的事务会一直等待LGWR完成所有写操作,并收到数据都已在磁盘上的确认才会返回。

  前面我提高过,由于某种原因,我们用的是一个Java程序而不是PL/SQL,这个原因就是 PL/SQL提供了提交时优化(commit-time optimization)。我说过,LGWR是一个同步调用,我们要等待它完成所有写操作。在Oracle 10g Release 1及以前版本中,除PL/SQL以外的所有编程语言都是如此。PL/SQL引擎不同,要认识到直到PL/SQL例程完成之前,客户并不知道这个PL /SQL例程中是否发生了COMMIT,所以PL/SQL引擎完成的是异步提交。它不会等待LGWR完成;相反,PL/SQL引擎会从COMMIT调用立即返回。不过,等到PL/SQL例程完成,我们从数据库返回客户时,PL/SQL例程则要等待LGWR完成所有尚未完成的COMMIT。因此,如果在PL /SQL中提交了100次,然后返回客户,会发现由于存在这种优化,你只会等待LGWR一次,而不是100次。这是不是说可以在PL/SQL中频繁地提交呢?这是一个很好或者不错的主意吗?不是,绝对不是,在PL/SQ;中频繁地提交与在其他语言中这样做同样糟糕。指导原则是,应该在逻辑工作单元完成时才提交,而不要在此之前草率地提交。

  COMMIT是一个“响应时间很平”的操作,虽然不同的操作将生成不同大小的redo,即使大小相差很大或者说无论生成多少redo,但也并不会影响提交(COMMIT)的时间或者说提交所用的时间都基本相同。

转自:
http://zhidao.baidu.com/question/345732898.html
http://zhidao.baidu.com/question/446956119.html
http://zhidao.baidu.com/question/126448794.html
http://soft.chinabyte.com/database/75/12306575.shtml