Oracle Data Guard Linux 平台 Logical Standby 创建实例

操作系统：linuxredhat4.7

Oracle:10.2.0.1

主库：orcl_pd

备库：LGDG

一．逻辑Standby创建过程

1创建物理Standby

具体的参考我的blog：

OracleDataGuardLinux平台PhysicalStandby搭建实例

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

OracleDataGuradPhysicalStandby相关说明

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

简单的做如下几点提示：

1）．初始化参数配置

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

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

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

2）．监听和NetService配置

建议用NetManager工具来配置，这样不容易出现错误。

3）．创建密钥文件

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

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

2Primary数据库生成数据字典

执行下列过程，生成LogMiner字典信息：

SQL>EXECUTEDBMS_LOGSTDBY.BUILD;

PL/SQLproceduresuccessfullycompleted.

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

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;

Databasealtered.

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

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

3转换物理Standby为逻辑Standby

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

SQL>SHOWPARAMETERDB_NAME

NAMETYPEVALUE

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

db_namestringorcl

SQL>ALTERDATABASERECOVERTOLOGICALSTANDBYLGDG;

Databasealtered.

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

SQL>SHUTDOWNIMMEDIATE

ORA-01507:databasenotmounted

ORACLEinstanceshutdown.

SQL>STARTUPMOUNT;

ORACLEinstancestarted.

TotalSystemGlobalArea167772160bytes

FixedSize1218316bytes

VariableSize79694068bytes

DatabaseBuffers83886080bytes

RedoBuffers2973696bytes

Databasemounted.

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

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

SQL>SHOWPARAMETERDB_NAME;

NAMETYPEVALUE

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

db_namestringLGDG

SQL>SELECTDATABASE_ROLEFROMV$DATABASE;

DATABASE_ROLE

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

LOGICALSTANDBY

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

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

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

SQL>ALTERSYSTEMSETLOG_ARCHIVE_DEST_1='LOCATION=/u01/archiveVALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=LGDG';#LGDG是在tnsnames.ora中配置的

Systemaltered.

SQL>ALTERSYSTEMSETLOG_ARCHIVE_DEST_3='LOCATION=/u01/std

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

Systemaltered.

5打开逻辑Standby

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

SQL>ALTERDATABASEOPENRESETLOGS;

Databasealtered.

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

SQL>ALTERDATABASESTARTLOGICALSTANDBYAPPLY;

Databasealtered.

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

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP4'/u01/app/oracle/oradata/orcl/redo04.log'SIZE50m;

Databasealtered.

重新执行启动REDO应用的命令，附加APPLYIMMEDIATE子句，以打开实时应用（由于当前REDO应用已经启动，因此我们首先停止REDO应用）：

SQL>ALTERDATABASESTOPLOGICALSTANDBYAPPLY;

Databasealtered.

SQL>ALTERDATABASESTARTLOGICALSTANDBYAPPLYIMMEDIATE;

Databasealtered.

6验证环境

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

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

SQL>insertintoscott.deptvalues(1,'dave','dmm');

1rowcreated.

SQL>commit;

Commitcomplete.

SQL>altersystemswitchlogfile;

Systemaltered.

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

SQL>select*fromscott.dept;

DEPTNODNAMELOC

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

10ACCOUNTINGNEWYORK

20RESEARCHDALLAS

30SALESCHICAGO

40OPERATIONSBOSTON

1davedmm

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

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

二．主备切换之switchover

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

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

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

1．准备工作

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

检查两机中初始化参数FAL_SERVER、FAL_CLIENT、LOG_ARCHIVE_CONFIG的参数值设置是否正确。

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

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

SQL>SHOWPARAMETERFAL;

NAMETYPEVALUE

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

fal_clientstringorcl_pd

fal_serverstringorcl_st

SQL>SHOWPARAMETERLOG_ARCHIVE_DEST;

NAMETYPEVALUE

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

log_archive_deststring

log_archive_dest_1stringlocation=/u01/archive

log_archive_dest_10string

log_archive_dest_2stringservice=LGDG

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

SQL>ALTERSYSTEMSETFAL_SERVER='LGDG';

Systemaltered.

SQL>altersystemsetlog_archive_dest_1='location=/u01/archive

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

Systemaltered.

SQL>altersystemsetlog_archive_dest_3='location=/u01/std

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

Systemaltered.

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

SQL>SHOWPARAMETERFAL;

NAMETYPEVALUE

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

fal_clientstringorcl_st

fal_serverstringorcl_pd

SQL>SHOWPARAMETERLOG_ARCHIVE_DEST;

NAMETYPEVALUE

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

log_archive_deststring

log_archive_dest_1stringLOCATION=/u01/archiveVALID_FO

R=(ONLINE_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=LGDG

log_archive_dest_10string

log_archive_dest_2stringservice=orcl_pdlgwrsyncAFFI

RM

log_archive_dest_3stringLOCATION=/u01/std

VALID_FOR=(STANDBY_LOGFILES,S

TANDBY_ROLE)DB_UNIQUE_NAME=LG

DG

修改一下：

SQL>ALTERSYSTEMSETFAL_CLIENT='LGDG';

最后检查Primary数据库是否配置了StandbyRedologs：

SQL>select*fromv$logfile;

GROUP#STATUSTYPEMEMBER

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

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

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

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

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

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

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

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

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

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP4'/u01/app/oracle/oradata/orcl/redo04.log'SIZE50m;

Databasealtered.

2．检查Primary数据库状态

查看当前Primary数据库状态：

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

TOSTANDBY

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

3．准备转换Primary为逻辑Standby

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

SQL>ALTERDATABASEPREPARETOSWITCHOVERTOLOGICALSTANDBY;

Databasealtered.

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

查看一下SWITCHOVER_STATUS的状态：

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

PREPARINGSWITCHOVER

4．准备转换逻辑Standby为Primary

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

SQL>ALTERDATABASEPREPARETOSWITCHOVERTOPRIMARY;

Databasealtered.

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

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

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

PREPARINGSWITCHOVER

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

执行下列语句：

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

TOLOGICALSTANDBY

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

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

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

ALTERDATABASEPREPARETOSWITCHOVERCANCEL;

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

6．转换Primary为逻辑Standby

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

SQL>ALTERDATABASECOMMITTOSWITCHOVERTOLOGICALSTANDBY;

Databasealtered.

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

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

7．再次检查逻辑Standby状态

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

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

TOPRIMARY

或者

SQL>SELECTSWITCHOVER_STATUSFROMV$DATABASE;

SWITCHOVER_STATUS

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

NOTALLOWED

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

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

SQL>ALTERDATABASECOMMITTOSWITCHOVERTOPRIMARY;

Databasealtered.

转换操作至此完成。

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

SQL>ALTERDATABASESTARTLOGICALSTANDBYAPPLYIMMEDIATE;

Databasealtered.

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

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

9．环境测试

最后来测试一下当前的DataGuard配置，首先在新Primary数据库操作一条记录：

SQL>insertintoscott.deptvalues(2,'bl','bl');

1rowcreated.

SQL>commit;

Commitcomplete.

转到逻辑Standby端查看：

DEPTNODNAMELOC

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

1davedmm

10ACCOUNTINGNEWYORK

20RESEARCHDALLAS

30SALESCHICAGO

40OPERATIONSBOSTON

2blbl

同步成功，也基本代表转换成功。

三．主备切换之Failover

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

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

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

在主库查询：

SQL>SELECTMAX(SEQUENCE#)FROMV$ARCHIVED_LOG;

MAX(SEQUENCE#)

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

113

在备库查询：

SQL>SELECTSEQUENCE#,APPLIEDFROMDBA_LOGSTDBY_LOG;

SEQUENCE#APPLIED

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

110CURRENT

111NO

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

通过执行ALTERDATABASEREGISTERLOGICALLOGFILE'filepath';命令，将复制过来的归档文件手工注册。

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

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

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

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

SQL>SELECTAPPLIED_SCN,LATEST_SCNFROMV$LOGSTDBY_PROGRESS;

APPLIED_SCNLATEST_SCN

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

598967598967

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

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

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

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

SQL>SHOWPARAMETERLOG_ARCHIVE_DEST

4．激活新的Primary数据库

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

SQL>SELECTDATABASE_ROLE,FORCE_LOGGINGFROMV$DATABASE;

DATABASE_ROLEFOR

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

LOGICALSTANDBYYES

注意

如果当前FORCE_LOGGING为NO，务必执行ALTERDATABASEFORCELOGGING;命令。

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

SQL>ALTERDATABASEACTIVATELOGICALSTANDBYDATABASEFINISHAPPLY;

数据库已更改。

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

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

SQL>SELECTDATABASE_ROLE,FORCE_LOGGINGFROMV$DATABASE;

DATABASE_ROLEFOR

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

PRIMARYYES

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

5．修复其他Standby数据库

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

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

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

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

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

SQL>ALTERSESSIONDISABLEGUARD;

Sessionaltered.

SQL>CREATEDATABASELINKBLCONNECTTOSYSTEMIDENTIFIEDBYadminUSING'orcl_pd';

Databaselinkcreated.

SQL>ALTERSESSIONENABLEGUARD;

会话已更改。

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

SQL>SELECTSYSDATEFROMDUAL@BL;

SYSDATE

---------

06-MAY-10

提示：ALTERSESSIONENABLE|DISABLEGUARD语句作用？

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

（2）重新启动SQL应用。

在各个逻辑Standby端执行下列语句启动SQL应用（注意更新dblinkName）：

SQL>ALTERDATABASESTARTLOGICALSTANDBYAPPLYNEWPRIMARYBL;

Databasealtered.

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

注：整理自李丙洋《涂抹Oracle》

<!--EndFragment-->