一步一步学DataGuard(15)逻辑standby之failover

逻辑standby之failover

前面学习物理standby的failover时我们提到过，failover有可能会丢失数据(视当前的保护模式而定)，对于逻辑standby也一样；物理standby在做failover演示时还提到过，所有的操作都会在standby端执行，对于逻辑standby这也一样，甚至对于明确提及在前primary执行的，你不执行，也没关系，毕竟对于failover，我们假设的就是，primary已经over了:)

一、准备工作要充分

准备工作可以从以下几个方面着手：

1、检查及处理丢失的归档

虽然本步不是必须的，但如果希望尽可能少丢失数据，除了数据保护模式之外，本步操作也非常重要。如果此时primary仍可被访问，首先检查当前的归档日志序号与逻辑standby是否相同：

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

MAX(SEQUENCE#)

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

            24

JSSWEB> select sequence#,applied from dba_logstdby_log;

 SEQUENCE# APPLIED

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

        23 YES

        24 YES

已选择2行。

提示：如果primary的数据库已经无法打开，您就只好直接到磁盘上查看归档目录中的序号来与standby端做比较了。

如果不同序号，则将primary尚未发送至standby的归档文件手工复制到待转换的逻辑standby服务器，然后在standby端通过 ALTER DATABASE REGISTER LOGICAL LOGFILE ''; 命令将文件手工注册

如果standby与primary的归档序号相同，但某些序号的applied状态为no，建议你检查一下当前standby是否启动了应用：）。

2、检查待转换逻辑standby的日志应用情况

可以通过查询v$logstdby_progress视图：

JSSWEB> select applied_scn,latest_scn from v$logstdby_progress;

APPLIED_SCN LATEST_SCN

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

    1259449    1259453

如果两值一致，表示所有接收到的归档都已经应用了。

3、检查及修正待转换逻辑standby的初始化参数配置

确认待转换的逻辑standby配置了正确的归档路径，不仅是写本地的归档，还要有写远程的归档，不然转换完之后，这台新的primary就成了光杆司令了。

JSSWEB> show parameter log_archive_dest

.......................

当然一般来说，我们都是推荐在创建standby的同时将一些用于角色切换的初始化参数也配置好(primary和standby端都应如此)，以减小切换时操作的时间，提高切换效率。

二、激活新的primary数据库

首先查看当前操作的角色

JSSWEB> select database_role,force_logging from v$database;

DATABASE_ROLE    FOR

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

LOGICAL STANDBY  YES

注意，如果当前force_logging为no，务必执行：Alter database force logging;

转换standby角色为primary

JSSWEB> alter database activate logical standby database finish apply;

数据库已更改。

该语句主要是停止待转换的逻辑standby中RFS进程，并应用完当前所有已接收但并未应用的redo数据，然后停止sql应用，将数据库转换成primary角色。

JSSWEB> select database_role,force_logging from v$database;

DATABASE_ROLE    FOR

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

PRIMARY          YES

基本上到这一步，我们可以说角色转换的工作已经完成了，但是注意，活还没有干完！

此处与逻辑standby的switchover同理，切换完之后，原dg配置就失效了(不仅原物理standby没了，原逻辑standby也失去了参照，看看，逻辑standby的failover确实威力巨大呀，怪不得逻辑standby用的人这么人呢，环境脆弱肯定是原因之一啊)，因此我们需要做些设置，重新将原来的standby再加入到新的dg配置环境中。

三、修复其它standby

注意哟，逻辑standby的修复可并不像物理standby那样简单，每个逻辑standby都相当于是独立的数据库，如果你不希望重建逻辑standby的话呢，倒是也提供了其它解决(虽然不一定好使)：

1、在各个原逻辑standby中创建数据库链，连接到新的primary

注意，数据库链中用于连接新primary的用户必须拥有SELECT_CATALOG_ROLE角色。

JSSLDG2> alter session disable guard;

会话已更改。

JSSLDG2> create database link getjssweb connect to jss identified by jss using 'jssweb';

数据库链接已创建。

JSSLDG2> alter session enable guard;

会话已更改。

验证一下数据链是否能够正常访问：

JSSLDG2> select sysdate from dual@getjssweb;

SYSDATE

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

23-2月 -08

提示：关于alter session enable|disable guard语句，用于允许或禁止用户修改逻辑standby中的结构。例如：

JSSLDG2> conn jss/jss

已连接。

JSSLDG2> select *from b;

        ID

----------

         1

         2

         3

         4

         5

         6

         7

         8

已选择8行。

JSSLDG2> alter table b rename to a;

alter table b rename to a

*

第 1 行出现错误:

ORA-16224: Database Guard 已启用

JSSLDG2> alter session disable guard;

会话已更改。

JSSLDG2> alter table b rename to a;

表已更改。

2、重新启动SQL应用

在各个逻辑standby执行下列语句启动sql应用(注意更新dblinkName)：

JSSLDG2> alter database start logical standby apply new primary getjssweb;

数据库已更改。

如果你运气好，等语句执行完之后，恢复过程就完成了。如果你非常不幸的碰到了ORA-16109错误，那么我不得不告诉你，恐怕你得重建逻辑standby了。所以，祝你好运吧:)

语句顺利执行完之后，我们来验证一下：

JSSWEB> alter system switch logfile;

系统已更改。

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

MAX(SEQUENCE#)

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

           862

JSSLDG2> select sequence#,applied from dba_logstdby_log;

 SEQUENCE# APPLIED

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

       862 NO

注意：出现问题了！！

日志是传输过去了，但是逻辑standby并没有开始应用，怎么回事？

我们先来确认一下standby的各进程状态：

JSSLDG2> select process,status,group#,thread#,sequence#,block#,blocks from v$managed_standby;

PROCESS   STATUS       GROUP#                                      THREAD#  SEQUENCE#     BLOCK#     BLOCKS

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

ARCH      CLOSING      2                                                 1          4      16385       1836

ARCH      CLOSING      6                                                 1        862          1         18

RFS       IDLE         N/A                                               0          0          0          0

RFS       IDLE         3                                                 1        863          2          1

看起来也是正常的，接收完了862,正在等待863，但是，为什么不应用呢。

手工查询一下新primary生成的归档日志情况：

JSSWEB> select sequence#,name,COMPLETION_TIME from v$archived_log where sequence#>855;

 SEQUENCE# NAME                                                                   COMPLETION_TIME

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

       856 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_856_641301252.ARC                    2008-02-21 10:15:42

       857 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_857_641301252.ARC                    2008-02-21 10:16:46

       858 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_858_641301252.ARC                    2008-02-23 14:15:18

       859 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_859_641301252.ARC                    2008-02-23 14:56:55

       860 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_860_641301252.ARC                    2008-02-23 14:57:03

       861 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_861_641301252.ARC                    2008-02-23 16:58:14

       861 jssldg2                                                                2008-02-23 16:58:16

       862 E:\ORA10G\ORADATA\JSSWEB\ARC\LOG1_862_641301252.ARC                    2008-02-23 17:08:57

       862 jssldg2                                                                2008-02-23 17:08:57

字数受限，详细请查看：

一步一步学DataGuard(15)逻辑standby之failover全文