Oracle Data Gurad Physical Standby 相关说明

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

Oracle Data Gurad 理论知识

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

一．启用Force Logging

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

查看状态：

SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;

DATABASE_ROLE FORCE_LOGGING

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

PRIMARY NO

修改模式

SQL> alter database force logging;

Database altered.

取消Force logging 模式：

SQL> alter database no force logging;

Database altered.

说明：为什么要改成Force Logging

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

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

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

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

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

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

[oracle@localhost ~]$ orapwd

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

where

file - name of password file (mand),

password - password for SYS (mand),

entries - maximum number of distinct DBA and force - whether to overwrite existing file (opt),

OPERs (opt),

There are no spaces around the equal-to (=) character.

其中：

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

password：SYS用户密码。

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

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

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

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

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

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

示例如下：

[oracle@localhost dbs]$ orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=admin entries=30

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

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

三．配置Standby Redologs

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

1．关于Standby Redologs

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

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

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

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

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

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

2．管理Standby Redologs

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

查看redo log：

SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;

GROUP# 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

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

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u01/app/oracle/oradata/orcl/redo04.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/u01/app/oracle/oradata/orcl/redo05.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/u01/app/oracle/oradata/orcl/redo06.log') size 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('/u01/app/oracle/oradata/orcl/redo07.log') size 50M;

删除Standby Redologs组也同样简单：

SQL> ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;

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

SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;

GROUP# 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

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

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

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

GROUP# THREAD# SEQUENCE# ARC STATUS

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

4 0 0 YES UNASSIGNED

5 0 0 YES UNASSIGNED

6 0 0 YES UNASSIGNED

7 0 0 YES UNASSIGNED

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

四设置初始化参数

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

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

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

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

1. SQL> alter system set log_archive_dest_1='location=/oracle/oracle10g/log/archive_log';

2.关闭数据库

SQL> shutdown immediate

3.启动数据mount状态：

SQL> startup mount;

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

SQL> alter database archivelog;

5、打开数据库，查询：

SQL> alter database open;

更多内容参考我的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 数据库

备份：

$ rman target /

RMAN> backup full format 'D:/FULL_%d_%T_%s.bak' database include current controlfile for standby;

RMAN> sql 'alter system archive log current';

RMAN> Backup ArchiveLog all format='D:/arch_%d_%T_%s.bak';

传送：

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

恢复：

$rman targetsys/admin@primaryauxiliary /

RMAN> duplicate target database for standby dorecover nofilenamecheck;

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

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

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

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

3). 通过ALTER TABLESPACE END BACKUP命令标记指定表空间结束备份。

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

SQL> select tablespace_name, file_name from dba_data_files;

TABLESPACE_NAME FILE_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> ALTER TABLESPACE USERS BEGIN BACKUP;

Tablespace altered.

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

SQL> ALTER TABLESPACE USERS END BACKUP;

Tablespace altered.

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

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

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

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

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/u01/backup/control01.ctl';

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

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

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

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

可按照下列步骤操作：

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

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

SQL> CREATE PFILE FROM SPFILE;

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

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

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

四．复制文件到Standby服务器

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

五．配置Standby数据库

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

oradim.exe -new -sid orcl -startmode m

oradim.exe -edit -sid orcl -startmode a

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

配置监听并启动。

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

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

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

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

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

SQL> STARTUP;

......

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

READ ONLY

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

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

SQL> STARTUP MOUNT;

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

例如，启动REDO应用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

或者附加USING CURRENT LOGFILE子句启动实时应用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

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

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

七停止Standby数据库

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

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

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

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

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

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

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL;

最后才是关闭Standby数据库：

SQL> SHUTDOWN IMMEDIATE;

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

Oracle Data Guard 环境搭建的完整实例，请参考我的CSDN Blog：

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

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

Oracle 10G windows 平台 DataGuard 实例

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

八用READ ONLY模式打开物理Standby

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

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

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

SQL>STARTUP

ORACLE instance started.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

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

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

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

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

SQL> ALTER DATABASE OPEN;

ALTER DATABASE OPEN

*

ERROR at line 1:

ORA-01154: database busy. Open, close, mount, and dismount not allowed now

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

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

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

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

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

OPEN_MODE

----------

MOUNTED

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

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

Oracle 11g全面改良了物理Standby，最突出的特点就是在READ ONLY打开模式下，可以边接收边应用了，所以可以考虑升级数据库到最新版本，当然新版本也有新版本的问题，如各种尚未暴露出来的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> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

System altered.

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

SQL> DROP TABLESPACE TEST INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

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

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

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

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

9.3 重命名数据文件

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

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

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

SQL> ALTER TABLESPACE SCOTT_TBS OFFLINE;

Tablespace altered.

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

SQL> HOST RENAME F:/oracle/oradata/test/scott_tbs01.dbf scott01.dbf

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

SQL> ALTER TABLESPACE SCOTT_TBS RENAME DATAFILE

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

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

Tablespace altered.

SQL> ALTER TABLESPACE SCOTT_TBS ONLINE;

Tablespace altered.

SQL> SELECT NAME FROM V$DATAFILE;

NAME

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

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

切换日志：

SQL> ALTER SYSTEM SWITCH LOGFILE;

System altered.

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

SQL> SELECT NAME FROM V$DATAFILE;

NAME

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

L:/ORADATA/JSSPDG/SCOTT_TBS01.DBF

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

首先暂停REDO应用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

手工将数据文件改名：

SQL> HOST REN l:/oradata/test/scott_tbs01.dbf scott01.dbf

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

SQL> ALTER DATABASE RENAME FILE

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

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

Database altered.

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

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

9.4 添加或删除Redologs文件

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

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

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

9.5 跨OPEN RESETLOGS的应用

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

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

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

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

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

十监控Primary和物理Standby数据库

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

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

10.2 监控恢复进度

10.2.1 查看进程的活动状态

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

SQL> SELECT PROCESS,CLIENT_PROCESS,SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;

PROCESS CLIENT_P SEQUENCE# STATUS

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

ARCH ARCH 78 CLOSING

ARCH ARCH 79 CLOSING

MRP0 N/A 80 WAIT_FOR_LOG

RFS LGWR 80 IDLE

RFS ARCH 0 IDLE

RFS N/A 0 IDLE