Oracle Data Guard是Oracle HA架构体系的重要组成部分，也是Oracle MAA（Maximum Availability Architecture）的关键技术方案。借助Data Guard的Switchover和Failover特性，我们可以实现运维系统高可用性需求，最大限度的降低计划内和非计划内宕机时间。
Data Guard建立在数据库软硬件、数据冗余策略，通过搭建和主库Primary Database数据相同、软硬件独立的物理（Physical）和逻辑（Logical）备库Standby，并且借助Redo Log传递应用确保数据同步。当单独数据库（通常为Primary）发生故障，不能继续提供服务时，额外的Standby可以作为备用数据库来支持应用，减少系统整体数据丢失和停机影响。
Switchover和Failover是Dataguard里面一组有区别又有联系的概念，其本质都是Primary停止对外服务，由Standby支持对外数据服务，变为新的Primary。但是两者从概念到操作上都有很大差异。
Switchover的核心是“Planned”，也就是计划内的停机切换动作。我们的运维系统在运行过程中，经常有如设备检修、软件升级补丁等维护操作。这个时候，如果是一些SLA要求很高的系统，停机时间窗口就是一个问题。特别是一些7*24的系统，业务部门是不会允许过长的停机时间。Switchover就是对Dataguard或者RAC环境下，临时性的Primary点停机进行升级工作，由Standby变为Primary支持服务，最后再切换回来的过程。这个过程在Oracle中成为角色转换role transition。由于是有准备、有计划的操作，Switchover是平顺的，不会引起数据的丢失。
Failover的核心则是“unplanned”，是和Switchover相对应，更贴近Data Guard的原始设计初衷。如果Primary出现故障，不能支持服务的时候。Standby可以在很短的时间内，自动或者手动的切换到Primary角色。之后由这个新的Primary支持服务。如果Primary可以修复好，则可能需要重新搭建DG或者Apply为新的Standby，之后切换回Primary角色。Failover由于涉及到Primary站点的故障类型程度，所以是可能出现数据丢失的。
进行Switchover和Failover的工具方法很多，最常用的有三个：SQL Command、Data Guard Broker和DB Grid Control。本文介绍如何使用SQL Command进行Switchover操作。
1、环境介绍
我们选择环境已经搭建好Dataguard，版本为11.2.0.4（Primary和Standby相同）。操作系统版本为Red Hat Linux 6.5。
SQL> select * from v$version;
BANNER
--------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
Primary数据库unique名称为ora11g。
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
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORA11G ARCHIVELOG READ WRITE PRIMARY SESSIONS ACTIVE ora11g
Standby数据库名称为ora11gsy，此时开启实时数据同步应用。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
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
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORA11G ARCHIVELOG READ ONLY WITH APPLY PHYSICAL STANDBY NOT ALLOWED ora11gsy
注意：此时standby的open mode为Read only with apply，这个是11g Active Data Guard的特性。传统DG在进行Apply的过程中，是处在mount状态的，不支持实时数据只读操作。11g支持在apply中打开数据库到只读状态。
2、Switchover过程中Primary主库操作
进行Switchover的过程分为三个步骤，一个是在Primary上停止工作，切换到Standby状态，第二个是在选择一个Standby实例，切换角色到Primary状态，最后是将其他Standby的Apply过程启动。
注意在上面我们查看Primary数据库ora11g的v$database视图，其中switchover_status取值是我们需要关注的，如果取值为session active或者to standby，我们是可以进行切换的。如果其他值，说明配置的log传输机制存在问题，需要解决调整。
--在ora11g上
SQL> alter database commit to switchover to physical standby with session shutdown;
Database altered
注意：如果swtichover_status状态为session active，就需要在命令中加入with session shutdown子句。执行后，我们发现Primary ora11g已经关闭。
SQL> select status from v$instance;
select status from v$instance
*
ERROR at line 1:
ORA-03135: connection lost contact
Process ID: 2357
Session ID: 1 Serial number: 5
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
--实例进程消失
[oracle@SimpleLinux trace]$ ps -ef | grep pmon
oracle 2107 1 0 15:35 ? 00:00:01 ora_pmon_ora11gsy
oracle 2473 1848 1 16:03 pts/1 00:00:00 grep pmon
此时，alert log中也记录了实例停止的情况。
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Archivelog for thread 1 sequence 19 required for standby recovery
Switchover: Primary controlfile converted to standby controlfile succesfully.
Switchover: Complete - Database shutdown required
USER (ospid: 2365): terminating the instance
Instance terminated by USER, pid = 2365
Completed: alter database commit to switchover to physical standby with session shutdown
Shutting down instance (abort)
License high water mark = 6
Sun Apr 20 16:02:11 2014
Instance shutdown complete
在这个过程中，为了确保数据无损失，Primary一定将所有的日志信息传递到Standby上。此时，可以启动Primary，到mount standby状态。
[oracle@SimpleLinux trace]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Apr 20 16:06:47 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 372449280 bytes
Fixed Size 1364732 bytes
Variable Size 331353348 bytes
Database Buffers 33554432 bytes
Redo Buffers 6176768 bytes
SQL> alter database mount standby database;
Database altered.
注意：如果需要进行设备维修或者停机操作，是可以不启动Primary的。
3、Switchover过程中Standby备库操作
此时standby状态。
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
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORA11G ARCHIVELOG READ ONLY WITH APPLY PHYSICAL STANDBY SESSIONS ACTIVE ora11gsy
首先检查standby上是否将所有的Redo Log顺利应用，是否存在apply gap。
SQL> select sequence#, applied from v$archived_log;
SEQUENCE# APPLIED
---------- ---------
17 YES
18 YES
19 YES
14 rows selected
使用命令进行切换。
SQL> alter database commit to switchover to primary;
alter database commit to switchover to primary
ORA-01093: ALTER DATABASE CLOSE 仅允许在没有连接会话时使用
SQL> alter database commit to switchover to primary with session shutdown;
Database altered
此时，standby数据库状态为：
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
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORA11G ARCHIVELOG MOUNTED PRIMARY NOT ALLOWED ora11gsy
SQL> conn / as sysdba
Connected.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
启动standby数据库ora11gsy，并且检查redo log传递情况。
SQL> alter database open;
Database altered.
SQL> select sequence# ,name, STANDBY_DEST, APPLIED from v$archived_log;
SEQUENCE# NAME STANDBY_DEST APPLIED
---------- -------------------------------------------------------------------------------- ------------ ---------
（篇幅原因，有省略……）
20 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_20/o1_mf_1_20_9o70fq3g_. NO NO
20 ora11g YES NO
21 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_20/o1_mf_1_21_9o70fvr7_. NO NO
21 ora11g YES NO
18 rows selected
注意：由于新standby端ora11g启动状态（mount），所以可以看到日志传递，只是没有应用。
4、效果检查和测试
此时，我们检查原来的Primary，也就是ora11g的数据库状态。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
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
--------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORA11G ARCHIVELOG MOUNTED PHYSICAL STANDBY RECOVERY NEEDED ora11g
已经接受数据，只是没有开启应用。
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
此时，检查ora11gsy的状态，发现传递日志已经应用。
SQL> select sequence# ,name, STANDBY_DEST, APPLIED from v$archived_log;
SEQUENCE# NAME STANDBY_DEST APPLIED
---------- -------------------------------------------------------------------------------- ------------ ---------
（篇幅原因，有省略…..）
20 ora11g YES YES
21 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_20/o1_mf_1_21_9o70fvr7_. NO NO
21 ora11g YES YES
18 rows selected
下面进行一个数据同步测试，判断switchover成功。我们在ora11gsy上创建数据表。
SQL> conn scott/tiger@ora11gsy
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.4.0
Connected as scott
SQL> create table t as select * from dba_objects;
Table created
SQL> select count(*) from t;
COUNT(*)
----------
86033
在primary端，启动进入read only apply过程。
SQL> conn sys/oracle@ora11g as sysdba
Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.4.0
Connected as SYS
SQL> alter database recover managed standby database cancel;
Database altered
SQL> alter database open;
Database altered
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered
SQL> select count(*) from scott.t;
COUNT(*)
----------
86033
同步成功，进行switchover成功。
5、结论
进行Dataguard switchover和failover是非常常见的运维需求，在实际场景下，我们尽可能选择稳妥完全的策略进行操作。Dataguard Broker存在一定的配置工作量，而DB Grid Control又是一个收费产品，所以SQL命令还是我们比较好的选择。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/8494287/viewspace-1351122/ ，如需转载，请注明出处，否则将追究法律责任。
