存儲數據快照
說了半天，在給用戶顯示先前版本的數據同時，Oracle是如何允許其他用戶修改數據的呢？其實，只要某一用戶啟動了一宗修改數據的交易，之前的數據映像就會被寫到一個特殊的存儲區域。這種“前映像”用來向任何查詢數據的用戶提供一致的數據庫視圖。這樣，當其他用戶在修改數據的時候，在以上的測試中我們就能看到尚未發生變更的薪金數據。這個特殊的存儲區域在哪裡呢？這個問題的答案就跟你正在使用的Oracle版本有關了。在 Oracle 8i及其以前版本中會為這一目的創建特殊的回滾段。然而，這種舉措會給數據庫管理員（DBA）帶來管理和調整數據段的工作負擔。例如，DBA必須確定為此需要的數據段的數量以及大小等。假如回滾段沒有正確配置，那麼對交易而言它們就可能不得不排隊等待回滾段中出現必要的數據空間。
Oracle 9i就不同了，這是Oracle的最新版本，Oracle實現了一種新特性，這就是所謂的undo表空間，它有效地消除了以上的管理復雜性。雖然回滾段仍然可以繼續使用，但是，DBA現在可以選擇創建undo表空間的方式令Oracle自己管理“前映像”的復雜空間分配。Oracle的這種方法對程序員具有重要意義。因為回滾空間不是無限的，所以，更新交易的數據快照會取代先前交易的映像。因此，如果必要的回滾段被其他交易的映像覆蓋的話。運行時間較長的查詢操作就可能產生“ snapshot too old”錯誤。
下面舉個可能發生的案例。假設在上午11:59的時候某位職員開始更新John Doe帳務的交易。這宗交易在下午12:01被提交。同時，下午12:00某財務經理開始查詢所有的客戶帳務報表和當月收費總計。因為客戶很多，所以這一查詢操作很費了點時間，但是不論這次操作到底執行了多久，反正它檢索出的結果就是下午12:00數據庫中存在的數據。如果包含John Doe帳務前映像的回滾空間在查詢執行到該客戶名字的時候被覆蓋則查詢返回錯誤消息。Oracle的解決方案當然更為合理，在抽象意義上提供了相比SQL Server更佳的數據一致性。在執行Oracle查詢的時候無須擔心較長的查詢操作會鎖定重要的交易。但是，在兩種數據庫同時支持海量用戶的情況下也很難證明Oracle是否就能真正實現具體條件下的數據一致性。
