Data Guard ⑸ .物理standby(3)角色转换

Data Guard 转载 ⑸ .物理standby(3)角色转换

本文作者： junsansi     转载网址： http://www.5ienet.com/index.shtml

 

 

第二部分物理standby(3)角色转换  2007.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 数据库有数据传输，此时alterdatabase 语句更改standby 数据库保护模式会失败，这也是由maximum protection 模式特性决定的。

 

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

 

 

一、物理standbstandby的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> selectswitchover_statusfromv$database;
    SWITCHOVER_STATUS
    --------------------
    TO STANDBY

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

 

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

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

    SQL> alterdatabasecommittoswitchovertophysicalstandby;
    数据库已更改。

 

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

 

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

 

    SQL> shutdownimmediate
    ORA-01507: 未装载数据库
    ORACLE 例程已经关闭。

    SQL> startupmount
    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

    此时待转换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> altealter 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.备份恢复。所涉及的技术前面的系列文章中均有涉及，此处不再赘述。