使用Rollback to xx 回滚到保存点.

下面做个例子:
登陆sqlplus:
例如hr账户下有一张表CL_DEPT:

现在去查看事务的系统视图v$transaction, 是没有人任何记录的:

这时我执行一条DML语句(insert),但是仲未Commit:

如上图, 插入了60,TEL MADRID就是保存点前一条DML语句插入的.

2.事务的隐式commit和rollback

1.执行DDL语句(create table之类) 会隐式提交事务

2. session异常退出(包括数据库崩溃)会令session未提交的事务回滚.

3. session 正常退出 (输入 exit/关闭终端窗口/输入ctrl +D) 会隐式提交事务. 这个要注意啊

无论如何,要尽量避免事务的隐式的commit和rollback.

3事务的特性
事务包含4大特性ACID:
分别是:
原子性(Atomicity)
一致性(Consistency)
隔离性(Isolation)
持久性(Durability)

3.1 原子性(Atomicity):
    事务的原子性是指事务中所有的操作,要么都做, 要么都不做,保证数据库是一致的.
    例如:  A账户向B账户划账1000蚊,  则先将A减少1000,然后将B增加1000,这两个动作要么都提交,要么都回滚,不能只提交1个另1个无效,否则数据总账就变化了.

3.2 一致性(Consistency):
       一致性是指数据库在事务操作前和事务处理后, 其中的数据必须都满足业务规则约束.
        例如: A, B账户的总金额在转帐前和和转帐后必须一致,其中的不一致必须是短暂的,在事务提交后就会消失的.
        再如: 约定B账户不能多余1000元, 则转出1000成功, 而B账户转入失败, 最终由原子性得到---整个事务回滚.

3.3 隔离性(Isolation):
        隔离性是指数据库允许多个并发事务同时对数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行时导致数据的不一致.
   
        例如: 在A,B 之间转帐时, C同时向A转帐,若同时进行则A B之间的一致性不能满足,所以当A B事务执行时,其他事务不能访问(修改)当前相关的数据.

3.4 持久性(Durabiity)
       持久性表示为: 事务处理结束后,对数据的修改是永久的,即使系统故障也不会丢失
       在提交啊之前如果系统故障,则所有信息全部丢失,提交后数据存放在磁盘中,是永久性的.

4.事务的隔离级别.
级别:(只能用普通用户执行)
(串行)  SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
commit;

SET TRANSACTION ISOLATION LEVEL READ COMMITED;(默认)

4.1 SET TRANSACTION ISOLATION LEVEL READ COMMITED;(默认)
我们知道默认的事务隔离级别是这样的:
如上面HR 和 scott的例子
Session B见不到 Session A提交前修改的数据, 但Session A一旦提交, B马上就见到了.

4.2 (串行)SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
但是我们执行上面那条语句后再试下:(用普通用户执行)
这时scott 执行将事务隔离化设为串行:

这时HR 向cl_dept插入一条数据:

这时Scott去查看这张表,当然是见不到HR未commit的新数据行的:

这时HR commit这条transaction:

再去scott那条session查看对应表, 发现即使hr commit了事务,  scott还是见不到修改后的数据:

那什么时候scott才能看到Hr修改的数据呢,  这时需要scott 执行commit...

5.另外两条 Set transaction 语句:
5.1 SET TRANSACTION  READ ONLY;
执行了上面那个语句, 你就不能执行DML语句了.. 也就是不能修改数据.
除非你执行rollback 或 commit;

5.1 SET TRANSACTION  READ WRITE;
这个是默认的,没什么可说啦~