故障检查最棘手的问题之一是访问同一数据的应用程序间的交互作用。虽然从本质上来说，每个应用程序都循规蹈矩，但是各个应用程序可能会对数据做出不同的假定。因此，行就可能出现，发生变化，并在你最不期望它的时候消失。
过去，解决这类问题的方法是在运行两个程序以追踪所发生的事情时，将数据丢弃。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视图中一个简单的列。
现在你可以告诉这两个用户停止修改双方的工作。
