由于硬件故障，数据库升级等计划内或者计划外的原因我们可能需要将生产环境从Primary Datbase切换到Standby Database上。本文主要介绍physical standby环境环境下的角色切换，其他环境下的切换再之后的文章中再介绍，或者请参考oracle的官方文档关于相关环境的搭建请查看：http://blog.youkuaiyun.com/huang_tg/archive/2010/06/23/5690358.aspx
在Data Guard环境下的数据库运行在primary或者standby角色。角色之间的转换可以使用命令动态的实现。当然也可以通过名为Data Guard broker的图形界面下完成，不过强烈的建议使用命令。在做角色切换的时候需要对Oracle Data Guard的配置进行验证，保证我们能顺利的完成角色切换工作，在做角色切换之前我们需要完成以下工作：
1.保证参数文件中的相关参数设置准确。
2.确定将要切换为primary角色的standby database处于归档模式下。
3.确保将要切换为primary角色的standby database的临时文件存在并与原primary database吻合。
4.如果standby database为RAC环境，那么在切换时候只保留一个实例，关闭其他的实例，切换完成后再启动其他实例。
5.如果是配置了多个standby database，那么切换的时候还考虑将要切换为primary角色的standby database的物理位置，服务器性能以及切换时间等因素。
Oracle Data Guard支持以下两种切换模式：
一. Switchover
switchover是对primary database和standby database的角色互换，不会有数据丢失。使用这种方式切换一般是在系统，硬件及数据库升级，硬件维护等计划内的情况。switchover分为两个步骤：将原primary database 转换为standby database，将原standby database转换为primary database。在切换前根据环境的不同还需要做一下工作。
physical standby环境：在切换之前保证primary database处于open状态，standby database处于mount并且redo应用状态。如果standby database处于read only的方式打开的，那么切换可能要等待一定的时间。接下来介绍physical standby环境下的switchover切换步骤：
1.old primary:SQL> select switchover_status from v$database
SWITCHOVER_STATUS
--------------------
TO_STANDBY
此处的值是TO STANDBY则表明可以直接通过alter database commit to switchover to physical standby 将primary切换为physical standby，如果此处的值为SESSIONS ACTIVE，使用上面语句则会报ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected错误。那么我们要通过语句select sid,process,program from v$session where type='USER' and sid<>(select distinct sid from v$mystat);查询视图V$SESSION及V$MYSTAT来获得哪些进程导致了此错误，处理这些进程然后再查询switchover_status的值，如果还是SESSIONS ACTIVE那么使用alter database commit to switchover to physical standby with session shutdown完成切换。
SQL> alter database commit to switchover to physical standby 或者alter database commit to switchover to physical standby with session shutdown;
SQL> shutdown immediate;
SQL> startup mount;
SQL> select switchover_status from v$database
SWITCHOVER_STATUS
--------------------
TO_PRIMARY
到这一步的查询switchover_status的值为TO_PRIMARY的话原primary的切换基本完成了。接下来就是physical standby的了。
2.old standby:SQL> alter database commit to switchover to primary;
SQL> alter database open;
如果standby database在最近一次重启之后没有以read only的方式打开过，那么直接使用alter database open打开就可以了。
SQL> shutdown immediate;
SQL> startup;
如果standby database在最近一次重启之后以read only的方式打开过，则在切换以后需要重新启动。
3.old primary:SQL>alter database recover managed standby database disconncet from session;
在以前的primary database也就是现在的physical standby database上启用redo apply。到这一步physical standby环境下的switchover切换基本完成了。如果有必要的话切换一下日文件，看是否正常。
二. Failover
Failover是当primary database发生了计划外的宕机时为了快速的启用数据库服务而设置的切换机制。计划外的宕机包括服务器意外掉电，硬件故障等等。在physical standby环境下，如果发生了failover切换，那么在所有情况下原primary database将不在是此data guard配置中的一部分，如果还有其他的standby datbase的配置的话，那么其他的将保留。在大多数情况下原primary database并不直接参与到failover的切换过程，不需要重启动。某些情况下在配置完新的primary database后需要重新配置此data guard中的所有physical standby database。
在进行failover切换之前除了文章开头的准备工作以外还有一些工作需要完成。首先将尽可能多的尚未传输及应用到原physical standby database的redo文件从原primary database拷贝到原physical standby database（即被选为新的primary的database）上。接下来验证一下当前data guard的保护模式，如果是最大保护模式（maximum protection）那么需要更改为最大性能模式（maximum performance），使用的SQL语句为：alter database set standby database to maximize performance;这个步骤是必须的，因为在最大保护模式（maximum protection）下failover切换是禁用的。当然如果还有其他的standby database与原primary database通讯的话，那么保护模式的切换将会失败。当切换发生时，会触发一个DB_ROLE_CHANGE的系统事件，我们可以通过编写触发器完成一些failover切换后的任务。切换完成以后可以通过查看V$DATABASE视图的DATABASE_ROLE列来确定当前数据库是什么角色。接下来详细的介绍failover的切换步骤：
如果原standby database是运行在最大保护模式（maximum protection）及最大性能模式（maximum availability）下，那么因为日志传输是使用日志写进程（LGWR），所以不会发生日志文件断点，直接跳到步骤四，否则的话就得从步骤一开始。
1.检测是否存在日志断点，使用SQL语句：select thread#,low_sequence#,high_sequence# from v$archive_gap;查询视图V$ARCHIVE_GAP例如：
SQL> select thread#,low_sequence#,high_sequence# from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
这表明90,91,92三个日志文件需要从原primary database拷贝到目标standby database。传输完成以后需要使用入如下语句将这些日志文件注册到数据库中：
SQL> alter database register physical logfile 'filename';
2.重复步骤一直到查询没有记录为止。
3.确认是否还有丢失的日志文件，并将其拷贝到目标数据库（原standby database），通过在目标数据库上运行SQL语句：select thread#,max(sequence#) from v$archived_log group by thread#;查询最大日志序列值，然后将原primary database中比这个序列值大的日志拷贝到目标数据库，并注册。完成此步以后再次重复第一个步骤，确认没有造成新的日志断点。
alter database comiit to switchover to physical standby with session shutdown
如果前面三个步骤都执行了，但是没有办法将原primary database的相关日志拷贝到目标数据，那么将造成数据丢失。比如说原primary database的系统彻底崩了。完成前三个步骤以后接下来就开始进行failover切换了。
4.结束redo应用，并进行角色切换。
old standby:SQL> alter database recover managed standby database finish force;
SQL> alter database commit to switchover to primary;
通过以上步骤就完成了physical standby到primary的failover角色切换，从以前的primary database接收到的日志将被忽略而不被新的primary database会接替原primary database的工作，为其他的standby database传输日志。当然前提是进行了相关的配置。其他没有参与failover的standby database不需要进行重启等额外操作。
5.启动新primary database。alter database commit to switchover to physical standby with session shutdown
SQL> alter database open;
如果目标数据库（原standby database）在最近一次重启以来没有以read only方式打开过那么直接打开数据就可以了。如果是以read only的方式打开过，那么就需要重新启动：
SQL> shutdown immediate;ORA-16014: log 3 sequence# 7 not archived, no available destinations
SQL> startup;
6.备份主数据库。如果切换后没有其他的standby的话，强烈的建议进行这一步。具体备份方法就不做过多介绍了，结合实际情况选择恰当的备份方式。
7.将原primary database重新设置加入data guard配置。（这一步为可选）
以上介绍了data guard在physical standby环境下的switchover及failover切换。DG主要还是作为高可用的解决方案，不能将他当做一个完善的备份方案，周期性的数据库备份时必不可少的，当然我们完全可以把备份工作放到standby上完成。保证primary始终保持较高的性能。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
