毛病检查最棘手的问题之一是访问同一数据的使用程序间的交互作用。虽然从本质上来说，每个使用程序都循规蹈矩，但是各个使用程序可能会对数据做出不同的假定。因此，行就可能出现，发生变化，并在你最不期望它的时候消逝。

过去，处理这类问题的方法是在运转两个程序以追踪所发生的事情时，将数据丢弃。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的网站。