您的位置:首页 > 博客中心 > 数据库 >

Oracle 六大闪回技术,flashback

时间:2022-03-14 00:59

 

Flashback 技术是以Undo segment中的内容为基础的, 因此受限于UNDO_RETENTON参数。
要使用flashback 的特性,必须启用自动撤销管理表空间。
在Oracle 11g里又出了一个新特性:Oracle Flashback Data Archive.
FDA通过将变化数据另外存储到创建的闪回归档区(Flashback Archive)中,以和undo区别开来,
这样就可以为闪回归档区单独设置存储策略,使之可以闪回到指定时间之前的旧数据而不影响undo策略。

在Oracle 10g中, Flash back家族分为以下成员:
Flashback Database,
Flashback Drop,
Flashback Query(分Flashback Query,Flashback Version Query,
Flashback Transaction Query 三种)
和Flashback Table。

Oracle 11g中闪回新特性 :闪回归档

 

 gxlsystem.com,布布扣

1 闪回恢复区(Flashback Recovery Area)
在oracle 9i中引入flashback查询,以便能在需要的时候查到过去某个时刻的一致性数据,
依赖于undo表空间存储的信息来闪回查询以前的版本,当然这个受限于undo表空间的大小,
以及保留策略。如果undo 被覆盖了就不能进行查询。

oracle10g中增强了闪回查询的功能,并且提供了将整个数据库回退到过去某个时刻的能力,
这是通过引入一种新的flashback log实现的。flashback log有点类似redo log,
只不过redo log将数据库往前滚,flashback log则将数据库往后滚。
为了保存管理和备份恢复相关的文件,oracle10g提供了一个叫做闪回恢复区(Flashback recovery area),
这个区域默认创建在oracle_base目录下。 可以将所有恢复相关的文件,
比如flashback log,archive log,backup set等,放到这个区域集中管理。

1.1 设置闪回恢复区
闪回恢复区主要通过3个初始化参数来设置和管理:
    db_recovery_file_dest:指定闪回恢复区的位置
    db_recovery_file_dest_size:指定闪回恢复区的可用空间大小
    db_flashback_retention_target:指定数据库可以回退的时间,单位为分钟,
     默认1440分钟,也就是一天。当然,实际上可回退的时间还决定于闪回恢复区的大小,
     因为里面保存了回退所需要的flash log。
     所以这个参数要和db_recovery_file_dest_size配合修改。

 
SQL> ALTER SYSTEM SET db_recovery_file_dest_size=3g SCOPE=BOTH;

System altered.

SQL> ALTER SYSTEM SET db_recovery_file_dest=‘ D:/app/Administrator/flash_recovery_area ‘ SCOPE=BOTH;

System altered.

SQL> show parameter db_recovery_file_dest

NAME                            TYPE                 VALUE
---------------------------    -----------           ------------------------------
db_recovery_file_dest           string               D:/app/Administrator/flash_recovery_area
db_recovery_file_dest_size      big integer          3852M
SQL> show parameter db_flashback

NAME                            TYPE         VALUE
----------------------------    --------     ------------------------------
db_flashback_retention_target   integer      1440

我们看到db_flashback_retention_target 默认是1440分钟,即24 小时,
需要注意的是该参数虽然未直接指定flash recovery area大小,但却受其制约,
举个例子假如数据库每天有10%左右的数据变动的话,如果该初始化参数值设置为1440,
则flash recovery area 的大小至少要是当前数据库实际容量的10%,
如果该初始化参数设置为2880,则flash recovery area 的大小就至少是数据库所占容量的20%。

 

修改该参数:

SQL>alter system set db_flashback_retention_target=2880 scope=both;

 

1.2  取消闪回恢复区
将db_recovery_file_dest参数设置为空,可以停用闪回恢复区。
如果已经启用flashback database,则不能取消闪回恢复区。

SQL> alter system set db_recovery_file_dest=‘‘;

 alter system set db_recovery_file_dest=‘‘

*

第 1 行出现错误:
ORA-02097: 无法修改参数, 因为指定的值无效
ORA-38775: 无法禁用恢复区 - 闪回数据库已启用
SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount;

ORACLE 例程已经启动。
Total System Global Area  849530880 bytes
Fixed Size                  1377896 bytes
Variable Size             637536664 bytes
Database Buffers          205520896 bytes
Redo Buffers                5095424 bytes
数据库装载完毕。

SQL> alter database flashback off;

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> alter system set db_recovery_file_dest=‘‘;

系统已更改。

SQL> show parameter db_recovery_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string
db_recovery_file_dest_size           big integer 3852M

SQL>


注意:
(1)DB_RECOVERY_FILE_DEST_SIZE 只有在 DB_RECOVERY_FILE_DEST 清空之后才可以清空。
(2)初始化参数 db_recovery_file_dest_size 的设定有一点点需要注意的地方:
     文件的第0块和操作系统数据块头的空间大小不包含在内,该参数并不代表实际占用的空间大小。
     如果空间被压缩、镜像、RAID 的话,该参数的值意义是不一样的

1.3  闪回恢复区的内容
所有和恢复相关的文件都可以存放到闪回恢复区
> select file_type from v$flash_recovery_area_usage;

FILE_TYPE
--------------------
CONTROL FILE
REDO LOG
ARCHIVED LOG
BACKUP PIECE
IMAGE COPY
FLASHBACK LOG
FOREIGN ARCHIVED LOG

7 rows selected.


 
上面视图中查询的结果列出的所有类型的文件,都可以利用闪回恢复区来存放、管理。
在一些 10g 的动态视图里( V$CONTROLFILE, V$LOGFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY 等 )
的新的列 IS_RECOVERY_DEST_FILE ,指明相关的文件是否在恢复区内。

> col is_recovery_dest_file for a25
> SELECT   recid, blocks, is_recovery_dest_file
  FROM   v$archived_log
 WHERE   recid < 5; 

     RECID     BLOCKS IS_RECOVERY_DEST_FILE
---------- ---------- -------------------------
         1      61856 YES
         2          1 YES
         3          1 YES
         4      87577 YES

 

1.4  闪回恢复区的一些限制
如果设置了闪回恢复区,则log_archive_dest和log_archive_duplex_dest将不可用。
SQL> alter system set log_archive_dest=‘e:/‘ ;

alter system set log_archive_dest=‘e:/‘

*

第 1 行出现错误:
ORA-02097: 无法修改参数, 因为指定的值无效
ORA-16018: 无法将 LOG_ARCHIVE_DEST 与 LOG_ARCHIVE_DEST_n 或
DB_RECOVERY_FILE_DEST 一起使用

SQL> alter system set log_archive_duplex_dest=‘e:/‘;

alter system set log_archive_duplex_dest=‘e:/‘

*

第 1 行出现错误:
ORA-02097: 无法修改参数, 因为指定的值无效
ORA-16018: 无法将 LOG_ARCHIVE_DUPLEX_DEST 与 LOG_ARCHIVE_DEST_n 或
DB_RECOVERY_FILE_DEST 一起使用


说明:
设置闪回恢复区后,如果没有设置过log_archive_dest_n参数,则归档日志默认是保存到该区域的。
实际上,oracle是通过隐式的设置log_archive_dest_10=‘location=USE_DB_RECOVERY_FILE_DEST‘
来实现的。所以,如果修改过log_archive_dest_n将归档日志保存到其他位置,
也可以修改该参数继续使用闪回恢复区。

多个数据库的闪回恢复区可以指定到同一个位置,但是db_name不能一样,或者db_unique_name不一样。
RAC的闪回恢复区必须位于共享磁盘上,能被所有实例访问。
上述说明适用于单节点上有多个数据库时的情况。

1.5  闪回恢复区的空间管理
闪回恢复区中添加或删除文件等变化都将记录在数据库的 alert 日志中,
Oracle 10g 也针对该新特性提供了一个新的视图, DBA_OUTSTANDING_ALERTS,
通过该视图可以得到相关的信息。
> desc dba_outstanding_alerts;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 SEQUENCE_ID                                        NUMBER
 REASON_ID                                 NOT NULL NUMBER
 OWNER                                              VARCHAR2(30)
 OBJECT_NAME                                        VARCHAR2(513)
 SUBOBJECT_NAME                                     VARCHAR2(30)
 OBJECT_TYPE                                        VARCHAR2(64)
 REASON                                             VARCHAR2(4000)
 TIME_SUGGESTED                                     TIMESTAMP(6) WITH TIME ZONE
 CREATION_TIME                                      TIMESTAMP(6) WITH TIME ZONE
 SUGGESTED_ACTION                                   VARCHAR2(4000)
 ADVISOR_NAME                                       VARCHAR2(30)
 METRIC_VALUE                                       NUMBER
 MESSAGE_TYPE                                       VARCHAR2(12)
 MESSAGE_GROUP                                      VARCHAR2(64)
 MESSAGE_LEVEL                                      NUMBER
 HOSTING_CLIENT_ID                                  VARCHAR2(64)
 MODULE_ID                                          VARCHAR2(64)
 PROCESS_ID                                         VARCHAR2(128)
 HOST_ID                                            VARCHAR2(256)
 HOST_NW_ADDR                                       VARCHAR2(256)
 INSTANCE_NAME                                      VARCHAR2(16)
 INSTANCE_NUMBER                                    NUMBER
 USER_ID                                            VARCHAR2(30)
 EXECUTION_CONTEXT_ID                               VARCHAR2(128)
 ERROR_INSTANCE_ID                                  VARCHAR2(142)

在闪回恢复区中的空间使用超过 85% 的时候,数据库将会向 alert 文件中写入告警信息。
而当超过 97% 的时候将会写入严重告警信息。当闪回恢复区空间不够的时候,
Oracle将报告如下类似的错误:

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 52428800 bytes disk space from 1258291200 limit

这个时候查询 dba_outstanding_alerts:
SQL> select reason,object_type,suggested_action from dba_outstanding_alerts;

REASON                         OBJECT_TYPE          SUGGESTED_ACTION
------------------------------ -------------------- ----------------------------------------
db_recovery_file_dest_size of  RECOVERY AREA        Add disk space and increase db_recovery_
1258291200 bytes is 88.20% use                      file_dest_size, backup files to tertiary
d and has 148509184 remaining                        device, delete files from recovery area
bytes available.                                     using RMAN, consider changing RMAN rete
                                                    ntion policy or consider changing RMAN a
                                                    rchivelog deletion policy.


同时,oracle在alert中还会给出解决该问题的建议
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMANB ACKUP RECOVERY AREA
   command.
3. Add disk space and increase db_recovery_file_dest_size parameter to reflect
   the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating system
   command was used to delete files, then use RMAN CROSSCHECK
   and DELETE EXPIRED commands.
************************************************************************

V$RECOVERY_FILE_DEST视图 包含闪回恢复区的相关信息:
> desc v$recovery_file_dest;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 NAME                                               VARCHAR2(513)
 SPACE_LIMIT                                        NUMBER
 SPACE_USED                                         NUMBER
 SPACE_RECLAIMABLE                                  NUMBER
 NUMBER_OF_FILES                                    NUMBER

> col name for a5
> select * from v$recovery_file_dest;

NAME  SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----- ----------- ---------- ----------------- ---------------
+FRA   4621074432  620756992                 0              33

通过查询视图v$flash_recovery_area_usage,可以获得当前闪回恢复区的空间使用情况,
并且可以知道是哪些文件占中了空间,据此可以做出相应的处理,或者加大闪回恢复区,
或者移走相应的文件。
> select * from v$flash_recovery_area_usage;

FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE
-------------------- ------------------ -------------------------
NUMBER_OF_FILES
---------------
CONTROL FILE                        .41                         0
              1

REDO LOG                           4.63                         0
              4

ARCHIVED LOG                       3.72                         0
             24


FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE
-------------------- ------------------ -------------------------
NUMBER_OF_FILES
---------------
BACKUP PIECE                          0                         0
              0

IMAGE COPY                            0                         0
              0

FLASHBACK LOG                      4.63                         0
              4


FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE
-------------------- ------------------ -------------------------
NUMBER_OF_FILES
---------------
FOREIGN ARCHIVED LOG                  0                         0
              0


7 rows selected.


如果闪回恢复区空间耗尽,且归档路径设置到了闪回恢复区中,则由于日志无法归档,
数据库会hang住。所以,对于生产库,如果将归档放到闪回恢复区中,
需要密切关注闪回恢复区的空间使用情况,否则一旦闪回恢复区的空间用尽,
将导致数据库无法提供服务。
因此,应该将闪回区的使用情况列入dba日常巡检工作中。
 

1.6  Flash Recovery Area空间不足导致DB不能打开或hang住处理方法
在上面讲到,当归档目录设置在闪回恢复区,并且闪回恢复区又满了的情况下,
 DB 就会无法归档而hang住或者无法打开。


这种情况下打开数据库会遇到如下错误信息:
SQL> select status from v$instance;

STATUS
------------
MOUNTED

SQL> alter database open;

alter database open

*

第 1 行出现错误:

ORA-16014: 日志 2 的序列号 27 未归档, 没有可用的目的地
ORA-00312: 联机日志 2 线程 1:
‘D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG‘


SQL> show parameter db_recovery_file

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest    string      D:/oracle/product/10.2.0/flash_recovery_area
db_recovery_file_dest_size        big integer 2G

SQL> alter system archive log current;

alter system archive log current

*

第 1 行出现错误:
ORA-01109: 数据库未打开
 

SQL> alter system switch logfile;

alter system switch logfile

*

第 1 行出现错误:
ORA-01109: 数据库未打开

 

SQL> shutdown immediate;

ORA-01109: 数据库未打开

已经卸载数据库。
ORACLE 例程已经关闭。

SQL> startup
ORACLE 例程已经启动。
Total System Global Area  201326592 bytes
Fixed Size                  1248092 bytes
Variable Size              88081572 bytes
Database Buffers          109051904 bytes
Redo Buffers               2945024 bytes
数据库装载完毕。

ORA-16038: 日志 2 序列号 27 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 2 线程 1:
‘D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG‘

SQL> alter database open;

alter database open

*

第 1 行出现错误:
ORA-16014: 日志 2 的序列号 27 未归档, 没有可用的目的地
ORA-00312: 联机日志 2 线程 1:
‘D:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG‘


通过增加闪回恢复区大小,我们可以正常打开数据库

SQL> show parameter db_recovery

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      D:/oracle/product/10.2.0/flash_recovery_area
db_recovery_file_dest_size           big integer 2G

SQL> alter system set db_recovery_file_dest_size=3G scope=both;

系统已更改。

SQL> alter database open;

数据库已更改。

 

检查一下flash recovery area的使用情况:

SQL> select * from v$flash_recovery_area_usage;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE          0                         0               0
ONLINELOG           0                         0               0
ARCHIVELOG        6.36                         0               4
BACKUPPIECE       .22                         0               1
IMAGECOPY        63.68                         0               5
FLASHBACKLOG     .51                       .25               2

已选择6行。

SQL>


计算flash recovery area已经占用的空间:

SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;

SUM(PERCENT_SPACE_USED)*3/100
-----------------------------
                       2.1231                     
--在11.2以后,v$flash_recovery_area_usage已经被v$recovery_area_usage取代。

可以看到,这里已经有2.1231G使用了,这说明我们刚开始设置的db_recovery_file_dest_size=2G不足,
导致online redo log无法归档,在这里,我们通过设置db_recovery_file_dest_size参数,
增大了flash recovery area来解决这个问题。
增加Flash recovery area 是一种解决方法,也可以将归档指定到其他的目录来解决这个问题。
或者删除备份中的obsolete备份,都可以解决问题。


1.7  Flash Recovery Area 的备份
备份命令是Flash recovery Area,该命令是Oracle 10g以后才有的。
10g引进了flash recovery area,同时在rman备份中支持对该区域的备份。

在9i中oracle引入flashback查询,依赖于undo表空间存储的信息来闪回查询以前的版本,
当然这个受限于undo表空间的大小,以及保留策略。

在10g中oracle又引入了新的flashback功能,使用了flash recovery area来存储flashback 1og等等。
这个区域默认创建在oracle_base目录下。
在其中可以存放备份集、镜像拷贝、归档日志、自动备份的控制文件以及spfile和flashback logs。
存放位置和大小由参数db_recovery_file_dest和db_recovery_file_dest_size决定。

默认情况数据库的flashback database是关闭,可以在mount exclusive状态下打开。


看一下Oracle 官方文档上的几段文字:
To free space in the FRA we could do take a backup of the Flash Recovery Area using the
command BACKUP RECOVERY AREA.This command will take the backup of all the files in the
FRA to tape only. After this the space occupied by the files in the FRA will be
marked as reclaimable。

the larger the fast recovery area, the more useful it is. Ideally, the fast recovery
area should be large enough for copies of the data files, control files, online
redo log files, and archived redo log files needed to recover the database,
and also the copies of these backup files that are kept based on the retention policy.

The Flash Recovery Area is a unified storage location for all recovery-related files
and activities in an Oracle Database. It includes Control File, Archived Log Files,
Flashback Logs, Control File Autobackups, Data Files, and RMAN files.


从上面的几段话,我们可以得到一下信息:
(1)    BACKUP RECOVERY AREA 命令只能备份到磁带上。
         在磁盘上备份会报如下错误:
RMAN> BACKUP RECOVERY AREA;

启动 backup 于 12-8月 -10
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=15 设备类型=DISK
说明与资料档案库中的任何归档日志都不匹配
说明与资料档案库中的任何数据文件副本都不匹配

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: backup 命令 (在 08/12/2010 13:50:10 上) 失败
RMAN-06603: 必须在磁盘设备上使用 RECOVERY AREA, RECOVERY FILES 或 DB_RECOVERY_FILE_DEST 指定 TO DESTINATION 选项


(2)    Flash recovery area 包含内容:控制文件,归档文件,flashback logs, 控制文件,
自动备份的控制文件,数据文件,数据文件拷贝,RMAN 文件(包括备份集,镜像备份)。

(3) BACKUP RECOVERY AREA 将备份所有Flash recovery area中的内容。

2 Flashback Database
2.1 Flashback Database 说明
            Flashback Database 功能非常类似与RMAN的不完全恢复,
            它可以把整个数据库回退到过去的某个时点的状态,
            这个功能依赖于Flashback log 日志。 比RMAN更快速和高效。
             因此Flashback Database 可以看作是不完全恢复的替代技术。
             但它也有某些限制:
            (1)Flashback Database 不能解决Media Failure, 这种错误RMAN恢复仍是唯一选择。
            (2)如果删除了数据文件或者利用Shrink技术缩小数据文件大小,
                 这时不能用Flashback Database技术回退到改变之前的状态,
                 这时候就必须先利用RMAN把删除之前或者缩小之前的文件备份restore 出来,
                 然后利用Flashback Database 执行剩下的Flashback Datbase。
            (3)如果控制文件是从备份中恢复出来的,或者是重建的控制文件,
                 也不能使用Flashback Database。
            (4)使用Flashback Database锁能恢复到的最早的SCN,
                 取决于Flashback Log中记录的最早SCN。

2.2 Flashback Database 架构
Flashback Database 整个架构包括一个进程Recover Writer(RVWR)后台进程,
Flashback Database Log日志 和Flash Recovery Area。
一旦数据库启用了Flashback Database, 则RVWR进程会启动,
该进程会向Flash Recovery Area中写入Flashback Database Log,
这些日志包括的是数据块的 " 前镜像(before image)",
 这也是Flashback Database 技术不完全恢复块的原因。

[oracle@rac1 ~]$ ps -ef|grep rvwr
oracle    6326     1  0 10:36 ?        00:00:00 ora_rvwr_orcl1

[oracle@rac2 ~]$ ps -ef|grep rvwr
oracle    6474     1  0 10:36 ?        00:00:00 ora_rvwr_orcl2

2.3 启用Flashback Database 步骤
数据库的Flashback Database功能缺省是关闭的,要想启用这个功能,就需要做如下配置。

2.3.1 配置Flash Recovery Area
这个参考1.1 节的配置。

2.3.2 启动flashback database
默认情况数据库的flashback database是关闭,
可以在mount exclusive状态下打开。在设置了闪回恢复区后,可以启动闪回数据库功能。
> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     12
Next log sequence to archive   13
Current log sequence           13
> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
> startup mount‘
SP2-0714: invalid combination of STARTUP options
> startup mount;
ORACLE instance started.

Total System Global Area  835104768 bytes
Fixed Size                  2257840 bytes
Variable Size             603982928 bytes
Database Buffers          226492416 bytes
Redo Buffers                2371584 bytes
Database mounted.
SQL> alter database flashback on;

数据库已更改。

> alter database open;

Database altered.

> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES


2.4 Flashback Database操作示例

做操作前先备份数据库:
RMAN> backup database;
2.4.1 检查是否启动了flash recovery area
SQL> show parameter db_recovery_file

NAME                    TYPE        VALUE
------------------------------------  ----------- ------------------------------
db_recovery_file_dest       tring       D:/oracle/flash_recovery_area
db_recovery_file_dest_size  big integer 1G

2.4.2 检查是否启用了归档
SQL> archive log list;
数据库日志模式      存档模式
自动存档            启用
存档终点           USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列  9
下一个存档日志序列  11
当前日志序列        11

 
2.4.3 检查是否启用了flashback database
SQL> select flashback_on from v$database;

FLASHBACK_ON    
------------------
YES              

2.4.4 查询当前的scn
SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
947921

2.4.5 查询当前的时间
SQL> select to_char(sysdate,‘yy-mm-dd hh24:mi:ss‘) time from dual;

TIME
-----------------
09-10-14 14:37:05

2.4.6 删除表A
SQL> select * from A;

ID  NAME
---------- ----------
1  tianlesoftware
2  dave

SQL> drop table A;

表已删除。

SQL> commit;


2.4.7 重启DB 到mount
Flashback Database 实际是对数据库的一个不完全恢复操作,
因为需要关闭数据库重启到mount状态
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area  209715200 bytes
Fixed Size                  1248116 bytes
Variable Size              79692940 bytes
Database Buffers          121634816 bytes
Redo Buffers                7139328 bytes

数据库装载完毕。

2.4.8 执行恢复:分timestamp 或者SCN两种
SQL> Flashback database to timestamp to_timestamp(‘09-10-14 14:37:05‘,‘yy-mm-dd hh24:mi:ss‘);

闪回完成。

或者:

SQL> Flashback database to scn 947921;

闪回完成。

2.4.9 打开数据库
在执行完flashback database 命令之后,oracle 提供了两种方式让你修复数据库:
1). 直接alter database open resetlogs 打开数据库,当然,指定scn 或者timestamp 时间点之后
    产生的数据统统丢失。
2). 先执行alter database open read only 命令,以read-only 模式打开数据库,
    然后立刻通过逻辑导出的方式将误操作涉及表的数据导出,再执行recover database
    命令以重新应用数据库产生的redo,将数据库修复到flashback database 操作前的状态,
    然后再通过逻辑导入的方式,将之前误操作的表重新导入,这样的话对现有数据的影响最小,
    不会有数据丢失。

这里演示,就以resetlogs方式打开:

SQL> alter database open resetlogs;

数据库已更改。

验证数据:

SQL> select * from A;

        ID NAME

---------- ----------
         1 tianlesoftware
         2 dave

 

2.5 和Flashback Database 相关的3个视图
2.5.1 V$database
 这个视图可以查看是否启用了Flashback database功能

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

 

2.5.2 V$flashback_database_log
Flashback Database 所能回退到的最早时间,取决与保留的Flashback Database Log 的多少,
该视图就可以查看许多有用的信息。
Oldest_flashback_scn / Oldest_flashback_time : 这两列用来记录可以恢复到最早的时点
Flashback_size: 记录了当前使用的Flash Recovery Area 空间的大小
Retention_target: 系统定义的策略
Estimated_flashback_size: 根据策略对需要的空间大小的估计值

SQL> select oldest_flashback_scn os, to_char(oldest_flashback_time,‘yy-mm-dd hh24:mi:ss‘) ot, retention_target rt,flashback_size fs, estimated_flashback_size es
 from v$flashback_database_log;

        OS OT                        RT         FS         ES
---------- ----------------- ---------- ---------- ----------
   1150657 14-07-01 10:18:39       1440  209715200          0


2.5.3 V$flashback_database_stat
这个视图用来对Flashback log 空间情况进行更细粒度的记录和估计。
这个视图以小时为单位记录单位时间内数据库的活动量:
            Flashback_Data 代表Flashback log产生数量,
            DB_Date 代表数据改变数量,
            Redo_Date代表日志数量,
通过这3个数量可以反映出数据的活动特点,更准确的预计Flash Recovery Area的空间需求

SQL> alter session set nls_date_format=‘hh24:mi:ss‘;

会话已更改。

SQL> select *from v$flashback_database_stat;

BEGIN_TI END_TIME FLASHBACK_DATA DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE
-------- -------- -------------- ---------- ---------- ------------------------
14:43:10 15:15:28        6455296   29310976    3898368              0

 
3 Flashback Drop
Flashback Drop 是从Oracle 10g 开始出现的,用于恢复用户误删除的对象(包括表,索引等),
这个技术依赖于Tablespace Recycle Bin(表空间回收站),这个功能和windows的回收站非常类似。
Flashback 不支持sys用户. system表空间下的对象,也不能从回收站里拿到。
故使用SYS 或者SYSTEM用户登陆时, show recyclebin 为空。
Flashback Drop 是基于Tablespace RecycleBin 来实现恢复的。
它只支持闪回与table 相关连的对象,比如表,索引,约束,触发器等。
如果是函数或者存储过程等,就需要使用Flashback Query来实现。

3.1 Tablespace Recycle Bin
从Oracle 10g 开始, 每个表空间都会有一个叫作回收站的逻辑区域,当用户执行drop命令时,
被删除的表和表的关联对象( 包括索引, 约束,触发器,LOB段,LOB index 段) 不会被物理删除,
这些对象先转移到回收站中,这就给用户提供了一个恢复的可能。
When you drop a table, the database does not immediately remove the space associated
with the table. The database renames the table and places it and any associated
objects in a recycle bin, where, in case the table was dropped in error,
it can be recovered at a later time. This feature is called Flashback Drop,
and the FLASHBACK TABLE statement is used to restore the table. Before discussing
the use of the FLASHBACK TABLE statement for this purpose, it is important to
understand how the recycle bin works, and how you manage its contents.
The recycle bin is actually a data dictionary table containing information about
dropped objects. Dropped tables and any associated objects such as indexes,
constraints, nested tables, and the likes are not removed and still occupy space.
They continue to count against user space quotas, until specifically purged from
the recycle bin or the unlikely situation where they must be purged by the
database because of tablespace space constraints.

 
初始化参数recyclebin 用于控制是否启用recyclebin功能,缺省是ON, 可以使用OFF关闭。
> show parameter recycle;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
buffer_pool_recycle                  string
db_recycle_cache_size                big integer 0
recyclebin                           string      on


禁用该功能:

SQL> alter system set recyclebin=off;
SQL> alter system set recyclebin=on;

SQL> alter session set recyclebin=off;
SQL> alter session set recyclebin=on;

禁用后删除的对象将直接删除,不会写到Recycle中,当然在删除时,指定purge 参数,
表也将直接删除,不会写到recyclebin中。

SQL> drop table name purge;
查看recyclebin中的对象列表:

SQL> select * from A;

        ID

        ----------

         1

         2

         3

SQL> drop table A;

表已删除。

SQL> show recyclebin

ORIGINAL NAME    RECYCLEBIN NAME       OBJECT TYPE  DROP TIME
----------------      -----------------------------          ------------      
A   BIN$RWXQQcTPRde0ws4h9ewJcg==$0  TABLE     2009-10-15:12:44:33

 

查看recyclebin中对象:

SQL> select original_name,object_name from recyclebin;

ORIGINAL_NAME       OBJECT_NAME
-------------------------------- ------------------------------
A                      BIN$RWXQQcTPRde0ws4h9ewJcg==$0

查看recyblebin对象里的内容:

SQL> select * from "BIN$RWXQQcTPRde0ws4h9ewJcg==$0";

        ID
       ----------
         1
         2
         3

 
表空间的Recycle Bin 区域只是一个逻辑区域,而不是从表空间上物理的划出一块区域固定用于回收站,
因此Recycle Bin是和普通对象共用表空间的存储区域,
或者说是Recycle Bin的对象要和普通对象抢夺存储空间。
当发生空间不够时,Oracle会按照先入先出的顺序覆盖Recycle Bin中的对象。
如果表空间的数据文件打开了自动扩展,则在数据文件扩展之前,不会清除recyclebin中的内容。
每次扩展的时候,Oracle实际上是执行了alter database datafile resize命令。
 
也可以手动的删除Recycle Bin占用的空间:
            1). Purge tablespace tablespace_name:
                用于清空表空间的Recycle Bin
            2). Purge tablespace tablespace_name user user_name:
                清空指定表空间的Recycle Bin中指定用户的对象
            3). Purge recyclebin:
                删除当前用户的Recycle Bin中的对象
            4). Purge dba_recyclebin:
                删除所有用户的Recycle Bin中的对象,该命令要sysdba权限
            5). Drop table table_name purge: 
                删除对象并且不放在Recycle Bin中,
                即永久的删除,不能用Flashback恢复。
            6). Purge index recycle_bin_object_name:
                当想释放Recycle bin的空间,
                又想能恢复表时,可以通过释放该对象的index所占用的空间来缓解空间压力。
                因为索引是可以重建的。

3.2 Flashback Drop 实例操作
SQL> select original_name,object_name from recyclebin;

ORIGINAL_NAME         OBJECT_NAME
-------------------------------- ------------------------------
A                       BIN$RWXQQcTPRde0ws4h9ewJcg==$0

 

SQL> flashback table a to before drop;

闪回完成。

SQL> select * from a;

        ID
         ----------
         1
         2
         3

当我们删除表A后,在新建表A,这时在恢复的时候就会报错,此时我们在闪回时,
对表重命名就可以了:

SQL> drop table a;

表已删除。

SQL> create table a

  2  (id number(1));

表已创建。

SQL> flashback table a to before drop ;

flashback table a to before drop

*

第 1 行出现错误:

ORA-38312: 原始名称已被现有对象使用

SQL> flashback table a to before drop rename to B;

闪回完成。

SQL> select * from B;

        ID
        ----------
         1
         2
         3

当我们删除表A,在新建表A,在删除它,这是在Recycle Bin中就会有2个相同的表名,
此时恢复我们就要指定object_name才行.

SQL> select * from B;

        ID
        ----------
         1
         2
         3

SQL> drop table B;

表已删除。

SQL> create table B(name varchar(20));

表已创建。

SQL> drop table B;

表已删除。

SQL> select original_name,object_name from recyclebin;

ORIGINAL_NAME                    OBJECT_NAME
--------------------------------            ------------------------------
B                                BIN$vYuv+g9fTi2exYP9X2048Q==$0
B                                BIN$geQ9+NekSjuRvzG+TqDVWw==$0

SQL> flashback table "BIN$vYuv+g9fTi2exYP9X2048Q==$0" to before drop;

闪回完成。

SQL> select * from B;

        ID
       ----------
         1
         2
         3

 
一旦完成闪回恢复,Recycle Bin中的对象就消失了.
如果表上索引或者约束等信息,这些信息也会被恢复,但是这些对象会使用Oracle 自动的命名。
我们需要查看这些对象,然后对这些对象重新命名:如:
SQL>select index_name from user_indexes where table_name = ‘job_history‘;

INDEX_NAME
------------------------------
BIN$DBo9UChwZSbgQFeMiAdCcQ==$0
BIN$DBo9UChtZSbgQFeMiAdCcQ==$0
BIN$DBo9UChuZSbgQFeMiAdCcQ==$0
BIN$DBo9UChvZSbgQFeMiAdCcQ==$0

重命名:

SQL>alter index "bin$dbo9uchtzsbgqfemiadccq==$0" rename to jhist_job_ix;


Flashback Drop 需要注意的地方:
1). 只能用于非系统表空间和本地管理的表空间
2). 对象的参考约束不会被恢复,指向该对象的外键约束需要重建。
3). 对象能否恢复成功,取决与对象空间是否被覆盖重用。
4). 当删除表时,信赖于该表的物化视图也会同时删除,但是由于物化视图并不会被放入recycle bin,
    因此当你执行flashback table to before drop 时,也不能恢复依赖其的物化视图,
    需要dba 手工介入重新创建。
5). 对于Recycle Bin中的对象,只支持查询.

4 Flashback Query
Flashback 是ORACLE 自9i 就开始提供的一项特性,在9i 中利用oracle 查询多版本一致的特点,
实现从回滚段中读取表一定时间内操作过的数据,可用来进行数据比对,
或者修正意外提交造成的错误数据,该项特性也被称为Flashback Query。
Flashback Query分
Flashback Query,
Flashback Version Query,
Flashback Transaction Query 三种。

4.1  Flashback Query
Flashback Query 是利用多版本读一致性的特性从UNDO 表空间读取操作前的记录数据。
flashback query 对v$tables,x$tables 等动态性能视图无效,
不过对于dba_*,all_*,user_*等数据字典是有效的。
该特性也完全支持访问远端数据库,比如select * from as of scn 3600;的形式。

4.1.1  多版本读一致性
不同的事务在写数据时,会将数据的前映像写入undo 表空间,这样如果同时有其它事务查询该表数据,
则可以通过undo 表空间中数据的前映像来构造所需的完整记录集,
而不需要等待写入的事务提交或回滚。
Flashback query 有多种方式构建查询记录集,记录集的选择范围可以基于时间或基于scn,
甚至可以同时查询出记录在undo 表空间中不同事务时的前映象。        
用法与标准查询非常类似,要通过flashback query 查询undo 中的撤销数据,
最简单的方式只需要在标准查询语句的表名后面跟上as of timestamp(基于时间)或as of scn
(基于scn)即可。
as of timestamp|scn 的语法是自9iR2 后才开始提供支持。

4.1.2  As  of  timestamp 的示例:
SQL>  alter session set nls_date_format=‘YYYY-MM-DD hh24:mi:ss‘;

会话已更改。

SQL> select sysdate from dual;

SYSDATE
-------------------
2009-10-15 19:04:16

SQL> select * from A;

        ID
        ----------
         2
         1
         3
         4

模拟用户误操作,删除数据

SQL> delete from A;

已删除4行。

SQL> commit;

提交完成。

SQL> select * from A;

未选定行

查看删除之前的状态:假设当前距离删除数据已经有5 分钟左右的话:

SQL> select * from A as of timestamp sysdate-5/1440;

      

热门排行

今日推荐

热门手游