Flashback和smon_scn_time

Flashback机制是oracle 9I 后推出的，依据是回滚段中的信息来构造数据块的前镜像，oracle 9I推出了aum也就是自动回滚段管理，设置了相应的undo_retention参数用来保证回滚段的保留时间，不过该参数并不是一个担保值，也就是如果事务提交过于频繁，新的回滚段信息可能会覆盖undo_retention范围内的回滚段信息，而我们可以设置alter tablespace undotbs1 guarantee来强制保证回滚段的信息在undo_retention范围内。

闪回查询可以在undo信息存在的情况下查询表、视图和物化视图，制定scn和timestamp来查询，timestamp是oracle 9I推出的精确到毫秒的时间单位

SQL> select systimestamp from dual;

SYSTIMESTAMP

30-4月 -12 08.31.17.798000 下午 +08:00

闪回查询形如select * from test03 as of scn/timestamp 可以结合v$archive_log的first_change#、next_change#、first_time#、next_time#来结合业务做相应的判断。Oracle 9I推出的闪回查询，除了利用undo信息外还需要一个内部的系统表smon_scn_time表，smon每五分钟更新一次这个内部表，用于记录scn和时间戳的关系，最多可以保存1440条记录，也就是在oracle 9I中可以对五天之内的scn进行和时间进行响应的估算，不过这也导致在oracle 9I中表闪回查询的时间至少要在五分钟之后，不然就可能出现所谓的ora-01466错误，因为scn和时间的关系暂时还没有记录在smon_scn_time内部表中。

在oracle 10g中，lgwr会在sga中记录scn与时间的关系，lgwr至少三秒会激活一次，smon定期检查内存中映射大于磁盘上，如果有就把sga中对应信息刷新至磁盘（这个定期我查看oracle 10g的内部表smon_scn_time，发现还是5分钟的样子），同时还推出的两个函数timestamp_to_scn和scn_to_timestamp用于直接可以用函数映射scn和时间的对应关系（oracle 9I下需要通过别的方法得到，例如logminer）

SQL> select scn_to_timestamp(2598776751) from dual;

SCN_TO_TIMESTAMP(2598776751)

--------------------------------------------------------------------------------

30-4月 -12 10.21.25.000000000 下午

SQL> select timestamp_to_scn(to_timestamp('30-4月 -12 10.21.25.000000000 下午')) from dual;

TIMESTAMP_TO_SCN(TO_TIMESTAMP(

------------------------------

2598776751

但是这里需要注意的是尽管利用函数timestamp_to_scn和scn_to_timestamp可以转化scn和时间关系，但是其本质依然是使用的smon_scn_time内部表和sga中的时间戳对应关系的信息，而如果转化一个未来的时间或者在smon_scn_time中已经覆盖的时间或者scn由于没有响应的对应关系是无法转换的。

SQL> select timestamp_to_scn(to_timestamp('3-5月 -12 10.21.25.000000000 下午')) from dual;

select timestamp_to_scn(to_timestamp('3-5月 -12 10.21.25.000000000 下午')) from dual

ORA-08186: 指定的时间戳无效

ORA-06512: 在 "SYS.TIMESTAMP_TO_SCN", line 1

SQL> select scn_to_timestamp(2598976751) from dual;

select scn_to_timestamp(2598976751) from dual

ORA-08181: 指定的编号不是有效的系统更改号

ORA-06512: 在 "SYS.SCN_TO_TIMESTAMP", line 1

下面来看看内部表smon_scn_time，其实这个内部表是属于聚簇smon_scn_to_time的，可以查看sql.bsq查看各字典表的由来，分别在scn和time_dp上创建两个索引.

create cluster smon_scn_to_time (

thread number /* thread, compatibility */

)

/

create index smon_scn_to_time_idx on cluster smon_scn_to_time

/

create table smon_scn_time (

thread number, /* thread, compatibility */

time_mp number, /* time this recent scn represents */

time_dp date, /* time as date, compatibility */

scn_wrp number, /* scn.wrp, compatibility */

scn_bas number, /* scn.bas, compatibility */

num_mappings number,

tim_scn_map raw(1200),

scn number default 0, /* scn */

orig_thread number default 0 /* for downgrade */

) cluster smon_scn_to_time (thread)

/

create unique index smon_scn_time_tim_idx on smon_scn_time(time_mp)

/

create unique index smon_scn_time_scn_idx on smon_scn_time(scn)

其中time_dp是对应的时间戳，scn_wrp是高16位scn，scn_bas是低位的scn，

Scn=power(2,16)*scn_wrp+scn_bas，

而oracle是如何更新维护smon_scn_time聚簇表了,由于oracle 9I中默认保存1440条记录，oracle 10g中保存144000条记录，而smon又不断的把数据写进到smon_scn_time表中，猜想这个维护是：

update smon_scn_time set orig_thread=0, time_mp=:1, time_dp=:2, scn=:3,scn_wrp=:4, scn_bas=:5, num_mappings=:6, tim_scn_map=:7 where thread=0 andscn = (select min(scn) from smon_scn_time where thread=0)

从以下实例可以看出在oracle 10.2.0.1.0版本中，确实是三秒收集一次scn和时间映射关系，至于有网友提到的6秒一次，可能是版本问题导致。

SQL> select * from v$version where rownum=1;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

2598777675

SQL> select scn_to_timestamp(2598777675) from dual;

SCN_TO_TIMESTAMP(2598777675)

--------------------------------------------------------------------------------

30-4月 -12 10.53.37.000000000 下午

SQL> select scn_to_timestamp(2598777676) from dual;

SCN_TO_TIMESTAMP(2598777676)

--------------------------------------------------------------------------------

30-4月