flashback table你需要知道的

今天查看数据库中一个SQL的执行计划，发现一个很奇怪的索引命名
--------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                                |     1 |   207 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| XXXX                           |     1 |   207 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | BIN$/bp0CBY6HR/gQx4BAQrghw==$0 |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------

根据团队的索引命名规范，一般是以表名作为索引命名的前缀，这个执行计划里看到的索引命名为 BIN$/bp0CBY6HR/gQx4BAQrghw==$0， 根据BIN$前缀，猜测是回收站对象的命名方式，难道这个索引是从回收站里来的?

查看索引的定义
CREATE INDEX "XXXXX"."BIN$/bp0CBY6HR/gQx4BAQrghw==$0" ON "XXXXX"."XXXX" ("ID");
确实是属于这张表上的索引。
猜测应该是当时表被误删除后，采用flashback table闪回了表，但是表的索引等依赖对象的名称不会自动还原为最初的名称。
来做个试验看看。

create table test as select * from user_objects;
create index test_oi_ind on test(object_id);
create or replace trigger test_tri before update on test for each row
begin
null;
end;
/
上面的代码创建了一张表，表上有一个索引、一个触发器。

test@DLSP>select count(*) from user_objects where object_name like 'BIN%'; 


  COUNT(*)
----------
         0


test@DLSP>drop table test;


Table dropped.

删除表，然后对表做闪回。

test@DLSP>flashback table test to before drop;


Flashback complete.

test@DLSP>desc test
 OBJECT_NAME                                                                                  VARCHAR2(128)
 SUBOBJECT_NAME                                                                               VARCHAR2(30)
 OBJECT_ID                                                                                    NUMBER
 DATA_OBJECT_ID                                                                               NUMBER
 OBJECT_TYPE                                                                                  VARCHAR2(19)
 CREATED                                                                                      DATE
 LAST_DDL_TIME                                                                                DATE
 TIMESTAMP                                                                                    VARCHAR2(19)
 STATUS                                                                                       VARCHAR2(7)
 TEMPORARY                                                                                    VARCHAR2(1)
 GENERATED                                                                                    VARCHAR2(1)
 SECONDARY                                                                                    VARCHAR2(1)
 NAMESPACE                                                                                    NUMBER
 EDITION_NAME                                                                                 VARCHAR2(30)

看到表删除经过闪回后又回来了，这个是我们期望的。但是索引呢？
test@DLSP>select count(*) from user_objects where object_name like 'BIN%'; 


  COUNT(*)
----------
         2


test@DLSP>select object_name,object_type from user_objects where object_name like 'BIN%'; 


OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- --------------------------------------
BIN$/b77R1m7J5bgQx4BAQr1Dg==$0           INDEX
BIN$/b77R1m8J5bgQx4BAQr1Dg==$0           TRIGGER

虽然索引和触发器都已经被闪回恢复了，但是名字已经不是它们当时原始的名字了。

test@DLSP>set autotrace on
test@DLSP>select * from test where object_id=1;


no rows selected




Execution Plan
----------------------------------------------------------
Plan hash value: 1815452549


--------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                                |     1 |   190 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST                           |     1 |   190 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | BIN$/b77R1m7J5bgQx4BAQr1Dg==$0 |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------
我们可以看到索引可以正常被使用。（触发器也一样可以被使用，这里不再给出实验）。

命名被改变看起来不是什么大事，但是在某些环境下，却可能引发灾难。
如果这个表上的索引，你通过HINT的方式在SQL里引用了，那么这些HINT将不再起作用。这个很可能引发严重后果。
如果你的代码里对这个表的某些依赖对象有引用，都可能会造成故障。
那么这个问题如何解决？
最好的办法是，在闪回表后，重命名这些依赖对象。
如何获取这些依赖对象的名称呢？可以通过查询recyclebin的original_name字段获取。
select ORIGINAL_NAME from recyclebin;
但是一旦表被闪回，查询recyclebin将不再有用，因为对象已经被闪回，不应该再存在在这个表里了。
可以通过对recylebin闪回查询进行获取。例如：
select  * from dba_RECYCLEBIN as of timestamp to_timestamp('2014-07-9 16:13:50','yyyy-mm-dd hh24:mi:ss') where owner='TEST';
可能很多同学对于这些数据字段表也可以被闪回查询感到疑惑，其实原理是一样的，这些数据字段表只是SYS SCHEMA下的表对象，依然需要产生redo,undo，依然要遵循事物的一致性原理。
但是对于X$表一般都不支持闪回查询，这些表并不遵循读一致性，也没有redo,undo这些事务上的东西。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-1214534/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-1214534/