SWITCHOVER主库出现LOG SWITCH GAP和RESOLVABLE GAP解决一例

本文记录了一次SWITCHOVER操作中遇到的LOGSWITCHGAP及RESOLVABLEGAP问题,并详细描述了解决过程。通过重启主库和执行FLUSH REDO操作最终解决了GAP问题。

switchover,环境是11.2.0.3+OEL5.7,开始时主备库状态都是正常的,符合直接切换条件:

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

OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PRIMARY          TO STANDBY

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

OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ ONLY WITH APPLY PHYSICAL STANDBY NOT ALLOWED

主库直接进行swichover:
SQL> alter database commit to switchover to physical standby;
alter database commit to switchover to physical standby
*
ERROR at line 1:
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected


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

OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PRIMARY          LOG SWITCH GAP

提示有日志切换GAP,于是直接重启主库:
SQL> startup force
ORACLE instance started.

Total System Global Area  413372416 bytes
Fixed Size                  2228904 bytes
Variable Size             322964824 bytes
Database Buffers           83886080 bytes
Redo Buffers                4292608 bytes
Database mounted.
Database opened.
SQL> select open_mode,database_role,switchover_status from v$database;

OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PRIMARY          RESOLVABLE GAP

状态由LOG SWITCH GAP变成了RESOLVABLE GAP,从字面理解是主备库之间存在GAP,于是执行:

SQL> ALTER SYSTEM FLUSH REDO TO ora11dg2;

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

OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PRIMARY          TO STANDBY

把主库REDO FLUSH到备库以后,以上状态消失,又重新回到之前的TO STANDBY状态了,可以重新进行SWITCHOVER了。
如果主库状态不是TO STANDBY,而是SESSION ACTIVE,就要加上WITH SESSION SHUTDOWN,否则不能切换成功,除此以外的其他状态,是不能直接进行转换的。备库通常的状态是NOT ALLOWED,当主库做了切换以后,会变成TO PRIMARY,所以通常是现在主库做ROLE TRANSITION,然后再在备库做。

以下是一些消除主备库之间GAP的命令和说明:

--主库,将所有未传送的redo传送给从库,target_db_name使用DB_UNIQUE_NAME 。
ALTER SYSTEM FLUSH REDO TO target_db_name;

--验证备库
SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

--如果必要,拷贝归档日志到从库,并进行注册
 ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

--重复上一步,知道确认所有归档完毕。
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

--查看目标日志传输路径状态和GAP状态
SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

--在目标备库上,停止日志应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

--在目标备库上
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

--如果日志确定丢失,可以采用激活方式,但这样会有数据丢失。
--ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

--验证目标备库
SELECT SWITCHOVER_STATUS FROM V$DATABASE;

--开始切换,如果状态为“TO PRIMARY”,则WITH SESSION SHUTDOWN从句可以去掉。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

--打开新主库
ALTER DATABASE OPEN;

附一份DG主备库切换状态说明:

v$database
  1. NOT ALLOWED - On a primary database, this status indicates that there are no valid and enabled standby databases. On a standby database, this status indicates that a switchover request has not been received from the primary database. 
  2.  
  3. SESSIONS ACTIVE - The database has active sessions. On a physical standby database, the WITH SESSION SHUTDOWN SQL clause must be specified to perform a role transition while in this state. On a logical standby database, a role transition can be performed while in this state, but the role transition will not complete until all current transactions have committed. 
  4.  
  5. SWITCHOVER PENDING - On a physical standby database, this status indicates that a switchover request has been received from the primary database and is being processed. A physical standby database cannot switch to the primary role while in this transient state. 
  6.  
  7. SWITCHOVER LATENT - On a physical standby database, this status indicates that a switchover request was pending, but the original primary database has been switched back to the primary role. 
  8.  
  9. TO PRIMARY - The database is ready to switch to the primary role. 
  10.  
  11. TO STANDBY - The database is ready to switch to either the physical or logical standby role. 
  12.  
  13. TO LOGICAL STANDBY - The database has received a data dictionary from a logical standby database and is ready to switch to the logical standby role. 
  14.  
  15. RECOVERY NEEDED - On a physical standby database, this status indicates that additional redo must be applied before the database can switch to the primary role. 
  16.  
  17. PREPARING SWITCHOVER - On a primary database, this status indicates that a data dictionary is being received from a logical standby database in preparation for switching to the logical standby role. On a logical standby database, this status indicates that the data dictionary has been sent to the primary database and other standby databases. 
  18.  
  19. PREPARING DICTIONARY - On a logical standby database, this status indicates that the data dictionary is being sent to the primary database and other standby databases in preparation for switching to the primary role. 
  20.  
  21. FAILED DESTINATION - On a primary database, this status indicates that one or more standby destinations are in an error state. 
  22.  
  23. RESOLVABLE GAP - On a primary database, this status indicates that one or more standby databases have a redo gap that can be automatically resolved by fetching the missing redo from the primary database or from another standby database. 
  24.  
  25. UNRESOLVABLE GAP - On a primary database, this status indicates that one or more standby databases have a redo gap that cannot be automatically resolved by fetching the missing redo from the primary database or from another standby database. 
  26.  
  27. LOG SWITCH GAP - On a primary database, this status indicates that one or more standby databases are missing redo due to a recent log switch. 

SWITCHOVER 示例:

原主库:
SQL> alter database commit to switchover to physical standby;


Database altered.


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


OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PHYSICAL STANDBY RECOVERY NEEDED


SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.


Total System Global Area  413372416 bytes
Fixed Size                  2228904 bytes
Variable Size             331353432 bytes
Database Buffers           75497472 bytes
Redo Buffers                4292608 bytes
Database mounted.

原备库:
SQL> select open_mode,database_role,switchover_status from v$database;


OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ ONLY WITH APPLY PHYSICAL STANDBY TO PRIMARY


SQL> alter database commit to switchover to primary;


Database altered.


SQL> alter database open;


Database altered.


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


OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ WRITE           PRIMARY          TO STANDBY

原主库(新备库):
SQL> alter database recover managed standby database using current logfile disconnect from session;


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


OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
MOUNTED              PHYSICAL STANDBY RECOVERY NEEDED

此时刚转换好的新备库SWITCHOVER状态是RECOVERY NEEDED,这是正常的,主库切几次日志以后就会变成NOT ALLOWED状态了,另外这个时候由于是REDO APPLY模式,虽然是11g,但也是无法直接OPEN的,如果要OPEN,必须先停止REDO APPLY:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-10456: cannot open standby database; media recovery session may be in progress




SQL> alter database recover managed standby database cancel;


Database altered.


SQL> alter database open;


Database altered.

由于11g的ACTIVE DG功能(需要LISENCE,否则属于非法使用),所以即便在OPEN状态下,依然能够REDO APPLY:

SQL> alter database recover managed standby database disconnect;


Database altered.


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


OPEN_MODE            DATABASE_ROLE    SWITCHOVER_STATUS
-------------------- ---------------- --------------------
READ ONLY WITH APPLY PHYSICAL STANDBY NOT ALLOWED

至此,整个SWITCHOVER就做完了,SWITCHOVER是不会丢失数据的(不同于FAILOVER),如果FAILOVER能做到没有GAP,也可以不丢数据,并且正常使用SWITCHOVER切换(见官方文档B25608,第8章)。
<think>嗯,用户这次问的是Oracle主库SWITCHOVER_STATUS显示FAILED DESTINATION的具体原因解决方案。从用户引用的资料来看,ta应该正在处理Data Guard环境下的主备切换问题,而且遇到了障碍。 用户提供的引用材料很有价值,特别是引用[1]里明确提到FAILED DESTINATION表示"至少有一个备库同步出错"。看来用户已经做了基础调研,现在需要的是深度故障排查指导。考虑到用户专门提到这是Oracle 11gR2环境,解决方案需要兼容这个版本。 从技术角度看,FAILED DESTINATION的核心是备库同步异常。需要分层次排查:首先是网络基础架构层(连接性/存储/TNS),然后是DG配置层(归档路径/保护模式),最后是日志层(GAP/损坏)。用户作为DBA可能更关注可操作的检查项,所以准备把解决方案做成步骤化的清单。 注意到用户没有提供具体错误日志,这点很重要。在回复时需要提醒用户查看alert日志备库状态细节。另外引用[2]提到switchover是无损切换,暗示用户可能在生产环境操作,所以解决方案要强调风险评估回退方案。 上次回复是关于DG的UNRESOLVABLE GAP错误,这次问题属于同类但更复杂——FAILED DESTINATION可能是多种故障的表象。需要在回复中建立问题树:先用表格锁定可能的故障分支(网络/配置/日志/GAP),再针对每个分支给出诊断命令。特别要加入V$DATAGUARD_PROCESS视图的检查,这是11gR2特有的诊断工具。 用户语气比较急切,可能面临生产系统切换压力。回复要保持技术严谨性,但诊断步骤要足够清晰。最后考虑补充性能影响说明,因为同步故障有时与资源瓶颈有关。 </think>当Oracle主库的`SWITCHOVER_STATUS`显示`FAILED DESTINATION`时,表明**至少有一个备库同步过程出现错误**,导致主备无法正常切换。以下是详细原因解决方案: --- ### **原因分析** 1. **日志传输中断** - 主库生成的Redo日志无法传输到备库(网络故障、归档路径配置错误) - 归档日志被误删或损坏 - `LOG_ARCHIVE_DEST_n`参数配置错误(例如权限、路径无效) 2. **日志应用失败** - 备库的`MRP`(Managed Recovery Process)进程异常终止 - Redo日志存在损坏或不连续(GAP) - 备库存储空间不足导致日志应用失败 3. **网络与连接问题** - 主备库之间的网络中断或延迟过高 - 监听器配置错误(`listener.ora`/`tnsnames.ora`中服务名解析失败) 4. **版本或补丁不兼容** - 主备库的Oracle版本或补丁级别不一致 - 备库未应用必要的数据库补丁 --- ### **解决方案** #### **步骤1:检查备库同步状态** ```sql -- 在备库执行: SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; ``` - **若MRP进程停止**:尝试重启日志应用 ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; ``` #### **步骤2:检查日志传输状态** 在主库查询日志传输错误: ```sql SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = [备库对应的DEST_ID]; ``` - **常见错误**:`ORA-12154`(TNS解析失败)、`ORA-12541`(监听器无响应)、`ORA-19505`(文件权限问题) #### **步骤3:验证日志GAP** 在备库检查缺失的日志序列: ```sql SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; ``` - **手动解决GAP**: 1. 在主库定位缺失的归档日志: ```sql SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND SEQUENCE# BETWEEN [low_seq] AND [high_seq]; ``` 2. 将日志手动复制到备库归档路径 3. 在备库注册日志: ```sql ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径/日志文件名'; ``` #### **步骤4:检查网络与配置** 1. **验证主备连通性**: ```bash tnsping <备库TNS服务名> ``` 2. **检查参数配置**: - 主库的`LOG_ARCHIVE_DEST_n`参数: ```sql SHOW PARAMETER LOG_ARCHIVE_DEST_2; ``` 确保`SERVICE`指向正确的备库TNS服务名,且`VALID_FOR`符合要求。 #### **步骤5:重启日志传输与应用** ```sql -- 主库重启传输(替换DEST_ID): ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = DEFER; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE; -- 备库重启应用: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; ``` #### **步骤6:监控与日志分析** - **主库Alert日志**:`$ORACLE_BASE/diag/rdbms/<DB_NAME>/<INSTANCE_NAME>/trace/alert_<INSTANCE_NAME>.log` - **备库Alert日志**:检查`MRP`进程报错细节 - 使用`DGMGRL`命令监控: ```bash DGMGRL> SHOW DATABASE '<备库名>' STATUS; ``` --- ### **关键预防措施** 1. **启用实时应用(Real-Time Apply)**: ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; ``` 2. **配置日志传输验证**: ```sql ALTER SYSTEM SET LOG_ARCHIVE_TRACE=31; -- 启用详细日志 ``` 3. **定期检查DG状态**: ```sql SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST; ``` > **重要提示**:若问题仍未解决,检查操作系统文件权限、存储空间及Oracle版本兼容性,并参考官方文档 *Data Guard Troubleshooting Guide* [^1][^2]。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值