前几天某大师提醒我说了，我以前一篇文档flashback_transaction_query 查询慢的问题 有点问题。 现在回想一下，确实不太对，
虽然以前的方法也是一种处理方法然而有点偏离方向了。首先我们来看一下试图的定义：
—definition

可以看到，该试图的本质是访问x$ktuqqry. 那么这个试图是干什么的呢？显然是闪回事务查询的时候需要用到的东西，而且访问的
的数据是来自undo.下面我们随便从该试图中取一个xid来重现一下：

可以发现访问很慢，为什么呢 ？我们先来看下执行计划：

可以发现，id 2的地方走了table full scan,也就是全表扫描. 以前没用注意的一个细节.大家注意看下面的filter部分,很明显是
进行了隐式转换,以至于走full table scan了。 这里用的rwatohex进行了转换,那么如果使用hextoraw进行反向转一下呢 ？

可以发现，这样的话，速度非常之快. 原来以前一直犯了一个错误，误导了不少人啊. 自我批评下.

到这里可能很多人以为这篇文章到此结束了，是吗？ 实际上，故事才刚刚开始….

或许有些网友已经想到了，这个试图是干吗的？闪回查询，那么如何去定位到这个xid号呢 ？

假如1分钟之前某人删除了一条记录，那么我们要通过闪回事务去恢复这条数据,如何去进行恢复呢 ？ 我们可以直接通过
查询该试图来获取undo_sql 进行恢复，其关键是如何获得该操作的XID ？

+++++++++ 方法1 闪回查询 +++++++++

这里的versions_xid,就表示该事务的xid,其中versions_operaition表示操作类型:D表示delete，I表示insert,U表示update.
通过该xid，我们可以直接查询undo_sql,然后执行该sql文本就可以将该条删除的数据恢复回来,如下查询：

实际上我们利用该视图来定位undo_sql，关键的地方是定位到具体的xid。

那么针对一个表的操作,可能有很多,我们如何去定位呢？ 其实完全可以结合scn和operation以及table_name,table_owner来缩小范围.
类似如下的操作：
SQL> select XID,OPERATION,UNDO_CHANGE#,TABLE_NAME,TABLE_OWNER,ROW_ID
2 from FLASHBACK_TRANSACTION_QUERY where table_name=’TEST_UNDO1′ and table_owner=’ROGER’ and row_id >’AAAPJyAACAAAR/vABN’;

当然如果由于该x$表仅仅在xid字段上存在索引，索引这样查询，可能会比较慢.如下：

显然这里我们根据判断知道第1条信息是我们所需要的.

++++++++++ 方法2 根据rowid 边界定位xid ++++++++++

除了利用闪回的方法，是否还有其他方法呢？假如我删除掉一个范围的数据，例如：

不考虑边界的问题,某条数据通常会跟其他数据存在同一block中,所以根据删除的数据范围,定位到block 号:

此时roger_ora_14279.trc 内容如下：

从上面2个block的dump可以看出xid 信息如下：
0x000c.011.0000038f
0x000c.011.0000038f 虽然涉及到多个block的操作,但是仍然是同一个事务.所以这里xid的一个值.

将其转换为FLASHBACK_TRANSACTION_QUERY.xid的格式,其长度为16位,不足的部分用0补齐.

0c00 1100 8f030000 即使xid=0c0011008f030000

获取到xid后，直接生成恢复的脚本即可,如下：

++++++++++++ 方法 3 使用bbed 定位XID
如果操作的数据刚好都在一个block,即一共block内数据被全部删除，那么无法通过第2种的边界方法去定位.
首先我这里用一个例子来展示，将一个block的数据全部delete掉，但是需要先定位到该block的数据范围：

从上面可以看出，该block内的数据范围在object_id 459和546之间，将其全部delete掉：

通过bbed来获取xid，首先观察操作前后的itl信息变化，如下：

—-delete操作之后

在不考虑ITL被覆盖的情况下，显然该事务所使用的itl应该是最后一个.

从这里我们可以看出对应的事务XID为:0x0014 0003 0000039d

转换为FLASHBACK_TRANSACTION_QUERY试图的标准xid格式为：140003009d030000

获得到xid后，我们就可以直接查询获得undo_sql文本了,如下：

我们可以发现，刚好82条记录，也就是该block中被删除的所有记录，一共82条.

备注： 本文不考虑block itl被覆盖的情况，如果block itl被覆盖，那么情况更为复制，大家可以一起研究下.