转 深入解析：一主多备DG环境，failover的实现过程详解 以及 11g 容灾库可以在线添加tempfile. 以及 11g 容灾库可以在线添加logile.

https://yq.aliyun.com/articles/229600

核心，就是11g通过datafille_scn 号来追日志，而不是日志序列号来追日志。

加快standby switchover 切换的速度，可以先再容灾库加 在线添加logile.这样switchover 时候就不会在redo 产生消耗时间了。

摘要： 在DG中，switchover和failover是两个重要的概念，也是DG实现的核心。根据不同的DG配置，switchover和failover也是有差异的。当主库被crash之后，如何进行DG foilover的操作？概述本文是针对在DG灾备环境进行failover操作以及后续恢复的报告。

在DG中，switchover和failover是两个重要的概念，也是DG实现的核心。根据不同的DG配置，switchover和failover也是有差异的。当主库被crash之后，如何进行DG foilover的操作？

概述

本文是针对在DG灾备环境进行failover操作以及后续恢复的报告。

验证过程

1、A库异常关闭

A库：

SQL>shutdown abort

2、B库进行failover切换为新主库

failover 标准步骤如下：

#取消DG应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
#重启下数据库（建议）
shutdown immediate;
startup
#操作不可逆，确定实际情况需要failover
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH force;
SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, FORCE_LOGGING, DATAGUARD_BROKER, GUARD_STATUS FROM V$DATABASE;
#尝试常规切换为主库
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

如果这一步的常规切换失败，提示需要介质恢复，那么：

1）恢复备库 recover standby database until cancel;
 2）激活备库 alterdatabaseactivatestandbydatabase;

#最后重新启动数据库
shutdownimmediate;
startup

查看此时B库的信息：

SQL>selectname, database_role, open_mode fromgv$database;

可以看到，目前B库已成为新的主库，redo日志的sequence重新开始。

3、要求C库成为新主库的备库

现在要求C库成为新主库的备库。是否需要重建C库呢？答案是不需要。下面具体来看下验证过程。

C库的alert日志：

可以看到，在A库crash之后，C库收到网络无法连接到A库的告警，说明C库目前没有新的操作。

接下来想要C库成为B库（新主库）的备库，就需要尝试在B库上配置DG参数，使得B库的归档可以传输到C库。

同时在B库的tnsnames.ora文件中增加到C库的连接：

#StandbySingle Instance
JYZHAO_S=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.111)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = jyzhao_s))  )

在B库设置完成后，观察B库的告警：

然后返回C库操作，将C库开启实时日志应用：

SQL>alter database recover managed standby database cancel;
Databasealtered.
SQL>alter database recover managed standby database using current logfile disconnect from session;
Databasealtered.

此时再观察C库的告警日志：

上面这个数据文件头的检查点是0，说明数据文件没有正确获取到，实际上是由于OMF的名字有变化，直接将数据文件路径catalog到备份集中，再switch即可。
catalogstartwith'+DATA1/jyzhao/datafile/';
switchdatabase to copy;

再次查询：

此时在mount状态下开启日志应用：

alter database recover managed standby database disconnect from session;

从告警日志观察，确认应用到最新时，取消日志应用：

alter database recover managed standby database cancel;

打开数据库，开启实时应用：

alter database recover managed standby database USING CURRENT LOGFILE disconnect from session;

最终查询可以正常实时应用。

结论

一般来说，在A库crash之后，B库failover成为新的主库，那么原来设置为延迟1小时应用的C 库是可以直接配置成为新主库的备库。A库修复后，也可以通过failover之前的现有备份集来恢复到failover之前的状态，而不需要在新主库重新去备份。

原文发布时间为：2017-11-1
本文作者：赵靖宇
本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”微信公众号

########11g 容灾库可以在线添加tempfile.

Data Guard Physical Standby - Managing temporary tablespace tempfiles (文档 ID 1514588.1)

3.
Verify Primary and Standby tempfiles match and all datafiles are ONLINE

SQL> SELECT TMP.NAME FILENAME, BYTES/1024/1024 "M", TS.NAME TABLESPACE
FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;

4. 11.2 DG 可以在DG Active Data Guard 状态下 添加临时文件。10G 无法做到。

You must add the new tempfile to the new primary site manually after the switchover is complete. This will ensure you maintain the same tempfile structures across the Primary and Standby sites.

5As this an 11.2 environment Active Data Guard can be running while this file is built into the standby sites structure. Managed recovery is started in this demonstration.

New Standby Site

To demonstrate the Standby will be opened read only and the tempfile added manually to the sites configuration.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
MOUNTED

SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database open;

Database altered.

As this an 11.2 environment Active Data Guard can be running while this file is built into the standby sites structure. Managed recovery is started in this demonstration.

SQL> recover managed standby database disconnect using current logfile;
Media recovery complete.
The new 20M tempfile that was added to the Primary has not been replicated, is not a part of the standby sites structure and must be added manually if we want both sites tempfile configuration to be the same.

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
+DATA/rs1/tempfile/temp.264.800115667
+DATA/rs1/tempfile/temp.273.802356687

SQL> alter tablespace temp add tempfile '+DATA' size 20M;

Tablespace altered.

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
+DATA/rs1/tempfile/temp.264.800115667
+DATA/rs1/tempfile/temp.273.802356687
+DATA/rs1/tempfile/temp.274.802357821

##########11g 库在线添加standby logfile

### primary

alter database drop standby logfile group 4;
alter database drop standby logfile group 5;
alter database drop standby logfile group 6;
alter database drop standby logfile group 7;

alter database add logfile thread 1 group 4 size 512M;
alter database add logfile thread 1 group 5 size 512M;
alter database add logfile thread 1 group 6 size 512M;

alter database add standby logfile thread 1 group 7 size 512M;
alter database add standby logfile thread 1 group 8 size 512M;
alter database add standby logfile thread 1 group 9 size 512M;
alter database add standby logfile thread 1 group 10 size 512M;
alter database add standby logfile thread 1 group 11 size 512M;
alter database add standby logfile thread 1 group 12 size 512M;
alter database add standby logfile thread 1 group 13 size 512M;

########standby

备库：
alter system set standby_file_management=manual;
alter database recover managed standby database cancel;

alter system set log_file_name_convert='/db/cps/data/db','/db/cps/data/db' scope=spfile;

alter database clear logfile group 1;
alter database drop logfile group 1;
!mv redo04.log /tmp
alter database add logfile group 1 '/db/cps/data/db/redo01.log' size 512m;

( You will get ORA-01623 if you try to drop a Redolog Group with Status CLEARING_CURRENT or CURRENT.
You can also change this status by doing a ALTER SYSTEM SWITCH LOGFILE; on primary.)

alter system set standby_file_management=auto;
alter system reset log_file_name_convert scope=spfile;
shutdown immediate
startup
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;

PS: