在Oracle中一个事务是由一个可执行的SQL语句开始，一个可执行SQL语句产生对实例的调用。在事务开始时，被赋给一个可用回滚段，记录该事务的回滚项。一个事务以下列任何一个出现而结束。
◆当COMMIT或ROLLBACK（没有SAVEPOINT子句）语句发出。
◆一个DDL语句被执行。在DDL语句执行前、后都隐式地提交。
◆用户撤消对Oracle的连接（当前事务提交）。
◆用户进程异常中止（当前事务回滚）。
(1)提交事务
提交一事务，即将在事务中由SQL语句所执行的改变永久化。在提交前，Oracle已有下列情况：
◆在SGA的回滚段缓冲区已生成回滚段记录，回滚信息包含有所修改值的老值。
◆在SGA的日志缓冲区已生成日志项。这些改变在事务提交前可进入磁盘。
◆对SGA的数据库缓冲区已作修改，这些修改在事务真正提交之前可进入磁盘。
在事务提交之后，有下列情况：
◆对于与回滚段相关的内部事务表记录提交事务，并赋给一个相应的唯一系统修改号（SCN），记录在表中。
◆在SGA的日志缓冲区中日志项由LGWR进程写入到在线日志文件， 这是构成提交事务的原子事务。
◆在行上和表上的封锁被释放。
◆该事务标志为完成 。
注意：对于提交事务的数据修改不必由DBWR后台进程立即写入数据文件，可继续存储在SGA的数据库缓冲区中，在最有效时将其写入数据文件。
(2)回滚事务
回滚事务的含义是撤消未提交事务中的SQL语句所作的对数据修改。Oracle允许撤消未提交的整个事务，也允许撤消部分。
在回滚整个事务（没有引用保留点）时，有下列情况：
◆在事务中所有SQL语句作的全部修改，利用相应的回滚段被撤消。
◆所有数据的事务封锁被释放。
◆事务结束。
◆当事务回滚到一保留点（具有SAVEPOINT）时，有下列情况：
◆仅在该保留点之后执行的语句被撤消。
◆该指定的保留点仍然被保留，该保留点之后所建立的保留点被删除。
◆自该保留点之后所获取的全部表封锁和行封锁被释放，但指定的保留点以前所获取的全部数据封锁继续保持。
◆该事务仍可继续。
(3)保留点
保留点（savepoint）是在一事务范围内的中间标志，经常用于将一个长的事务划分为小的部分。保留点可标志长事务中的任何点，允许可回滚该点之后的工作。在应用程序中经常使用保留点；例如一过程包含几个函数，在每个函数前可建立一个保留点，如果函数失败，很容易返回到每一个函数开始的情况。在回滚到一个保留点之后，该保持点之后所获得的数据封锁被释放。
--------------------------------------------------------
事务结束的地方有：
1>. 执行Commit, Rollback， 没有使用savepoint.
2>. 执行DDL操作如：create , drop, rename, alter
3>. 断开与Oracle的连接，事务将自动提交。
4>. 用户进程异常终止，当前事务回滚。
注意：应用程序与Oracle连接的情况，在应用程序终止前必须显示的提交(Commit)或回滚(Rollback)。
Commit操作Oracle做了：
1>. 与UNDO表空间关联的内部事务表记录该事务已经提交，产生唯一的系统交易号（SCN）保存到该表
中。
2>. LGWR进程将SGA中的重做日志写入redo log文件，当然也要写SCN到重做日志文件。
3>. Oracle释放锁定表中的行。
4>. Oracle设置该事务完成。
注意：Commit操作前的改变数据（保存在SGA）不会马上写到数据文件中。这样做的目的也是为了数据
库更高效。从开发人员的角度想想也是这样的，这样可以减少很多小事务的多次写磁盘的。
---------------------------------------------------------------------------
若循环提交DML语句但不进行commit或rollback？提交不是commit吗？
连接上的内存会不断增长吗？我觉得不会。
开发的时候根据业务的需要进行提交就可以了，一般不会有问题的。
dml只是会产生undo信息，同时写入redo日志，还有就是把数据块写入数据文件，涉及的内存包括：块缓存区，日志缓存区，shared pool，等，oracle中的内存分配要不是分配好的，也就是固定大小。要不就是oracle自动管理的，由orcle动态调整。
------------------------------------------------------------------------------
只想说一句，频繁提交，会导致日志操作频繁，效率受影响。
在回滚段足够的情况下，
你可以试验一下，插入1000000条记录，
每10条提交一次，
和每1000条提交一次，谁的时间更长？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。