一般事务(DML)即数据修改(增、删、改)的事务

事务会将所有在事务中被修改的数据行加上锁(行级锁)，来阻止其它人(会话)同时对这些数据的修改操作。

当事务被提交或回滚后，这些数据才会被释放锁。

举个例子：

当A操作一条数据N1后，暂未提交事务 ，此时B又上来操作同一条数据N1，这时的情况是：

1、所有除A以外的人看不到被A所修改后的数据

2、B会处于等待状态，直到A提交或回滚了针对这条数据的修改(这也就是行级锁的概念)

3、当A提交事务后，所有人可以看到被A修改后的数据，看不到B修改后的数据。但B能看到自己修改后的数据(与A一样，因为B还未提交事务)。

4、当B提交事务后，所有人可以看到被B修改后的数据。

由上可以看出，对同一条数据的事务处理，必须按先后顺序进行。

即：A先提交了事务后，B才可以提交事务，否则B将无法对这条数据进行修改(B会在操作这条数据时处于等待状态，直到A提交或回滚了事务，释放了这行数据的锁)。

这里注意一点，这里所说有A与B并不是指二个ORACLE帐户，而是二个连接会话。上面只是为了方便举例。

就是说即使是在同一台电脑上用同一个ORACLE帐户，但同时分别打开了二个连接会话(比如同时打开二个PL/sql并用相同帐户连接到同一个库中)，就会被视为A、B两个人。

在PS/sql中，对数据修改完后，如果用户未提交事务，但关闭或断开了PS/sql，此时ORACLE会立即提交此会话的事务。

我们可以事务中使用保存点来回滚到指定的时间节点上来，但如果用提交事务(commit)后，所有保存点将被删除。

举个举子：

savepoint a1;    --设置一个保存点 a1;

update tmp set username=‘张三‘ where userid=‘101‘  --修改一条数据

savepoint a2;   --设置一个保存点 a1;

update tmp set username=‘李四‘ where userid=‘102  --再修改一条数据

rollback to a2;   --回滚到a2 保存点。 此时在 a2 保存点之后的所有数据修改视为无效。

rollback to a1;   --这里可以再从a2保存点再回滚到a1 保存点。 此时在 a1 保存点之后的所有数据修改视为无效。

rollback;           --回滚全部。即撤消至上一次提交事务后的所有数据修改。

commit;  --提交事务 将回滚后的事务提交，并会删除所有保存点。

注意：我们可以从a2向前再回滚到a1 ，但无法从a1回滚到a2。也就是只能向前回滚，不能从前面的点再向后回滚！

只读事务 即，只用于select 查询的事务

只读事务主要用于在某一个时间点对数据的查询统计。如：在18:00创建一个只读事务，然后可以开始统计某张表的记录数。此时18：00之后新添加到这张表中的数据就不会进入到统计中去。也就是创建只读事务的会话连接人，将无法看到在创建只读事务之后其它任何人对数据的真实修改。

方法是：

set transaction read only;  --在此之后，拥有此会话的连接人将无法看到其它人对数据的任何改动。用户可以用select 进行此时间点的统计查询

set transaction read write;  --取消只读事务

只读事务没有回滚和提交的功能也不记录回滚LOG。

只读事务最大的用处是保证在某个时间点查询结果的一致性。换句话说，如果你要统计很多信息，有多个select查询时，但你执行完第一个查询后(如用户信息统计)，可能其它人进来修改了某些数据你正在查询的数据。这时你再进行第二个查询(如用户信息的统计或其它有关用户信息的查询)。这时候将出现数据查询结果的不一致，第二次查询的结果会由于数据被修改了而与第一次查询结果一不样。只读事务正是解决这类问题的办法。

其实ORACLE为了优化查询在对于单条查询时也会启动只读事务(就是在你开始执行查询时会有一个只读事务点，到查询结束前，在这期间的数据修改都被无视掉)，你无须手动创建只读事务。但多条查询时我们就必须手动创建只读事务。

(来源：https://www.linuxidc.com/Linux/2012-07/66120.htm)

提交的类型：

提交数据有三种类型：

显式提交、隐式提交及自动提交。

1、显式提交：用COMMIT命令直接完成的提交为显式提交。其格式为：sql>COMMIT；

2、隐式提交：用sql命令间接完成的提交为隐式提交。这些命令是：ALTER，AUDIT，COMMENT，CONNECT，CREATE，DISCONNECT，DROP，EXIT，GRANT，NOAUDIT，QUIT，REVOKE，RENAME。(此隐式提交是在自己的session，如果在其他人的session(如用户a)中正在修改相同的数据，则引起隐式提交的语句(用户a的k另一个session)则必需等待)

3、自动提交：若把AUTOCOMMIT设置为ON，则在插入、修改、删除语句执行后，系统将自动进行提交，这就是自动提交。其格式为：sql>SET AUTOCOMMIT ON；

查看当前是否是自动提交：show autocommit；

隐式提交：

隐式提交的定义

又名自动提交，即无需显示执行commit语句，session中的操作被自动提交到数据库的过程。

隐式提交的方式

1、正常执行完ddl语句。包括create，alter，drop，truncate，rename。

2、正常执行完dcl语句。包括grant，revoke。

3、正常退出isql*plus，没有明确发出commit或者rollback。

隐式提交的注意事项

1、执行ddl语句时，前面的dml操作也会被提交到数据库中

因为是在一个session里，那执行ddl语句的时候前面的dml语句肯定也会“不可幸免”的被提交到库中。

2、即使ddl语句执行失败，前面的dml操作也会被提交到数据库中

这就有点儿让人奇怪了，ddl都执行失败了，怎么还会提交呢？这就需要探究一下隐式提交的本质了(下文有叙述)。

3、在前面1和2的基础上总结

为了避免隐式提交或者回滚，尽量保证一条或者几条DML操作完成后有显示的提交或者回滚，防止后续执行的DCL或者DDL自动提交前期的DML操作。

隐式提交的本质

1、一条ddl语句执行了两次commit

commit;

ddl statement;

commit;

第一个commit将当前session中未提交的事务隐式提交，以保证ddl语句失败时的回滚位置。

第二个commit将ddl

2、为什么需要隐式提交？

为了保证事务的一致性。我们在执行ddl语句的时候，oracle需要在它的系统表中进行元数据的记录操作(即：除了建表还会进行不少insert操作)，如果它不隐式提交就无法保证一致性；从内部运行机制来看ddl语句和dml语句还是有很大区别的，dml会对每个语句的每条记录都做日志记录以便于回滚，而ddl往往没必要搞这么复杂，从功能和易用性上看隐式提交都是最好的选择。

(来源：https://www.linuxidc.com/wap.aspx?cid=7&nid=92704&sp=850)