Oracle Data Gurad Physical Standby 相关说明

OracleDataGuard,分逻辑Standby和物理Standby。下面讲的是物理Standby环境的搭建步骤。有关DataGuard的一些概念性的理论知识，请参考我的blog，这里不做过多的说明。

OracleDataGurad理论知识

http://blog.csdn.net/tianlesoftware/archive/2010/04/22/5514082.aspx

一．启用ForceLogging

将Primary数据库置为ForceLogging模式。通过下列语句：

查看状态：

SQL>SELECTDATABASE_ROLE,FORCE_LOGGINGFROMV$DATABASE;

DATABASE_ROLEFORCE_LOGGING

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

PRIMARY NO

修改模式

SQL>alterdatabaseforcelogging;

Databasealtered.

取消Forcelogging模式：

SQL>alterdatabasenoforcelogging;

Databasealtered.

说明：为什么要改成ForceLogging

有一些DDL语句可以通过指定NOLOGGING子句的方式避免写REDO（目的是提高速度，某些时候确实有效）。指定数据库为ForceLogging模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作，而忽略类似NOLOGGING之类的指定参数。如果在执行ForceLogging时有NOLOGGING之类的语句在执行，那么ForceLogging会等待，直到这类语句全部执行。

ForceLogging是作为固定参数保存在控制文件中，因此其不受重启之类操作的影响（只执行一次即可），如果想取消，可以通过ALTERDATABASENOFORCELOGGING语句关闭强制记录。

二．创建密钥文件（如果不存在的话）

同一个DataGuard配置中所有数据库必须都拥有独立的密钥文件，并且必须保证同一个DataGuard配置中，所有数据库服务器的SYS用户拥有相同密码，以保证REDO数据的顺利传输，因为REDO传输服务是通过认证的网络会话来传输REDO数据，而会话使用包含在密钥文件中的SYS用户密码来认证。

如果使用DBCA建库则Oracle会自动创建密钥文件，该文件默认路径在%ORACLE_HOME%/database目录下，如果在该目录没能找到对应的密钥文件也没关系，Oracle提供了一个创建密钥文件的命令：orapwd，位于%ORACLE_HOME%/bin目录下，该命令有两种调用方式：带参调用和不带参调用。

不带参调用时，会返回该命令的调用方式和参数形式，例如：

[oracle@localhost~]$orapwd

Usage:orapwdfile=<fname>password=<password>entries=<users>force=<y/n>

where

file-nameofpasswordfile(mand),

password-passwordforSYS(mand),

entries-maximumnumberofdistinctDBAandforce-whethertooverwriteexistingfile(opt),

OPERs(opt),

Therearenospacesaroundtheequal-to(=)character.

其中：

file：指定密钥文件名称和路径。

password：SYS用户密码。

entries：指定该数据库能够拥有SYSDBA权限的用户最大数。

force：如果文件存在是否覆盖。

orapwd命令使用非常简单，file和password为必填参数。

需要注意Windows平台和Linux/UNIX平台密钥文件的命名规则并不相同：

Windows平台命名规则：PWD[sid].ora

Linux/UNIX平台命令规则：orapw[sid]--注意：没有文件名，(大小写敏感）

示例如下：

[oracle@localhostdbs]$orapwdfile=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworclpassword=adminentries=30

OracleOS认证口令文件密码丢失处理

http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4698293.aspx

三．配置StandbyRedologs

对于最大保护和最高可用性模式，建议为Standby数据库配置StandbyRedologs（不配置也可以，Oracle将在Standby数据库端自动创建归档文件，并虚拟为一组StandbyRedologs），并使用LGWRSYNC模式传输REDO数据。

1．关于StandbyRedologs

Oracle建议DBA在创建Standby数据库时，就考虑StandbyRedologs配置的问题。StandbyRedologs与OnlineRedologs非常类似，应该说两者只是服务对象不同，其他参数属性，甚至操作的命令格式几乎都一样，DBA在设计StandbyRedologs的时候完全可以借鉴创建OnlineRedologs的思路，如创建几个文件组，每组多个文件冗余之类的。除些之外呢，Oracle提供了一些标准的建议，如下所示：

（1）确保StandbyRedologs的文件大小与Primary数据库OnlineRedologs文件大小相同。这个很好理解，就是为了接收和应用方便嘛。

（2）创建适当数目的日志组。一般而言，StandbyRedologs日志组要比Primary数据库的OnlineRedologs日志文件组数至少多一个。建议StandbyRedologs日志组数量基于Primary数据库的线程数来确定（这里的线程数可以理解为RAC环境中的节点数）。

有一个推荐的公式可供参考：（每线程的日志组数+1）×最大线程数。

例如Primary数据库有两个线程，每个线程分配两组日志，则Standby日志组数建议为6组，使用这个公式可以降低Primary数据库实例LGWR进程锁住的可能性。

提示：逻辑Standby数据库有可能需要视工作量，增加更多的StandbyRedologs组（或增加归档进程），因为逻辑Standby数据库有可能需要同时写OnlineRedologs文件。

2．管理StandbyRedologs

StandbyRedologs的操作方式与OnlineRedologs几乎一模一样，只不过在创建或删除时需要多指定一个Standby关键字。

查看redolog：

SQL>SELECTGROUP#,TYPE,MEMBERFROMV$LOGFILE;

GROUP#TYPEMEMBER

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

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

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

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

添加一个新的StandbyRedologs组（注意组号不要与当前存在的OnlineRedologs组重复），并为该组指定一个成员：

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP4('/u01/app/oracle/oradata/orcl/redo04.log')size50M;

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP5('/u01/app/oracle/oradata/orcl/redo05.log')size50M;

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP6('/u01/app/oracle/oradata/orcl/redo06.log')size50M;

SQL>ALTERDATABASEADDSTANDBYLOGFILEGROUP7('/u01/app/oracle/oradata/orcl/redo07.log')size50M;

删除StandbyRedologs组也同样简单：

SQL>ALTERDATABASEDROPSTANDBYLOGFILEGROUP4;

可以通过动态性能视图V$LOGFILE查看当前数据库中创建的StandbyRedologs，例如：

SQL>SELECTGROUP#,TYPE,MEMBERFROMV$LOGFILE;

GROUP#TYPEMEMBER

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

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

提示：通过该视图中的TYPE列区分该条记录是OnlineRedologs或是StandbyRedologs。

通过查看StandbyRedologs的专用视图V$STANDBY_LOG来查看当前数据库中创建的StandbyRedologs，如：

SQL>SELECTGROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUSFROMV$STANDBY_LOG;

GROUP#THREAD#SEQUENCE#ARCSTATUS

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

400YESUNASSIGNED

500YESUNASSIGNED

600YESUNASSIGNED

700YESUNASSIGNED

从可靠性方面考虑，DG的设计初衷就是当发生故障时快速切换Primary和Standby的角色，以达到快速恢复应用访问的目的。一旦发生切换，原Primary数据库就变成了Standby数据库，就得需要StandbyRedologs，为了减少真正切换时应做的工作，建议在Primary数据库也创建StandbyRedologs，这样即使发生切换，也不会影响Primary作为Standby身份的正常运行。

四设置初始化参数

对于Primary数据库，有几个与角色相关的初始化参数需要进行设置，这些参数初始时有些用来控制REDO传输服务（即Primary数据库生成的REDO数据传给谁以及怎么传），有些用来指定角色，还有几个与Standby角色相关的初始化参数，也建议进行配置，以便switchover/failover操作后，Primary/Standby数据库仍能正常工作，建议不管是Primary数据库，还是Standby数据库，对于角色相关的初始化参数都进行配置。

五．将Primary数据库置于归档模式

要创建一个DataGuard环境，Primary数据库必须处于归档模式。

对于非归档模式的数据库该为归档模式，步骤如下：

1.SQL>altersystemsetlog_archive_dest_1='location=/oracle/oracle10g/log/archive_log';

2.关闭数据库

SQL>shutdownimmediate

3.启动数据mount状态：

SQL>startupmount;

4、修改数据库为归档模式：

SQL>alterdatabasearchivelog;

5、打开数据库，查询：

SQL>alterdatabaseopen;

更多内容参考我的Blog：Oracle归档与非归档的切换：

http://blog.csdn.net/tianlesoftware/archive/2009/10/19/4693470.aspx

----------

10.2.2物理Standby创建时的操作步骤

一．创建备份

物理Standby数据库相当于Primary数据库在某个时间点的镜像复制，因此在创建物理Standby数据库之前，至少要有一份Primary数据库的完整备份。

Oracle建议使用RMAN创建备份集，不过如果数据库规模不是太大，我个人更倾向于通过用户管理的方式创建备份集。

创建备份有三种方式：

1.RMAN备份与恢复--不需要shutdown数据库

备份：

$rmantarget/

RMAN>backupfullformat'D:/FULL_%d_%T_%s.bak'databaseincludecurrentcontrolfileforstandby;

RMAN>sql'altersystemarchivelogcurrent';

RMAN>BackupArchiveLogallformat='D:/arch_%d_%T_%s.bak';

传送：

备份完后将备份文件拷到standby上同样的目录，强调：同样的目录，在standby进行rman恢复即可

恢复：

$rmantargetsys/admin@primaryauxiliary/

RMAN>duplicatetargetdatabaseforstandbydorecovernofilenamecheck;

2.用户管理方式--不需要shutdown数据库

用用户管理方式创建热备份就是备份表空间，可以分成三个步骤：

1).通过ALTERTABLESPACEBEGINBACKUP命令标记指定表空间进入备份状态。

2).通过操作系统命令复制锁定表空间的数据文件。

3).通过ALTERTABLESPACEENDBACKUP命令标记指定表空间结束备份。

例如，对USERS表空间进行备份：

SQL>selecttablespace_name,file_namefromdba_data_files;

TABLESPACE_NAMEFILE_NAME

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

USERS/u01/app/oracle/oradata/orcl/users01.dbf

SYSAUX/u01/app/oracle/oradata/orcl/sysaux01.dbf

UNDOTBS1/u01/app/oracle/oradata/orcl/undotbs01.dbf

SYSTEM/u01/app/oracle/oradata/orcl/system01.dbf

SQL>ALTERTABLESPACEUSERSBEGINBACKUP;

Tablespacealtered.

SQL>!cp/u01/app/oracle/oradata/orcl/users01.dbf/u01/users01.dbf

SQL>ALTERTABLESPACEUSERSENDBACKUP;

Tablespacealtered.

3.直接copy文件--shutdown进行

实例关闭后，拷贝数据文件到备库上即可。

二．创建Standby数据库控制文件

在Primary库上执行如下语句，为Standby数据库创建控制文件：

SQL>ALTERDATABASECREATESTANDBYCONTROLFILEAS'/u01/backup/control01.ctl';

注意：控制文件通常需要有多份，你要么手工将上述文件复制几份，要么用命令多创建几个出来。需要注意，如果选择多次执行上述命令创建出多份，务必确保执行创建时数据库处于MOUNT状态，否则几个控制文件的SCN有可能并不匹配，从而导致Standby数据库无法正常启动到MOUNT状态。

另外，创建完控制文件之后到Standby数据库创建完成这段时间内，要保证Primary数据库不再有结构上的变化（如增加表空间等），不然Primary和Standby同步时会有问题。

DataGuard也是根据控制文件来判断哪个是standby的

三．配置Standby数据库的初始化参数文件

可按照下列步骤操作：

（1）创建PFILE客户端初始化参数文件。

由于SPFILE服务器端初始化参数文件为二进制格式，无法直接编辑，因此建议首先通过SPFILE创建PFILE，操作如下：

SQL>CREATEPFILEFROMSPFILE;

（2）修改初始化参数文件中的参数。

注意Primary和Standby不同角色对应初始化参数的配置。

注意保持各初始化参数中的路径准确有效。

四．复制文件到Standby服务器

复制文件到Standby服务器主要包括三部分：备份的数据文件、创建的Standby数据库控制文件和修改过的初始化参数文件。

五．配置Standby数据库

如果是Windows环境下，还需要创建新的OracleService。

oradim.exe-new-sidorcl-startmodem

oradim.exe-edit-sidorcl-startmodea

创建密钥文件，注意保持密码与Primary数据库一致。

配置监听并启动。

修改Primary数据库所在服务器和Standby数据库所在服务器的tnsnames.ora，各自增加对应的NetServiceName。

创建服务器端的初始化文件。

六．启动物理Standby数据库REDO应用

完成对Standby数据库的配置之后，就可以启动该Standby数据库了。物理Standby极少情况下可以以READWRITE模式打开，某些情况下可以以READONLY模式打开，不过多数情况下，应该启动到MOUNT状态。

直接执行STARTUP命令打开物理Standby数据库，默认会以只读方式打开数据库，而不是READWRITE模式，Oracle会根据控制文件判断是否是物理Standby，如果是则默认启动到READONLY模式，例如：

SQL>STARTUP;

......

SQL>SELECTOPEN_MODEFROMV$DATABASE;

OPEN_MODE

----------

READONLY

跟你想的不一样是吧，那说明你的思维还没转过弯来。

通常情况下，我们将物理Standby数据库加载到MOUNT状态即可：

SQL>STARTUPMOUNT;

进入MOUNT状态后，Standby数据库就开始接收Primary数据库发送的归档REDO数据，然后你可以继续通过一些命令应用这些REDO数据。

例如，启动REDO应用：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECTFROMSESSION;

或者附加USINGCURRENTLOGFILE子句启动实时应用：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEUSINGCURRENTLOGFILEDISCONNECTFROMSESSION;

注意，要启动实时应用，Primary数据库在发送REDO数据时必须使用LGWR进程发送。如果使用ARCH方式发送REDO数据，Standby数据库无法启动实时应用，强行启动会报ORA-38500错误。

提示：DISCONNECTFROMSESSION子句并非必需，该子句的作用呢，是指定启动完应用后自动退出到命令操作符前。如果不指定该子句的话，当前SESSION就会一直停留处理REDO应用，如果想做其他操作，就只能新建一个连接。

七停止Standby数据库

跟启动一样，关闭Standby数据库也有很多讲究，某些情况下如果操作不当，关闭Standby数据库甚至会连带导致Primary数据库也关闭（这点后面会有详细介绍），幸好一般情况下不会出现这种情况，即使是像Primary数据库那样直接关闭，数据库也没有问题，毕竟DataGuard就是用于容灾的，别说普通的关闭数据库，就是直接拔电源也不怕，最多就是在Primary数据库的警告日志文件中记录一堆报错信息。

正常情况下，停止Standby数据库（含物理Standby和逻辑Standby）之前，应该首先停止Primary数据库，如果直接停止Standby数据库，轻则Primary数据库的Alert文件中记录一堆归档发送失败的错误信息，重则Primary直接shutdown。

不过，对于一些测试环境，偶尔也希望能在Primary数据库正常运行的情况下，停止Standby以进行一些其他操作，在这种情况下通常建议使用下列步骤：

首先是Primary端操作，修改Primary数据库的log_archive_dest_state_n参数，暂时取消向Standby数据库发送日志，例如：

SQL>ALTERSYSTEMSETLOG_ARCHIVE_DEST_STATE_2=DEFER;

这样Standby端不可访问时，Primary数据库的Alert日志文件中也不会再报错了。

然后Standby端就可以停止REDO应用：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECALCEL;

最后才是关闭Standby数据库：

SQL>SHUTDOWNIMMEDIATE;

物理Standby创建的基本步骤就是这样。

OracleDataGuard环境搭建的完整实例，请参考我的CSDNBlog：

OracleDataGuardLinux平台PhysicalStandby搭建实例

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

Oracle10Gwindows平台DataGuard实例

http://blog.csdn.net/tianlesoftware/archive/2009/10/27/4730092.aspx

八用READONLY模式打开物理Standby

物理Standby可以有效分担Primary数据库压力，提升资源利用，实际上说的就是将物理Standby置于OPEN状态。

当以READONLY模式打开物理Standby，可以将一些不涉及数据库写操作的任务如查询、备份转移到Standby数据库端进行，通过这种方式来分担Primary数据库的压力。下面我们通过实际操作，详细了解Standby数据库在关闭状态、打开状态以及REDO应用状态中的转换。

1．物理Standby数据库从SHUTDOWN状态启动到READONLY状态

SQL>STARTUP

ORACLEinstancestarted.

SQL>SELECTOPEN_MODEFROMV$DATABASE;

OPEN_MODE

----------

MOUNTED

不过启动成功之后，并不是像普通Oracle数据库那样置于READWRITE模式，而是进入到READONLY模式。

2．物理Standby数据库从REDO应用状态启动到READONLY状态

1）首先需要取消REDO应用，执行下列语句：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;

Databasealtered.

注意：虽然当前是在MOUNT状态，但并不能直接ALTERDATABASEOPEN打开数据库，否则会报ORA-01154错误。

SQL>ALTERDATABASEOPEN;

ALTERDATABASEOPEN

*

ERRORatline1:

ORA-01154:databasebusy.Open,close,mount,anddismountnotallowednow

2）取消REDO应用后，再打开数据库：

SQL>ALTERDATABASEOPEN;

Databasealtered.

SQL>SELECTOPEN_MODEFROMV$DATABASE;

OPEN_MODE

----------

MOUNTED

注意：OPEN的时候不需要附加READONLY子句，Oracle会根据控制文件判断是否是物理Standby，从而自动启动到READONLY模式。

3．物理Standby数据库从READONLY状态切换回REDO应用状态

要从OPEN状态切换回REDO应用状态，并不需要SHUTDOWN数据库再启动，直接执行启用REDO应用的语句即可，例如：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECTFROMSESSION;

Databasealtered.

SQL>SELECTOPEN_MODEFROMV$DATABASE;

OPEN_MODE

----------

MOUNTED

由于只读打开时不能应用，查询的结果可能与Primary数据库并不同步的，这一点小小的缺憾降低了物理Standby提供报表服务，分担Primary数据库压力的实用性，对于这点呢，我们有两个解决方案：

改用逻辑Standby，由于逻辑Standby是打开状态下的实时应用，因此数据同步应该是没啥问题了（只要Primary数据库的数据类型都能被逻辑Standby支持）。

Oracle11g全面改良了物理Standby，最突出的特点就是在READONLY打开模式下，可以边接收边应用了，所以可以考虑升级数据库到最新版本，当然新版本也有新版本的问题，如各种尚未暴露出来的Bug。

九管理影响物理Standby的Primary数据库事件

多数情况下，Primary数据库的修改会随着REDO数据传播到物理Standby数据库端并被应用，不需要在物理Standby端做额外的操作，不过根据实际配置的不同，也会有例外，有些操作不是没有被传播到Standby端，而是传播过去了，但不能正确执行，其中最常见的就是对表空间和日志文件的管理操作，下面通过实例逐一进行说明。

9.1创建表空间或数据文件

初始化参数STANDBY_FILE_MANAGEMENT用来控制是否自动将Primary数据库增加表空间或数据文件的改动，传播到物理Standby数据库。该参数有两个值：

AUTO：如果该参数值设置为AUTO，则Primary数据库执行的表空间创建操作也会被传播到物理Standby数据库上执行。

MANUAL：如果设置为MANUAL或未设置任何值（默认值是MANUAL），需要手工复制新创建的数据文件到物理Standby服务器。

注意：STANDBY_FILE_MANAGEMENT参数特指Primary数据库端的表空间或数据文件创建，如果数据文件是从其他数据库复制而来（比如通过TTS传输表空间），则不管STANDBY_FILE_MANAGEMENT参数值如何设置，都必须同时手工复制到Standby数据库，并重建物理Standby数据库的控制文件。

9.2删除表空间

在Primary数据库端删除表空间时，会影响到物理Standby端数据库的数据文件和表空间，初始化参数STANDBY_FILE_MANAGEMENT的属性值设置决定了该事件是否需要DBA介入。

当STANDBY_FILE_MANAGEMENT设置为AUTO。

SQL>ALTERSYSTEMSETSTANDBY_FILE_MANAGEMENT=AUTO;

Systemaltered.

在Primary数据库端执行删除表空间的操作：

SQL>DROPTABLESPACETESTINCLUDINGCONTENTSANDDATAFILES;

Tablespacedropped.

注：INCLUDINGDATAFILES子句，在删除表空间时Oracle也将自动删除对应的物理文件。

将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，对于表空间和数据文件的操作也无须DBA手工干预，物理Standby能很好地进行处理。

当STANDBY_FILE_MANAGEMENT参数设置为MANUAL时，即使DBA在Primary数据库端执行删除操作时加上了INCLUDINGDATAFILES子句，Standby数据库仍然只会将表空间和数据文件从数据字典中删除，表空间涉及的物理文件仍需要手工删除。

对于文件系统，我们可以将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，但是对于裸设备，只能将该参数设置为MANUAL。

9.3重命名数据文件

如果Primary数据库重命名了一个或多个数据文件，该项修改并不会自动传播到Standby数据库。就算设置了初始化参数STANDBY_FILE_MANAGEMENT等于AUTO也不行，要让Standby的数据文件与Primary保持一致，只能手工操作。

下面通过示例演示，操作步骤如下：

首先OFFLINE要更名的数据文件所在的表空间：

SQL>ALTERTABLESPACESCOTT_TBSOFFLINE;

Tablespacealtered.

然后手工修改数据文件名。方法很多，这里直接使用操作系统自带的RENAME命令（在Linux平台下可用mv命令）：

SQL>HOSTRENAMEF:/oracle/oradata/test/scott_tbs01.dbfscott01.dbf

通过命令修改数据字典中的数据文件路径，然后ONLINE表空间：

SQL>ALTERTABLESPACESCOTT_TBSRENAMEDATAFILE

2'F:/oracle/oradata/test/scott_tbs01.dbf'to

3'F:/oracle/oradata/test/scott01.dbf';

Tablespacealtered.

SQL>ALTERTABLESPACESCOTT_TBSONLINE;

Tablespacealtered.

SQL>SELECTNAMEFROMV$DATAFILE;

NAME

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

F:/ORACLE/ORADATA/TEST/SCOTT01.DBF

切换日志：

SQL>ALTERSYSTEMSWITCHLOGFILE;

Systemaltered.

在物理Standby端查看当前数据文件路径：

SQL>SELECTNAMEFROMV$DATAFILE;

NAME

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

L:/ORADATA/JSSPDG/SCOTT_TBS01.DBF

Standby数据库端的数据文件仍为原路径，并未被修改，因此只能DBA介入手动修改。步骤如下：

首先暂停REDO应用：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;

Databasealtered.

手工将数据文件改名：

SQL>HOSTRENl:/oradata/test/scott_tbs01.dbfscott01.dbf

然后修改数据字典中数据文件的路径：

SQL>ALTERDATABASERENAMEFILE

2'L:/ORADATA/TEST/SCOTT_TBS01.DBF'to

3'L:/ORADATA/TEST/SCOTT01.DBF';

Databasealtered.

最后重新启动Standby数据库的REDO应用即可：

SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECTFROMSESSION;

Databasealtered.

9.4添加或删除Redologs文件

数据库调优时极有可能会涉及重置日志文件大小或增加删除日志组等操作，如果STANDBY_FILE_MANAGEMENT参数值设置为AUTO的话，这种操作也会被传播到物理Standby数据库。不过在一般情况下，你可以不管STANDBY_FILE_MANAGEMENT参数的设置，因为无论Primary端对日志组或日志文件的操作是否传播到物理Standby数据库，也不会影响到物理Standby数据库的运行，不过如果你不注意其中的关系，造成的影响可能会很深远。

通常建议当你在Primary数据库增加或删除OnlineRedologs时，一定记得手工同步相关物理Standby数据库中相关的设置，同时也要考虑好StandbyRedologs与OnlineRedologs之间的关系，即保证StandbyRedologs比OnlineRedologs要至少多一组。

注意的就是在Standby数据库端操作前务必将STANDBY_FILE_MANAGEMENT设置为MANUAL，如果物理Standby数据库的日志文件与Primary数据库路径不同的话，应该通过初始化参数LOG_FILE_NAME_CONVERT的设置，让其自动进行转换。

9.5跨OPENRESETLOGS的应用

在某些情况下，Primary数据库以RESETLOGS方式打开之后，也不会影响DataGuard的配置，Standby数据库无须人工参与，自动应用OPENRESETLOGS的操作，继续接收并应用Primary数据库OPENRESETLOGS之后产生的日志。

当然这是有条件的，并不是所有情况下都能这么智能。我们知道执行ALTERDATABASEOPENRESETLOGS语句之后，数据库的INCARNATION被重置，也就是此时其Standby数据库的SEQUENCE序号也会从头开始设置。当然物理Standby数据库并不关注这一点，它只是忠实地紧跟Primary数据库的脚步，一步一步地执行Primary数据库曾经执行过的操作，因此当其接收到新的REDO数据时，就会自动应用这部分REDO数据。

正常情况下这个逻辑没有问题，不过遇到Primary执行过OPENRESETLOGS之后，又通过备份恢复到OPENRESETLOGS之前的状态，视物理Standby的具体配置（配置方式决定了物理Standby是否有可能回到OPENRESETLOGS之前的状态）的不同，情况可能会复杂很多。

图中显示了Primary数据库RESETLOGS操作对Standby的影响

Standby数据库状态	Standby服务器操作	解决方案
尚未应用RESETLOGS之前的REDO数据	自动应用REDO数据	无须手工介入
应用了RESETLOGS之后的REDO数据，不过Standby数据库启用了FRA	可以回到应用RESETLOGS之前的状态，不过需要DBA手工介入	手工FLASHBACKDATABASE到应用RESETLOGS日志之前的状态 重启REDO应用，以重新接收新的REDO数据
应用了RESETLOGS之后的REDO数据，而且没有配置FRA	无法进行应用处理	重建物理Standby是唯一的选择

十监控Primary和物理Standby数据库

10.1监控途径：概括起来主要通过两个方面来进行：

Primary数据库事件	Primary监控途径	物理Standby监控途径
带有ENABLE|DISABLETHREAD子句的ALTERDATABASE命令	Alert.log V$THREAD	Alert.log
当前数据库角色，保护模式，保护级别，switchover状态，failover快速启动信息等	V$DATABASE	V$DATABASE
Redolog切换	Alert.log V$LOG V$LOGFILE的status列	Alert.log
重建控制文件	Alertlog	Alertlog
手动执行恢复	Alertlog	Alertlog
表空间状态修改（READWRITE/READONLY，ONLINE/OFFLINE）	DBA_TABLESPACES Alertlog	V$RECOVER_FILE
创建删除表空间或数据文件	DBA_DATA_FILES Alertlog	V$DATAFILE Alertlog
表空间或数据文件OFFLINE	V$RECOVER_FILE Alertlog DBA_TABLESPACES	V$RECOVER_FILE DBA_TABLESPACES
重命名数据文件	V$DATAFILE Alertlog	V$DATAFILE Alertlog
未被日志记录或不可恢复的操作	V$DATAFILE V$DATABASE	Alertlog
恢复的进程	V$ARCHIVE_DEST_STATUS Alertlog	V$ARCHIVED_LOG V$LOG_HISTORYV$MANAGED_STANDBY Alertlog
REDO传输的状态和进度	V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOGV$ARCHIVE_DEST Alertlog	V$ARCHIVED_LOGAlertlog
数据文件自动扩展	Alertlog	Alertlog
执行OPENRESETLOGS或CLEARUNARCHIVEDLOGFILES	Alertlog	Alertlog
修改初始化参数	Alertlog	Alertlog

10.2监控恢复进度

10.2.1查看进程的活动状态

V$MANAGED_STANDBY视图专用于显示物理Standby数据库相关进程的当前状态，该视图中的列也很有特点，查看进程状态时，通常我们会关注PROCESS、CLIENT_PROCESS、SEQUENC#和STATUS几列，例如：

SQL>SELECTPROCESS,CLIENT_PROCESS,SEQUENCE#,STATUSFROMV$MANAGED_STANDBY;

PROCESSCLIENT_PSEQUENCE#STATUS

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

ARCHARCH78 CLOSING

ARCHARCH79 CLOSING

MRP0N/A80 WAIT_FOR_LOG

RFSLGWR80 IDLE

RFSARCH0 IDLE

RFSN/A 0 IDLE

相关说明：

PROCESS：进程名称，如ARCH、RFS、MRP0等。

CLIENT_P：对应的Primary数据库中的进程，如ARCH、LGWR等。

SEQUENCE#：归档序号。

STATUS：进程的当前状态，值较多，常见的有：

1）ALLOCATED：正准备连接Primary数据库。

2）ATTACHED：正在连接Primary数据库。

3）CONNECTED：已连接至Primary数据库。

4）IDLE：空闲中。

5）RECEIVING：归档文件接收中。

6）OPENING：归档文件处理中。

7）CLOSING：归档文件处理完，收尾中。

8）WRITING：REDO数据库写向归档文件中。

9）WAIT_FOR_LOG：等待新的REDO数据中。

10）WAIT_FOR_GAP：归档有中断，正等待中断的那部分REDO数据。

11）APPLYING_LOG：应用REDO数据中。

10.2.2检查REDO应用进度

V$ARCHIVE_DEST_STATUS视图显示归档文件路径配置信息及REDO的应用情况等，例如：

SQL>SELECTDEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,

DB_UNIQUE_NAMEFROMV$ARCHIVE_DEST_STATUSWHERESTATUS='VALID';

DEST_NAMEARCHIVED_THREAD#ARCHIVED_SEQ#APPLIED_THREAD#APPLIED_SEQ#DB_UNIQUE_NAME

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

LOG_ARCHIVE_DEST_117900 NONE

STANDBY_ARCHIVE_DEST178178NONE

10.2.3检查归档文件路径和创建信息

物理Standby数据库端可以通过查询V$ARCHIVED_LOG视图，获取归档文件的一些附加信息，如文件创建时间、创建进程、归档序号、是否被应用等，例如：

SQL>SELECTNAME,CREATOR,SEQUENCE#,APPLIED,COMPLETION_TIMEFROMV$ARCHIVED_LOG;

NAMECREATORSEQUENCE#APPCOMPLETIO

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

/u01/archive/1_1_717413573.dbfARCH1YES30-APR-10

/u01/archive/1_3_717413573.dbfARCH3YES30-APR-10

......

/u01/archive/1_78_717413573.dbfARCH78YES01-MAY-10

/u01/archive/1_79_717413573.dbfARCH79YES02-MAY-10

10.2.4查询归档历史

物理Standby数据库端通过V$LOG_HISTORY视图，可以查询所有已被应用的归档文件信息（无论该归档文件是否还存在），例如：

SQL>SELECTFIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#,SEQUENCE#FROMV$LOG_HISTORY;

FIRST_TIMFIRST_CHANGE#NEXT_CHANGE#SEQUENCE#

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

27-APR-104460754758331

27-APR-104758334894822

......

30-APR-1054492959011378

01-MAY-1059011365235779

仍然通过该视图，稍稍修改下SQL语句，就可以查询到最后应用的归档文件，例如：

SQL>SELECTTHREAD#,MAX(SEQUENCE#)AS"LAST_APPLIED_LOG"FROMV$LOG_HISTORYGROUPBYTHREAD#;

THREAD#LAST_APPLIED_LOG

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

179

当然也可以通过查询V$ARCHIVED_LOG视图中的APP列获得相同的功能，例如：

SQL>SELECTTHREAD#,SEQUENCE#,APPLIEDFROMV$ARCHIVED_LOG;

THREAD#SEQUENCE#APP

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

11YES

12YES

13YES

10.2.5 查看物理Standby数据库未接收的日志文件

日志文件的发送是通过LOG_ARHIVE_DEST_N参数来控制，因此我们只需要对比本地生成的归档和远端生成的归档间差异即可。例如：

SQL>SELECTLOCAL.THREAD#,LOCAL.SEQUENCE#FROM(SELECTTHREAD#,SEQUENCE#FROMV$ARCHIVED_LOGWHEREDEST_ID=1)LOCALWHERELOCAL.SEQUENCE#NOTIN(SELECTSEQUENCE#FROMV$ARCHIVED_LOGWHEREDEST_ID=2ANDTHREAD#=LOCAL.THREAD#);

THREAD#SEQUENCE#

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

176

177

178

179

说明:DEST_ID=N，N其实就是LOG_ARCHIVE_DEST_N参数中的那个N。

10.2.6监控日志应用服务

1）查询当前数据的基本信息（v$database信息）：如，查询数据库角色、保护模式、保护级别等：

SQL>SELECTDATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,

PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUSFROMV$DATABASE;

DATABASE_ROLEDB_UNIQUE_NAMEOPEN_MODEPROTECTION_MODEPROTECTION_LEVELSWITCHOVER_STATUS

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

PRIMARYorcl_pdREADWRITEMAXIMUMAVAILABILITYMAXIMUMAVAILABILITYSESSIONSACTIVE

再比如，查询failover后快速启动的信息：

SQL>SELECTFS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET,FS_FAILOVER_THRESHOLD,FS_FAILOVER_OBSERVER_PRESENTFROMV$DATABASE;

FS_FAILOVER_STATUSFS_FAILOVER_CURRENT_TARGETFS_FAILOVER_THRESHOLDFS_FAIL

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

DISABLED0

2）查看当前REDO应用和REDO传输服务的活动状态

查询物理Standby数据库当前REDO应用和REDO传输服务的状态非V$MANAGED_STANDBY视图莫属，例如：

SQL>SELECTPROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKSFROMV$MANAGED_STANDBY;

PROCESSSTATUSTHREAD#SEQUENCE#BLOCK#BLOCKS

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

ARCHCLOSING178983051752

ARCHCLOSING179983051752

MRP0WAIT_FOR_LOG18000

RFSIDLE180752973

RFSIDLE0000

RFSIDLE0000

3）检查应用模式（是否启用了实时应用）

物理Standby数据库查询V$ARCHIVE_DEST_STATUS视图，如果打开了实时应用，则RECOVERY_MODE列会显示为：MANAGEDREALTIMEAPPLY，例如：

SQL>SELECTRECOVERY_MODEFROMV$ARCHIVE_DEST_STATUSWHEREDEST_ID=2;

RECOVERY_MODE

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

MANAGED

4）DataGuard事件（V$DATAGUARD_STATUS）

该视图显示那些被自动触发写入Alert.log或服务器Trace文件的事件。通常是在你不便访问到服务器查询Alert.log时，可以临时访问本视图查看一些与DataGuard相关的信息，例如：

SQL>SELECTMESSAGEFROMV$DATAGUARD_STATUS;

MESSAGE

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

ARC0:Archivalstarted

ARC1:Archivalstarted

ARC0:Becomingthe'noFAL'ARCH

ARC0:Becomingthe'noSRL'ARCH

ARC1:BecomingtheheartbeatARCH

AttempttostartbackgroundManagedStandbyRecoveryprocess

MRP0:BackgroundManagedStandbyRecoveryprocessstarted

ManagedStandbyRecoverynotusingRealTimeApply

Clearingonlineredologfile1/u01/app/oracle/oradata/orcl/redo01.log

Clearingonlineredologfile1complete

MediaRecoveryWaitingforthread1sequence74

10.2.7调整物理Standby端REDO数据应用频率

调整应用频率，说白了就是调整I/O读取能力，所以通常我们从以下几个方面着手：

1）设置RECOVER并行度

在介质恢复或REDO应用期间，都需要读取重做日志文件，默认都是串行恢复，我们可以在执行RECOVER的时候加上PARALLEL子句来指定并行度，提高读取和应用的性能，例如：

SQL>RECOVERSTANDBYDATABASEPARALLEL2;

提示:建议PARALLEL的值为#CPUs×2。

注意:该设置仅对当前环境有效，Oracle数据库重启之后，默认情况下并行度会恢复至初始值，如果DBA觉着每次执行很麻烦，要通过初始化参数PARALLEL_MAX_SERVERS来设置默认的并行度。

2)加快REDO应用频繁

设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率，该参数设置是否验证数据块的有效性，对于物理Standby数据库，禁止验证基本上还是可以接受的（Primary数据库强烈建议将该参数值设置为TRUE，当然默认就是TRUE），该参数是一个动态参数，修改后直接生效，不需要重启数据库。

3)设置PARALLEL_EXECUTION_MESSAGE_SIZE参数值

如果打开了并行恢复，适当提高初始化参数PARALLEL_EXECUTION_MESSAGE_SIZE的参数值，比如4096也能提高大概20%左右的性能，不过需要注意，增大这个参数的参数值可能会占用更多内存。

4)优化磁盘I/O

在恢复期间最大的瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O能降低数据库文件并行读取，提高整个恢复时间。

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

<!--EndFragment-->