ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转]一步一步学DataGuard 第二部分 物理standby(3)角色转换

[转]一步一步学DataGuard 第二部分 物理standby(3)角色转换

原创 Linux操作系统 作者:hjgo5 时间:2019-06-28 10:15:06 0 删除 编辑

  第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模式特性决定的。

下面分别演示switchover和failover的过程:

一、 物理standby的Switchover

注意操作步骤的先后,很关键的哟。

1、 检查是否支持switchover操作   --primary数据库操作

  登陆primary数据库,查询v$database视图的switchover_status列。

    E:\ora10g>set oracle_sid=jssweb

    E:\ora10g>sqlplus "/ as sysdba"

    SQL*Plus: Release 10.2.0.3.0 - Production on  星期四 12月 13 09:41:29 2007

    Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

    已连接。

    SQL>  select switchover_status from v$database;

    SWITCHOVER_STATUS

    --------------------

    TO STANDBY

  如果该列值为"TO STANDBY"则表示primary数据库支持转换为standby角色,否则的话你就需要重新检查一下Data Guard配置,比如看看LOG_ARCHIVE_DEST_n之类参数值是否正确有效等等。

2、 启动switchover  --primary数据库操作

  首先将primary转换为standby的角色,通过下列语句:

    SQL>  alter database commit to switchover to physical standby;

    数据库已更改。

  语句执行完毕后,primary数据库将会转换为standby数据库,并自动备份控制文件到trace。

3、 重启动到mount  --原primary数据库操作

    SQL>  shutdown immediate

    ORA-01507:  未装载数据库

    ORACLE  例程已经关闭。

    SQL>  startup mount

    ORACLE  例程已经启动。

    Total System Global Area  167772160 bytes

    Fixed Size                  1289484 bytes

    Variable Size             104858356 bytes

    Database Buffers           54525952 bytes

    Redo Buffers                7098368 bytes

    数据库装载完毕。

4、 检查是否支持switchover操作   --待转换standby数据库操作

  待原primary切换为standby角色之后,检查待转换的standby数据库switchover_status列,看看是否支持角色转换。

    E:\ora10g>set oracle_sid=jsspdg

    E:\ora10g>sqlplus " / as sysdba"

    SQL*Plus: Release 10.2.0.3.0 - Production on  星期四 12月 13 10:08:15 2007

    Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

    已连接。

    SQL> select switchover_status from v$database;

    SWITCHOVER_STATUS

    --------------------

    TO PRIMARY

    SQL>

  此时待转换standby数据库switchover_status列值应该是"TO_PRIMARY",如否则检查其初始化参数文件中的设置,提示一下,比着原primary数据库的初始化参数改改。

5、 转换角色到primary  --待转换standby数据库操作

  通过下列语句转换standby到primary角色:

    SQL> alter database commit to switchover to primary;

    数据库已更改。

  注意:待转换的物理standby可以处于mount模式或open read only模式,但不能处于open read write模式。

6、 完成转换,打开新的primary数据库

    SQL> alter database open;

    数据库已更改。

  注:如果数据库处于open read-only模式的话,需要先shutdown然后直接startup即可。

7、 验证一下

  新的primary数据库

    SQL> show parameter db_unique

    NAME                                 TYPE        VALUE

    ------------------------------------ ----------- ------------------------------

    db_unique_name                       string      jsspdg

    SQL> select max(sequence#) from v$archived_log;

    MAX(SEQUENCE#)

    --------------

                67

    SQL>  alter system switch logfile;

    系统已更改。

    SQL> select max(sequence#) from v$archived_log;

    MAX(SEQUENCE#)

    --------------

                68

  新的standby数据库

    SQL> show parameter db_unique

    NAME                                 TYPE        VALUE

    ------------------------------------ ----------- ------------------------------

    db_unique_name                       string      jssweb

    SQL>  select max(sequence#) from v$archived_log;

    MAX(SEQUENCE#)

    --------------

                68

      转换成功。

二、 物理standby的failover

  注意几点:

  • failover 之后,原primary数据库默认不再是data guard配置的一部分。
  • 多数情况下,其它逻辑/物理standby数据库不直接参与failover的过程,因此这些数据库不需要做任何操作。
  • 某些情况下,新的primary数据库配置之后,需要重新创建其它所有的standby数据库。

  另外,如果待转换角色的standby处于maximum protection或maximum availability模式的话,归档日志应该是连续存在的,这种情况下你可以直接从第 3 步执行,否则建议你按照操作步骤从第1步开始执行。

  一般情况下failover都是表示primary数据库瘫痪,最起码也是起不来了,因此这种类型的切换基本上不需要primary数据库做什么操作。所以下列步骤中如果有提到primary和standby执行的,只是建议你如果primary还可以用,那就执行一下,即使它能用你却不执行,也没关系,不影响standby数据库的切换:)

1、 检查归档文件是否连续

  查询待转换standby数据库的V$ARCHIVE_GAP视图,确认归档文件是否连接:

    SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

    未选定行

  如果返回的有记录,按照列出的记录号复制对应的归档文件到待转换的standby服务器。这一步非常重要,必须确保所有已生成的归档文件均已存在于standby服务器,不然可能会数据不一致造成转换时报错。文件复制之后,通过下列命令将其加入数据字典:

    SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ¨filespec1¨;

2、 检查归档文件是否完整

  分别在primary/standby执行下列语句:

    SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;

  该语句取得当前数据库各线程已归档文件最大序号,如果primary与standby最大序号不相同,必须将多出的序号对应的归档文件复制到待转换的standby服务器。不过既然是failover,有可能primary数据库此时已经无法打开,甚至无法访问,那你只好听天由命喽,三思在这里替你默念:苍天啊,大地啊,哪路的神仙大姐能来保佑俺们不丢数据呀!

3、 启动failover

  执行下列语句:

    SQL> alter database recover managed standby database finish force;

    数据库已更改。

  FORCE 关键字将会停止当前活动的RFS进程,以便立刻执行failover。

  剩下的步骤就与前面switchover很相似了

4、 切换物理standby角色为primary

    SQL> alter database commit to switchover to primary;

    数据库已更改。

5、 启动新的primary数据库。

  如果当前数据库已mount,直接open即可,如果处于read-only模式,需要首先shutdown immediate,然后再直接startup。

    SQL> alter database open;

    数据库已更改。

  角色转换工作完成。剩下的是补救措施(针对原primary数据库),由于此时primary数据库已经不再是data guard配置的一部分,我们需要做的就是尝试看看能否恢复原primary数据库,将其改造为新的standby服务器。具体操作方式可以分为二类:1.重建  2.备份恢复。所涉及的技术前面的系列文章中均有涉及,此处不再赘述。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/266281/viewspace-670738/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2005-03-03

  • 博文量
    58
  • 访问量
    42982