故障檢查最棘手的問題之一是訪問同一數據的應用程序間的交互作用雖然從本質上來說每個應用程序都循規蹈矩但是各個應用程序可能會對數據做出不同的假定因此行就可能出現發生變化並在你最不期望它的時候消失
過去解決這類問題的方法是在運行兩個程序以追蹤所發生的事情時將數據丟棄Log Miner的出現使執行這一任務變得更為容易但它使用起來較為麻煩現在在Oracle g中有一個與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視圖中一個簡單的列
現在你可以告訴這兩個用戶停止修改雙方的工作
From:http://tw.wingwit.com/Article/program/Oracle/201311/18243.html
