Oracle 學習筆記
圖解深入剖析一個事務的操作流程
這節課講一下一個事務的操作流程
内容有點難度
先簡單的看一下
一）事務ID
當一個事務開始以後
在oracle資料庫裡面針對這個事務
oracle會給它配置設定一個事務ID就是編号這個東西
簡單的做一個操作
實驗需要一個t2表，若沒有可以自己建一個
SQL> create table t2(id number,name varchar2());
Table created.
可以檢視有沒有這個表
沒有這個表的時候的結果
SQL> desc t2;
ERROR:
ORA-: object t2 does not exist
有這個表時的結果
SQL> desc t2;
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NUMBER
NAME VARCHAR2(20)
看表中有沒有資料
SQL> select * from t2;
no rows selected
這時沒有資料，插入一行資料
insert into t2 values(1,’xkj’);
這個指令一執行就開始一個事務
執行以前先查一下，
目前資料庫沒有任何的操作，應該沒有任何的事務
SQL> select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction;
no rows selected
目前結果是空的
然後去執行一下
SQL> insert into t2 values(,'xkj');
row created.
這時應該開始一個事務了
再查一下系統中的事務
SQL> select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction;
XID XIDUSN XIDSLOT XIDSQN UBABLK UBAFIL
---------------- ---------- ---------- ---------- ---------- ----------
02001C009E010000 2 28 414 580 2
這是一個事務開始以後的結果
這個時候
oracle配置設定了一個XID（transaction identifier）既：事務編号
這是事務唯一的一個編号，像身份證一樣
一個事務開始以後，oracle會給它配置設定一個事務ID
二）事務表
再看一下有一個叫事務表的概念
undo表空間有undo段，undo段有第一個資料塊
oracle的undo表空間的undo段的第一個資料塊裡面放着一個事務表
這個事務表鑒于這個塊的大小最多可以放47個事務
在undo表空間裡面的一個undo段
第一個塊叫undo段的段頭塊
在這個段頭塊裡面有一個事務表
這個事務表最多有47行
每一行放一個事務
一個事務開始以後
首先來講oracle給它配置設定了一個XID事務編号
這個時候這個事務會做的第一件事
就是在undo表空間裡面找一個undo段
在undo段的段頭塊裡面有事務表，事務表有47行
找其中一行把自己的事務資訊寫上，至少把XID寫上
就是找一個空行将自己的資訊寫上
就是說
一個undo段最多可以同時有47個活動事務
意味着47個活動事務共用這一個段
第一、oracle盡量的一個事務使用一個復原段
第二、如果說事務太多復原段太少，這時會出現多個事務使用一個復原段的情況
第三、oracle盡量的均勻的将活動的事務分布在各個復原段上
事務表在undo段的第一個資料塊，每一個復原段最多可以同時有47個活動事務
三）復原段段頭塊
可以把復原段段頭塊給大家看一下
select * from v$rollname;
這個語句看有多少個復原段
執行一下
SQL> select * from v$rollname;
USN NAME
---------- ------------------------------
SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU1$
rows selected.
目前有這麼多的復原段，根據undo表空間負載情況系統會根據情況自動增加undo段數目
将一個復原段的名字複制一下，如：_SYSSMU1$
複制進指令
select header_block,header_file from dba_segments where segment_name=’_SYSSMU1$’;
這個語句可以看到這個復原段的段頭塊的位址
SQL> select header_block,header_file from dba_segments where segment_name='_SYSSMU1$';
HEADER_BLOCK HEADER_FILE
------------ -----------
位址是2号檔案的第9個塊
接着可以把段頭塊給dump出來
語句
alter system dump undo header ‘_SYSSMU1$’;
可以将_SYSSMU1$段的段頭塊dump出來
dump出來以後就可以去vi去看
dump一下試試
SQL> alter system dump undo header '_SYSSMU1$';
System altered.
dump成功了
我們去看一下它dump哪個檔案去了
檢視目前會話的程序編号語句
select spid from v$process where addr in (select paddr from v$session where
sid=(select sid from v$mystat where rownum=1));
執行結果
SQL> select spid from v$process where addr in (select paddr from v$session where
sid=(select sid from v$mystat where rownum=));
SPID
------------
得到目前會話所對應的server process的程序ID号
剛才dump出來的資料
dump出的段頭的資訊就寫到一個檔案裡面去
這個檔案的命名就以serverprocess的編号命名
我們去找一下，記住21978
先退出目前會話
SQL> exit
Disconnected from Oracle Database g Enterprise Edition Release - Production
With the Partitioning, OLAP and Data Mining options
進入目錄
[oracle@redhat4 ~]$ cd $ORACLE_BASE
[oracle@redhat4 oracle]$ cd admin
[oracle@redhat4 admin]$ ls
jiagulun
[oracle@redhat4 admin]$ cd jiagulun/
[oracle@redhat4 jiagulun]$ ls
adump bdump cdump dpdump pfile udump
這裡有一個udump目錄
[oracle@redhat4 jiagulun]$ cd udump/
最終路徑
[oracle@redhat4 udump]$ pwd
/u01/app/oracle/admin/jiagulun/udump
[oracle@redhat4 udump]$ ls **
jiagulun_ora_21978.trc
看到路徑下有一個jiagulun_ora_21978.trc檔案
這個檔案裡面就是我們dump出來的這個復原段段頭的資訊
vi一下這個檔案
[oracle@redhat4 udump]$ vi jiagulun_ora_21978.trc
檔案内容：
/u01/app/oracle/admin/jiagulun/udump/jiagulun_ora_21978.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: redhat4
Release: 2.6.9-78.ELsmp
Version: #1 SMP Wed Jul 9 15:39:47 EDT 2008
Machine: i686
Instance name: jiagulun
Redo thread mounted by this instance: 1
Oracle process number: 28
Unix process pid: 21978, image: [email protected] (TNS V1-V3)
*** 2017-08-03 10:16:01.750
*** SERVICE NAME:(SYS$USERS) 2017-08-03 10:16:01.750
*** SESSION ID:(145.3581) 2017-08-03 10:16:01.750
********************************************************************************
Undo Segment: _SYSSMU1$ (1)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 4 #blocks: 271
last map 0x00000000 #maps: 0 offset: 4080
Highwater:: 0x008003c9 ext#: 2 blk#: 64 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 2
Unlocked
Map Header:: next 0x00000000 #extents: 4 obj#: 0 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x0080000a length: 7
0x00800011 length: 8
0x00800389 length: 128
0x00800589 length: 128
Retention Table
-----------------------------------------------------------
Extent Number:0 Commit Time: 1501725693
Extent Number:1 Commit Time: 1501725693
Extent Number:2 Commit Time: 1501725693
Extent Number:3 Commit Time: 1501725693
TRN CTL:: seq: 0x0100 chd: 0x0012 ctl: 0x0018 inc: 0x00000000 nfb: 0x0001
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x008003c9.0100.04 scn: 0x0000.000c07e1
Version: 0x01
FREE BLOCK POOL::
uba: 0x008003c9.0100.04 ext: 0x2 spc: 0x1d72
uba: 0x00000000.00fd.05 ext: 0x2 spc: 0xe94
uba: 0x00000000.00fa.02 ext: 0x2 spc: 0x1e86
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
TRN TBL::
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x013d 0x0007 0x0000.000c138c 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725703
0x01 9 0x00 0x013d 0x0006 0x0000.000c13aa 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725704
0x02 9 0x00 0x013d 0x0005 0x0000.000c146b 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725963
0x03 9 0x00 0x013d 0x0011 0x0000.000c150f 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726182
0x04 9 0x00 0x013d 0x0009 0x0000.000c1409 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725879
0x05 9 0x00 0x013d 0x000d 0x0000.000c1487 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501726008
0x06 9 0x00 0x013d 0x0004 0x0000.000c13cb 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725768
0x07 9 0x00 0x013d 0x0001 0x0000.000c139a 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725703
0x08 9 0x00 0x013d 0x000a 0x0000.000c1578 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x09 9 0x00 0x013d 0x0002 0x0000.000c1450 0x008003c3 0x0000.000.00000000 0x00000001 0x00000000 1501725963
0x0a 9 0x00 0x013c 0x001c 0x0000.000c1588 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x0b 9 0x00 0x013d 0x0017 0x0000.000c15b2 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x0c 9 0x00 0x013d 0x0018 0x0000.000c169e 0x008003c9 0x0000.000.00000000 0x00000001 0x00000000 1501726418
0x0d 9 0x00 0x013d 0x002f 0x0000.000c14a9 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 1501726044
0x0e 9 0x00 0x013d 0x0014 0x0000.000c15f2 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x0f 9 0x00 0x013d 0x0003 0x0000.000c14e5 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726128
0x10 9 0x00 0x013d 0x0008 0x0000.000c155b 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x11 9 0x00 0x013d 0x0010 0x0000.000c1542 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726278
0x12 9 0x00 0x013c 0x001f 0x0000.000c080e 0x008005dc 0x0000.000.00000000 0x00000002 0x00000000 1501725104
0x13 9 0x00 0x013d 0x001e 0x0000.000c1622 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x14 9 0x00 0x013d 0x0013 0x0000.000c160f 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x15 9 0x00 0x013c 0x0028 0x0000.000c08c0 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725247
0x16 9 0x00 0x013d 0x0022 0x0000.000c1647 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726288
0x17 9 0x00 0x013d 0x000e 0x0000.000c15de 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x18 9 0x00 0x013d 0xffff 0x0000.000c16e1 0x008003c9 0x0000.000.00000000 0x00000001 0x00000000 1501726548
0x19 9 0x00 0x013c 0x0023 0x0000.000c08df 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725247
0x1a 9 0x00 0x013c 0x0020 0x0000.000c085a 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725148
0x1b 9 0x00 0x013c 0x001d 0x0000.000c091a 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725313
0x1c 9 0x00 0x013d 0x000b 0x0000.000c15a1 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x1d 9 0x00 0x013b 0x0026 0x0000.000c0930 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725313
0x1e 9 0x00 0x013d 0x0016 0x0000.000c162e 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726279
0x1f 9 0x00 0x013c 0x001a 0x0000.000c0835 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725148
0x20 9 0x00 0x013c 0x0021 0x0000.000c0874 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725183
0x21 9 0x00 0x013c 0x0015 0x0000.000c08b0 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725247
0x22 9 0x00 0x013d 0x000c 0x0000.000c167c 0x008003c8 0x0000.000.00000000 0x00000005 0x00000000 1501726374
0x23 9 0x00 0x013c 0x001b 0x0000.000c0905 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725282
0x24 9 0x00 0x013c 0x002d 0x0000.000c09a8 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725492
0x25 9 0x00 0x013c 0x0000 0x0000.000c0b99 0x008003c2 0x0000.000.00000000 0x00000075 0x00000000 1501725693
0x26 9 0x00 0x013c 0x0024 0x0000.000c0975 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725408
0x27 9 0x00 0x013c 0x002e 0x0000.000c0a04 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725638
0x28 9 0x00 0x013c 0x0019 0x0000.000c08d3 0x008005dc 0x0000.000.00000000 0x00000001 0x00000000 1501725247
0x29 9 0x00 0x013c 0x002b 0x0000.000c0a50 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725679
0x2a 9 0x00 0x013c 0x0029 0x0000.000c0a26 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725638
0x2b 9 0x00 0x013c 0x002c 0x0000.000c0a68 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725679
0x2c 9 0x00 0x013c 0x0025 0x0000.000c0a76 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725679
0x2d 9 0x00 0x013c 0x0027 0x0000.000c09e6 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725573
0x2e 9 0x00 0x013c 0x002a 0x0000.000c0a13 0x008005dd 0x0000.000.00000000 0x00000001 0x00000000 1501725638
0x2f 9 0x00 0x013c 0x000f 0x0000.000c14d6 0x008003c4 0x0000.000.00000000 0x00000001 0x00000000 1501726119
這就是資訊
關于這個段頭可以去讀裡面相關的資訊
如：
********************************************************************************
Undo Segment: _SYSSMU1$ (1)
********************************************************************************
部分說明是哪個復原段
裡面有一些區的資訊
如：
Extent Control Header
-----------------------------------------------------------------
Extent Map
-----------------------------------------------------------------
Retention Table
-----------------------------------------------------------
最後面的部分
TRN TBL::後面
是事務表
剛才給大家講了一個操作
如何把塊給dump出來，然後再去看
除了dump出來dump段頭塊以外
我們單獨的去dump出來某個資料塊也可以
如：
alter system dump datafile 5 block 4308;//轉儲資料塊
把某個檔案的某個塊dump出來
關于
alter system dump undo header ‘_SYSSMU1$’;//轉儲復原段頭
轉儲復原段段頭塊，轉儲出來以後如何去細細的解讀
會作為以後的一個進階課程，去講段頭塊裡面的一些細節
我們回顧一下剛才講的内容
Undo段的組成：段頭、復原塊
事務ID
select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction;
事務表
undo段的第一個資料塊，每一個復原段最多可以47個事務
復原段的段頭塊
select * from v$rollname;
select header_block,header_file from dba_segments where segment_name=’_SYSSMU1$’;
alter system dump undo header ‘_SYSSMU1$’;//轉儲復原段頭
alter system dump datafile 5 block 4308;//轉儲復原段資料塊
四）undo資訊的位置
執行個體中有三個地方有undo資訊
Undo Segment Header 復原段段頭
Data block header 資料塊頭
Undo block 復原塊
已下面的語句為例：
Begin transaction
T1:update table set column=' value' where id=;
T2:update table set column=' value' where id=;
T3:update table set column=' value' where id=;
Commit;
開始一個事務
然後這個事務做了三個操作
不管怎麼說開始一個事務了
Undo Segment Header是undo段的段頭塊
開始一個事務首先找到一個復原段
找到復原段以後就在復原段的段頭塊的事務表裡面将我的事務資訊寫上
然後一個事務開始了
一個事務開始做的第一個事情
在undo段的段頭塊的事務表裡面找一個空槽控制槽位
把事務資訊寫上
事務的基礎還有一個：事務槽
一個事務可能修改一個資料塊，在資料塊塊的頭部有事務槽
一個事務可以修改多個資料塊
一個資料塊有多個事務槽，可以有1到255個
修改一個資料塊，首先這個事務要
在這個資料塊的頭部的事務槽的位置找一個事務槽一個空槽将我的事務資訊寫上
一個事務開始以後
首先在復原段的段頭塊的事務表裡面寫上一行事務資訊
第二個在那個要修改的資料塊的塊的頭部的事務槽裡面也要寫上事務資訊
目前為止我們發現一個事情
一個事務開始以後至少要在兩個位置，不是說兩個具體地方是在兩個位置
一個位置是復原段的段頭塊的事務表裡面寫上事務資訊
第二個位置在要修改的資料塊裡面還要寫上事務資訊
事務資訊為什麼要在兩個地方
和oracle事務的一種送出方式有關
事務表是在undo復原段的段頭塊裡面
事務槽在具體的資料塊裡面，比如要修改的某個資料塊
事務槽也可以dump出來vi去看
需要把資料塊dump出來看其中的事務槽
事務表、事務槽講了，還有個UBA（undo block address）
是undo資料塊的位址
第一個是在復原段的段頭塊裡面事務表
第二個事務槽是我們要修改的那個資料塊，塊的頭部有事務槽
第三個叫復原塊 我要修改這個資料塊的時候
我會做一件事情，把要修改前的資料存起來，存到復原塊裡面去
復原塊是實實在在的存復原資料的
事務表和事務槽都是存事務資訊的
是以說復原塊會有很多
講了復原塊、事務表、事務槽三個概念
五）事務表、事務槽、復原塊關系
一個事務開始的時候首先oracle做一件事情
在undo表空間裡面找一個相對空閑的undo段
然後在undo表空間裡面一個相對空閑的undo段的段頭塊的事務表裡面
找其中的一個槽位
找到裡面一個槽位以後，将自己的事務資訊寫上，寫到這個槽位上
同時在Undo Segment Header做完後
其實oralce還會給這個事務配置設定一個undo塊
因為一個事務開始以後
隻是在undo復原段段頭的事務表裡面配置設定一個槽位，不夠
還要給他配置設定一個undo塊，這個undo塊實實在在的寫資料
同時将undo塊的位址寫到事務表裡面去
第一步找復原段，段頭，段頭裡面找到事務表
事務表裡面将xid寫上
同時還要在復原段裡面配置設定一個空塊
這個空塊要給oracle寫復原資料
事務表的槽位裡面除了寫xid以外還要寫UBA位址
就是所配置設定的一個復原塊位址
第二步要實實在在的修改資料了
要修改某個資料塊
首先在要修改的資料塊的頭部事務槽裡面又找到一個槽位
把XID（事務id）寫上
這個事務id既是一個編号也是一個位址
會寫到我要修改的資料塊的事務槽裡面去
接着修改裡面的資料
比如修改了三行資料
修改資料以後，我就需要把修改前的資料儲存到undo塊裡面去
針對這個事務的undo塊已配置設定了
就把修改前的資料寫到undo塊裡面去
同時資料塊事務槽裡面也有uba位址，它指向復原塊
描述到目前為止就有點脈絡了
六）Xid
我們再來剖析一下Xid（transaction identifier 或 Transaction ID）
事務的Xid既是事務編号也是個位址
它代表着這個事務用哪個復原段
首先它在段的頭部，還有使用哪個復原段，使用哪個段頭塊
xid裡面寫的資訊
第一個、
使用了哪個復原段的段頭塊
第二個、
段頭塊事務表裡面有47行，使用的哪一行
第三個、
所用槽位是第幾次被使用
回過來看看事務表
一個事務表有47行
第一個因素xid是使用哪個復原段的段頭塊
找到這個塊了有一個復原段段的編号
第二個事務表裡有47行
找到事務表裡的哪一行
這兩個都确定以後
可以确認是一行了
但不能唯一的确認是這一行
這個事務表裡的47行可能被覆寫了多次
是第幾次覆寫，比如第十次覆寫
塊号行号加上是第10次覆寫
可以唯一的标志某一行
舉例講
對我們來講事務是唯一的
事務編号也是唯一的
假設沒有第3部分會出現
第一個事務A事務
用了2号段頭的第13行
用完了以後送出了，送出了以後就可以被覆寫了
過了很長時間
有可能B事務也是用了2号段的第13行
如果xid中使用復原段的段号和事務表中的行号這兩個資訊
如果唯一的辨別事務id的話
就會出現兩個事務事務id一樣
加上一個覆寫的次數
比如A事務是第一次覆寫，而B事務是第13次覆寫或第14次覆寫
這三個資訊和起來
就可以唯一的組成事務的id，即XID
是以說xid由三塊組成
塊号 行号 和 覆寫次數
包括第幾次被repeat被循環使用
通過xid事務id可以找到事務表
七）事務流程中的事務資訊
回顧一下
第一步、
一個事務開始oracle做的第一件事情
在undo表空間裡找一個相對空閑的undo段
找到undo段的段頭塊裡的事務表
在事務表裡面找到其中一行，把事務資訊寫上
除了在事務表裡面找到一個槽位
還要在這個復原段裡面找到一個undo塊
讓它事務表中的槽位指向這個塊
第二步、
我要修改具體的資料塊
要修改資料塊的時候
首先在資料塊的頭部的事務槽裡面找一行
然後要修改資料塊的事務槽裡面把xid寫上
這個事務編号就指向undo段頭部的事務表中的那個記錄
因為xid是位址，通過位址可以找到事務表
第三步、
然後對資料塊進行修改
如：
修改了1行2行3行4行5行
修改了5行
然後它把這5行資訊寫到復原塊裡面去
同時資料塊的事務槽有位址指向這個復原塊
這個事務我修改了一個塊，還可以修改第二個塊
一個事務可以修改多個塊
同樣的這個事務修改的資料塊頭部有事務槽
把資料塊頭部事務槽指向undo段頭部的事務表中的那個事務記錄
然後在第二個資料塊中修改
修改的時候這個復原塊滿了
再配置設定一個復原塊
然後把資料塊的修改資訊寫進去
第二個資料塊頭部的事務槽又指向新的復原塊
這兩個復原塊有先後關系
有最早的復原資訊和最新的復原資訊
新的復原塊指向早的復原塊把這兩個復原塊鍊起來
就是新的復原塊有個連結指向老的復原塊
也就是找到最新的復原資訊可以依次向前推
這時事務表裡面的uba就指向這個事務最新的復原塊
當然可以再繼續加修改、修改……
每個資料塊指向自己對應修改時最新的復原塊
最新修改的資料塊中事務uba指向最新的復原塊
八）UBA的指向
undo段段頭有事務表
段頭裡面有XID還有UBA
段頭事務表中事務的uba指向最新的undo段
比如一個事務産生有三個復原塊
因為我這個事務修改了很多資料
可能産生了很多個復原塊
有最新的復原塊，有其次新的，有最老的復原塊
一個事務的復原塊自動地它們串起來了
我們知道資料塊塊的頭部
都有個xid使資料塊指向事務表
一個事務的所有資料塊頭部的xid都指向事務表中的一行資料
修改的某一個資料塊
修改前的資料放到了一個復原塊裡面
各個資料塊裡面的uba都指向各自修改時的復原塊
一個事務對應undo段頭的uba指向最後一個最新的那個復原塊
有這兩種UBA的原因：
1）事務表中的UBA作用
假設一個事務修改三個資料塊塊
先修改了第一個塊，再修改第二個塊，又修改了第三個塊
要復原的時候
要先把第三個塊的資料復原回去，再把第二個塊的資料復原回去
先修改了産生1号塊，再修改産生2号塊，再修改産生3号塊
修改的順序1、2、3
要復原的時候
把3号復原塊中的資料先復原回去，再復原2号，再復原1号
修改的時候從1、2到3
復原的時候逆着復原
undo段頭事務表中這個事務uba指向最新的復原塊
要復原的時候，根據事務表中的uba找到最新的
先把最新的復原塊復原了
因為最新的復原塊有個位址指向前一個復原塊，這裡指向了第二個
再把第二個復原塊復原了
第二個復原塊又指向了第一個復原塊
這裡再把最早的一個復原塊復原了
復原完以後，第一個復原塊不指向任何塊了
表示這個事務復原完了
oracle做rollback的時候
會這樣做：
首先在事務表裡找到這個要復原的事務
然後找到uba，再找到最新的復原塊把對應資料塊復原了
然後使用前一個復原塊把它對應的資料塊復原了
然後再使用最早的復原塊把它對應的資料塊復原了
這樣就復原完了，rollback成功了
例中三個復原塊串起來
undo段頭事務表中的對應事務記錄指向最後的undo block
是有道理的
2）事務槽中UBA作用
資料塊中的事務槽中有一個位址指向一個復原塊
有直接指向的意義
資料塊資料槽中的uba直接指向復原塊
是資料塊實實在在的指向它自己的復原資料
一個資料塊要找復原資料的話
第一種辦法、
可以直接找過來，從資料塊的事務槽uba資訊直接找到復原塊
第二個辦法、
從資料塊找到undo段頭事務表中對應的事務資訊，再過來找到undo塊也可以
因為從資料塊找到事務表再找到undo塊一個鍊也可以找到
資料塊單獨有位址指向復原資料，這個鍊短
在要進行cr讀、讀一緻性的時候有好處
讀資料塊的時候發現這個塊有未送出事務，就需要構造cr塊
就找一個空塊把資料塊和undo塊資訊兩個合起來，拼成一個新塊，然後讀這個塊
如果這個資料塊直接寫上對應undo塊位址的話
直接讀資料塊和對應的復原塊兩個塊就可以了，就可以拼一個cr塊
不需要再讀段頭了
在資料塊裡面直接寫上uba位址指向自己的復原資料
将來對cr讀非常有幫助，也有意義
九）事務資訊的鍊的意義
undo segment header 和 data block header 和 Undo block
的事務資訊之間有很多的鍊，有很多的位址
它們的意義：
1、rollback
在復原段的段頭塊裡面有事務有事務資訊和uba位址
事務表uba位址指向該事務最後一個undo塊
最後一個undo塊又串着前一個undo塊又向前串着上一個undo塊
意義主要是為rollback復原做準備
2、cr讀
資料塊的事務槽有uba直接指向undo塊復原資料
是為了一緻性讀cr做準備
3、快速送出
資料塊xid還要指向undo段頭的事務表
此意義下節課講，先簡單的描述一下就是
如果一個事務快速送出時未清理這個事務對應資料塊事務槽中的相關資訊，
再有其它操作需要修改這個資料塊中前面這個事務已修改的資料時，在事務槽不能确定這個事務的送出狀态
就需要通過這個事務槽找到這個事務在事務表中對應的行，來最終确定前面這個事務的送出狀态
是以需要這種指向鍊
十）總結
上面講了一個事務改變過程
我們再來描述一下這個事務的修改過程
第一步、
一個事務開始
首先在undo表空間裡面相對空閑的undo段的段頭塊的事務表裡面找一行資訊，将自己的xid寫上
同時在undo段裡面配置設定一個空塊，復原塊
同時将復原塊的位址寫到事務表裡的事務槽裡面去
在undo裡面操作完成
第二步、
要修改具體的資料塊
修改任何一個資料塊都是要在資料塊塊的頭部擷取到一個事務槽
然後将xid寫上就是将事務id寫上
擷取到事務槽就開始修改資料塊
修改資料塊的時候
還将修改前的資料寫到復原塊裡面去
因為這個事務已經被配置設定一個復原塊了，就直接寫到復原塊裡面去
同時将這個資料塊所對應的復原塊的位址也寫到事務槽裡面去
復原資料寫完了，接下來修改實實在在的行
第一個資料塊修改完了
再修改第二個資料塊
同樣的操作，再修改第三個資料塊
同時如果這個時候一個復原塊不夠以後
要配置設定第二個第三個復原塊
復原塊和復原塊之間要串起來
最老的復原塊串其次新的再串最新的
同時如果你加了復原塊了
會把最新的復原塊資訊寫到事務表裡面去
這是整個事務的操作流程
同時我們也知道了
這三個復原塊串起來
以及事務表的uba指向最新的復原塊有意義是為了復原
在每個資料塊裡面
直接寫uba指向自己的undo資料也是有意義的是為了構造cr塊
一個事務資訊在兩個地方都有
事務塊裡面也有，事務表裡面也有
資料塊裡面的事務槽指向undo段頭的事務表
這個和oracle的一種送出方式有關，下節課講
在這個過程中
一個事務開始以後
oracle修改了四個地方
第一個
復原段的段頭塊的事務表被修改了
第二個
復原塊被修改了
第三個
資料塊的事務槽被修改了
第四個
資料塊裡面實實在在的資料行被修改了
有4個地方被修改了
這四個地方的資料都在資料塊裡面
資料塊的任何地方的改變都會産生redo
在剛才整個過程裡面
這四個地方被修改都産生redo
redo不僅僅記錄的是資料行的改變
事務槽的改變undo塊的改變事務表的改變一樣都會産生redo
這就是一個事務的一個操作流程
也講了怎麼轉儲復原段頭、轉儲復原段資料塊，怎麼去看
2017年8月25日
文字：韻筝
![android SQLite事務和kotlin協程[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)