oracle事务 set transaction readonly演示

set transaction readonly 类似于SERIALIZABLE事务隔离级别，在发布SET TRANSACTION 
READ ONLY起的所有SELECT语句，其结果均为同一个时间点一致，直至显式地发布了COMMIT或ROLLBACK命令或隐式提交（执行DDL）。这个时间点为SET TRANSACTION READ ONLY这个语句执行后的时间点。这个语句与SERIALIZABLE不同之处在于，在READ ONLY这个范围内，不能进行DML。以下用测试说明：用TEST1用户开启两个会话
在会话一中：
SQL> create table t1 (a int );
Table created.
SQL> insert into t1 values (10);
1 row created.
SQL> commit;
Commit complete.

在会话二中：
SQL> select * from t1;
         A
----------
        10
SQL> set transaction read only;
Transaction set.

SQL> select * from t1;
         A
----------
        10
然后在会话一中插入一行数据，并提交：
SQL> insert into t1 values (20);
1 row created.
SQL> commit;
Commit complete.

在会话二中查看表t2的数据：
SQL> /
         A
----------
        10
SQL> /
         A
----------
        10
SQL> commit;
Commit complete.
SQL> select * from t1;
         A
----------
        10
        20
可以看到，虽然会话一已经插入了一条数据并提交了，但是查询时，仍然只能看到一条数据。在COMMIT之后，SET TRANSACTION READ ONLY作用结束，再查询T1，可以看到新插入的数据了。
我们再看一下，这个“时间点”是从第一个SELECT语句的时候还是SET TRANSACTION READ ONLY刚执行完的时候：在会话二中：
SQL> set transaction read only;
Transaction set.

然后在会话一中：
SQL> insert into t1 values (30);
1 row created.
SQL> commit;
Commit complete.
在会话二中：
SQL> select * from t1;
         A
----------
        10
        20
可以看到，新插入的数据30是在会话二的SET TRANSACTION READ 
ONLY之后和SELECT之前插入的，但SELECT语句看不到这个数据，因此这个时间点是在执行完SET TRANSACTION READ ONLY之后，而不是第一个SELECT语句执行那一刻。
我们继续下面的测试：在会话二中：
SQL> drop table t2;
Table dropped.
SQL> select * from t1;
         A
----------
        10
        20
        30
可以看到DROP语句之后，由于隐式提交，SET TRANSACTION READ ONLY作用范围结束，又可以查到新插入的数据。
SQL> set transaction read only;
Transaction set.
SQL> insert into t1 values (40);
insert into t1 values (40)
            *
ERROR at line 1:
ORA-01456: may not perform. insert/delete/update operation inside a READ ONLY transaction
可以看到，在SET TRANSACTION READ ONLY之后，不能执行DML
注意：SYS用户并不受SET TRANSACTION READ ONLY的影响：
SQL> show user
USER is "SYS"
SQL> set transaction read only;
Transaction set.
SQL> delete from t1 where rownum=1;
1 row deleted.
SQL> commit;
Commit complete.
以上测试即证明了这一点。
EXP导出数据时，如果CONSISTEN参数设为TRUE，则EXP导出时，会先发布SET TRANSACTION READ ONLY，保证所有导出数据在同一时间点上的一致性。当然，如果事务频繁，导出的数据量又大，很可能会遭遇ORA-01555错误。由于SET TRANSACTION READ ONLY对SYS用户无效，用SYS用户导出时CONSISTENT设为TRUE，应该没有效果。有兴趣的朋友可以进行测试。

 

1、幻想读：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。
2、不可重复读取：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第一次读取的记录不同，这称为不可重复读。
3、脏读：事务T1更新了一行记录，还未提交所做的修改，这个T2读取了更新后的数据，然后T1执行回滚操作，取消刚才的修改，所以T2所读取的行就无效，也就是脏数据。
 
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/firefoxboy/archive/2008/10/06/3023687.aspx