oracle的事务与锁与回滚段 的block 的一点摸索

muhaook

最初由 biti_rainy 发布
[B]是因为 我想到 当多个 事务同时 更新一个块上的不同记录的时候

其中一个提交之后
server  crash 掉

做恢复的时候
oracle在前滚，回滚的过程中 值得探究
我观察了这些 dirty  block的更新变化
发现如果回滚段中对于 一个 block 只有一个before  image
那么oracle不能回滚到 不丢失 数据状态！
[/B]

对你的钻研精神表示钦佩!
另外，我觉得在以上的恢复过程中，即使存在相当多的before image ， 也不能回滚到不丢失数据的状态。
因为几个事务是同时对一个数据块中的数据进行更改的，以ORACLE目前的回滚机制，应该无法做到保存一个事务的改动而回滚同时发生的另一个事务的改动。
只代表我的观点。

biti_rainy

最初由 muhaook 发布
[B]

对你的钻研精神表示钦佩!
另外，我觉得在以上的恢复过程中，即使存在相当多的before image ， 也不能回滚到不丢失数据的状态。
因为几个事务是同时对一个数据块中的数据进行更改的，以ORACLE目前的回滚机制，应该无法做到保存一个事务的改动而回滚同时发生的另一个事务的改动。
只代表我的观点。 [/B]

假如存在顺序未提交事务 a,b,c

分别存在before  image a1,b1,c1

a1 是原始数据
b1包含了a 的改变
c1包含了a和b的改变

就算提交了任何一个 事务  的数据
也可以通过before  image 的数据来回滚


这里要提醒注意的一点是：

回滚不是用 回滚段中的block 去替换 datafile 中的block
如果是这样那肯定无法  恢复  到不丢失数据状态

回滚，是 DML 的逆操作

也就是
insert ----  delete
delete --- insert
update-----update

muhaook

最初由 biti_rainy 发布
[B]

假如存在顺序未提交事务 a,b,c

分别存在before  image a1,b1,c1

a1 是原始数据
b1包含了a 的改变
c1包含了a和b的改变

就算提交了任何一个 事务  的数据
也可以通过before  image 的数据来回滚


这里要提醒注意的一点是：

回滚不是用 回滚段中的block 去替换 datafile 中的block
如果是这样那肯定无法  恢复  到不丢失数据状态

回滚，是 DML 的逆操作

也就是
insert ----  delete
delete --- insert
update-----update [/B]

能否详细说明一下：如果回滚事务B，如何通过3个before image回滚？

biti_rainy

记录了  事务 b 所涉及到的 数据的变化
假如不存在事务c,则这个变化存在于我们通常所说的 dirty  buffer 中(事务c所导致的变化就在 dirty buffer 中 )

通过比较  c1  和 b1 就能找出  发生了变化的数据的 after  iamge and  before  image
这个变化的数据就是 事务b 所改变的数据
c1 中是改变后的状态，b1中是改变前的状态

在 c1 中记录了 事务b涉及到的数据，通过类似如下信息：

scn: 0x0000.000982e5 seq: 0x06 flg: 0x00 tail: 0x82e50606
0x01 xid: 0x0002.022.000000be uba: 0x008010c4.00cd.0c

在数据的每一行中，实际改变的行 还有这个标记：

tab 0, row 2, @0x1fa0
tl: 6 fb: --H-FL-- lb: 0x1  (这里就是表示该块上的事务槽编号，总数量跟 maxtrans 和 block 大小涉及的容量  有关 ) cc: 1
col 0: [ 2] c2 02


于是就可以把 事务 b 改变的这些数据 恢复 到改变前的状态

muhaook

谢谢 很有帮助!

大侠可否提供block，segment的详细物理结构，如果有的话 ^^

小段探花

SQL>CREATE TABLE A AS
  SELECT ROWNUM A FROM DICT WHERE ROWNUM<100;

表已创建。

SQL> SELECT COUNT(*) FROM A;

  COUNT(*)
----------
        99

SQL> ALTER TABLE A INITRANS 5
  2  /

表已更改。

SQL> UPDATE A SET A=100 WHERE A IN (1,3,5,7,9);

已更新5行。

SQL> SELECT FILE_ID,EXTENT_ID,BLOCK_ID,BLOCKS FROM DBA_EXTENTS WHERE SEGMENT_NAME='A';

   FILE_ID  EXTENT_ID   BLOCK_ID     BLOCKS
---------- ---------- ---------- ----------
        11          0       9753         16

SQL> alter system dump datafile 11 block 9753;

系统已更改。

*** 2003-03-19 12:37:11.000
*** SESSION ID18.1369) 2003-03-19 12:37:11.000
Start dump data blocks tsn: 12 file#: 11 minblk 9753 maxblk 9753
buffer tsn: 12 rdba: 0x02c02619 (11/9753)
scn: 0x0000.0691ed65 seq: 0x01 flg: 0x00 tail: 0xed651001
frmt: 0x02 chkval: 0x0000 type: 0x10=DATA SEGMENT HEADER - UNLIMITED
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 1      #blocks: 15   
                  last map  0x00000000  #maps: 0      offset: 4128  
      Highwater::  0x02c0261b  ext#: 0      blk#: 1      ext size: 15   
  #blocks in seg. hdr's freelists: 1     
  #blocks below: 1     
  mapblk  0x00000000  offset: 0     
                   Unlocked
     Map Header:: next  0x00000000  #extents: 1    obj#: 32737  flag: 0x40000000
  Extent Map
  -----------------------------------------------------------------
   0x02c0261a  length: 15   
  
  nfl = 1, nfb = 1 typ = 1 nxf = 1 ccnt = 0
  SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000
  XCT LST:: flg: USED   lhd: 0x02c0261a ltl: 0x02c0261a xid: 0x0001.00a.00001d42
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 1      #blocks: 15   
                  last map  0x00000000  #maps: 0      offset: 4128  
      Highwater::  0x02c0261b  ext#: 0      blk#: 1      ext size: 15   
  #blocks in seg. hdr's freelists: 1     
  #blocks below: 1     
  mapblk  0x00000000  offset: 0     
                   Unlocked
     Map Header:: next  0x00000000  #extents: 1    obj#: 32737  flag: 0x40000000
  Extent Map
  -----------------------------------------------------------------
   0x02c0261a  length: 15   
  
  nfl = 1, nfb = 1 typ = 1 nxf = 1 ccnt = 0
  SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000
  XCT LST:: flg: USED   lhd: 0x02c0261a ltl: 0x02c0261a xid: 0x0001.00a.00001d42
End dump data blocks tsn: 12 file#: 11 minblk 9753 maxblk 9753

我做到这里，后面的“数据中的内容”就不知道如何看了？

小段探花

对了
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
CORE    9.2.0.1.0       Production
TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

eygle

你的一个区，从9753开始，共 16 个数据块

除了头块就是数据块了
alter system dump datafile 11 block 9754;
这里面就应该是数据了，试试看。

Yong Huang

最初由 Yong Huang 发布
[B]

Only at commit is an SCN assigned (except in the rare case when the sequence following the SCN in a block dump is exhausted and wraps, as Steve Adam's article you cited points out). It's not that each DML in a transaction is given an SCN. Some people even call SCN system commit number instead of system change number.

Yong Huang [/B]

I did some test and find my above statement is wrong. biti_rainy is correct. SCNs are assigned on each DML that create a transaction (Not all DMLs create transactions; e.g. update mytab set mycol=1 where mycol=2 will not if there's no row where mycol=2).

I apologize for the error.

Yong Huang

小段探花

很佩服Yong Huang和biti_rainy ，以后想你们学习