故障檢查最棘手的問題之一是訪問同一數據的應用程序間的交互作用。雖然從本質上來說，每個應用程序都循規蹈矩，但是各個應用程序可能會對數據做出不同的假定。因此，行就可能出現，發生變化，並在你最不期望它的時候消失。
過去，解決這類問題的方法是在運行兩個程序以追蹤所發生的事情時，將數據丟棄。Log Miner的出現使執行這一任務變得更為容易，但它使用起來較為麻煩。現在，在Oracle 10g中，有一個與Log Miner同樣功能的工具，但執行起來更為方便。
這個工具稱之為回溯版本查詢，它依靠自動撤消管理特性與撤消表空間自始至終提供行圖像。位於“FROM表名”之後，表別名之前，回溯版本查詢語法通過指示哪些行版本要包括在SELECT內，從而證明表名的資格。其語法為：
VERSIONS BETWEEN { SCN | TIMESTAMP}
{exp | MINVALUE} AND {exp | MAXVALUE}
因為它證明了表的資格，查詢中的每個對象可在不同的時間點呈現。但是，你最遠只能返回指定的UNDO_RETENTION參數，或最近的DDL命令（CREATE/ALTER/DROP），不管哪個在前面。
假設兩個員工正在就PARTS表的一個部分描述打“編輯戰”。每個人認為他或她的改變沒有被數據庫保存。實際上，每個人正將值改“回”到他們認為適當的地方。你可以通過提取那個行的版本歷史來了解發生的內容。列表A顯示了查詢及其結果。
幾個新的偽列為你提供影響行的事務信息。VERSIONS_STARTTIME和VERSIONS_STARTSCN讓你了解歷史記錄的第一行內容。還有一個VERSIONS_XID列（未顯示）指明事務ID；你可以應用它來研究其它行——甚至是在其它表中的其它行——所同時發生的變化。
由於發生了多次更新，你可查詢數據庫找出行的唯一ROWID。然後你可以使用一個相關的特性——回溯事務查詢——來了解哪些用戶做出過改變，他們以何種順序提交數據。列表B顯示了該查詢及其結果。
這裡要注意的是ROW_ID列，它與ROWID偽列不同（見下劃線部分）。它只是FlashBACK_TRANSACTION_QUERY視圖中一個簡單的列。
現在你可以告訴這兩個用戶停止修改雙方的工作。
Bob Watkins(OCP, MCDBA, MCSE, MCT)是一個有著25年經驗的計算機專業人士，曾做過技術培訓師、顧問與數據庫管理員。訪問Bob的網站。
