Oracle未提交的数据可能写入数据文件？如何去验证

[netmin]

Oracle未提交的数据可能写入数据文件？如何去验证这个问题。

[suiziguo]

是的，当时就是这样！

比如当数据高速缓冲区没有多余空间，而ORACLE需要cache新数据库块，则通知dbwr将某些脏数据块写人数据文件。而不管这些脏数据是否提交。

当然，你不用担心，万一你回滚，ORACLE会通过undo数据回滚，清除前面写入数据文件的数据。

[sleepzzzzz]

好象一般是提交后才写入数据文件的，未提交的数据只是在重做文件里。

[sleepzzzzz]

都给忘了，呵呵，应该提交和未提交的都可能写入数据文件。至于验证，没测试过。

[netmin]

没有提交的数据是可能写入数据文件的，在oracle官方文档里已有验证。
另外：DBWn进程写入数据文件时是不判断事务是否提交的，比如：检查点发生 或 没有可用的缓存的空间等。

但问题是如何去验证这个问题？

[netmin]

各位大哥帮个忙

[yuzhenhuan01]

这个不好说
不过你rollback的话都会没有的

[doveli]

用另外一个用户登录，查询一下，是不是就验证了呢？

[vc555]

[Quote=引用 4 楼 netmin 的回复:]
没有提交的数据是可能写入数据文件的，在oracle官方文档里已有验证。
另外：DBWn进程写入数据文件时是不判断事务是否提交的，比如：检查点发生 或 没有可用的缓存的空间等。

但问题是如何去验证这个问题？

[/Quote]
这个简单阿。你插入大量数据不提交，然后看数据文件是否变大了。

[BenChiM888]

顶楼上，是这么个道理。

[kywinder]

数据文件分配下来就是固定大小的，所以想看效果得将数据文件设为自动扩展，初始值小点，然后按照楼楼上的方法多插点数据，看他是否扩展了。

[kywinder]

还有种方法，可以查看DBA_FREE_SPACE;
我实验了下：
SQL> select tablespace_name ,sum(bytes)/1024/1024 from dba_free_space group by tablespace_name;

TABLESPACE_NAME SUM(BYTES)/1024/1024
------------------------------ --------------------
UNDOTBS1 18.6875
USERS 4.6875
SYSTEM 8.5625
XXX .9375

SQL> alter user lyn quota unlimited on xxx;

User altered.

SQL> create table lyn.sdf(t int) tablespace xxx;

Table created.

SQL> insert into lyn.sdf select 2010 from dual;

1 row created.

SQL> insert into lyn.sdf select 2010 from dual;

1 row created.

SQL> /

1 row created.

SQL> insert into lyn.sdf select * from lyn.sdf;

3 rows created.

SQL> insert into lyn.sdf select * from lyn.sdf;

6 rows created.

SQL> /

12 rows created.

SQL> /

24 rows created.

SQL> select tablespace_name ,sum(bytes)/1024/1024 from dba_free_space group by tablespace_name;

TABLESPACE_NAME SUM(BYTES)/1024/1024
------------------------------ --------------------
UNDOTBS1 18.6875
USERS 4.6875
SYSTEM 8.5625
XXX .875
可以发现，XXX的FREESPACE由0.9375M变为0.875M,而我并未COMMIT;

[badaciacia]

查看dba_free_space
楼上方法不错

[mars199]

我试过一个笨方法：写一个update，然后不去commit，这时另一个用户去select得到的结果会是我update之后的结果

[huanyouyu]

这是数据库隔离级别问题，有四种隔离级别，一般的都默认是第三级别，
比如Oracle，要手动提交的，提交前的话，那些数据时已经写进数据的了，
不过只有第一级别才能看到，所以把数据库查看级别设置成第一级别就可以查看未提交的数据了。

你自己搜下会更清楚

在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同:
◆未授权读取（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。
◆授权读取（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
◆可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
◆序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

[qiyousyc]

写就写吧，为什么要验证呢？
而且，确实是写进文件了的呀。

[kywinder]

[Quote=引用 13 楼 mars199 的回复:]
我试过一个笨方法：写一个update，然后不去commit，这时另一个用户去select得到的结果会是我update之后的结果
[/Quote]
头像好像松岛枫啊。。哈哈

[huangdh12]

[Quote=引用 13 楼 mars199 的回复:]
我试过一个笨方法：写一个update，然后不去commit，这时另一个用户去select得到的结果会是我update之后的结果
[/Quote]

这个应该不会吧。。。那还怎么保证数据的正确性。。

[kywinder]

[Quote=引用 17 楼 huangdh12 的回复:]
引用 13 楼 mars199 的回复:
我试过一个笨方法：写一个update，然后不去commit，这时另一个用户去select得到的结果会是我update之后的结果


这个应该不会吧。。。那还怎么保证数据的正确性。。
[/Quote]
恩，事务具有隔离性，自己的DML操作在COMMIT之前其他用户是看不到的。我们只看他的头像！真的好像啊。。

[kirayunfei]

[Quote=引用 17 楼 huangdh12 的回复:]
引用 13 楼 mars199 的回复:
我试过一个笨方法：写一个update，然后不去commit，这时另一个用户去select得到的结果会是我update之后的结果


这个应该不会吧。。。那还怎么保证数据的正确性。。
[/Quote]

他是说错了, 没有commit的数据都是从undo中取得的, 必然是update之前的值