一步一步学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是否启动了SQL应用：）。

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的话呢，oracle倒是也提供了其它解决方案(虽然不一定好使)：

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

       863 E:/ORA10G/ORADATA/JSSWEB/ARC/LOG1_863_641301252.ARC                    2008-02-23 17:19:48

       863 jssldg2                                                                2008-02-23 17:20:59

       864 E:/ORA10G/ORADATA/JSSWEB/ARC/LOG1_864_641301252.ARC                    2008-02-23 17:21:11

       864 jssldg2                                                                2008-02-23 17:21:13

已选择13行。

发现了一点点痕迹，我们的切换操作是下午3点左右进行的，期间还产生了序列号为860,861之类的归档文件，但并未传输至standby，是不是因为这些文件中包含了一部分应被应用的数据，因此造成standby接收到的新primary传输过来的归档scn与最后应用的scn不连续，所以无法应用？再来验证一下：

JSSLDG2> select applied_scn,latest_scn from v$logstdby_progress;

APPLIED_SCN LATEST_SCN

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

    1259449     1284126

果然如此，应用的scn与最后的scn确实不匹配，剩下的就好解决了，把所有可疑的应传输到standby的归档文件手工复制到standby，然后通过alter命令注册一下：

JSSLDG2> alter database register logical logfile 'E:/ora10g/oradata/jssldg2/std/LOG1_859_641301252.ARC';

数据库已更改。

JSSLDG2> alter database register logical logfile 'E:/ora10g/oradata/jssldg2/std/LOG1_860_641301252.ARC';

数据库已更改。

JSSLDG2> alter database register logical logfile 'E:/ora10g/oradata/jssldg2/std/LOG1_861_641301252.ARC';

数据库已更改。

提示：复制文件的时候尽可能把相近时间段的归档文件都拷过来，不用担心无用归档会不会影响到应用，oracle会自动判断归档中的scn，对于已经应用过的正常情况下是不会重复应用的，因此我们把859,860,861全部复制过来。

再查看一下应用状态：

JSSLDG2> select sequence#,applied from dba_logstdby_log;

 SEQUENCE# APPLIED

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

       862 CURRENT

       863 CURRENT

哈哈，已经开始应用了。逻辑standby恢复成功！想起官方文档中有一句提示，说的是在打开新的primary数据库，生成数据字典之前，不要执行任何DDL，不然就只能重建逻辑standby了，估计就是担心执行ddl后不幸触发日志切换，造成逻辑standby接收新primary传来的归档文件不连续，无法顺利应用。

切换完成之后，在修复逻辑standby的同时，顺手打扫一下战场，比如设置新primary数据库的备份策略，以及考虑如何修复前故障的primary等等，dba这份工作，人前看起来光鲜，如果你已经下定决心要从事这行，那对于人后的辛苦一定要有深刻心理准备哟，你看看像上面这种情况，primary只要随随便便宕个机，引之而来的工作量就够我们忙活的。

也许这个时候dba需要的不仅是保持清晰的大脑，还要能打开思路，此时我们更不妨考虑在做角色切换和修复损坏的primary之间做个选择，究竟哪个更快，哪个更简便一些呢，

你看，干dba这行，不仅压力大，不仅要本领过硬，不仅要耐心细致，关键时刻还要保持清醒的头脑，额地神耶，太刺激啦，太有挑战啦~~~~~~