Oracle DG 管理影响物理Standby的主库事件

 

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

1、创建表空间或数据文件

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

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

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

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

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。

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.

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的设置，让其自动进行转换。

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的影响

（文章来自网络，如有侵权请来信告知，本站将在第一时间删除。）