在1點鐘，有個使用者a發出了select * from table1;此時不管將來table1怎麼變化，正確的結果應該是使用者a會看到在1點鐘這個時刻的內容。這個是沒有疑問的。
在1點30分，有個使用者b執行了update命令，更新了table1表中的第4000萬行的這條記錄，這時，使用者a的全表掃瞄還沒有到達第4000萬條。毫無疑問，這個時候，第4000萬行的這條記錄是被寫到了回滾段裡去了的，我假設是回滾段rbs1，如果使用者a的全表掃瞄到達了第4000萬行，是應該會正確的從回滾段rbs1中讀取出1點鐘時刻的內容的。
這時，使用者b將他剛才做的操作commit了，但是這時，系統仍然可以給使用者a提供正確的資料，因為那第4000萬行記錄的內容仍然還在回滾段rbs1裡，系統可以根據scn來到回滾段裡找到正確的資料，但是大家注意到，這時記錄在rbs1裡的第4000萬行記錄已經發生了一點重大的改變：就是這個第4000萬行的在回滾段rbs1裡的資料有可能隨時被覆蓋掉，因為這條記錄已經被提交了！！！
由於使用者a的查詢時間漫長，而業務在一直不斷的進行，rbs1回滾段在被多個不同的tracnsaction使用著，這個回滾段裡的extent迴圈到了第4000萬行資料所在的extent，由於這條記錄已經被標記提交了，所以這個extent是可以被其他transaction覆蓋掉的！
到了1點40分，使用者a的查詢終於到了第4000萬行，而這時已經出現了第4條說的情況，需要到回滾段rbs1去找資料，但是已經被覆蓋掉了，於是01555就出現了。
關於oracle的回滾
pl sql設置自動commit 資料庫中做增加 刪除 修改等之後需要做commit，否則資料只存在記憶體中，沒有真正提交到資料庫，乙個操作要麼commit，要麼回滾 tool preferences windows types sql window 選中autocommit sql commit ...
關於Oracle資料庫中的undo回滾段
oracle資料庫當中，關於日誌與回滾那一部分，與別的資料庫確實有很大的不同。為了避免在寫日誌的同時後台程序對日誌檔案的讀操作，oracle使用了單獨的回滾段來記錄 舊 的資料。這樣可以達到並行讀寫的目的，整體i o效率提高了不少，但也引入了一些問題。最經典的莫過於ora 01555 snapsho...
關於 sqlserver 的事物回滾
例 先進行標記事物的開始 begin transaction 進行表的操作，例如插入 修改等。在進行過程中，如果發生錯誤則回滾事物 rollback transaction 若事物結束，則提交事物 commit 在事物過程中通常用 error 語句是否發生錯誤 例如，插入幾條資料，後面的資料主鍵重複...