【DATAGUARD】物理dg在主库丢失归档文件的情况下的恢复(七)-阿里云开发者社区

【DATAGUARD】物理dg在主库丢失归档文件的情况下的恢复(七)

一.1 BLOG文档结构图

一.2 前言部分

一.2.1 导读

各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：

① 物理dg的在主库丢失归档文件的情况下的恢复

② 物理dg管理和维护的一些sql

注意：本篇BLOG中代码部分需要特别关注的地方我都用黄色背景和红色字体来表示，比如下边的例子中，thread 1的最大归档日志号为33，thread 2的最大归档日志号为43是需要特别关注的地方。

List of Archived Logs in backup set 11

Thrd Seq Low SCN Low Time Next SCN Next Time

---- ------- ---------- ------------------- ---------- ---------

1 32 1621589 2015-05-29 11:09:52 1625242 2015-05-29 11:15:48

1 33 1625242 2015-05-29 11:15:48 1625293 2015-05-29 11:15:58

2 42 1613951 2015-05-29 10:41:18 1625245 2015-05-29 11:15:49

2 43 1625245 2015-05-29 11:15:49 1625253 2015-05-29 11:15:53

本文如有错误或不完善的地方请大家多多指正，ITPUB留言或QQ皆可，您的批评指正是我写作的最大动力。

一.2.2 实验环境介绍

项目	主库	dg库
db 类型	单实例	单实例
db version	11.2.0.3	11.2.0.3
db 存储	FS type	FS type
ORACLE_SID	oradg11g	oradgphy
db_name	oradg11g	oradg11g
主机IP地址：	192.168.59.130	192.168.59.130
OS版本及kernel版本	RHEL6.5 64位，2.6.32-504.16.2.el6.x86_64	RHEL6.5 64位，2.6.32-504.16.2.el6.x86_64
OS hostname	rhel6_lhr	rhel6_lhr

一.2.3 相关参考文章链接

dg的系列文章参考：

【DATAGUARD】基于同一个主机建立物理备库和逻辑备库（一）： http://blog.itpub.net/26736162/viewspace-1448197/
【DATAGUARD】基于同一个主机建立物理备库和逻辑备库（二 ): http://blog.itpub.net/26736162/viewspace-1448207/
【DATAGUARD】基于同一个主机建立物理备库和逻辑备库（三 ): http://blog.itpub.net/26736162/viewspace-1481972/
【DATAGUARD】基于同一个主机建立物理备库和逻辑备库 (四)--添加一个物理dg节点：http://blog.itpub.net/26736162/viewspace-1484878/

【DATAGUARD】物理dg的switchover切换（五）：http://blog.itpub.net/26736162/viewspace-1753111/

【DATAGUARD】物理dg的failover切换(六)： http://blog.itpub.net/26736162/viewspace-1753130/

一.2.4 本文简介

最近由于合同到期，去面试了几家做oracle dba的工作，面试中出现了不少的问题，有的面试官太奇葩了，问的问题也比较难以回答，可怜我的表达能力不太好，俗话就是说不会忽悠人，因此面试连连碰壁，这也是哥的软肋，本来哥的技术已经很好的了，一般的DBA的活一点问题都没有，可面试就是不能通过，最近真的是身心俱创，不说了，说多了都是泪，这篇blog是基于我去1号店面试的时候面试官提的一个问题，当时隐约觉得有什么办法可以恢复，但是想不起来，结果就回答只能重建了，回来后搜了搜资料还是可以恢复的，趁着周末就实验了一番，今天贴出来给大家共享共享。

一.3 相关知识点扫盲

都是DG的一些基本维护知识，这里就不贴了，直接进入实验环节吧。

Using RMAN Incremental Backups to Refresh a Standby Database

You can create an incremental backup of the target database containing changes to the database since the creation of the duplicate or the previous syncrhonization. You can apply the incremental backup to the standby database.

Note:

This technique cannot be used to update a duplicate database.

RMAN enables you to synchronize a standby database with a primary database by creating an incremental backup at the source database that contains all changed blocks since the duplicate was created or last refreshed. You then apply the incremental backup to the standby database, which updates it with all changes.

This capability facilitates the temporary conversion of a physical standby database into a reporting database, as described in Oracle Data Guard Concepts and Administration. In particular, this capability makes it possible to reverse the effects of converting the standby into a reporting database. After the standby database has been used for reporting or testing, Flashback Database can reverse any changes resulting from that work, returning the database to its contents when it was still a standby. An incremental backup created with BACKUP INCREMENTAL... FROM SCN can be used to refresh the standby with changes at the primary since the conversion and then managed recovery can resume. The effect is to return the reporting database to its role as standby.

For more details on this scenario, see Oracle Data Guard Concepts and Administration.

Using BACKUP INCREMENTAL... FROM SCN

The incremental backup is created at the source database by means of the BACKUP INCREMENTAL FROM SCN=n form of the BACKUP command. For example:

BACKUP DEVICE TYPE SBT INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
FORMAT '/tmp/incr_standby_%U';

RMAN uses the selected SCN as the basis for this incremental backup. For all files being backed up, RMAN includes all data blocks that were changed at SCNs greater than or equal to the FROM SCN in the incremental backup.

Note:

· RMAN does not consider the incremental backup as part of a backup strategy at the source database. The backup is not suitable for use in a normal RECOVER DATABASE operation at the source database.

· The backup sets produced by this command are written to ?/dbs by default, even if the flash recovery area or some other backup destination is defined as the default for disk backups.

· You must create this incremental backup on disk for it to be useful. When you move the incremental backup to the standby, you must catalog it at the standby as described in "Step 3: Catalog the Incremental Backup Files at the Standby Database". Backups on tape cannot be cataloged.

See Also:

《Oracle Database Backup and Recovery Reference 》 for more details on BACKUP command syntax

Refreshing a Standby Database With INCREMENTAL FROM SCN Backups: Example

This example shows the steps required to update a standby database using incremental backups. The assumption is that you have already activated the standby, performed your tests or other operations at the standby, and then used Flashback Database to undo the effects of those changes. The task here is to refresh the standby with the latest changes to the primary, so that it can resume its role as a standby database.

Step 1: Create the Incremental Backup

Create the needed incremental backup at the source database, using BACKUP with the INCREMENTAL FROM SCN clause.

Assume that the incremental backup to be used in updating the duplicate database is to be created on disk, with the filenames for backup pieces determined by the format /tmp/incr_for_standby/bkup_%U.

RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
FORMAT '/tmp/incr_for_standby/bkup_%U';

Step 2: Make the Incremental Backup Accessible at the Standby Database

Make the backup pieces containing the incremental backup available in some directory accessible on the system containing the standby database. For this example, assume that the destination directory is called /standbydisk1/incrback/ and ensure that it contains nothing besides the incremental backups from Step 1.

Step 3: Catalog the Incremental Backup Files at the Standby Database

Use the RMAN CATALOG command to register the backup sets in the RMAN repository at the duplicate. With an RMAN client connected to the standby database and the recovery catalog (if you use one at the standby), mount the standby and run the following command:

RMAN> CATALOG START WITH '/standbydisk1/incrback/';

The backups are now available for use in recovery of the standby.

Step 4: Apply the Incremental Backup to the Standby Database

Use the RMAN RECOVER command with the NOREDO option to apply the incremental backup to the standby database. All changed blocks captured in the incremental backup are updated at the standby database, bringing it up to date with the primary database. With an RMAN client connected to the standby database, run the following command:

RMAN> RECOVER DATABASE NOREDO;

You can now resume managed recovery at the standby. Any redo logs required at the standby with changes since those contained in the incremental are automatically requested from the primary and applied

一.4 实验部分

一.4.1 实验目标

①　主库丢失归档文件，然后在不重建物理dg的情况下来恢复物理dg

一.4.2 实验过程

一.4.2.1 主备库环境

主库：

20:39:41 SQL> select dbid,name,current_scn,protection_mode,protection_level,database_role,force_logging,open_mode,switchover_status from v$database;

DBID NAME CURRENT_SCN PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE FOR OPEN_MODE SWITCHOVER_STATUS

---------- --------- ----------- -------------------- -------------------- ---------------- --- -------------------- --------------------

1403587593 ORADG11G 2240299 MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY YES READ WRITE TO STANDBY

已用时间: 00: 00: 00.01

20:39:42 SQL>

20:42:29 SQL> archive log list;

数据库日志模式存档模式

自动存档启用

存档终点 USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列 47

下一个存档日志序列 49

当前日志序列 49

20:43:02 SQL>

备库：

20:40:39 SQL> select dbid,name,current_scn,protection_mode,protection_level,database_role,force_logging,open_mode,switchover_status from v$database;

DBID NAME CURRENT_SCN PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE FOR OPEN_MODE SWITCHOVER_STATUS

---------- --------- ----------- -------------------- -------------------- ---------------- --- -------------------- --------------------

1403587593 ORADG11G 2240295 MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY YES READ ONLY WITH APPLY NOT ALLOWED

已用时间: 00: 00: 00.06

20:40:44 SQL>

20:42:23 SQL> archive log list;

数据库日志模式存档模式

自动存档启用

存档终点 USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列 47

下一个存档日志序列 0

当前日志序列 49

20:43:23 SQL>

一.4.2.2 模拟归档丢失

备库操作，备库取消归档应用，让备库处于只读模式：

20:43:23 SQL> ALTER DATABASE recover managed standby DATABASE cancel;

数据库已更改。

已用时间: 00: 00: 01.00

20:44:39 SQL>

20:44:39 SQL> select dbid,name,current_scn,protection_mode,protection_level,database_role,force_logging,open_mode,switchover_status from v$database;

DBID NAME CURRENT_SCN PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE FOR OPEN_MODE SWITCHOVER_STATUS

---------- --------- ----------- -------------------- -------------------- ---------------- --- -------------------- --------------------

1403587593 ORADG11G 2240536 MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY YES READ ONLY NOT ALLOWED

已用时间: 00: 00: 00.00

20:45:09 SQL>

主库配置归档2的状态为defer，目的是为了不把归档自动传递到备库,实际情况下往往是由于网络故障，备库挂掉等等情况导致，我们多次切换主库日志：

20:50:48 SQL> ALTER system SET log_archive_dest_state_2 = 'defer';

系统已更改。

已用时间: 00: 00: 00.01

20:52:31 SQL>

20:52:31 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.01

20:54:54 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.03

20:54:56 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.01

20:54:57 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.01

20:55:05 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.00

20:55:45 SQL> create table lhr.testdg as select * from dual;

表已创建。

已用时间: 00: 00: 00.10

20:55:49 SQL> insert into lhr.testdg select * from dual;

已创建 1 行。

已用时间: 00: 00: 00.01

20:56:10 SQL> commit;

提交完成。

已用时间: 00: 00: 00.00

20:56:43 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.01

20:56:52 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 00.01

20:56:56 SQL> insert into lhr.testdg select * from dual;

已创建 1 行。

已用时间: 00: 00: 00.00

20:57:07 SQL> commit;

提交完成。

已用时间: 00: 00: 00.00

20:57:11 SQL> alter system switch logfile;

系统已更改。

已用时间: 00: 00: 01.57

20:57:15 SQL>

20:57:15 SQL> select * from lhr.testdg;

已用时间: 00: 00: 00.00

20:58:00 SQL>

20:58:00 SQL> archive log list;

数据库日志模式存档模式

自动存档启用

存档终点 USE_DB_RECOVERY_FILE_DEST

最早的联机日志序列 55

下一个存档日志序列 57

当前日志序列 57

20:58:30 SQL>

查看主库归档情况：

20:58:30 SQL> col name for a100

20:58:55 SQL> set linesize 9999 pagesize 9999

20:58:55 SQL> SELECT dest_id,

20:58:55 2 THREAD#,

20:58:55 3 NAME,

sequence#,

archived,

applied,

a.NEXT_CHANGE#

FROM v$archived_log a

WHERE a.sequence# >= 40

AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

and a.dest_id=1

ORDER BY a.THREAD#,

a.sequence#,

20:58:55 14 a.dest_id;

DEST_ID THREAD# NAME SEQUENCE# ARC APPLIED NEXT_CHANGE#

---------- ---------- ---------------------------------------------------------------------------------------------------- ---------- --- --------- ------------

1 1 40 YES NO 2181533

1 1 41 YES NO 2181856

1 1 42 YES NO 2182794

1 1 43 YES NO 2182842

1 1 44 YES NO 2223480

1 1 45 YES NO 2223488

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_46_bxm58pvo_.arc 46 YES NO 2224321

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_47_bxmc8z90_.arc 47 YES NO 2234639

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_48_bxmc917l_.arc 48 YES NO 2234642

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_49_bxmjnyoh_.arc 49 YES NO 2241189

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_50_bxmjo0gk_.arc 50 YES NO 2241194

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_51_bxmjo1vw_.arc 51 YES NO 2241198

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_52_bxmjo9pw_.arc 52 YES NO 2241209

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_53_bxmjocqc_.arc 53 YES NO 2241214

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_54_bxmjrnt2_.arc 54 YES NO 2241390

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_55_bxmjrrbl_.arc 55 YES NO 2241396

1 1 /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23/o1_mf_1_56_bxmjscy0_.arc 56 YES NO 2241419

已选择17行。

已用时间: 00: 00: 00.00

20:58:56 SQL>

查看备库归档情况：

20:59:04 SQL> col name for a100

21:00:45 SQL> set linesize 9999 pagesize 9999

21:00:45 SQL> SELECT dest_id,

21:00:45 2 THREAD#,

21:00:45 3 NAME,

21:00:45 4 sequence#,

21:00:45 5 archived,

21:00:45 6 applied,

21:00:45 7 a.NEXT_CHANGE#

21:00:45 8 FROM v$archived_log a

21:00:45 9 WHERE a.sequence# >= 45

21:00:45 10 AND resetlogs_change# = (SELECT d.RESETLOGS_CHANGE# FROM v$database d)

21:00:45 11 and a.dest_id=1

21:00:45 12 ORDER BY a.THREAD#,

21:00:45 13 a.sequence#,

21:00:45 14 a.dest_id;

DEST_ID THREAD# NAME SEQUENCE# ARC APPLIED NEXT_CHANGE#

---------- ---------- ---------------------------------------------------------------------------------------------------- ---------- --- --------- ------------

1 1 46 YES YES 2224321

1 1 47 YES YES 2234639

1 1 /u01/app/oracle/flash_recovery_area/ORADGPHY/archivelog/2015_08_23/o1_mf_1_48_bxmc9189_.arc 48 YES YES 2234642

1 1 /u01/app/oracle/flash_recovery_area/ORADGPHY/archivelog/2015_08_23/o1_mf_1_49_bxmjnyj3_.arc 49 YES NO 2241189

已用时间: 00: 00: 00.01

21:00:46 SQL>

可以看到，备库已经断档了，50到56都没有接收，接下来我们删除主库的归档日志，我们只删除54、55这2个归档日志：

[oracle@rhel6_lhr ~]$ cd /u01/app/oracle/flash_recovery_area/ORADG11G/archivelog/2015_08_23

[oracle@rhel6_lhr 2015_08_23]$ ls

o1_mf_1_46_bxm58pvo_.arc o1_mf_1_48_bxmc917l_.arc o1_mf_1_50_bxmjo0gk_.arc o1_mf_1_52_bxmjo9pw_.arc o1_mf_1_54_bxmjrnt2_.arc o1_mf_1_56_bxmjscy0_.arc

o1_mf_1_47_bxmc8z90_.arc o1_mf_1_49_bxmjnyoh_.arc o1_mf_1_51_bxmjo1vw_.arc o1_mf_1_53_bxmjocqc_.arc o1_mf_1_55_bxmjrrbl_.arc

[oracle@rhel6_lhr 2015_08_23]$ ll

total 23624

-rw-r----- 1 oracle asmadmin 422400 Aug 23 17:40 o1_mf_1_46_bxm58pvo_.arc

-rw-r----- 1 oracle asmadmin 17354240 Aug 23 19:23 o1_mf_1_47_bxmc8z90_.arc

-rw-r----- 1 oracle asmadmin 1536 Aug 23 19:23 o1_mf_1_48_bxmc917l_.arc

-rw-r----- 1 oracle asmadmin 6266368 Aug 23 20:54 o1_mf_1_49_bxmjnyoh_.arc

-rw-r----- 1 oracle asmadmin 2048 Aug 23 20:54 o1_mf_1_50_bxmjo0gk_.arc

-rw-r----- 1 oracle asmadmin 1536 Aug 23 20:54 o1_mf_1_51_bxmjo1vw_.arc

-rw-r----- 1 oracle asmadmin 5120 Aug 23 20:55 o1_mf_1_52_bxmjo9pw_.arc

-rw-r----- 1 oracle asmadmin 2048 Aug 23 20:55 o1_mf_1_53_bxmjocqc_.arc

-rw-r----- 1 oracle asmadmin 96256 Aug 23 20:56 o1_mf_1_54_bxmjrnt2_.arc

-rw-r----- 1 oracle asmadmin 2560 Aug 23 20:56 o1_mf_1_55_bxmjrrbl_.arc

-rw-r----- 1 oracle asmadmin 12800 Aug 23 20:57 o1_mf_1_56_bxmjscy0_.arc

[oracle@rhel6_lhr 2015_08_23]$ rm -rf o1_mf_1_54*

[oracle@rhel6_lhr 2015_08_23]$ rm -rf o1_mf_1_55*

You have new mail in /var/spool/mail/oracle

[oracle@rhel6_lhr 2015_08_23]$ ll

total 23524