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