作者介绍
现任云和恩墨数据库技术顾问,擅长Oracle数据库的安装配置、故障诊断、性能诊断、性能优化、备份容灾解决方案的设计与实施。
个人技术博客:https://www.cnblogs.com/jyzhao
,回复:prelection ,你可以找到本文的相关视频文档。
同时点击【阅读全文】,即可观看在线课程。
在DG中,switchover和failover是两个重要的概念,也是DG实现的核心。根据不同的DG配置,switchover和failover也是有差异的。当主库被crash之后,如何进行DG foilover的操作?
本文是针对在DG灾备环境进行failover操作以及后续恢复的报告。
当A库crash后,在B库进行failover将B切换为新的主库,确认failover之后,A库和C库应该如何处理才可以成为新的备库继续使用?是否需要重建?重建的话,是否需要重新备份来恢复,以前的备份是否可以用来创建备库?
问题
1、A库异常关闭
A库:
SQL>shutdown abort
2、B库进行failover切换为新主库
failover 标准步骤如下:
#取消DG应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
#重启下数据库(建议)
shutdown immediate;
startup
#操作不可逆,确定实际情况需要failover
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH force;
SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, FORCE_LOGGING, DATAGUARD_BROKER, GUARD_STATUS FROM V$DATABASE;
#尝试常规切换为主库
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
如果这一步的常规切换失败,提示需要介质恢复,那么:
1)恢复备库 recover standby database until cancel;
2)激活备库 alterdatabaseactivatestandbydatabase;
#最后重新启动数据库
shutdownimmediate;
startup
查看此时B库的信息:
SQL>selectname, database_role, open_mode fromgv$database;
可以看到,目前B库已成为新的主库,redo日志的sequence重新开始。
3、要求C库成为新主库的备库
现在要求C库成为新主库的备库。是否需要重建C库呢?答案是不需要。下面具体来看下验证过程。
C库的alert日志:
可以看到,在A库crash之后,C库收到网络无法连接到A库的告警,说明C库目前没有新的操作。
接下来想要C库成为B库(新主库)的备库,就需要尝试在B库上配置DG参数,使得B库的归档可以传输到C库。
同时在B库的tnsnames.ora文件中增加到C库的连接:
#StandbySingle Instance
JYZHAO_S=
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.111)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = jyzhao_s)) )
在B库设置完成后,观察B库的告警:
然后返回C库操作,将C库开启实时日志应用:
SQL>alter database recover managed standby database cancel;
Databasealtered.
SQL>alter database recover managed standby database using current logfile disconnect from session;
Databasealtered.
此时再观察C库的告警日志:
实际看到,C库已经可以正常应用日志。说明C库不需要重建即可通过简单配置成为新主库B库的新备库。
4、要求A库成为新主库的备库
此时A库启动的话,是一个独立运行的数据库,如果想将A库也设置为主库的话,那么,通过新主库的最新备份肯定是可行的,但是如果数据量很大,之前A库自己本身有历史的备份,能否不再耗时备份新主库,直接通过历史的备份恢复呢?其实这个从上面的C库不再需要重建直接成为新主库的备库,也可以推断出,是可以的。只需要确认这个备份是在failover之前完成的。下面我们来具体实验验证下可行性。
在B库创建新的备库控制文件,并传输到A库相同路径下:
backupcurrentcontrolfileforstandbyformat'/tmp/std_control02.ctl';
在A库启动到nomount,恢复新的备库控制文件
restorestandbycontrolfilefrom'/tmp/std_control02.ctl';
在A库查看数据文件头的检查点,确认是在failover之前:
上面这个数据文件头的检查点是0,说明数据文件没有正确获取到,实际上是由于OMF的名字有变化,直接将数据文件路径catalog到备份集中,再switch即可。
catalogstartwith'+DATA1/jyzhao/datafile/';
switchdatabase to copy;
再次查询:
此时在mount状态下开启日志应用:
alter database recover managed standby database disconnect from session;
从告警日志观察,确认应用到最新时,取消日志应用:
alter database recover managed standby database cancel;
打开数据库,开启实时应用:
alter database recover managed standby database USING CURRENT LOGFILE disconnect from session;
最终查询可以正常实时应用。
一般来说,在A库crash之后,B库failover成为新的主库,那么原来设置为延迟1小时应用的C 库是可以直接配置成为新主库的备库。A库修复后,也可以通过failover之前的现有备份集来恢复到failover之前的状态,而不需要在新主库重新去备份。