在oracle資料庫中，undo主要有三大作用：提供一致性讀（consistent read）、回滾事務（rollback
transaction）以及例項恢復（instance recovery）。
一致性讀是相對於髒讀（dirty
read）而言的。假設某個表t中有10000條記錄，獲取所有記錄需要15分鐘時間。當前時間為9點整，某使用者a發出一條查詢語句：select * from
t，該語句在9點15分時執行完畢。當使用者a執行該sql語句到9點10分的時候，另外乙個使用者b發出了一條delete命令，將t表中的最後一條記錄刪除並提交了。那麼到9點15分時，a使用者將返回多少條記錄？
如果返回9999條記錄，則說明發生了髒讀；如果仍然返回10000條記錄，則說明發生了一致性讀。很明顯，在
9點鐘那個時間點發出查詢語句時，表t中確實有10000條記錄，只不過由於i/o的相對較慢，所以才會花15分鐘完成所有記錄的檢索。對於oracle
資料庫來說，沒有辦法實現髒讀，必須提供一致性讀，並且該一致性讀是在沒有阻塞使用者的dml的前提下實現的。
那麼undo資料是如何實現一致性讀的呢？還是針對上面的例子。使用者a在9點發出查詢語句時，伺服器程序會將9
點那個時間點上的scn號記錄下來，假設該scn號為scn9.00。那麼9點整的時刻的scn9.00一定大於等於記錄在所有資料塊頭部的itl槽中的
scn號（如果有多個itl槽，則為其中最大的那個scn號）。
注:itl（
interested transaction
list）
是oracle資料塊內部的乙個組成部分，用來記錄該塊所有發生的事務，乙個itl可以看作是乙個記錄，在乙個時間，可以記錄乙個事務（包括提交或者未提交事務）。當然，如果這個事務已經提交，那麼這個itl的位置就可以被反覆使用了，因為itl類似記錄，所以，有的時候也叫itl槽位。
伺服器程序在掃瞄表t的資料塊時，會把掃瞄到的資料塊頭部的itl槽中的scn號與scn9:00之間進行比較，哪個更大。如果資料塊頭部的scn號比scn9.00要小，則說明該資料塊在9點以後沒有被更新，可以直接讀取其中的資料；否則，如果資料塊itl槽的scn號比scn9.00要大，則說明該資料塊在9點以後被更新了，該塊裡的資料已經不是9點那個時間點的資料了，於是要借助undo塊。
9點10分，b使用者更新了表t的最後一條記錄並提交（注意，在這裡，提交或者不提交並不是關鍵，只要使用者b更新了表t，使用者a就會去讀undo資料塊）。假設被更新記錄屬於n號資料塊。那麼這個時候n號資料塊頭部的itl槽的scn號就被改為scn9.10。當伺服器程序掃瞄到被更新的資料塊（也就是n號塊）時，發現其itl槽中的scn9.10大於發出查詢時的scn9.00，說明該資料塊在9點以後被更新了。於是伺服器程序到n號塊的頭部，找到scn9.10所在的itl槽。由於itl槽中記錄了對應的undo塊的位址，於是根據該位址找到undo塊，將
undo塊中的被修改前的資料取出，再結合n號塊裡的資料行，從而構建出9點10分被更新之前的那個時間點的資料塊內容，這樣的資料塊叫做cr塊（consistent
read）。對於delete來說，其undo資訊就是insert，也就是說該構建出來的cr塊中就插入了被刪除的那條記錄。隨後，伺服器程序掃瞄該
cr塊，從而返回正確的10000條記錄。
讓我們繼續把問題複雜化。假設在9點10分b使用者刪除了最後一條記錄並提交以後，緊跟著9點11分，c使用者在同乙個資料塊裡（也就是n號塊）插入了2條記錄。這個時候oracle又是如何實現一致性讀的呢（假設表t的initrans為1，也就是只有乙個itl
槽）？因為我們已經知道，事務需要使用itl槽，只要該事務提交或回滾，該itl槽就能夠被重用。換句話說，該itl槽裡記錄的已經是scn9.11，而不是scn9.10了。這時，itl槽被覆蓋了，oracle的伺服器程序又怎能找回最初的資料呢？
其中的秘密就在於，oracle在記錄undo資料的時候，不僅記錄了改變前的資料，還記錄了改變前的資料所在的資料塊頭部的itl資訊。因此，9點10分b使用者刪除記錄時（位於n號塊裡，並假設該n號塊的itl資訊為[undo_block0
/ scn8.50]），則oracle會將改變前的資料（也就是insert）放到undo塊（假設該undo塊位址為undo_block1）裡，同時在該undo塊裡記錄刪除前itl槽的資訊（也就是[undo_block0
/ scn8.50]）。刪除記錄以後，該n號塊的itl資訊變為 [undo_block1 /
scn9.10]；到了9點11分，c使用者又在n號塊裡插入了兩條記錄，則oracle將插入前的資料（也就是delete兩條記錄）放到undo塊（假設該undo塊的位址為undo_block2）裡，並將9點11分時的itl槽的資訊（也就是[undo_block1
/ scn9.10]）也記錄到該undo塊裡。插入兩條記錄以後，該n號塊的itl槽的資訊改為 [undo_block2 /
scn9.11]。
那麼當執行查詢的伺服器程序掃瞄到n號塊時，發現scn9.11大於scn9.00，於是到itl槽中指定的
undo_block2處找到該undo塊。發現該undo塊裡記錄的itl資訊為[undo_block1 /
scn9.10]，其中的scn9.10仍然大於scn9.00，於是伺服器程序繼續根據itl中記錄的undo_block1，找到該undo塊。發現該undo塊裡記錄的itl資訊為[undo_block0
/ scn8.50]，這時itl裡的scn8.50小於發出查詢時的scn9.00，說明這時undo塊包含合適的undo資訊，於是伺服器程序不再找下去，而是將n號塊、undo_block2以及undo_block1的資料結合起來，構建cr塊。將當前n號的資料複製到cr塊裡，然後在cr塊裡先回退9點11分的事務，也就是在cr塊裡刪除兩條記錄，然後再回退9點10分的事務，也就是在cr塊裡插入被刪除的記錄，從而構建出9點鐘時的資料。
oracle就是這樣，以層層巢狀的方式，查詢整個undo塊的鍊錶，直到發現itl槽裡的scn號小於等於發出查詢時的那個scn號為止。正常來說，當前undo塊裡記錄的scn號要比上乙個undo塊裡記錄的scn號要小。
但是在查詢的過程中，可能會發現當前undo塊裡記錄的itl槽的scn號比上乙個undo塊裡記錄的scn號還要大。這種情況說明由於事務被提交或回滾，導致當前找到的undo塊裡的資料已經被其他事務覆蓋了，於是我們無法再找出小於等於發出查詢時的那個時間點的scn號，這時oracle就會丟擲乙個非常經典的錯誤——ora-1555，也就是snapshot
too old的錯誤。
以上的描述可以用圖來描述：
回滾事務則是在執行dml以後，發出rollback命令撤銷dml所作的變化。oracle利用記錄在itl槽裡記錄的undo
塊的位址找到該undo塊，然後從中取出變化前的值，並放入資料塊中，從而對事務所作的變化進行回滾。
例項恢復則是在smon程序完成前滾並開啟資料庫以後發生。smon程序會去檢視undo
segment頭部（所謂頭部就是undo segment裡的第乙個資料塊）記錄的事務表（每個事務在使用undo塊時，首先要在該undo塊所在的undo
segment的頭部記錄乙個條目，該條目裡記錄了該事務相關的資訊，其中包括是否提交等），將其中既沒有提交也沒有回滾，而是在例項崩潰時被異常終止的事務全部回滾。
Oracle資料庫一致性讀的原理
在oracle資料庫中，undo主要有三大作用 提供一致性讀 consistent read 回滾事務 rollback transaction 以及例項恢復 instance recovery 一致性讀是相對於髒讀 dirty read 而言的。假設某個表t中有10000條記錄，獲取所有記錄需要1...
資料讀一致性
undo段由兩個元件組成 undo頭和undo入口。undo段的第一塊是undo頭。undo被建立時僅有undo頭被建立。保留時間表 retention table 這是自動管理undo新增的乙個元件。儲存了undo段中每乙個區最後乙個事務提交的時間。事務表 transaction table 儲存...
MySQL 資料庫的一致性讀
mysql 在不同的事務隔離級別下提供兩種讀模式 一致性讀 非加鎖 當前讀 加鎖讀 一致性讀 利用mvcc機制讀取到某個事務已經提交的資料,其實是從undo裡面獲取的資料快照 事務的概念 由一組dml語句組成，要麼全部成功，要麼全部失敗。事務的acid 事務的併發問題 事務的隔離級別 隔離級別 髒讀...