2.Oracle闪回技术之基本介绍02

1.Flashback的简单原理

Oracle会将数据库数据的每1个改动记录在日志文件中，所以理论上依靠日志文件，是能将数据库回滚到任何一个时间点的

而flash的机制有点类似与回收站，会把数据库改动前的镜像放到undo表空间中，

如果用户rollback 1个数据对象，只需要找到undo表空间中对应的undo数据即可。

2.Flashback的优点

很明显，Flashback并不依赖于日志文件，只需undo表空间数据即可发挥作用，所以有如下优点：

• 快速
• 在线恢复，无须关闭数据
• 操作简单，便捷

3.Flashback的缺点

Flashback的缺点同样明显

• 只适用于用户逻辑错误，所谓逻辑错误就是用户对于数据的误操作，例如误删除一些数据行等，而对于数据文件的损坏则无能为力(只能通过日志恢复)
• undo表空间的容量有限，旧的undo数据有可能被新的数据覆盖，所以flashback一般只适用于短时间的恢复，对于一段相当时间前的误操作，很可能因为undo数据而被覆盖而恢复失败

4.启动flashback功能

为了正常使用Flashback功能，通常我们要打开补充日志(Supplemental logging)功能，Oracle 11g数据库默认情况下补充日志是关闭的

补充日志也分为几个级别，最小(Minimal)，支持所有字段(all)，支持主键(primary key)，支持唯一键(unique),支持外键(foreign key).包括LONG,LOB,LONG RAW及集合等字段类型均无法利用补全日志.

例如:

使用如下命令来打开最小补全日志.

alter database add supplemental log data;

使用如下命令来查看补全日志是否被打开.

SQL> select supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_ui, supplemental_log_data_fk, supplemental_log_data_all from v$database;

SUPPLEME SUP SUP SUP SUP
-------- --- --- --- ---
YES  NO  NO  NO  NO

使用Flashback 需要当前用户具有select any transaction 权限.

可以用dba账号执行:

grant select any transaction to xxx;

来获得这个权限.

5.关于flashback的undo设置，Automatic Undo Management

11g我们一般使用Automatic Undo Mangement(自动撤销管理表空间)，提到这个，就不得不提到手动管理回滚段(Rollback segment)

在oracle 91及之前，回滚段的管理和监控是需要dba手工介入的，创建合适的回滚段是一件费精力的事情，dba可能需要不断关注oracle运行情况很长一阵子时间之后，通过不断尝试调整才能确定一段时间内合适的回滚段大小，一旦回滚段创建的不合适，就极有可能引起性能问题甚至error.

在9i之后，oracle为了清晰整个概念，取消了回滚段的说法(实际上并未取消回滚段),而完全用undo来代替，这也正好与redo相对应，1个撤销，1个重做，回滚段不再由dba手工介入，完全由它在运行时自动分配，这在一定程度上解放了dba，也确实起到了提高性能的作用，比如采用auto undo management能最大限度地降低(非避免)ora-1555发生的几率。

数据库关于automatic undo management涉及了3个数据参数：

SQL> show parameter undo;

NAME        TYPE  VALUE
------------------------------------ ----------- -----------------------------
undo_management       string  AUTO
undo_retention        integer  900
undo_tablespace       string  UNDOTBS1

undo_management :当它的值是auto时表示启用了，当值是manual则表示手动管理
undo_tablespace :这个参数制定了回滚段空间，当undo_management的值是auto时，可以手动指定这个参数，指定数据库使用了哪个表空间作为undo表空间
　　　　　　　　　　undo表空间的大小，直接影响到flashback query的查询能力，因为多版本查询依赖的undo数据都存放在undo tablesspace中，该tablespace越大，能够存储的undo数据　　　　　　　　　　自然就越多，如果undo tablespace的空间很小，别说flashback了，连正常的查询都可能出错(如果事务DML操作频繁)
undo_retention: 这个参数用来指定undo记录在undo tablespace内保存的最长时间，以秒为单位，这个参数是一个动态参数，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.