Data Guard ----理论详解(三)

1.Data Guard

第一章详细部分阅读–传送门

2 DG Services 详解 – Redo Transport Services

第二章详细部分阅读–传送门

3 DG Services 详解 – Apply Services

3.1 Apply Services

Apply service 可以自动在备库应用接收的redo data，从而维护主备库的同步。默认情况下，只有当standby redo log 归档以后，apply services 才会去apply 这些信息。
如果启用了real-time apply, apply services 就会直接apply current standby redo 里的数据，有数据过来，就直接apply，而不需要等待归档后才开始apply。

• Redo Apply (physical standby databases only) ：使用media recovery 来保持主库和物理standby 库的同步。
• SQL Apply (logical standby databases only)：从接收的redo data中重新构建出SQL 语句，然后在logical standby 上执行这些SQL 语句来实现同步。

Standby Database 上Apply Service 对应的进程：

1. 如果是physical standby database，那么就是由MRP(Managed Recovery
   Process)进程来负责Redo Apply 日志。
2. 如果是logical standby database，那么就是由LSP（Logical Standby
   Process）进程来负责SQL Apply。

3.2 Apply Services 的配置选项

3.2.1 使用 Real-Time Apply 实现redo data 实时apply

(1) physical standby databases：

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

(2)logical standby databases：

SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3.2.2 指定备库归档延时apply

设置 Time Delay
我们可以在primary database 和standby database 的LOG_ARCHIVE_DEST_n 参数中设置DELAY=minutes 属性。默认的DELAY=30 分钟。

取消 Time Delay
对于physical standby database：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

对于logical standby database：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

3.2.3停止 Redo Apply

对于physical standby database：最后绝对不能使用⛔️finish，不然DG就完蛋了

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

对于logical standby database：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

3.3.3 监控 Primary, Physical, Snapshot Standby Databases 的应用

备库查进程状态
select process,status from V$MANAGED_STANDBY;  
主库查看有没有eeror
select dest_name,status,error from V$ARCHIVE_DEST; 
主库和备库查看日志应用情况
select sequence#,applied from V$ARCHIVED_LOG;  

4 DG Services 详解 – Role Transitions

4.1 Role Transitions

Switchover
Switchover 切换允许primary 和一个备库进行切换，并且这种切换没有数据丢失。

Failover
当主库不可用或者没反应的时候，我们可以把备库激活成primary状态。 在备库激活之前，如果不是最大保护或者最高可用性的模式，那么可能就会有一些数据丢失。 如果主库已经启动了Flashback Database，可以将主库重新闪回到之前的状态，这样原来的主库就可以继续当作备库使用。

4.1.1 Role Transition 的准备工作

1. 验证主备库的配置信息，包括初始化参数，归档模式，standby redo logs 和online redo log。
2. 在主库查询V$ARCHIVE_DEST_STATUS 视图，验证备库没有redo 传输错误 或者redo gap。
3. 确保主备库Temp 表空间一致。
4. 移除standby 上任何delay apply redo 的设置。
5. 如果是将RAC 主库切换到物理备库，RAC 主库只能保留一个节点，其他节点要关闭，在switchover 完成以后在启动关闭的节点即可。
6. 如果备库是real-time apply 的物理standby，并且是read only 模式，在切换之前，建议先将备库启动到mount状态，而不是open状态，这样可以实现最快速的角色切换，而不需要在切换之前清除用户的session连接。

如果有多个standby，在Role Transition 时如何选择？
（1） standby 数据库的位置。
（2） standby database的性能，比如CPU,I/O，带宽等。
（3） 执行role transition 需要的时间,主要是看有多少redo data 需要apply。
（4） Standby 数据库的类型。

4.1.2 Switchover 说明

DG 的switchover 操作分2个步骤：

1. 将现主库切换成备库
2. 将原备库切换成主库。

4.1.3 Failover 说明

Failover 注意事项：

• 如果可能，在将备库激活之前，应该尽可能多的把主库的redo data 传送到备库，并应用。 这样可以减少数据丢失。
• maximum protection 模式不能进行Failover。

4.2 Physical Standby 的 switchover

验证主库能否切换成备库

在主库执行如下SQL查询：

SQL> select switchover_status,database_role,open_mode from v$database;

查询结果是TO STANDBY或 SESSIONS ACTIVE表明可以进行切换；当SESSION ACTIVE时，备库切换需要加上WITH SESSION SHUTDOWN；

将主库切换成备库

SQL> alter database commit to switchover to physical standby with session shutdown;

如果在切换时想做DUBUG

SQL> oradebug setmypid;
SQL> alter database commit to switchover to physical standby with session shutdown;
SQL> oradebug tracefile_name;

原主库并启动到mount状态

SQL> select open_mode from v$database;
SQL> shutdown immediate;
SQL> startup mount;

验证原备库是否可以切换成主库

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

结果为TO PRIMARY 或 SESSIONS ACTIVE表明可以切换成主库；

将原备库切换成主库

SQL> alter database commit to switchover to primary with session shutdown;
SQL> select open_mode from v$database;

打开新主库

SQL> ALTER DATABASE OPEN;

在新的物理standby 上启动REDO APPLY

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

验证

SQL> alter system switch logfile; 
SQL> select sequence#,applied from v$archived_log;

4.3 Physical Standby 的Failover

一般做Failover 切换都是主库发生了故障，出现问题，但只要主库能够启动到mount 状态，那么在11g环境下就可以将任何没有发送的归档和current online redo log 刷到备库上去，只要Flush成功，Failover 也不会有数据丢失。 如果是10g环境，就需要手工将归档和redo日志拷贝到备库，手工注册文件信息并应用

将原主库还未发送的Redo data 刷到备库

SQL> ALTER SYSTEM FLUSH REDO TO 'study_st';

验证备库最近接收的归档信息

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

确认并解决GAP
在备库查询V$ARCHIVE_GAP，确认是否存在GAP，如果有从主库copy过来，注册一下。

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

停止 Redo Apply.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

结束Apply 所有的Redo data
在备库执行如下SQL,结束所有的Apply：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

验证备库是否可以切换成主库

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

将备库切换成主库
执行如下SQL 完成切换：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

打开新主库

SQL> ALTER DATABASE OPEN;

强制Failover
将主库启动到mount状态并FLUSH REDO

SQL> shutdown immediate
SQL> startup mount;
SQL> alter system flush redo to 'dave_st';
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database activate physical standby database;
Database altered.
SQL> alter database open;

今天的文章先到这里，后面继续更新Data Guard ----理论详解(四)和ADG实战之11g和19C