暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

ADG实操:如何吃下这颗“后悔药”

Ethan_Yang 2019-07-09
1024

【引言】

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

 【场景介绍】

在库到了T级别,业务不允许过长或不允许中断的情况,如何办?这种场景下就可以借助DG端恢复。DGData 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@standby
        SQL*Plus: Release 12.1.0.2.0 Production on Mon Jul 8 21:54:50 2019
        Copyright (c) 1982, 2014, Oracle. All rights reserved.
        Last Successful login time: Mon Jul 08 2019 21:53:46 +08:00
        Connected to:
        Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
        With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
        and 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 dropped
                SQL> 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]$exp ethan/ethan@standby tables=(ethan_adg) file=ethan_adg.dmp

                        主库逻辑导入操作

                          [oracle@host01admin]$imp ethan/ethan@primarydb tables=(ethan_adg) file=ethan_adg.dmp ignore=y

                          PS:当然也可以使用expdp/impdp的形式进行逻辑恢复,这里使用exp/imp比较方便,故本文做了简单演示;在恢复的表比较大的时候,可以使用expdp开启多并发导出,减少误操作表的恢复时间,尽快恢复业务。

                          4.登陆primay库,验证表ethan_adg是否已经恢复

                            SQL> conn ethan/ethan@standbySQL*Plus: Release 12.1.0.2.0 Production on Mon Jul 8 22:29:45 2019
                            Copyright (c) 1982, 2014, Oracle. All rights reserved.
                            Connected to:
                            Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
                            With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
                            and 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的分析,总结一句就是“吃药时间需谨慎”。

                                  4.最后来一张陪我写文章一直到现在的我家“老汉”的“王之蔑视”



                                  如果大家觉得此文有帮助,欢迎关注个人微信微信;

                                  长按识别二维码或微信搜索“一森咖记”



                                  最后修改时间:2020-05-07 23:38:04
                                  文章转载自Ethan_Yang,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                                  评论