ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一步一步学DataGuard(15)逻辑standby之failover

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

原创 Linux操作系统 作者:junsansi 时间:2008-03-26 13:32:31 0 删除 编辑

逻辑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

字数受限,详细请查看:

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

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

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-21

  • 博文量
    640
  • 访问量
    4094183