【生产篇】_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．在备库standby端执行，根据删除操作前时间点执行备库不完全恢复

SQL> alter database recover managed standby database cancel;

数据库已更改。

SQL> ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE until time ’2019-07-08 22:14:13′;

数据库已更改。

SQL> select count(*) from ethan_adg;
COUNT(*)———91049

3．使用逻辑Exp/imp
备库逻辑导出操作：
[oracle@host02 admin]$expethan/ethan@standbytables=(etha{n}_{a}dg)file=etha{n}_{a}dg.dmp主库逻辑导入操作[oracle@host01admin]$imp ethan/ethan@primarydb tables=(ethan_adg) file=ethan_adg.dmp ignore=y
注意：
当然也可以使用expdp/impdp的形式进行逻辑恢复，这里使用exp/imp比较方便，故本文做了简单演示；在恢复的表比较大的时候，可以使用expdp开启多并发导出，减少误操作表的恢复时间，尽快恢复业务。

4．登陆primay库，验证表ethan_adg是否已经恢复
SQL> conn ethan/ethan@standbySQLPlus: Release 12.1.0.2.0 Production on Mon Jul 8 22:29:45 2019Copyright © 1982, 2014, Oracle. All rights reserved.Connected 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> select count() from ethan_adg;COUNT(*)———-91049

5．在standby同步库恢复原有时间间隔

SQL> alter database recover managed standby database cancel;

SQL> alter database recover managed standby database delay 60 disconnect from session;
至此，使用ADG的delay同步延迟设置恢复表删除操作完成；此恢复同样适用于任何的人为误操作恢复。

【结语】

1.在业务允许的前提下，合理设置主备库的同步间隔时间，可用于快速处理任意的人为误操作行为。
2.但，万事有利就有弊；使用delay延迟同步这种后悔药，需掌控好时间；数据恢复可以在延迟应用日志时间差内任意时间。如当前时间点为11:00,延迟同步为60min，同步库数据可以恢复10:00至11:00内的任意一点数据，假如我们恢复数据到了10:30分后，还想回退10:00到10:30间的数据是不能够的，原因很好介绍：10:00到10:30的数据备库已经进行了落盘；但10:30到11:00的数据还是能够接着“吃药”的。所以在不是很确定异常操作的情况下，可以分多个颗粒度小的时段的进行逐步日志应用，避免“无效吃药”，到时候只能做耗时很长的全库恢复了。
3.鉴于1的分析，总结一句就是“吃药时间需谨慎”。

如果大家觉得此文有帮助，欢迎扫描关注如下微信公众号