oracle connection reset_oracle adg主备切换

一、 概述

Oracle数据库以主/备角色之一运行，可以通过以下方法更改数据库角色：

• SwitchOver：在主库正常运行、主从正常同步时进行，可翻转数据库主备角色。SwitchOver没有数据丢失，通常在预期的主库维护前进行。
• Failover：在主库故障时进行，可把备库强行提升为主库。Failover后主从关系不会自动恢复，可以使用代理的恢复功能或闪回恢复主从关系。Failover可能有数据丢失，丢不丢取决于保护模式设置。
• Activate：激活从库使其变为独立主库，此后与原主库主从关系中断，只能重搭。

本篇先介绍利用sql操作的方法，下一篇介绍利用DG Broker操作的方法。

二、 SwitchOver

1. 架构图

切换前

切换中（同步恢复前）

切换后

只要有可能，就应该切换到物理备库：

• 如果 切换将物理备库转换为主库，那么：

• 原主库将切换为物理备库。

• redo log将从新主库归档到配置中的所有备库。

• 原主库将作为切换操作的一部分重启。请注意，不需要重启新主库。

• 切换中不涉及的备库（称为旁观者备库） 继续以切换前的状态运行，并且将自动开始应用从新主库接收的重做数据。

• 如果 切换将逻辑备库转换为主库，那么：

• 当配置在最大保护模式下运行时，不允许切换到逻辑备用数据库。

• 原主库将切换为逻辑备库。

• 切换完成后，无需重启主库或逻辑备库。

• 切换后，代理配置中的其他逻辑旁观者备库将保持可用，无需重新启动任何数据库。

• 在切换到逻辑备库后，所有物理和快照备库都将被禁用，必须从新主库的副本中重新创建。

2. 切换前准备

• 若有多个备库，确保各节点间数据库端口是通的
• 确保主库的状态为TRANSPORT-ON，备库的状态为APPLY-ON。任何旁观者备库发生错误均不会妨碍切换。
• 确保主数据库正确设置了备库log_archive目标
• 确保在主数据库上添加了Standby redo logfiles (SRLs)
• 如果主库是rac，只留待切换实例启动，其他实例全部关闭

3. 执行切换

步骤1：在主库上，检查switchover_status

状态为TO STANDBY 或 SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话

SQL> select switchover_status from v$database;   SWITCHOVER_STATUS -------------------- TO STANDBY

步骤2：将主库转为物理备库

with session shutdow用于强制关闭活动会话。

SQL> alter database commit to switchover to standby with session shutdown; Database altered.

步骤3：重启并进行日志应用

如果是rac，只有一个实例能运行MRP进程，其他实例只能运行RFS进程接收日志。

SQL> shutdown immediate SQL> startup SQL> alter database recover managed standby database using current logfile disconnect from session parallel 4;

步骤4：检查状态，可以看到已变为从库

SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database; NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME ------------------------- ------------ -------------------- ---------------- -------------------- ------------------------------ ORCL ARCHIVELOG READ ONLY PHYSICAL STANDBY SESSIONS ACTIVE orcl 

至此对原主库操作已完成，下面是对目标从库的操作。

步骤5：检查目标备库状态

状态为TO PRIMARY 或 SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话。

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO_PRIMARY 

步骤6：将备库切为主库

SQL> alter database commit to switchover to primary with session shutdown;

步骤7：OPEN新主库

检查数据库的打开模式，可以看到已变为主数据库角色

SQL> ALTER DATABASE OPEN; SQL> select name,open_mode,database_role from v$database;   NAME OPEN_MODE DATABASE_ROLE --------- -------------------- MYTEST READ WRITE PRIMARY

步骤8：若其他备库的日志应用停止了，需要启动

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

三、 Failover

failover与switchover最大的区别在于此时主库故障，切换可能丢数据（丢不丢取决于保护模式设置），并且Failover后主从关系不会自动恢复，可以使用代理的恢复功能或闪回恢复主从关系。

1. Failover的类型

① 手动failover

需要DBA手动干预，可以再细分为Complete Failover和Immediate Failover。

• Complete Failover（默认方法）：尝试先将在主库所有重做日志应用到备库，最大程度地减少数据丢失。
• Immediate Failover ：不再对备库进行数据应用，立刻进行切换。

如果满足以下任一条件，请使用立即故障转移：

• 备库遇到ORA-752错误

• 备库遇到ORA-600 [3020]错误，并且Oracle support已确定它是由于在主库中lost write造成的

• 不可能进行完全故障转移

如果在故障转移目标上发生ORA-752或ORA-600 [3020]错误，请不要尝试恢复旧主库，因为这样做可能会导致数据丢失。必须从新主库的备份中重新创建旧主库作为备库（就是要重搭DG了）。

② Fast-Start FailOver（FSFO，自动故障转移）

需要在Data Guard Broker中进行配置。当主数据库不可用时，DG Broker会将主库自动故障转移到预设的备库。

2. 注意事项

• 如果主库崩溃并且生成的归档日志还未复制到备库，则可能会丢失数据。
• Failover仅应在主库确实无法恢复或紧急情况下使用。
• 应将主库Failover到最新的备库（lag最小）

3. 故障转移前准备

以手动Failover为例，FSFO配置相对复杂，单独在后面文章介绍。

故障转移前建议处理主库尚未传送的日志，如果不介意丢数据，可以跳过这一步。

步骤1：如果主库还能到mount状态，执行以下命令将未发送redo全部发送到目标备库。如果不能，跳过该步。执行完后等待从库应用完所有redo日志，如果期间没有报错，直接跳到第4部分开始failover。

alter system flush redo to target_db_name;

步骤2：检查目标备库接收到的最新归档日志号

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG; THREAD LAST ---------- ---------- 1 100

如果主库服务器没有宕机，检查这个归档是不是主库最新的，如果不是，拷贝还未发送的归档日志到从库。

步骤3：检查目标备库是否有gap

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 90 92

如上示例缺少sequence numbers为90, 91, 92 for thread 1的归档，如果主库服务器没有宕机，建议拷贝到目标备库。

步骤4：在目标备库注册缺失的归档日志

alter database register physical logfile 'filespec1';

4. 故障转移步骤

步骤1：停止目标备库日志应用

SQL> alter database recover managed standby database cancel;

步骤2：完成备库日志应用

alter database recover managed standby database finish; -- force选项，个人理解相当于前面提到的Immediate Failover alter database recover managed standby database finish force;

RECOVER MANAGED STANDBY DATABASE FINISH [FORCE][NOWAIT|WAIT] ]

• FINISH子句在目标备库上启动故障转移并恢复当前standby redo log files。仅在主数据库发生故障时使用FINISH子句，此子句覆盖任何延迟间隔。

• FORCE子句 终止 RFS 进程并允许立即执行故障转移，无需等待RFS进程退出。

• NOWAIT子句，立即返回控制，而不是在恢复过程完成后返回。

参考：SQL Statements Relevant to Data Guard

如果没有报错，执行下一步。

如果报错，可能归档存在gap，需要重新检查准备工作中归档日志是否都已拷贝到从库并进行注册。如果情况紧急来不及处理、或者主服务器已宕机、或者不介意丢数据，可以直接激活当前备库（ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;），但是此后主从关系将断开，需要重搭。

步骤3：检查备库状态

状态为TO PRIMARY或SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY

步骤4：将备库切为主库

这个命令跟前面switchover其实是一样的，二者的差距在于failover前面多执行了一个 alter database recover managed standby database finish [force];

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

步骤5：OPEN新主库

ALTER DATABASE OPEN;

步骤6：检查新主库状态

SQL> select name,open_mode,database_role from v$database;   NAME OPEN_MODE DATABASE_ROLE --------- -------------------- ---------------- MYTEST READ WRITE PRIMARY

四、 Failover后恢复主从关系

这里介绍Failover后利用闪回恢复主从同步的方法，要求原主库（Failover后的备库）闪回功能必须打开并且闪回日志还在。利用DG Broker操作的方法放在下一篇介绍，其实原理是一样的，只是Oracle帮你做了。

假设当前failover已完成，新主库已打开。

在新主库上执行：

select to_char(standby_became_primary_scn) from v$database;

在原主库上，也就是现在的备库执行：

startup mount flashback database to scn ; --这个值为在新主库上查询到的SCN值 alter database convert to physical standby; shutdown immediate startup alter database recover managed standby database using current logfile disconnect from session parallel 4;

至此，failover和其后的主从同步恢复已经完成，下一篇来看如何利用DG Broker来简化这些操作。

参考

Switchover and Failover Operations

Role Transitions

SQL Statements Relevant to Data Guard

Data Guard Scenarios

https://blog.csdn.net/shiyu/article/details/

How To Open Physical Standby For Read Write Testing and Flashback (文档 ID .1)

今天的文章
oracle connection reset_oracle adg主备切换分享到此就结束了，感谢您的阅读。