Oracle 闪回（flashback）数据库到指定时间点

如果是update,delete类误操作且已经commit，优先考虑使用flashback query进行恢复。

select * from test1 as of timestamp to_timestamp('2018-01-13 16:59:29','YYYY-MM-DD hh24:mi:ss');

如果是drop或truncate table，则不能使用闪回查询，需要使用备库进行整库闪回。

一、 闪回前检查

1. flashback database功能是否开启

通常主库不开启flashback database功能而在adg库开启，主库整库闪回影响太大，可能得不偿失。

select flashback_on from v$database;

2. 闪回日志保留时间

闪回日志保留时间须大于要恢复到的时间点，也可以直接到fra目录查看闪回日志保留情况，建议保留3天（4320分钟）。

show parameter flashback

NAME TYPE VALUE
------------------------------------ ------------------------------ -----------------------
db_flashback_retention_target integer 4320

3. 归档日志保留时间

闪回日志能保证闪回到3天前的数据，但是归档日志可能会由于空间压力被OMF删除，如果归档日志被删除，需要从主库传输到备库，甚至从备份软件还原后再传输到备库。

若闪回保留3天，通常需要有最近3天的归档日志才能闪回到3天前。用官方文档的话说，

Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is 1 week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.

Using Flashback Database and Restore Points

二、 闪回整库步骤

1. 取消备库日志应用

alter database recover managed standby database cancel;

2. 备库执行闪回命令

SQL> flashback database to timestamp to_timestamp('2019-06-05 09:58','yyyy-MM-dd hh24:mi');
#耐心等待完成
Flashback complete.

flashback database的过程中，可以另外开启一个窗口，通过v$session_longops查询进度（未必准确，仅做参考）。另外闪回的进度不是线性的，有时快有时慢。

如果出现类似报错，说明18636号归档日志没有找到。

ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not available
ORA-38762: redo logs needed for SCN 1499058577 to SCN 1499283544
ORA-38761: redo log sequence 18636 in thread 1, incarnation 2 could not be
accessed

需要从主库或者备份文件获得，传输到备库后注册进rman，然后重新执行flashback database。

rman target /

RMAN> catalog archivelog '/archivelog/2017_12_27/1_18636_870799604.dbf';
RMAN> catalog archivelog '/archivelog/2017_12_27/1_18637_870799604.dbf';
RMAN> ....

禁用系统触发器

是因为之前有创建open数据库自动启动mrp进程的触发器，如果不禁掉在open数据库后会自动应用日志，导致数据时间点错乱。没有的话可以忽略。

alter system set "_system_trig_enabled"=false;

3. 闪回完成后以只读方式打开备库

#可以看到闪回后实例状态变为了MOUNTED
SQL> select status from v$instance;

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

SQL> alter database open read only;
Database altered.

检查闪回后的数据是否正确，验证无误后，在主库创建dblink将准确数据插入临时表，交给业务方修复数据

-- 主库创建dblink
CREATE PUBLIC DATABASE LINK recover_link CONNECT TO rec_user IDENTIFIED BY "xxxx" USING 'recover_dg';
-- 创建临时表
create table rec_user.recover_table_bak as select * from rec_user.recover_table@recover_link;

-- 待业务方修复完数据记得删除link
drop public database link recover_link;

至此数据恢复已完成，我们还需要恢复主从同步。

三、 主从同步恢复

1. 闪回从库到离从库最后一个归档最近的时间点

追主库时需要应用的日志最少，方便恢复主从同步

flashback database to timestamp to_timestamp('2019-06-05 19:12','yyyy-MM-dd hh24:mi');

2. 启动验证

alter database open read only;

3. 验证无误后开启日志应用

#开启日志应用
SQL> alter database recover managed standby database using current logfile disconnect from session parallel 4;
Database altered.

#查看进程情况
SQL> select PROCESS,CLIENT_PROCESS,SEQUENCE#,STATUS,DELAY_MINS from v$managed_standby;

PROCESS   CLIENT_P  SEQUENCE# STATUS       DELAY_MINS
--------- -------- ---------- ------------ ----------
ARCH      ARCH          43585 CLOSING               0
ARCH      ARCH              0 CONNECTED             0
ARCH      ARCH              0 CONNECTED             0
ARCH      ARCH              0 CONNECTED             0
RFS       LGWR          43586 IDLE                  0
RFS       ARCH              0 IDLE                  0
MRP0      N/A           43584 APPLYING_LOG          0

7 rows selected.

#检查主从apply lag
SQL> select value from v$dataguard_stats where name='apply lag'; 

VALUE
----------------------------------------------------------------
+00 00:11:13

SQL> select value from v$dataguard_stats where name='apply lag'; 

VALUE
----------------------------------------------------------------
+00 00:00:00

数据恢复及主从同步恢复完成~

记得把系统触发器启用回来

alter system set "_system_trig_enabled"=true;