【生产篇】_ADG实操：如何吃下这颗“后悔药”

																		    Note-taker：Ethan_Yang 
																		    Recording time: 2019/09/23
																		    Location:BJ T3
																		    number of docs:11

【引言】

之前的一篇公众推文介绍了ADG的两种用途，详见文章《【生产篇】_Oracle ADG同步技术 ——DBA必备的一种“后悔药”》, 文中也承诺了将要推一篇有关ADG设置delay延迟同步的案例。本文将介绍ADG这种“后悔药”的一种实操服用方法。

【场景介绍】

在库到了T级别，业务不允许过长或不允许中断的情况，如何办？这种场景下就可以借助DG端恢复。DG（Data Guard）有个参数为delay，利用延迟应用日志时间差，来迅速将standby recover到故障时间点之前，然后利用逻辑exp&imp来实现表级恢复。

接下来，本文将讲述一个利用DG的delay延迟日志应用做的表误删除操作模拟恢复。

【操作步骤】
1.在standby端，设置日志的延迟应用时间
这里有两种设置方式：
方式1: 备库延迟60分钟应用主库日志

SQL>alter database recover managed standby database DELAY 60 disconnect from session;

方法2: 主库log_ archive_dest_n参数中指定了delay属性

SQL>alter system set log_archive_dest_2='service=standby lgwr async delay=60 valid_for=(all_logfiles,all_roles) db_unique_name=standby';

注意：
这里的delay设置很容易让人误认为是延迟发送主库日志到备库为60min，真实意思为日志到备库后，延迟60min时间应用主库日志。但这里有个特殊：如备库应用主库日志的语句中使用了using current logfile指定了实时应用，具体命令如下，即使在log_ archive_dest_n参数中指定了delay属性，备库也会忽略delay属性。

PS：上述两种方式推荐方式
1.原因操作简洁，操作在备库;
2.主库不用修改参数。

主库模拟表误删除操作

[oracle@host02 admin]$ sqlplus ethan/ethan@standbySQL*Plus: Release 12.1.0.2.0 Production on Mon Jul 8 21:54:50 2019Copyright (c) 1982, 2014, Oracle.  All rights reserved.Last Successful login time: Mon Jul 08 2019 21:53:46 +08:00Connected to:Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit ProductionWith the Partitioning, Oracle Label Security, OLAP, Advanced Analyticsand Real Application Testing options

    SQL> create table ethan_adg as select * from dba_objects;
    Table created
    SQL> select count(*) from ethan_adg;
    COUNT(*)———-91049
    SQL> select to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
    TO_CHAR(SYSDATE,'-----------------20190708 22:14:13

——执行如下删除操作前，记录主库误操作前的时间点，也即是事件恢复点；

SQL> drop table ethan_adg;Table droppedSQL> alter system switch logfile;
System altered

2．在备库stand