consistent read（读一致性）的通俗理解

samchj

是有点区别，如果你在delete之前并没没有select到这个块的时候，你在delete的时候是没有cr block的，这两种情况下我都试过一下，你这种情况也是对的。我猜，oracle在进行delete的时候发现在buffer中有一个块存在，那它必须为它做一个cr而不能直接修改这个块，因此在b步骤中，oracle完成了xcur和cr块，xcur为了delete，cr是原来有的buffer。
嘻嘻，指教！

玉面飞龙

最初由 samchj 发布
[B]我猜，oracle在进行delete的时候发现在buffer中有一个块存在，那它必须为它做一个cr而不能直接修改这个块 [/B]

session 1:

SQL> select file#,block#,class#,xnc,status,objd,ts# from v$bh where file#=9 and
block# in (907,908);

no rows selected

SQL> select count(*) from tdump;

  COUNT(*)
----------
         9

SQL> select file#,block#,class#,xnc,status,objd,ts# from v$bh where file#=9 and
block# in (907,908);

     FILE#     BLOCK#     CLASS#        XNC STATU       OBJD        TS#
---------- ---------- ---------- ---------- ----- ---------- ----------
         9        907          4          0 xcur       30437          9
         9        908          1          0 xcur       30437          9

At this time,Session2 delete one record
then session 1 :
SQL> select file#,block#,class#,xnc,status,objd,ts# from v$bh where file#=9 and
block# in (907,908);

     FILE#     BLOCK#     CLASS#        XNC STATU       OBJD        TS#
---------- ---------- ---------- ---------- ----- ---------- ----------
         9        907          4          0 xcur       30437          9
         9        908          1          0 xcur       30437          9



Could you test your case again?

samchj

$ sqlplus '/as sysdba'

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Mar 29 10:13:32 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE    9.2.0.3.0       Production
TNS for IBM/AIX RISC System/6000: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

SQL> create user samchj identified by samchj default tablespace users temporary tablespace temp;

User created.

SQL> grant dba,connect,resource to samchj;

Grant succeeded.

SQL> conn samchj/samchj
Connected.
SQL> create table test as select * from sys.obj$ where rownum<101;

Table created.

  1* select file#,block#,class#,xnc,status,objd,ts# from v$bh where file#=4 and block# >38776
SQL> /

     FILE#     BLOCK#     CLASS#        XNC STATU       OBJD        TS#
---------- ---------- ---------- ---------- ----- ---------- ----------
         4      38777          8          0 xcur        6611          4
         4      38778          9          0 xcur        6611          4
         4      38779          4          0 xcur        6611          4
这个时候在另外的session2中执行一个选择操作：
$ sqlplus samchj/samchj

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Mar 29 10:21:20 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> select * from test where obj#=4;

................
执行完这个select后，session1

SQL> /

     FILE#     BLOCK#     CLASS#        XNC STATU       OBJD        TS#
---------- ---------- ---------- ---------- ----- ---------- ----------
         4      38777          8          0 xcur        6611          4
         4      38778          9          0 xcur        6611          4
         4      38779          4          0 xcur        6611          4
         4      38780          1          0 xcur        6611          4

注意产生了一个xcur块，38780这个块被调用到buffer中了。
到session2中执行delete：
SQL> delete from test where obj#=4;

1 row deleted.

SQL> select file#,block#,class#,xnc,status,objd,ts# from v$bh where file#=4 and block# >38776;

     FILE#     BLOCK#     CLASS#        XNC STATU       OBJD        TS#
---------- ---------- ---------- ---------- ----- ---------- ----------
         4      38777          8          0 xcur        6611          4
         4      38778          9          0 xcur        6611          4
         4      38779          4          0 xcur        6611          4
         4      38780          1          0 xcur        6611          4
         4      38780          1          0 cr          6611          4
因为没有提交，这里产生了一个cr块

玉面飞龙

你的测试是对的。不过我有了疑问，为什么delete会产生cr block哪？

tracyly

Samchi,在一致读的步骤中，有两处不太明白，能否说明一下：
1、一个交易占用几个undo块时，是从rdba读取其前一个undo块地址吗？
2、一个undo block 中的record是从后往前读的，由irb指定先读取哪一个，跟随其后读取的record number从哪里得知，是从 rci 吗？
先谢过了。

samchj

最初由 玉面飞龙 发布
[B]你的测试是对的。不过我有了疑问，为什么delete会产生cr block哪？ [/B]

session1中，只执行了select操作：         
OBJECT_NAME          STATE    DBARFIL     DBABLK BA
-------------------- ----- ---------- ---------- ----------------
TEST2                xcur           4      38787 07000000014BE000
TEST2                xcur           4      38786 0700000001C90000
TEST2                xcur           4      38788 0700000001D7A000
TEST2                xcur           4      38785 0700000001E24000

SQL> /
session1中，执行了delete操作但是没有提交：
OBJECT_NAME          STATE    DBARFIL     DBABLK BA
-------------------- ----- ---------- ---------- ----------------
TEST2                xcur           4      38787 07000000014BE000
TEST2                xcur           4      38788 0700000001C64000
TEST2                xcur           4      38786 0700000001C90000
TEST2                xcur           4      38785 0700000001E24000
TEST2                cr             4      38788 0700000001D7A000

session2中，执行一个select操作。

OBJECT_NAME          STATE    DBARFIL     DBABLK BA
-------------------- ----- ---------- ---------- ----------------
TEST2                xcur           4      38787 07000000014BE000
TEST2                xcur           4      38788 0700000001C64000
TEST2                xcur           4      38786 0700000001C90000
TEST2                xcur           4      38785 0700000001E24000
TEST2                cr             4      38788 0700000001D24000
TEST2                cr             4      38788 0700000001D7A000

从这里可以看出，当我在同一个session中执行完select/delete操作后，生成cr block的块是我在select
操作的时候被读入到buffer中的，地址为：0700000001D7A000。
然后我在session2中执行select，又有一个新的cr块产生。
因此，我认为，delete之所以产生了cr块，是为了在同一个session中的select操作产生的。我们看到这个
cr块其实是select的那个块，因此，就相当于先执行delete后执行select是同样的道理。

samchj

最初由 tracyly 发布
[B]Samchi,在一致读的步骤中，有两处不太明白，能否说明一下：
1、一个交易占用几个undo块时，是从rdba读取其前一个undo块地址吗？

不是，是在一个undo块最后的地方，也就是在第一个rec#的地方会有下一个undo的地址，请看：
Rec #0x48 slt: 0x21 objn: 6379(0x000018eb) objd: 6379 tblspc: 3(0x00000003)
* Layer: 11 (Row) opc: 1 rci 0x00
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
在类似上面的undo格式中，在Rec #0x00这个行，undo是倒序的，就会有下一个undo块的地址，你可以自己做实验验证。



2、一个undo block 中的record是从后往前读的，由irb指定先读取哪一个，跟随其后读取的record number从哪里得知，是从 rci 吗？

是的，如果rci是0x00了，就说明这是最后一个rec#。

先谢过了。 [/B]

samchj

最初由 玉面飞龙 发布
[B]你的测试是对的。不过我有了疑问，为什么delete会产生cr block哪？ [/B]

给你推荐一篇文档，很详细，你看看就很明白了，我也是因为你提的问题才找到的文档，很不错，大家都可以看看，帮助你了解一些你在课本上找不到的东西，嘻嘻！
共同提高！

jametong

下载不了了, 能不能重新上传一份啊

samchj

重新上传，为什么下载不了呢？