1  创建物理Standby

具体的参考我的blog

Oracle Data Guard Linux 平台 Physical Standby 搭建实例

http://blog.csdn.net/tianlesoftware/archive/2010/04/30/5547565.aspx

 

Oracle Data Gurad Physical Standby 相关说明

http://blog.csdn.net/tianlesoftware/archive/2010/05/04/5557410.aspx

 

简单的做如下几点提示:

1.初始化参数配置

初始化参数的修改并不仅仅只是在待创建的Standby数据库端创建,当前的Primary数据库甚至同一个Data Guard配置中的其他Standby数据库的初始化参数都有可能需要进行修改。

对于Primary数据库,至少需要新增一个LOG_ARCHIVE_DEST_n参数,以发送REDO数据到新的Standby端,同时其他一些与Standby环境相关的参数也会涉及调整,如LOG_ARCHIVE_CONFIGFAL_*等参数。

而对于现有的Standby数据库(如果有的话),主要是基于角色转换的考虑,有必要对一些参数提前进行设置,设置的参数对当前功能不会有任何影响或促进,如果确定不进行角色转换,那么同一个Data Guard配置中的其他Standby数据库初始化参数也可以不做任何调整。

2.监听和NetService配置

建议用Net Manager 工具来配置,这样不容易出现错误。

 

3.创建密钥文件

必须确保在同一个Data Guard环境中,所有数据库的SYS用户拥有相同密码,建议从其他服务器复制密钥文件到本地,然后按照密钥文件名的格式修改文件名即可。

注意Windows平台和Linux/UNIX平台下,密钥文件名的命名格式并不相同,Windows平台下密钥文件名格式为PWD[sid].ora,而Linux/UNIX平台下密钥文件名格式为orapw[sid],注意文件名的大小写哟。

 

2  Primary数据库生成数据字典

执行下列过程,生成LogMiner字典信息:

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;  

PL/SQL procedure successfully completed. 

 

注意:Primary生成数据字典前,一定要确保待转换的物理Standby数据库已经停止REDO应用。如果已经启用了REDO应用,执行下列语句停止REDO应用:

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  

Database altered. 

 

控制文件中记录了日志文件的应用状态,正常情况下一个日志文件只会被应用一次,如果Primary生成的数据字典信息被物理Standby数据库应用了,等该物理Standby转换成逻辑Standby数据库时(不应用数据字典不代表就不能执行转换哟)就不会再应用这些文件,自然也没有Primary数据库对象的元数据,这可能会导致这部分对象的修改不能被逻辑Standby正常应用。

我们操作的根本目的是为了让逻辑Standby能够应用到这部分数据字典信息,只要能够实现这一点,是否暂停REDO应用或什么时间暂停REDO应用就无所谓了。这也我们理解另外一个问题,如果Primary生成LogMiner字典信息时,待转换的物理Standby数据库没有暂停REDO应用怎么办?好办,马上暂停REDO应用,然后Primary数据库重新生成一下LogMiner字典信息就是。

 

3  转换物理Standby为逻辑Standby

执行下列语句,转换物理Standby为逻辑Standby

SQL> SHOW PARAMETER DB_NAME

NAME         TYPE        VALUE

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

db_name        string      orcl

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY LGDG;  

Database altered. 

执行完该语句之后,关闭数据库并重新启动到MOUNT状态:

SQL> SHUTDOWN IMMEDIATE  

ORA-01507: database not mounted  

ORACLE instance shut down.  

SQL>  STARTUP MOUNT;

ORACLE instance started.

Total System Global Area  167772160 bytes

Fixed Size                  1218316 bytes

Variable Size              79694068 bytes

Database Buffers           83886080 bytes

Redo Buffers                2973696 bytes

Database mounted. 

 

为什么要重启?因为上述操作涉及逻辑Standby数据库更名,包括DBIDINCARNATION等均已被重新初始化。

再次查看DB_NAME参数和数据库角色:

 

SQL> SHOW PARAMETER DB_NAME;

NAME               TYPE        VALUE

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

db_name             string      LGDG

SQL> SELECT DATABASE_ROLE FROM V$DATABASE;

 

DATABASE_ROLE

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

LOGICAL STANDBY

 

现在DB_NAME和数据库的角色都已经被修改。

 

 

4  调整逻辑Standby数据库初始化参数

设置重做日志文件路径,将本地生成的归档文件和Primary数据库发送来的归档文件分开,存放到不同目录内,注意归档文件路径不要冲突,修改参数如下:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archive VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=LGDG';    # LGDG 是在tnsnames.ora 中配置的

System altered.

 

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='LOCATION=/u01/std

VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME=LGDG'; 

System altered.

 

5  打开逻辑Standby

由于逻辑StandbyPrimary数据库事务并不一致,因此第一次打开时必须指定RESETLOGS子句,执行语句如下:

SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered. 

然后执行下列SQL命令开始应用REDO数据:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY ; 

Database altered. 

 

如果要启用实时应用,建议首先创建Standby Redologs,例如,为该逻辑Standby创建几组Standby Redologs

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/app/oracle/oradata/orcl/redo04.log' SIZE 50m;  

Database altered.  

 

重新执行启动REDO应用的命令,附加APPLY IMMEDIATE子句,以打开实时应用(由于当前REDO应用已经启动,因此我们首先停止REDO应用):

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;  

Database altered.  

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;  

Database altered. 

 

6  验证环境

所有配置完成,接下来尝试在Primary数据库端执行修改操作,看看是否能够分别在逻辑Standby和物理Standby端应用。

首先在Primary数据库端执行下列语句,向tmp1表插入一条新记录并提交:

SQL> insert into scott.dept values(1,'dave','dmm');

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

 

接下来看看逻辑Standby的同步情况:

SQL> select * from scott.dept;

    DEPTNO DNAME          LOC

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

        10 ACCOUNTING     NEW YORK

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON

         1 dave           dmm

 

提 示细心观察重做日志,发现逻辑Standby有一点设计得很好,从Primary数据库接收到的重做日志文件文件,应用过之后就会自动删除,节省了磁盘空间。

 

OK,至此逻辑Standby创建成功.

 

 

二. 主备切换之switchover 

要在Primary和逻辑Standby之间切换角色,一般是从Primary数据库开始操作。

如果Primary或逻辑StandbyRAC结构,切记在执行角色切换时,只保留一个实例启动,其他实例应当全部SHUTDOWN。等角色转换操作完成之后再启动其他实例,角色转换的操作会自动传播到这些实例上,并不需要DBA再对这些实例单独做处理。

 

注意下列操作的执行步骤,强烈建议按照以下步骤执行,否则可能导致切换不成功。

 

1.准备工作

检查Primary和逻辑Standby的初始化参数设置,常规的检查包括:

检查两机中初始化参数FAL_SERVERFAL_CLIENTLOG_ARCHIVE_CONFIG的参数值设置是否正确。

检查两机中初始化参数LOG_ARCHIVE_DEST_n的参数值设置是否正确。

 

首先来看当前的Primary数据库:

SQL>  SHOW PARAMETER FAL;

NAME                    TYPE        VALUE

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

fal_client                  string      orcl_pd

fal_server                  string      orcl_st

SQL> SHOW PARAMETER LOG_ARCHIVE_DEST;

 

NAME                                 TYPE        VALUE

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

log_archive_dest                     string

log_archive_dest_1                   string      location=/u01/archive

log_archive_dest_10                  string

log_archive_dest_2                   string      service=LGDG

       

从上述显示的结果来看,Primary数据库的初始化参数并不太适合,为了避免其转换之后可能发生的错误,我们提前做些修改:

SQL> ALTER SYSTEM SET FAL_SERVER='LGDG';

System altered.

SQL> alter system set log_archive_dest_1='location=/u01/archive 

valid_for=(online_logfiles,all_roles)  db_unique_name=orcl_pd';  

System altered.  

SQL> alter system set log_archive_dest_3='location=/u01/std

 valid_for=(standby_logfiles,standby_role)  db_unique_name=orcl_pd';  

System altered. 

 

然后再看看待转换的逻辑Standby

SQL> SHOW PARAMETER FAL;

NAME                    TYPE        VALUE

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

fal_client                  string      orcl_st

fal_server                  string      orcl_pd

SQL> SHOW PARAMETER LOG_ARCHIVE_DEST;

 

NAME                                 TYPE        VALUE

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

log_archive_dest                     string

log_archive_dest_1                   string      LOCATION=/u01/archive VALID_FO

                                                 R=(ONLINE_LOGFILES, ALL_ROLES)

                                                  DB_UNIQUE_NAME=LGDG

log_archive_dest_10                  string

log_archive_dest_2                   string      service=orcl_pd lgwr sync AFFI

                                                 RM

log_archive_dest_3                   string      LOCATION=/u01/std

                                                 VALID_FOR=(STANDBY_LOGFILES, S

                                                 TANDBY_ROLE) DB_UNIQUE_NAME=LG

                                                 DG

修改一下:

SQL> ALTER SYSTEM SET FAL_CLIENT='LGDG';

 

 

最后检查Primary数据库是否配置了Standby Redologs

SQL> select * from v$logfile;

    GROUP# STATUS  TYPE    MEMBER

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

         3         ONLINE  /u01/app/oracle/oradata/orcl/redo03.log

         2         ONLINE  /u01/app/oracle/oradata/orcl/redo02.log

         1         ONLINE  /u01/app/oracle/oradata/orcl/redo01.log

         4         STANDBY /u01/app/oracle/oradata/orcl/redo04.log

         5         STANDBY /u01/app/oracle/oradata/orcl/redo05.log

         6         STANDBY /u01/app/oracle/oradata/orcl/redo06.log

         7         STANDBY /u01/app/oracle/oradata/orcl/redo07.log

 

已经存在, 如果不存在,我们就手工的添加一下:

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/app/oracle/oradata/orcl/redo04.log' SIZE 50m;  

Database altered.  

 

 

2.检查Primary数据库状态

查看当前Primary数据库状态:

SQL>  SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS

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

TO STANDBY

如果该查询返回TO STANDBY SESSIONS ACTIVE则表示状态正常,可以执行转换操作,如果是其他值,你就需要重新检查一下Data Guard配置,如看看LOG_ARCHIVE_DEST_n之类的参数值是否正确、有效等。

 

3.准备转换Primary为逻辑Standby

执行下列语句,将Primary置为准备转换的状态:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;

 

Database altered.

 

执行完上述操作后,Primary数据库就开始为角色的转换打好基础,时刻准备着接收来自逻辑Standby数据库,也就是未来的新Primary数据库发来的REDO数据。

 

查看一下SWITCHOVER_STATUS的状态:

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

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

PREPARING SWITCHOVER

 

4.准备转换逻辑StandbyPrimary

逻辑Standby数据库准备转换为Primary角色,执行下列语句:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

Database altered.

语句执行时响应可能会有点慢。

 

执行完后查看当前逻辑Standby数据库的转换状态:

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;  

SWITCHOVER_STATUS  

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

PREPARING SWITCHOVER 

 

5.再次检查Primary数据库状态

执行下列语句:

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

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

TO LOGICAL STANDBY

 

这步虽然不用做什么操作,但检查结果却非常重要,它直接关系到switchover转换是否能够成功。逻辑Standby执行完PREPARE命令之后,就会生成相应的LogMiner字典数据(就像我们前面创建逻辑Standby时,Primary数据库会生成LogMiner字典数据一样),只有它正常生成并发送至当前的Primary数据库,转换操作才能够继续下去。不然当前的Primary数据库在转换完之后,可能就失去了从新的Primary数据库接收REDO数据的能力了。

因此,如果上述查询的返回结果不是TO LOGICAL STANDBY的话,DBA就需要考虑是否取消此次转换,检查原因,然后再重新操作了。

 

取消转换可以通过下列语句进行:

ALTER DATABASE PREPARE TO SWITCHOVER CANCEL; 

需要分别在Primary端和逻辑Standby端执行。由此可见准备工作的好处显现出来了嘛,一旦异常,随时可以选择取消。

 

 

6.转换Primary为逻辑Standby

如果前面的操作都没有问题,就可以正式开始角色转换的操作,首先是将原Primary数据库转换成新的Standby,操作如下:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

 

Database altered.

 

该语句需要等待当前Primary数据库所有事务全部结束才开始执行。该语句执行过程中会自动拒绝用户提交新事务或修改需求。为了确保该操作尽可能快的执行,最好自开始切换操作起就禁止所有用户的操作。

该命令执行完之后,这个Primary数据库就已经成为新的逻辑Standby了。不过在新Primary执行完转换之前,不要关闭当前这个数据库。

 

 

7.再次检查逻辑Standby状态

逻辑Standby在接收到前Primary的转换消息,并应用完相关的REDO数据之后,会自动暂停SQL应用,然后查询SWITCHOVER_STATUS的状态,应该为TO PRIMARY

SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;  

SWITCHOVER_STATUS  

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

TO PRIMARY 

或者

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

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

NOT ALLOWED

 

 

8.转换逻辑Standby为新的Primary数据库

最后的工作总会在逻辑Standby端操作,通过下列语句,将该逻辑Standby转换为新的Primary数据库:

SQL>  ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Database altered.

 

转换操作至此完成。

 

最后启动新逻辑Standby,即前Primary数据库端的SQL应用即可:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Database altered.

 

注意:每一个逻辑Standby都相当于是一个不同于(前)Primary的数据库(DBID都不同),因此当逻辑Standby完成了转换之后,相当于原Primary数据库已经消失,依照原Primary数据库配置的物理Standby自然也就失去了主从参照,物理Standby也就不再是当前Data Guard配置中的成员了。

这也正是前面修改Primary初始化参数时,取消发送REDO数据到物理Standby数据库的原因。不过还好,对于switchoverData Guard配置中的其他逻辑Standby数据库不会有影响。

 

9.环境测试

最后来测试一下当前的Data Guard配置,首先在新Primary数据库操作一条记录:

SQL> insert into scott.dept values(2,'bl','bl');

1 row created.

SQL> commit;

Commit complete.

 

转到逻辑Standby端查看:  

    DEPTNO DNAME          LOC

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

         1 dave           dmm

        10 ACCOUNTING     NEW YORK

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON

         2 bl             bl

同步成功,也基本代表转换成功

 

 

三.主备切换之 Failover

 

failover有可能会丢失数据(视当前的数据库保护模式而定),而且所有的操作都是在Standby数据库端执行,这几点对于逻辑Standby也同样适用,甚至对于明确提及需要在前Primary数据库执行的,不执行也没关系,毕竟对于failover,我们假设的就是Primary数据库已经over

 

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

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

 

在主库查询:

SQL>  SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;

MAX(SEQUENCE#)

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

           113

在备库查询:

SQL> SELECT SEQUENCE#,APPLIED FROM DBA_LOGSTDBY_LOG;

 SEQUENCE# APPLIED

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

       110 CURRENT

       111 NO

 

如果上述查询的结果不同,说明Primary存在尚未发送至逻辑Standby数据库的归档文件,手工复制这些文件到待转换角色的逻辑Standby端,然后在该逻辑Standby数据库的SQL*Plus命令窗口,

通过执行ALTER DATABASE REGISTER LOGICAL LOGFILE 'filepath'; 命令,将复制过来的归档文件手工注册。

如果逻辑StandbyPrimary的归档序号相同,但某些序号的APPLIED状态为NO,建议DBA检查一下当前逻辑Standby数据库是否启动了SQL应用。

如果Primary数据库已经无法打开,DBA就只好直接到磁盘上查看归档目录中的序号,来与逻辑Standby数据库做比较。如果Primary数据库已经完全无法访问,那请直接跳过本步。

 

2.检查待转换逻辑Standby的日志应用情况

查询重做日志的应用情况,可以通过V$LOGSTDBY_PROGRESS视图进行,例如:

SQL>  SELECT APPLIED_SCN,LATEST_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN LATEST_SCN

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

     598967     598967

如果返回的结果中显示,两列的列值一致,则表示所有接收到的重做日志都已经应用。如果不一致的话,启动逻辑Standby端的SQL应用。

 

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

确认待转换的逻辑Standby配置了正确的归档路径,不仅是写本地的归档配置,还要有写远端服务器的归档配置,不然转换完之后,这台新的Primary数据库就成了光杆司令了。

一般来说,我们都是推荐在创建Standby数据库的同时将一些用于角色切换的初始化参数也配置好(PrimaryStandby端都应如此),以减少切换时操作的时间,提高切换效率。执行如下命令:

SQL> SHOW PARAMETER LOG_ARCHIVE_DEST  

 

4.激活新的Primary数据库

首先查看当前操作的角色:

SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;  

DATABASE_ROLE    FOR 

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

LOGICAL STANDBY  YES 

注 意

如果当前FORCE_LOGGINGNO,务必执行ALTER DATABASE FORCE LOGGING;命令。

执行下列语句,转换Standby数据库角色为Primary

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; 

数据库已更改。

 

该语句主要是停止待转换的逻辑StandbyRFS进程,并应用完当前所有已接收但并未应用的REDO数据,然后停止SQL应用,将数据库转换成Primary角色。

 

语句执行完成后,再次查看当前数据库的角色:

SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;  

DATABASE_ROLE    FOR 

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

PRIMARY          YES 

 

基本上到这一步,我们可以说角色转换的工作已经完成了此处与逻辑Standbyswitchover同理,切换完之后,原Data Guard配置就失效了,彻底的失效了,不仅物理Standby没了,逻辑Standby也失去了参照,逻辑Standbyfailover威力确实大呀,怪不得逻辑Standby用的人这么少呢,环境脆弱肯定是原因之一,因此我们需要做些设置,重新将原来的逻辑Standby再加入到新的Data Guard配置环境中。

 

5.修复其他Standby数据库

物理Standby数据库的修复只有重建一种方式,至于如何创建物理Standby,前面说的已经足够多了,下面重点描述一下原Data Guard环境中的逻辑Standby

注意的是,逻辑Standby的修复可不像物理Standby那样简单相比较来说,重建其实是个简单的工作,因为初始化参数文件、密钥文件、存放目录等都是现成的,几乎不需要改动,DBA所需要做的,基本上就是重新复制一份新Primary数据库的相关文件,每个逻辑Standby都相当于是独立的数据库,如果你不希望重建逻辑Standby的话呢,Oracle倒是也提供了其他的解决方案。

 

假定原Data Guard环境中有逻辑Standby数据库LGDG,执行failover后,LGDG不再是新Data Guard环境中的成员,这里演示如何恢复该数据库到当前的Data Guard配置,操作步骤如下:

1)在原逻辑Standby中创建数据库链,连接到新的Primary数据库。

这里所谓的原Standby数据库,自然是指JSSLDG2喽,注意,数据库链中用于连接新Primary数据库的用户必须拥有SELECT_CATALOG_ROLE角色。执行以下语句:

SQL> ALTER SESSION DISABLE GUARD; 

Session altered.

SQL> CREATE DATABASE LINK BL CONNECT TO SYSTEM IDENTIFIED BY admin USING 'orcl_pd';

Database link created.

SQL> ALTER SESSION ENABLE GUARD; 

会话已更改。

 

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

SQL> SELECT SYSDATE FROM DUAL@BL;

SYSDATE

---------

06-MAY-10

提 示 ALTER SESSION ENABLE|DISABLE GUARD语句作用?

该语句用于允许或禁止用户修改逻辑Standby中的结构。

2)重新启动SQL应用。

在各个逻辑Standby端执行下列语句启动SQL应用(注意更新dblinkName):

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY BL;  

Database altered. 

 

如果你运气好,等语句执行完之后,恢复过程就完成了。如果你非常不幸地碰到了ORA-16109错误,那么我不得不告诉你,恐怕你得重建逻辑Standby了。

 

One Response


    还没有评论!
1  

Leave your comment

请留下您的姓名(*)

请输入正确的邮箱地址(*)

请输入你的评论(*)


感谢开源 © 2016. All rights reserved.&3Q Open Source&^_^赣ICP备15012863号-1^_^
乐于分享共同进步 KreativeThemes