关于Oracle Data Guard的角色切换
1.概述
Oracle数据库通过其 Data Guard技术通过网络将数据实时异地的Oracle数据库中,实现其数据的异地安全机制。
它的实现过程是一般是这样:
首先,在异地建立一样的环境,包括主机操作系统,数据库版本和数据文件存储方式,先模拟建个库,后在此库基础上创建physical standby。
其次,在主库和备库节点上修改一下init.ora,listener.ora和tnsnames.ora文件配置,及主库的v$database的protection_mode修改为MAXIMUMAVAILABILITY(最大可用)。
再次,在主库上备份一下控制文件,当然是for standby方式。
最后,在备库上创建一下standby logfile,启动到recover managed standbydatabase 状态;并在主库上将指向该备库的log_archive_dest_state_*做一下defer和enable,即激活一下。
这样,整个过程就此完成。
好吧,这不是重点。
重点是,在DataGuard环境搭建完成后备库能切换吗?如何切换呢?
2.主备库相互切换
其实,OracleData Guard的切换有两种,其专业术语称为switchover和failover。
正常切换switchover的操作步骤简单明了,如下:
第一步,关掉主库上的监听,再将主库上的所有连接也关掉。可以直接kill -9 local=no的oracle进程,我就是这么干的。
第二步,在主库上将数据库角色设置为PHYSICAL STANDBY,切换状态设置为TO PRIMARY。
操作的SQL为:alter database commit to switchover to physical standby;
结果检查:
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
主库已经变成一个standby库了。但该库的切换状态设置是TO PRIMARY,如果你这个时候反悔,就可以再切换回去。
切换操作完成后,数据库实例需要重启,init.ora文件需要更换,实例设置为实时恢复状态。
操作的SQL为:
startupnomount force;
alterdatabase mount standby database;
alterdatabase recover managed standby database using current logfile disconnect fromsession;
第三步,在备库上将数据库角色设置为PRIMARY。
操作的SQL为:alter database commit to switchover to primary;
结果检查:
先检查数据库角色和切换状态,决定备库能不能切换。
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
SQL>alter database commit to switchover to primary;
Databasealtered.
切换操作完成后,数据库实例需要重启,init.ora文件需要更换。
SQL>conn / as sysdba
Connected.
SQL>startup open force;
ORACLEinstance started.
Databasemounted.
Databaseopened.
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PRIMARY TO STANDBY
通过这三步,切换操作就完成了。这个切换操作可以用来做数据迁移。比以前使用RMAN的backup/restore简单多了。更重要的是,它还可以再切换回去。
这三步操作,看上去很简单,但是涉及到了主库角色转换的问题。如果在主库的角色转换后,备库因某些原因如硬件不能转换为主库了,又该怎么办?
没有了主库,对于任何应用系统都是灾难啊。
好吧,我承认,这才是我想说的重点。
Oracle数据库通过其 Data Guard技术通过网络将数据实时异地的Oracle数据库中,实现其数据的异地安全机制。
它的实现过程是一般是这样:
首先,在异地建立一样的环境,包括主机操作系统,数据库版本和数据文件存储方式,先模拟建个库,后在此库基础上创建physical standby。
其次,在主库和备库节点上修改一下init.ora,listener.ora和tnsnames.ora文件配置,及主库的v$database的protection_mode修改为MAXIMUMAVAILABILITY(最大可用)。
再次,在主库上备份一下控制文件,当然是for standby方式。
最后,在备库上创建一下standby logfile,启动到recover managed standbydatabase 状态;并在主库上将指向该备库的log_archive_dest_state_*做一下defer和enable,即激活一下。
这样,整个过程就此完成。
好吧,这不是重点。
重点是,在DataGuard环境搭建完成后备库能切换吗?如何切换呢?
2.主备库相互切换
其实,OracleData Guard的切换有两种,其专业术语称为switchover和failover。
正常切换switchover的操作步骤简单明了,如下:
第一步,关掉主库上的监听,再将主库上的所有连接也关掉。可以直接kill -9 local=no的oracle进程,我就是这么干的。
第二步,在主库上将数据库角色设置为PHYSICAL STANDBY,切换状态设置为TO PRIMARY。
操作的SQL为:alter database commit to switchover to physical standby;
结果检查:
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
主库已经变成一个standby库了。但该库的切换状态设置是TO PRIMARY,如果你这个时候反悔,就可以再切换回去。
切换操作完成后,数据库实例需要重启,init.ora文件需要更换,实例设置为实时恢复状态。
操作的SQL为:
startupnomount force;
alterdatabase mount standby database;
alterdatabase recover managed standby database using current logfile disconnect fromsession;
第三步,在备库上将数据库角色设置为PRIMARY。
操作的SQL为:alter database commit to switchover to primary;
结果检查:
先检查数据库角色和切换状态,决定备库能不能切换。
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PHYSICALSTANDBY TO PRIMARY
SQL>alter database commit to switchover to primary;
Databasealtered.
切换操作完成后,数据库实例需要重启,init.ora文件需要更换。
SQL>conn / as sysdba
Connected.
SQL>startup open force;
ORACLEinstance started.
Databasemounted.
Databaseopened.
SQL>select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
------------------------------------
PRIMARY TO STANDBY
通过这三步,切换操作就完成了。这个切换操作可以用来做数据迁移。比以前使用RMAN的backup/restore简单多了。更重要的是,它还可以再切换回去。
这三步操作,看上去很简单,但是涉及到了主库角色转换的问题。如果在主库的角色转换后,备库因某些原因如硬件不能转换为主库了,又该怎么办?
没有了主库,对于任何应用系统都是灾难啊。
好吧,我承认,这才是我想说的重点。
相关推荐
周嘉笙 2020-11-09
zhuzhufxz 2020-09-16
lklong 2020-11-22
oraclemch 2020-11-06
shilukun 2020-10-10
bfcady 2020-08-16
Hody 2020-08-16
FightFourEggs 2020-08-16
数据库设计 2020-08-16
yanghuatong 2020-08-16
dbasunny 2020-08-16
罗罗 2020-08-16
ihuaqiang 2020-08-16
choice0 2020-07-30
娜娜 2020-07-28
solarspot 2020-07-28
踩风火轮的乌龟 2020-07-26
娜娜 2020-07-20
xwb 2020-07-19
娜娜 2020-07-18
流云追风 2020-07-04
dataminer 2020-06-25
娜娜 2020-06-22
zhangchaoming 2020-06-21