oracle 的 flash back,Oracle Flashback(闪回) 详解

SQL> show parameter undo;

NAME        TYPE  VALUE

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

undo_management       string  AUTO

undo_retention        integer  900

undo_tablespace       string  UNDOTBS1

1.5.1  Parameter UNDO_MANAGEMENT

UNDO_MANAGEMENT:    当它的值是AUTO时表示启用了, 当值是MANUAL则表示手动管理.

1.5.2  Parameter UNDO_TABLESPACE

这个参数制定了回滚表空间, 当UNDO_MANAGEMENT的值是auto时, 可以手动制定这个参数, 指定数据库使用哪个表空间作为undo 表空间.

undo表空间的大小, 直接影响到flashback query 的查询能力, 因为多版本查询依赖的undo数据都存放在undo tablespace中.  该tablespace 越大, 能够存储的undo数据自然就越多, 如果undo tablespace的空间很小, 别说flashback了, 连正常的查询都可能出错.(如果事务DML操作频繁)

1.5.3  Parameter UNDO_RETENTION

这个参数用来制定undo记录在undo tablespace 内保存的最长时间. 以秒为单位.

这个参数是1个动态参数, dba可以在实例运行时随时修改. 默认是 900秒(15min)

指的注意的是,  undo_retention只是制定undo数据的过期时间, 但是并不保证undo数据能在undo tablespace中能保存段时间.

也就是说, 当服务器负载压力大时,  undo数据很可能在undo_retention指定的时间内就被其他undo数据覆盖.

因此, 当dba创建1个自动管理的undo tablespace时, 还要注意其空间大小, 要尽可能保证 undo 表空间内有足够的空间.

同时, 也并不是说, undo_retention指定的时间已过,  已经提交的事务数据就无法访问.  它只是失效, 只要不被别的事务的undo数据覆盖. flashback仍然可以正常执行.

那么undo_retention是1个多余的参数?  其实只要dba指定的undo tablespace 空间足够大, 而数据库也不是那么繁忙, 这样undo_retention这个参数是不会影响到你的, 哪怕这个参数被设置为1.  总要没有事务去覆盖undo数据, 它就持续有效, 也就是讲, undo tablespace的大小比这个参数重要得多.

只有1中情况例外,  当为undo tablespace 启用retention guarantee.

oracle 可以保证undo 数据在undo_retention指定的时间内一定存在(不能被其他undo数据覆盖).

启用guarantee:

Alter tablespace undotbs1 retention guarantee;

禁用guarantee:

Alter tablespace undotbs1 retention noguarantee;

启用这个特性能保证undo数据在undo tablespace 内的存在时间, 但是也有代价的.

假如表空间已满, 而且不允许旧的undo数据被新数据覆盖.   为了保证多版本的读一致性(详见本文第五节), 新的事务的

操作就会受影响了.

所以还是那几句话:  the size of undo tablespace is very importance.

二, Flashback的级别和成员

2.1 Flashback的级别

Flashback可以分为三个级别:

1.Database Level

数据库级别的flashback允许将数据库恢复到某个时间点,  当误删除1个user或误truncate 1张表是适用数据库级别的flashback.

2.Table level

表级flashback可以将1个table回滚到某个时间点或者某个SCN号,  也可以闪回通过Drop命令删除的表.

3.Transaction level

事务级闪回会记录用户事务的每个DML操作, 并给出相应rollback的DML指令. 比如insert操作的rollback指令就是delete.

一般用于rollback 用户已经commit的误操作事务.

而根据误操作对于数据的影响.

用户可以选择执行flashback操作或者flashback查询.(flashback query)

所谓falshback查询就是查询数据被DML操作的历史记录(一般就是commit的记录), 然后在此基础上确定是否进行flashback操作.

2.2 Flashback的成员

Flashback可以分为如下成员:

1.Flashback Database

2.Flashback Drop

3.Flashback Query

-- Flashback Query

-- Flashback Version Query

-- Flashback Transaction Query

4.Flashback Table

5.Flashback Data Archive

三, Flashback Version Query

首先我们介绍的第一个成员叫flashback 版本查询.

所谓Version是指数据库中每次因为事务commit 而产生的数据行变化情况, 每一次变化就是1个版本.

这里需要强调的是这里变化是因为事务commit 产生的变化, 未commit的事务引起的变化不会被Flashback Version query 检索出来.

Flash Version Query 查询使用的undo 表空间的Undo 数据, 一旦undo数据因为undo segment的空间压力被清除, 则产生无法flashback的情况.

通过versions between 关键字可以查询制定时间(timestamp) or 版本(scn号)区间内的的不同修改版本.

语法:

基于 SCN 的版本查询

SELECT

FROM

VERSIONS BETWEEN SCN AND

[WHERE ]

[GROUP BY ]

[HAVING

[ORDER BY ]

基于 TIMESTAMP 的版���查询

SELECT

FROM

VERSIONSBETWEEN timestamp to_timestamp('start_timestamp')and to_timestamp('end_timestamp')

[WHERE ]

[GROUP BY ]

[HAVING

[ORDER BY ]

返回的视图提供多个伪列. 包括:

VERSIONS_STARTSCN VERSIONS_STARTTIME

记录操作时(也就是产生这条记录)的scn或时间, 如果为空, 表示该行记录是查询范围外创建的.

VERSIONS_ENDSCN VERSIONS_ENDTIME

表示该记录失效时的scn或时间.

这里什么是失效?  所谓失效就是对应的数据行被修改或者删除.

例如事务1中在A时间点修改了数据行x.  那么数据行x在事务1中的starttime 是A,  但是endtime是空的, 因为事务1的修改一直维持.

直到事务2在B时间点再次修改数据行x, 那么数据行x在事务1中的endtime 就是B了, 因为事务1的修改已经失效.

也就是说, 如果这两列的数据是空, 代表在改断时间内无操作(update or delete)

VERSIONS_OPERATION

记录操作的类型, I 表示Insert, D表示Delete, U表示Update.  如果对索引键的update操作, flashback version query可能会表示为Delete和Insert两个动作.

VERSIONS_XID

表示该操作的事务ID(key)

例子:

SQL> create table Test3(id numeric, name varchar2(10));

Table created.

SQL> insert into test3 select 1,'Jack' from dual;

1 row created.

SQL> commit;

Commit complete.

SQL> insert into test3 select 2,'Bill' from dual;

1 row created.

SQL> commit;

Commit complete.

SQL> insert into test3 select 3,'Gordon' from dual;

1 row created.

SQL> commit;

Commit complete.

SQL> update test3 set name = 'Billing' where id = 2;

1 row updated.

SQL> commit;

Commit complete.

SQL> delete from test3 where id = 3;

1 row deleted.

SQL> commit;

Commit complete.

上面例子中我新建1个简单的table Test3, 然后插入了3个数据行, 更新了1条, 删除了1条, 注意的是每条语句后都commit了一次.

接下来可以利用flashback versions query 来查询这张表被修改的版本信息.

select id, name, versions_xid, versions_startscn, versions_endscn,

to_char(versions_starttime,'YY/MM/DD HH24:MI:SS') as startime,

to_char(versions_endtime,'YY/MM/DD HH24:MI:SS') as endtime,

versions_operation

from Test3 versions between scn minvalue and maxvalue where id > 0;

输出:

ID NAME      VERSIONS_XID    VERSIONS_STARTSCN VERSIONS_ENDSCN STARTIME    ENDTIME          VERSIONS_OPERATION

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

3 Gordon    05001400BC090000          3028255                  14/05/22 22:15:47                    D

2 Billing      08001D002B090000          3028245                14/05/22 22:15:23                    U

3 Gordon    020010004A090000          3028239        3028255  14/05/22 22:15:11  14/05/22 22:15:47  I

2 Bill        07000900D5060000          3028234        3028245  14/05/22 22:14:56  14/05/22 22:15:23  I

1 Jack        03000B0068090000          3028229                  14/05/22 22:14:48                    I

可以见到:

1. 在倒数第一行, 我们插入了一条数据1,Jack, 它的versions_scn为空, 因为自从insert后一直没有对这条数据行操作.

2. 倒数第2行, 具有version_scn数据, 因为它被倒数第4行的事务更新了(Bill - > Billing).

3. 同样道理, 倒数第3行的Gordon被删除.