物理dataguard 正常切换 脚色转换,switchover_status 状态改变

本文详细介绍了Oracle DataGuard环境中进行角色切换的过程,包括正常的主备切换流程、注意事项及故障转移(failover)的步骤。通过具体命令展示如何从主库切换到备用库,再从备用库切换回主库,以及在出现故障时如何快速完成切换。


正常切换

切换前:
主库:

SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PRIMARY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE TO STANDBY

SQL> SELECT COUNT(*) FROM V$SESSION WHERE USERNAME IS NOT NULL;

COUNT(*)
----------
1
在切换前,杀掉所有的数据库连接 观察SWITCHOVER_STATUS,如果是 TO STANDBY,则可以直接切换
如果SESSIONS ACTIVE ,则用

备用库 :

SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
MOUNTED MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE NOT ALLOWED


说明:

主库需要注意事项
A 如果switchover_status为TO_STANDBY说明可以转换
直接转换
alter database commit to switchover to physical standby;
B 如果switchover_status为SESSIONS ACTIVE 则关闭会话
SQL>alter database commit to switchover to physical standby with session shutdown;

在备库中操作,查看备库
SQL> select switchover_status from v$database;

A 如果switchover_status为TO_PRIMARY 说明标记恢复可以直接转换为primary库
SQL>alter database commit to switchover to primary

B 如果switchover_status为SESSION ACTIVE 就应该断开活动会话
SQL>alter database commit to switchover to primary with session shutdown;

C 如果switchover_status为NOT ALLOWED 说明切换标记还没收到,此时不能
执行转换。

切换中 :

备用库
SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
MOUNTED MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE SESSIONS ACTIVE

切换后备用的状态,模式:


SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PRIMARY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE TO STANDBY


2. 检查环境:

确认主库和从库间网络连接通畅;

确认没有活动的会话连接在数据库中;

PRIMARY数据库处于打开的状态,STANDBY数据库处于MOUNT状态;

确保STANDBY数据库处于ARCHIVELOG模式;

如果设置了REDO应用的延迟,那么将这个设置去掉;

确保配置了主库和从库的初始化参数,使得切换完成后,DATA GUARD机制可以顺利的运行。

如果是最大保护模式,先变成最大性能模式:


3. 切换的顺序: 先从主库到备用,再从备库到主库


主切备:

SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PRIMARY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
READ WRITE MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE TO STANDBY

SQL>
SQL>
SQL> alter database commit to switchover to physical standby ;

Database altered.

SQL> shutdown immediate;
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup nomount ;
ORACLE instance started.

Total System Global Area 3242987696 bytes
Fixed Size 733360 bytes
Variable Size 1174405120 bytes
Database Buffers 2063597568 bytes
Redo Buffers 4251648 bytes
SQL> alter database mount standby database;

Database altered.

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

Database altered.

SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
MOUNTED MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE TO PRIMARY

备切主
SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> select OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS from v$database;

OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------- -------------------- -------------------- ------------------
MOUNTED MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE TO PRIMARY

SQL> alter database commit to switchover to primary;

Database altered.

SQL> SQL> SQL>
SQL>
SQL>
SQL> shutdown immediate;
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup ;
ORACLE instance started.

Total System Global Area 3242987696 bytes
Fixed Size 733360 bytes
Variable Size 1174405120 bytes
Database Buffers 2063597568 bytes
Redo Buffers 4251648 bytes
Database mounted.
Database opened.


修改主 备库 的 tnsnames.ora
主库SESSIONS ACTIVE是正常primary状态下的结果。

 

DataGuard:Physical Standby Failover

 

接physical standby switchover

 

primary db :db2

standby db :db1

 

一般情况下failover都是表示primary数据库瘫痪,最起码也是起不来了,因此这种类型的切换基本上不需要primary数据库做什么操作。所以下列步骤中如果有提到primary和standby执行的,只是建议你如果primary还可以用,那就执行一下,即使不去执行,对failover来说也没有关系

 

 

1.检查归档文件是否连续,是否有gap

      在standby库执行

      SQL> select THREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE# from v$archive_gap;

 2.如果步骤1查询出来纪录,则在primary库上执行,否则跳过此步骤

    在主库上执行语句,按步骤1查询出来的纪录找出归档文件

 SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN XX AND XX;

  --如果primary存在,拷贝相应的归档到STANDBY数据库,并注册.

  SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'xxx';

3.检查归档文件是否完整

  分别在primary/standby执行下列语句:

  SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;

  把相差的归档复制到待转换的standby服务器,并手工register

 

4.开始做failover

  察看standby进程状态

  SQL> select process,client_process,sequence#,status from v$managed_standby;

 

PROCESS  CLIENT_P SEQUENCE# STATUS

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

ARCH     ARCH            30 CLOSING

ARCH     ARCH             0 CONNECTED

RFS      LGWR            31 IDLE

RFS      ARCH             0 IDLE

RFS      N/A              0 IDLE

MRP0     N/A             31 APPLYING_LOG

 

   SQL> alter database recover managed standby database finish force ;

FORCE关键字将会停止当前活动的RFS进程,以便立刻执行failover。

  或

  SQL> alter database recover managed standby database finish skip standby logfile;

 

SQL> alter database commit to switchover to primary;

SQL> shutdown immediate

SQL> startup

 

SQL> select database_role,protection_mode,protection_level,open_mode from v$database;

 

DATABASE_ROLE   PROTECTION_MODE     PROTECTION_LEVEL    OPEN_MODE

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

PRIMARY         MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE READ WRITE

 

Failover切换成功

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13024285/viewspace-679538/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/13024285/viewspace-679538/

<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、付费专栏及课程。

余额充值