今天遇到了一个有些类似于“审计”的问题。
因为在检查all_objects时发现有一张表的last_ddl_time发生了变化,为了防止是其结构发生变化,进而进行了检查。但是如果没有对原始表的结构记录,该如何处理呢?
因为当时该数据库已经开启了FLASH BACK功能,所以通过这个线索来进行处理。
进行如下方法:
然后比对tab_log_ver和tab_log字段没有发现不同。为防止判断有问题,又做了进一步的实验:
然后开始修改该测试表的结构:
试图检查修改之前的数据信息:
报ORA-01466错误。使用FLASHBACK TABLE来执行,同样的报错信息。
这里我们不难发现,如果结构发生改变,基于FLASH BACK的查询或者恢复都会有一定的问题,它只能恢复到修改后的时间点。毕竟FLASHBACK是为数据的快速恢复来设计使用的。
但是可以在一定的程度上证明,数据结构没有发生改变的时间。否则就会报ORA-01466错误了。
因为在检查all_objects时发现有一张表的last_ddl_time发生了变化,为了防止是其结构发生变化,进而进行了检查。但是如果没有对原始表的结构记录,该如何处理呢?
因为当时该数据库已经开启了FLASH BACK功能,所以通过这个线索来进行处理。
进行如下方法:
select tab_log_ver
as select *
from tab_log as timestamp('2008-12-08 8:00:00', 'YYYY-MM-DD HH24:MI:SS') where rownum<5;
as select *
from tab_log as timestamp('2008-12-08 8:00:00', 'YYYY-MM-DD HH24:MI:SS') where rownum<5;
然后比对tab_log_ver和tab_log字段没有发现不同。为防止判断有问题,又做了进一步的实验:
首先创建一张测试表:
SQL> desc test_log_ver
Name Type Nullable Default Comments
----------- ------------- -------- ------- --------
MESSAGE_ID VARCHAR2(100)
TASK_ID VARCHAR2(18)
SUBMIT_TIME VARCHAR2(14) Y
TERMINAL_ID VARCHAR2(20) Y
STATUS CHAR(10) Y
SQL> desc test_log_ver
Name Type Nullable Default Comments
----------- ------------- -------- ------- --------
MESSAGE_ID VARCHAR2(100)
TASK_ID VARCHAR2(18)
SUBMIT_TIME VARCHAR2(14) Y
TERMINAL_ID VARCHAR2(20) Y
STATUS CHAR(10) Y
然后开始修改该测试表的结构:
SQL> alter table test_log_ver modify (MESSAGE_ID varchar2(30));
Table altered
Executed in 0.125 seconds
SQL> alter table test_log_ver add(test_col number);
Table altered
Executed in 0 seconds
SQL> select object_name,
2 to_char(created, 'yyyy-mm-dd hh24:mi:ss') created,
3 to_char(last_ddl_time, 'yyyy-mm-dd hh24:mi:ss') last_ddl_time
4 from user_objects
5 where object_name = 'TEST_LOG_VER'
6 ;
OBJECT_NAME CREATED LAST_DDL_TIME
---------------- ------------------- ---------------------
TEST_LOG_VER 2008-12-08 15:38:00 2008-12-08 15:46:15
Executed in 0.016 seconds
Table altered
Executed in 0.125 seconds
SQL> alter table test_log_ver add(test_col number);
Table altered
Executed in 0 seconds
SQL> select object_name,
2 to_char(created, 'yyyy-mm-dd hh24:mi:ss') created,
3 to_char(last_ddl_time, 'yyyy-mm-dd hh24:mi:ss') last_ddl_time
4 from user_objects
5 where object_name = 'TEST_LOG_VER'
6 ;
OBJECT_NAME CREATED LAST_DDL_TIME
---------------- ------------------- ---------------------
TEST_LOG_VER 2008-12-08 15:38:00 2008-12-08 15:46:15
Executed in 0.016 seconds
试图检查修改之前的数据信息:
select * from test_log_ver as of timestamp
to_timestamp('2008-12-08 15:38:10', 'YYYY-MM-DD HH24:MI:SS')
ORA-01466: unable to read data - table definition has changed
to_timestamp('2008-12-08 15:38:10', 'YYYY-MM-DD HH24:MI:SS')
ORA-01466: unable to read data - table definition has changed
报ORA-01466错误。使用FLASHBACK TABLE来执行,同样的报错信息。
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') SYSDATE from dual;
SYSDATE
-----------------------
2008-12-08 16:28:50
在16:28分时,执行FLASHBACK操作,并且指定的时间大于2008-12-08 15:46:15。
SQL> flashback table XXX.test_log_ver to timestamp to_timestamp('2008-12-08 15:50:00', 'YYYY-MM-DD HH24:MI:SS');
Flashback complete.
成功执行!
SYSDATE
-----------------------
2008-12-08 16:28:50
在16:28分时,执行FLASHBACK操作,并且指定的时间大于2008-12-08 15:46:15。
SQL> flashback table XXX.test_log_ver to timestamp to_timestamp('2008-12-08 15:50:00', 'YYYY-MM-DD HH24:MI:SS');
Flashback complete.
成功执行!
这里我们不难发现,如果结构发生改变,基于FLASH BACK的查询或者恢复都会有一定的问题,它只能恢复到修改后的时间点。毕竟FLASHBACK是为数据的快速恢复来设计使用的。
但是可以在一定的程度上证明,数据结构没有发生改变的时间。否则就会报ORA-01466错误了。
-:)
本文转自Be the miracle!博客51CTO博客,原文链接http://blog.51cto.com/miracle/117956如需转载请自行联系原作者
Larry.Yue