事务的ACID特性
1、原子性(Atomicity)
事务的原子性是指事务中包含的所有操作要么都做，要么都不做，保证数据库是一致的。
例如：A帐户向B帐户划账1000，则先将A减少1000，再将B增加1000，这两个动作要么都提交，要么都回退，不可能发生一个有效、一个无效的情况。
2、一致性(Consistency)
一致性是指数据库在事务操作前和事务处理后，其中的数据必须都满足业务规则约束。
例如：A、B帐户的总金额在转账前和转帐后必须一致，其中的不一致必须是短暂的，在事务提交前才会出现的。
再如：约定B帐户不能多于1000元，则A转出1000成功，B转入1000失败，最终由原子性得到——整个事务回滚
3、隔离性(Isolation)
隔离性是数据库允许多个并发事务同时对齐数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
例如：在A、B之间转帐时，C同时向A转帐，若同时进行则A、B之间的一致性不能得到满足。所以在A、B事务执行过程中，其他事务不能访问(修改)当前相关的数值。
4、持久性(Durability)
持久性表示为：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
在提交之前如果系统故障，则所有信息全部丢失。提交之后数据存放在磁盘中，是永久性的。
事务的控制
事务的开始是隐形声明的，不用也没有语句可以进行操作，默认从对数据的修改开始就开始了当前事务。
对数据库的设置主要有一下语句：
SET TRANSACTION-----设置事务属性
SET CONSTRANS-------设置约束模式
SAVEPOINT-----------建立存储点
RELEASE SAVEPOINT---释放存储点
ROLLBACK------------回滚
COMMIT--------------提交
1、设置事务属性
设置事务属性主要可以用来完成以下工作：
* 指定事务的隔离层
* 规定回滚事务时所使用的存储空间
* 命名事务
注：SET TRANSACTION必须是事务的第一个语句。并在事务终止后自动失效。
SET TRANSACTION ISOLATION LEVEL READ COMMITED
A事务设置为READ COMMITED，该开始后B事务修改了数据，此时A无法得到新数据，B提交之后，A可以查询到更新数据。
A不可能错读，但可能发生假读和非重复读。
在需要并发数很大时应该使用READ COMMITED，对于多用户并发的性能和响应速度都比较好。
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
事务和事务之间完全隔离开，事务以串行的方式执行。不是说必须等一个结束，而是事务一旦开始，在结束之前查询到的数据永远是开始时刻的数据。由于留存的模式会比较多，所以会消耗一定的系统资源。
SET TRANSACTION READ ONLY
当前事务不能有任何修改数据的操作，READ ONLY是SERIALIZABLE的一个子集，基本上属于最高的安全级。
SET TRANSACTION READ WRITE
在READ的基础上增加WRITE权限，不常用
2、设置约束延期性
在操作过程中可能需要违反约束向表中插入重复的数据，其实需要设置约束延期性。
设置格式如下：
SET CONSTRAINT ALL | <constraint_name>
DEFERRED | IMMEDIATE
可以选择要延期的约束名，也可以使用ALL关键字延期所有的约束
DEFERRED表示延期，IMMEDIATE表示应用
注：理论上在COMMIT前需要设置回IMMEDIATE，但是系统可以隐式自动完成这一操作。
注意：要使用延迟的约束，必须在创建时就进行说明：
ALTER TABLE T1 ADD CONSTRAINT <constraint_name> DEFERRABLE INITIALLY IMMEDIATE
后面的DEFERRABLE 指名可以使用延迟，INITIALLY 设定了初始值
3、存储点
由于事务太大，一次回滚会对系统造成很大的压力。而且有时候在某一段特定的代码附近会特别发生错误而回滚。这时就需要在希望的地方设置一个存储点，可以显示得操作数据在发生错误时回滚到指定的存储点，而节省不必要的开销。
创建格式如下：
SAVEPOINT <savepoint_name>
使用格式如下：
ROLLBACK TO [SAVEPOINT] <savepoint_name>
4、结束事务
以下操作为将事务结束：
* 使用COMMIT提交事务，数据被永久保存
* 使用ROLLBACK回滚事务(不包括回滚到存储点)
* 执行DDL时，结束默认COMMIT
* 用户断开连接，此时事务自动COMMIT
* 进程意外中止，此时事务自动ROLLBACK
注：事务COMMIT时会生成一个唯一的系统变化号(SCN)保存到事务表
附：关于事务相关的数据字典
=========================================================================================================
晶晶实验七之事务表篇
回滚段头中，有一项非常重要的信息，就是事务表。对事务表频繁的访问,可能会造成回滚段头的争用.了解什么样的操作会访问事务表,对于了解回滚段头争用的原因非常重要.下面我们来做一些实验来验证一下,什么样的操作才会访问事务表.
首先简单介绍一个视图,备份x$bh.对这个视图我想大家都有一定的了解,bh即buffer header 的简写.在buffer header中有一个TCH 列,表示块被访问的次数.我们通过他来验证事务表什么时候被访问.需要注意的是.TCH列每3秒,才会重新计算一次,3秒之内无论访问某一个块多少次.TCH列只会增加1.
在会话A开启一个事务后:
步骤一:通过v$transaction视图找到XID
SQL> select xidusn,ubablk,ubafil from v$transaction;
XIDUSN UBABLK UBAFIL
---------- ---------- ----------
13 97 5
步骤二:通过回滚段编号,可得知事务所占回滚段名,并用此查找事务头块号,文件号
SQL> select header_block,header_file from dba_segments where segment_name='_SYSSMU13$';
HEADER_BLOCK HEADER_FILE
------------ -----------
41 5
步骤三:查看x$bh视图中,TCH值的增加.
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B5208 41
步骤四:查找完TCH后,马上执行要测试的命令(会话B),
SQL> select * from jj_3;
ID NA
---------- --
1 aa
2 aa
3 aa
4 aa
5 CN
步骤五:再次查看x$bh视图
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B5208 42
注意:步骤三四五应尽快完成.避免oracle的其他内部操作影响测试结果.（因为oracle内部的操作也会造成回滚段头的tch值增加，特别在１０Ｇ中，这种情况更为明显，不过我没有跟踪是什么oracle的内部操作造成的）
小结:从结果集来看,在另一会话中访问未提交数据的select语句会访问事务表,那么其他的DML操作呢?(希望大家也都试试,我的结果是都会增加TCH值).上面我的步骤四是全表扫描.
如果我的表有两个块,分别是块一块二,在块一中修改行A,按照rowid访问块一中的行B,这样会访问事务表吗?如果
按照rowid访问块二中的行,会访问事务表吗?下面我来实验下看结果是什么:
步一:利用函数查看该表的块号.
SQL> select rowid,dbms_rowid.rowid_block_number(rowid) from jj_3;
ROWID DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------ ------------------------------------
AAAMvjAAKAAAAEdAAA 285
AAAMvjAAKAAAAEdAAB 285
AAAMvjAAKAAAAEdAAC 285
AAAMvjAAKAAAAEeAAA 286
步二: 在B会话中通过AAAMvjAAKAAAAEdAAC修改表.
SQL> update jj_3 set id=10 where rowid='AAAMvjAAKAAAAEdAAC';
已更新 1 行。
步三: 在A会话中通过AAAMvjAAKAAAAEdAAA查看行
SQL> select * from jj_3 where rowid='AAAMvjAAKAAAAEdAAA';
ID NA
---------- --
4 aa
在做步一和二之前,先查看一下X$BH,因为他会因为oracle的内部操作而增加,
实验前查看结果:
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B51BC 63
实验后查看结果:
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B51BC 64
结论一:在块一中修改行A,按照rowid访问块一中的行B,这样会访问事务表;再试试不同的块
操作前先查看下X$BH:
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B51BC 67
接着刚才的实验,我又访问了不同的块:
SQL> select * from jj_3 where rowid='AAAMvjAAKAAAAEeAAA';
ID NA
---------- --
4 aa
再次查看X$BH的结果是:
SQL> select addr,tch from x$bh where dbarfil=5 and dbablk=41;
ADDR TCH
-------- ----------
080B51BC 67
结果很明显了,用rowid访问不同的块,是不会增加TCH值的.也就是说不会有CR块产生.
在晶晶实验六中,已经证明了在生成CR块时,oracle可以根据数据块头部的ITL槽中的UBA,找到存放数据块回滚信息的回
滚块和回滚记录,通过这个UBA就可以构造CR块咯,oracle为什么还要再去访问事务表呢?这是因为,oracle的提交有时会
是延迟提交.oracle并不清除延迟提交所涉及的块中的事务信息,如:事务所占ITL槽和行锁.而把清除事务信息这个操作
放到了以后的块清除中(块清除在以后的实验会详细讲述),oracle这样做的目的是为加快提交速度.如果一个事务涉及
到了过多的块,单单是提交时清除每个块中的事务信息就需要耗费很长时间.这降低了提交速度.有可能使提交成为最易
引起争用的操作.当事务提交时,对事务所涉及的块,不做任何操作,块将保持事务仍在持续时的信息.当一个select操作
查询到这个块时,ITL槽中的提交标志为未提交,但实际上这个事务是已经提交的.就是因为有了延迟提交oracle无法根
据ITL槽中的提交标志来判断一个块中的事务是否真的提交.他必须根据ITL中的XID 去访问事务表.才能确定此块中的
事务是否真的提交.在生成CR块前,oracle先要判断是否真的有必要为此块生成CR块.这就要去访问事务表.
-The End-