![](https://csdnimg.cn/release/download_crawler_static/88471746/bg12.jpg)
第二部分 物理 standby(3)角色转换 2017.12.11
第 1 节的时候我们就提到了角色切换,我们也听说了其操作简单但用途广泛,同时我们也猜测其属于primary与
standby 之间的互动,那么在primary 和 standby 数据库(之一)上都需要有操作,并且切换又分了:switchover和
failover,前者是无损切换,不会丢失数据,而后者则有可能会丢失数据,并且切换后原primary 数据库也不再
是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同。en,内容也挺多地。我们
还是先大概了解下概念,然后再通过实战去印证。
角色转换前的准备工作
检查各数据库的初始化参数,主要确认对不同角色相关的初始化参数都进行了正确的配置。
确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式。
确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
确保standby 数据库的RAC 实例只有一个处于open 状态。(对于 rac 结构的standby 数据库,在角
色转换时只能有一个实例startup。其它rac 实例必须统统shutdown,待角色转换结束后再startup)
Switchover:
无损转换,通常是用户手动触发或者有计划的让其自动触发,比如硬件升级啦,软件升级啦之类的。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段,第一步, primary 数据库转换为
standby 角色,第二步,standby 数据库(之一)转换为primary 角色,primary 和 standby 只是简单的角色互换
,
这也印证了我们前面关于角色转换是primary/standby 互动的猜测。
Failover:
不可预知原因导致primary 数据库故障并且短期内不能恢复就需要failover。如果是这种切换那你就要
小心点了,有可能只是虚惊一场,甚至连你可能损失的脑细胞的数量都能预估,但如果运气不好又没有完
备的备份恢复策略而且primary 数据并非处于最大数据保护或最高可用性模式地话,黑黑,哭是没用地,表
太伤心了,来,让三思GG 安慰安慰你,这种情况下呢丢失数据有可能是难免的,并且如果其故障未能修
复,那它甚至连快速修复成为 standby 的机会也都失去了呐,咦,你脑门怎么好像在往外冒水,难道是强效
净肤液,你的脸也忽然好白皙哟~~~~
在执行failover 之前,尽可能将原primary 数据库的可用redo 都复制到standby 数据库。
注意,如果要转换角色的 standby 处于 maximum protection 模式,需要你首先将其切换为 maximum
performance 模式(什么什么,你不知道怎么转换模式?oooo,对对,我们还没有操作过,这块并不复杂,接
下来会通过专门章节讨论),这里先提供透露一下,转换 standby 数据库到MAXIMIZE PERFORMANCE 执
行下列SQL 即可:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等 standby 切换为新的primary 之后,你可以再随意更改数据库的保护模式。
你是不是有疑问关于为什么待切换角色的standby 不能处于maximum protection 模式呢?这个其实很好
理解,我们在第一节学习三种保护模式的时候就介绍过其各自的特点,脑袋瓜好使的同学应该还有印象,
maximum protection 模式需要确保绝无数据丢失,因此其对于提交事务对应的 redo 数据一致性要求非常高
,
另外,如果处于 maximum protection 模式的 primary 数据库仍然与 standby 数据库有数据传输,此时 alter
database 语句更改standby 数据库保护模式会失败,这也是由maximum protection 模式特性决定的。