管理物理和快照备数据库（Physical and Snapshot Standby Databases）

1．打开物理备数据库

物理备数据库可以打开做只读访问，用于从主数据库卸载查询负载。

如果已经购买Oracle Active Data Guard选项的授权，当数据库打开时Redo Apply可以是激活的，因此允许查询返回与从主数据库返回的完全相同的结果。这个功能也称为实时查询特性。

1.1. 实时查询

数据库初始化参数COMPATIBLE必须设置成11.0或更高来使用Oracle Active Data Guard选项的实时查询特性。

如果挂载的数据库实例上Redo Apply是活动的，物理备数据库实例不能被打开。使用以下SQL语句停止Redo Apply，以只读方式打开备数据库实例，然后重启Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

注：如果在一个打开的实例上Redo Apply是活动的，其他备数据库实例不用停止Redo Apply就可以被打开。

如果物理备数据库的其他实例在打开状态，挂载的物理备数据库实例上的Redo Apply不可以启动。实例必须打开后再启动Redo Apply。

以下示例显示V$DATABASE.OPEN_MODE列在物理数据库以实时查询模式打开时的变化。

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.

SQL> ALTER DATABASE OPEN;
Database altered.

SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.

SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY

1.1.1. 监控实时查询环境中的延迟应用

如果使用实时查询来从主数据库卸载查询到物理备数据库，可以监控应用延迟来确保它在可以接受的范围内。

当前的应用延迟是在上次应用的更改在备数据库上可见和相同的更改在主数据库上可见之间过去的时间的差异。

查询视图V$DATAGUARD_STATS获得应用延迟。
SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like ‘apply lag’;

NAME            VALUE            DATUM_TIME          TIME_COMPUTED
--------- ------------- -------------------   -------------------
apply lag  +00 00:00:00  05/27/2009 08:54:16  05/27/2009 08:54:17

apply lag度量值是使用从主数据库定期接收的数据计算的。DATUM_TIME列包含备数据库上次接收数据的时间戳。TIME_COMPUTED列包含计算apply lag度量时的时间戳。这些列的值的差异应该少于30秒，如果差异大于30秒，apply lag度量值可能会不准确。

查询视图V$STANDBY_EVENT_HISTOGRAM获取显示从备实例上次启动以来的apply lag的历史值直方图。

SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = ‘apply lag’
AND COUNT > 0;

NAME 			TIME UNIT 		COUNT 		LAST_TIME_UPDATED
--------- --------- -------- ----------- ------------------------
apply lag 		0 seconds 		79681 		06/18/2009 10:05:00
apply lag 		1 seconds 		1006 		06/18/2009 10:03:56
apply lag 		2 seconds 		96 			06/18/2009 09:51:06
apply lag 		3 seconds 		4 			06/18/2009 04:12:32
apply lag 		4 seconds 		1 			06/17/2009 11:43:51
apply lag 		5 seconds 		1 			06/17/2009 11:43:52

注：COUNT值是应用延迟落在这个时间范围内的次数，物理备数据库每秒采集一次数据，增加直方图中对应的时间范围的COUNT值。

为了评估一段时间的apply lag，可以在时间段的开始对视图V$STANDBY_EVENT_HISTOGRAM做个快照，然后在时间段的末尾再对视图做个快照进行对比。

1.1.2. 在实时查询环境中配置apply lag tolerance

会话参数STANDBY_MAX_DATA_DELAY可以用来为非管理用户向处于实时查询模式的物理备数据库发出的查询指定会话特定的应用延迟容忍值（以秒为单位）。

这个特性允许查询安全地从主数据库卸载到物理备数据库，因为它可以检测到备数据库是否变成不可接受的已过时的。

STANDBY_MAX_DATA_DELAY值	说明
NONE	缺省值，不管备数据库的应用延迟多少，总是执行向物理备数据库发出的查询。
非零值	只有应用延迟少于或等于STANDBY_MAX_DATA_DELAY值时，才执行向物理备数据库发出的查询。
0	向物理备数据库发出的查询保证会返回与在主数据库上发出的查询完全相同的结果，除非物理备数据库落后于主数据库，这时会返回ORA-3172错误。

使用ALTER SESSION语句设置STANDBY_MAX_DATA_DELAY值：
SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2

1.1.3. 在实时查询环境中强制Redo Apply同步

为了确保所有从主数据库接收的redo数据已经应用到物理备数据库，可以使用以下SQL语句：
SQL> ALTER SESSION SYNC WITH PRIMARY;

语句会阻塞直到在命令发出时备数据库接收到的所有redo数据已经应用到物理备数据库。如果备数据库的redo传输状态不是SYNCHRONIZED或Redo Apply不是活动的，将会立即返回错误ORA-3173，不会进行同步。

在某些特定的情况下为了确保执行Redo Apply同步，使用函数SYS_CONTEXT(‘USERENV’,‘DATABASE_ROLE’)创建备数据库专用的触发器（在主数据库上启用但只有运行在备数据库上才会采取某些行动）。例如，在某个特定用户登录连接时才执行ALTER SESSION SYNC WITH PRIMARY语句：
CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
begin
if (SYS_CONTEXT(‘USERENV’, ‘DATABASE_ROLE’) IN (‘PHYSICAL STANDBY’)) then
execute immediate ‘alter session sync with primary’;
end if;
end;

1.1.4. 实时查询限制

以下是实时查询模式的相关限制：
1）以上描述的应用延迟控制和Redo Apply同步机制要求客户端连接和发出查询的物理备数据库在实时查询模式
2）如果应用延迟控制参数STANDBY_MAX_DATA_DELAY设置为0或使用了SQL语句ALTER SESSION SYNC WITH PRIMARY，还有下面的限制：
a. 备数据库必须通过SYNC传输接收redo数据
b. 备数据库的redo传输状态必须是SYNCHRONIZED和主数据库必须运行在最大保护模式或最大可用模式
c. 实时Apply必须启用
3）Oracle Active Data Guard在Oracle RAC环境中通过使用缓存融合（cache fusion）来获得实时查询的高性能。这允许Oracle Data Guard apply instance和查询在缓存上工作，而不被磁盘I/O限制减慢速度。

1.1.5. 自动块介质恢复

如果数据库被访问时遇到了损坏的数据块，它们可以自动被没有损坏的数据块拷贝替换。自动块介质恢复要求符合以下条件：
1）物理备数据库必须运行在实时查询模式（需要购买Oracle Active Data Guard授权）
2）物理备数据库必须运行实时Apply。

取决于是在主数据库还是备数据库上遇到损坏块，自动块介质恢复运行在两个方向上。

主数据库的损坏块
如果在主数据库上遇到了损坏数据块，主数据库会在备数据库上自动搜索这些数据块未损坏的拷贝，如果找到了，将它们传输回主数据库。
主数据库只需要设置了LOG_ARCHIVE_DEST_n参数指向备数据库。

备数据库的损坏块
如果在备数据库上遇到了损坏数据块，备数据库自动发起与主数据库的通讯，请求这些数据块的未损坏的拷贝。为了让主数据库可以传输这些未损坏的数据块到备数据库，下面的数据库初始化参数必须在备数据库上配置。即使主数据库不是直接为备数据库提供服务（例如在层叠配置中），也需要配置。
配置参数LOG_ARCHIVE_CONFIG包含DG_CONFIG列表和为主数据库配置LOG_ARCHIVE_DEST_n参数。
或
配置FAL_SERVER参数，它的值包含主数据库的Oracle网络服务名。

额外的自动块介质修复说明：
1）Oracle Data Guard保护模式支持自动修复，但是，使用备数据库非损坏版本的数据块修复主数据库的损坏块的效果取决于备数据库的Redo Apply与主数据库生成的redo同步的紧密程度。
2）当执行自动块修复时，相关消息会写到数据库alert日志里。
3）如果块不能自动修复，会返回ORA-1578错误。

1.1.6. 手动块介质恢复

RMAN的RECOVER BLOCK命令可以用来手动修复损坏的数据块。命令从几个位置搜索数据块的非损坏拷贝。缺省时，其中一个位置是任何可用的运行在实时查询模式下的物理备数据库。
RMAN的RECOVERY BLOCK命令的EXCLUDE STANDBY选项可以用来排除物理备数据库作为替换块的来源。

1.1.7. 增加临时文件到物理备数据库

如果使用备数据库来从主数据库卸载查询，那么备数据库必须至少配置使用一个临时数据文件的临时表空间。
如果负载本质上比备数据库第一次创建时自动创建的要求更多的表空间，可以手动增加额外的空间。

执行以下步骤来为物理备数据库增加临时文件：
1）确认包含临时文件的表空间。在物理备数据库上执行以下语句：
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE CONTENTS = ‘TEMPORARY’;

TABLESPACE_NAME
--------------------------------
TEMP1
TEMP2

2）对于在步骤1中确认的每个表空间，增加一个临时文件到备数据库。
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE ‘/arch1/boston/temp01.dbf’ SIZE 40M REUSE;

2．需要在物理备数据库中人工干预的主数据库更改

大部分主数据库的结构性更改会通过redo数据自动传播到物理备数据库，但有些更改需要人工干预。

下面列出了需要在物理备数据库上人工干预的主数据库的结构性和配置更改。

主数据库更改	要求在物理备数据库上人工干预的操作
增加数据文件或创建表空间	如果STANDBY_FILE_MANAGEMENT数据库初始化参数设置为AUTO，那么不需要人工操作。 如果参数设置为MANUAL，新的数据文件必须手工复制到物理备数据库。
删除表空间或删除数据文件	在包含DROP或DELETE命令的redo数据应用到物理备数据库后从主数据库和物理备数据库删除数据文件
在物理备数据库使用可传输表的空间	在主数据库和物理备数据库之间移动表空间
在主数据库重命名数据文件	在物理备数据库上重命名数据文件
增加或删除redo日志文件组	在物理备数据库上评估redo日志和备redo日志，然后进行必要的调整
NOLOGGING或不能恢复的操作	使用RMAN命令的RECOVER … NOLOGGED BLOCK用主数据库的更改过的数据坏来替换备数据库上的无效数据块
更新密码文件	从Oracle数据库12.2.0.1版本开始，主数据库上的密码文件更改会自动传播到备数据库。唯一的例外是far sync实例。更新的密码文件必须手动拷贝到far sync实例，因为far sync实例接收redo，但不应用redo数据。Far sync实例上的密码文件更新后，主数据库上包含密码更新的redo数据会自动传播到设置从far sync实例接收redo的备数据库上。当redo应用时，备数据库上的密码文件就会更新。
重置TDE主加密密钥	使用主数据库上的新的数据库加密钱包拷贝替换物理备数据库上的数据库加密钱包
初始化参数	评估物理备数据库上的初始化参数是否要做相应的更改

2.1.增加数据文件或创建表空间

数据库初始化参数STANDBY_FILE_MANAGEMENT控制主数据库增加数据文件是否会自动传播到物理备数据库。
1）如果物理备数据库的数据库参数STANDBY_FILE_MANAGEMENT设置为AUTO，在主数据库上创建的新数据文件会自动在物理备数据库上创建；
2）如果物理备数据库的数据库参数STANDBY_FILE_MANAGEMENT设置为MANUAL，主数据库上的新数据文件必须在增加后手动拷贝到物理备数据库。

注：如果物理备数据库的Oracle Actvie Data Guard选项已经启用，不能使用手工拷贝方法。
必须执行以下SQL语句来创建空的数据文件：
SQL> ALTER DATABASE CREATE DATAFILE [filename | filenumber] AS [NEW | new_filename];
必须指定filename或filenumber来重命名，同时指定新的文件名或NEW。如果启用了OMF（Oracle Managed Files），NEW关键字让Oracle自动选择一个文件名。

如果从其他数据库拷贝一个存在的数据文件到主数据库，不管STANDBY_FILE_MANAGEMENT参数设置为何值，也必须拷贝该数据文件到物理备数据库和重建备数据库的控制文件。

2.2.删除表空间和数据文件

当从主数据库删除表空间或数据文件时，相应的数据文件也必须 从物理备数据库上删除。
下面示例如何删除表空间：
SQL> DROP TABLESPACE tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;

查询视图V$DATAFILE确认删除的数据文件是否还属于数据库。

在包含删除表空间操作的redo数据已经应用到备数据库后删除相应的数据文件：
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf

在主数据库上，在确保备数据库应用了包含删除表空间的redo数据后，可以删除表空间的数据文件：
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf

2.2.1.使用DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES语句

可以在主数据库上使用SQL语句DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES在主数据库和备数据库上都删除数据文件。

为了使用这个语句，初始化参数STANDBY_FILE_MANAGEMENT必须设置为AUTO。
SQL> DROP TABLESPACE tbs_4 INCLUDING CONTENTS AND DATAFILES;
SQL> ALTER SYSTEM SWITCH LOGFILE;

2.3. 物理备数据库使用可传输表空间

可以使用Oracle可传输表空间特性来移动数据库的子集和插入到其他Oracle数据库，本质上在数据库之间实现表空间移动。

当使用物理备数据库时，执行以下步骤来移动或拷贝表空间集到主数据库：
1）生成包含数据文件的可传输表空间集和包含表空间结构信息的export文件

2）传输表空间集：
a. 拷贝数据文件和export文件到主数据库
b. 拷贝数据文件到备数据库

主数据库和备数据库上的数据文件必须拥有相同的路径名称，除非已经配置DB_FILE_NAME_CONVERT数据库初始化参数。如果没有设置参数DB_FILE_NAME_CONVERT，而主备数据库的数据文件路径名不同时，使用ALTER DATABASE RENAME FILE语句重命名数据文件。在Redo Apply应用插入表空间到主数据库生成的redo数据失败后再进行操作。在重命名前初始化参数STANDBY_FILE_MANAGEMENT必须设置为MANUAL，然后在重命名数据文件后再重新设置为之前的值。

3）插入表空间。
使用Data Pump工具将表空间集插入到主数据库。插入操作会生成Redo数据，然后在备数据库上应用redo插入表空间到备数据库。

2.4. 在主数据库上重命名数据文件

当重命名一个或更多主数据库的数据文件时，更改不会传播到备数据库，必须手动更改。

重命名物理备数据库上的相同数据文件时，必须在备数据库上手动进行相同的更改，因为修改不会自动执行，即使初始化参数STANDBY_FILE_MANAGEMENT设置为AUTO。

以下步骤描述如何在主数据库上重命名数据文件和手动传播更改到备数据库。
1） 为了重命名主数据库的数据文件，将表空间脱机：
SQL> ALTER TABLESPACE tbs_4 OFFLINE;

2） 退出SQL提示符，执行操作系统命令，例如UNIX的mv命令，在主数据库所在的系统上重命名数据文件：
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf

3） 在主数据库上重命名数据文件，然后将表空间联机：
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE ‘/disk1/oracle/oradata/payroll/tbs_4.dbf’
TO ‘/disk1/oracle/oradata/payroll/tbs_x.dbf’;

SQL> ALTER TABLESPACE tbs_4 ONLINE;

注：可替代以上3个步骤的方法是使用ALTER DATABASE MOVE DATAFILE命令来重命名数据文件。命令可以让数据文件在重命名的同时继续被读写访问。足够的剩余存储空间是命令执行的前提条件，因为在执行MOVE DATAFILE命令的过程中，数据库需要同时维护原数据文件和重命名的数据文件这两个不同的文件。

4） 连接到备数据库，停止Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

5） 关闭备数据库：
SQL> SHUTDOWN;

6） 使用操作系统命令重命名备数据库的数据文件，例如UNIX mv命令：
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf

7） 启动和挂载备数据库：
SQL> STARTUP MOUNT;

8）在备数据库的控制文件中重命名数据文件。为了重命名数据文件，必须设置STNADBY_FILE_MANAGEMENT参数为MANUAL，在完成重命名数据文件后再重新设置参数为之前的值。
SQL> ALTER DATABASE RENAME FILE ‘/disk1/oracle/oradata/payroll/tbs_4.dbf’
TO ‘/disk1/oracle/oradata/payroll/tbs_x.dbf’;

9）在备数据库上，重新启动Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

如果在备系统上没有重命名相应的数据文件，然后尝试刷新备数据库的控制文件，备数据库尝试使用重命名的数据文件，但会无法找到它。类似下面的消息会写到alert日志中：
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: ‘/Disk1/oracle/oradata/payroll/tbs_x.dbf’

注：如前面所述，可替换步骤4-9的方法是使用ALTER DATABASE MOVE DATAFILE命令来在备数据库上重命名数据文件。

2.5. 增加或删除redo日志文件组

在主数据库上增加和删除日志文件组后需要对物理备数据库上的在线redo日志和备redo日志的配置重新评估和进行必要的调整。

采取以下步骤在物理备数据为上添加或删除日志文件组或备日志文件组：
1）停止Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2）如果STANDBY_FILE_MANAGEMENT初始化参数设置为AUTO，更改为MANUAL。
SQL> alter system set standby_file_management=manual;
3）增加或删除日志文件组
注：在从物理备数据库删除前必须先清空在线日志组，例如：
ALTER DATABASE CLEAR LOGFILE GROUP 3;
状态为CURRENT或CLEARING_CURRENT的在线日志文件组不能从物理备数据库上删除。具有这种状态的在线日志组在角色转换后可以删除。
4） 恢复STANDBY_FILE_MANAGEMENT初始化参数的值
5） 重新启动Redo Apply。

在Oracle RAC环境中，注意以下几点：
1） 当主数据库增加在线redo日志组的时候，必须手动在备数据库增加在线redo日志组。这个不会自动完成。
2） 当主数据库增加一个新的redo线程，备数据库上会自动增加一个新的redo线程。缺省情况下，新的线程会配置2个100MB的日志组，不能更改或覆写。
3） 当增加一个新的日志组到现有的redo线程，新的日志组不会自动增加到现有的线程（When a new log group is added to an existing redo thread, a new log group is not automatically added to its existing thread）。

2.6. NOLOGGING或不可恢复的操作

当使用NOLOGGING或UNRECOVERABLE子语句执行DML或DLL操作时，备数据库上的数据块可能会被标记为无效的（也称为非日志块）。

当redo应用到物理备数据库时，一部分数据文件会被标记为不可恢复。当故障切换到物理备数据库，或以只读模式打开备数据库时，尝试读取标记为UNRECOVERABLE的数据块的区块图时，会看到类似以下的错误信息：
ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: ‘/oracle/dbs/stdby/tbs_1.dbf’
ORA-26040: Data block was loaded using the NOLOGGING option

当使用STANDBY NOLOGGING FOR LOAD PERFORMANCE模式时，在物理备数据库上执行的查询仍然可能会因为nologging操作而报告损坏块。然而，当管理的恢复（managed recovery）作为Active Data Guard配置的一部分运行在备数据库上时，它自动会从主数据库提取替换块。（管理的恢复使用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT来启动）。管理的恢复在数据块开始创建之后不久就尝试提取所有这些块和继续尝试修复它们直到成功为止。无论何时启动管理恢复，它会再开始修复任何在前面恢复会话中的未完成的块。这个自动的恢复只应用到STANDBY NOLOGGING FOR LOAD PERFORMANCE模式启用时产生的redo导致的损坏块。由于传统的nonlogged操作损坏的数据块必须使用以下步骤来进行恢复。

1） 在备数据库上停止恢复：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2） 使用RMAN连接到备数据库，执行以下命令来恢复nonlogged数据块：
RMAN> RECOVER DATABASE NONLOGGED BLOCK;

如果不可恢复的数据块只在switchover后被发现存在，那么可以使用这两个相同的步骤，但主数据库必须在mount状态（不是open）和RMAN必须连接到主数据库。

RMAN的RECOVER命令也许不能恢复所有nonlogged的数据块。可能发生的原因会详细地列在执行RMAN命令的数据库的alert.log文件中。最普遍的原因是数据块最近在主数据库上被更改，还没有写入到相应的数据文件中。这可能意味着发送到备数据库的数据块太旧而不能替换备数据库上的不可恢复块。为了解决这个问题，在迟些时间数据块被写出到数据文件之后，再次执行RECOVER命令。

2.6.1.确认在不可恢复操作之后是否需要备份

如果在主数据库上执行不可恢复的操作，那么需要确认是否需要进行新的备份操作。

采取以下步骤来操作：
1）在主数据库上查询视图V$DATAFILE来确认数据库产生最近无效redo数据的SCN（system change number）或时间。

2）在主数据库上执行以下SQL语句来确认是否需要执行另外一个备份：
SQL> SELECT UNRECOVERABLE_CHANGE#,TO_CHAR(UNRECOVERABLE_TIME, ‘mm-dd-yyyy hh:mi:ss’) FROM V$DATAFILE;

3）如果在前面步骤的查询报告数据文件的不可恢复的时间比上一次数据文件备份的时间更近，那么对有问题的数据文件再做另外一次备份。

2.6.2. 物理备数据库的部分恢复步骤

RMAN命令RECOVER … NONLOGGED BLOCK可以用来恢复属于一组数据文件或表空间的数据块。

这个功能可能有用，如果可以接受在某些数据文件中仍然含有nonlogged数据块，例如因为明确知道nologged数据块作为导入行到现在已经被删除的对象的结果而创建的。

视图V$NONLOGGED_BLOCK一般会列出每个数据文件已知的无效数据块的区块图，整体会作为介质恢复的一部分来维护。然而，有时候信息不完整。典型的情况是在从12.1之前的版本升级之后或在还原操作系统备份的数据文件之后。下次介质恢复运行时，失效的整体会被移除，任何新的无效数据块会被记录，但之前无效的数据块不会在视图V$NONLOGGED_BLOCK有记录。视图V$DATAFILE的列FIRST_NONLOGGED_SCN仍然可以用来查看至少存在1个无效数据块的数据文件，即使数据文件在视图V$NONLOGGED_BLOCK中没有记录。

RMAN命令VALIDATE … NONLOGGED BLOCK可以用来将视图V$NONLOGGED_BLOCK中的记录带回到与数据文件同步。它通过确认存在的区块图是否完整，如果不完整，就扫描必要的数据文件来鉴别任何无效数据块，确认它们被V$NONLOGGED_BLOCK的记录捕获。命令VALIDATE … NONLOGGED BLOCK含有与命令RECOVER … NONLOGGED BLOCK一样的选项来验证一组数据文件或表空间。

如果只有脱机的数据文件被验证或恢复，那么它们所属的数据库可以在RMAN命令运行的时候打开。

2.7. 更新密码文件

如果数据库初始化参数REMOTE_LOGIN_PASSWORDFILE设置为SHARED或EXCLUSIVE，那么物理备数据库的密码文件会自动被来自主数据库的新拷贝替换。
在授予或撤销管理权限后，或在有管理权限的用户密码更改时，密码文件会被替换。唯一的例外是far sync实例。更新过的密码文件必须手动拷贝到far sync实例，因为far sync实例接收redo数据，但不会应用它。当密码文件在far sync实例上手工更新后，包含密码更改的redo会自动传播到设置为从far sync实例接收redo的备数据库。当redo应用时，密码文件就会在备数据库上更新。

3．使用OPEN RESETLOGS语句恢复

Oracle Data Guard允许物理备数据库在主数据库以RESETLOGS选项打开后继续恢复。

当ALTER DATABASE OPEN RESETLOGS语句在主数据库上执行时，数据库更改的转生（incarnation）会创建redo数据的一个新分支。

当物理备数据库接收到redo数据的新分支时，Redo Apply自动采用redo数据的新分支。对于物理备数据库，如果备数据库没有应用超过新resetlogs的SCN（超过redo数据的新分支的起点）的redo数据，不需要人工干预。下表描述了如何使用主数据库的新分支同步备数据库：

如果备数据库…	那么…	执行下面的步骤…
还没有应用超过新resetlogs SCN（超过redo数据的新分支的起点）的redo数据，而且来自OPEN RESETLOGS的新的redo分支已经在备数据库上注册	Redo Apply自动采用redo数据的新分支	不需要人工干预。管理redo进程（MRP）自动使用redo数据的新分支来同步物理备数据库。 注：在主备数据库执行以下查询，检查新redo新分支是否已经在备数据库上注册，确认结果匹配：SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status=‘CURRENT’
已经应用了超过新resetlogs SCN（超过redo数据的新分支的起点）的redo数据，而且闪回数据库在物理备数据库上已启用	备数据库已恢复到redo数据的新分支的未来时间点	1．按照闪回物理备数据库到特定的时间点的步骤闪回物理备数据库 2．重启Redo Apply继续应用redo数据到新的resetlogs分支。 3．管理redo进程（MPR）自动使用新分支redo同步备数据库
已经应用了超过新resetlogs SCN（超过redo数据的新分支的起点）的redo数据，而且闪回数据库在物理备数据库上未启用	主数据库与备数据库在表明的主数据库分支上偏离	按照创建物理备数据库的步骤重新创建物理备数据库
缺失从redo数据的新分支开始介于中间的归档redo日志文件	MRP不能继续直到找回缺失的日志文件	找到和注册来自每个分支的缺失的归档redo日志文件
缺失redo数据之前的分支从结尾开始的归档redo日志文件	MRP不能继续直到找回缺失的日志文件	找到和注册来自以前的分支的缺失的归档redo日志文件

3.1.主数据库RESETLOGS操作后自动闪回挂载的备数据库

在挂载状态的备数据库可以在主数据库执行RESETLOGS操作后自动仿效主数据库。这简化了在主数据库上执行RESETLOGS操作后的备数据库的管理。

当在主数据库或主数据库的PDB上执行闪回或时间点恢复时，主数据库或PDB移动到之前的时间点，然后以RESETLOGS选项打开主数据库。主数据库或PDB的转生（incarnation）会被创建。为了让备数据库自动效仿主数据库，MRP执行以下操作：
1）检测到新的转生
2）闪回备数据库或PDB到与主数据库相同的时间点
3）重启备数据库恢复和移动备数据到redo的新分支

闪回操作只有在备数据库有足够的闪回数据时才会成功。

如果不想备数据库自动效仿主数据库，将备数据库保持在打开状态或停止备数据库的MRP进程。

如果备数据库以只读模式打开，相应的报错信息会记录在alert日志中。当在关闭物理备数据库后重启MRP，恢复进程会自动闪回备数据库，然后继续应用redo数据的新分支。

3.2. 闪回物理备数据库到指定时间点

下面步骤描述如何在主数据库发出OPEN RESETLOGS语句后避免重建物理备数据库。

在Oracle Database 19c版本中，如果备数据库在挂载状态和闪回已启用，可能不需要做任何操作。一般情况下，如果有足够的闪回数据可用，备数据库会自动闪回，这样备数据库继续效仿主数据库。

如果备数据库是打开状态和已启用闪回数据库，可以将备数据库置于挂载状态，然后启动备数据库恢复。MRP进程尝试让备数据库效仿主数据库，触发备数据库自动闪回。如果这个操作成功，像alert日志报告的一样，跟着需要打开Active Data Guard实例。

如果自动闪回没有触发，或自动闪回没有让备数据库效仿主数据库，可以执行以下步骤来闪回备数据库。
1）确认在RESETLOGS操作发生前的SCN（system change number）。例如，在主数据库上，使用以下查询来获取在RESETLOGS操作发生前2个SCN的SCN值:
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

2）在备数据库上，获取当前SCN:
SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

3）根据当前SCN的值，执行相应的操作：
a. 如果备数据库当前SCN（CURRENT_SCN）比resetlogs_change# - 2的值大，执行以下语句闪回备数据库：
SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;

b. 如果当前SCN比resetlogs_change# -2小，跳到步骤4。
如果备数据库的SCN是远远落后于主数据库的SCN，从执行语句OPEN RESETLOGS开始的redo新分支已经在备数据库上注册，那么应用服务会继续通过OPEN RESETLOGS语句而不会停止。在这种情况下，闪回数据库是不必要的，因为应用服务在到达redo数据的OPEN RESETLOGS语句时不会停止。

4）在物理备数据库上启动Redo Apply，执行以下语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

备数据库准备接收和应用来自主数据库redo数据。

4．监控主数据库，物理备数据库和快照备数据库

下表总结了一般主数据库管理操作和在哪里能找到这些操作相关的信息。

主数据库操作	主数据库信息	备数据库信息
启用或禁用redo线程	1）alert日志 2）V$THREAD	alert日志
查看数据库角色，保护模式，保护级别，正常切换状态，快速启动故障切换信息等	V$DATABASE	V$DATABASE
增加或删除redo日志文件组	1）alert日志 2）V$LOG 3）V$LOGFILE的STATUS列	alert日志
创建控制文件CREATE CONTROLFILE	alert日志	alert日志
监控Redo Apply	1）alert日志 2）V$ARCHIVE_DEST_STATUS	1）alert日志 2）V$ARCHIVED_LOG 3）V$LOG_HISTORY 4）V$MANAGED_STANDBY
更改表空间状态	1）V$RECOVER_FILE 2）DBA_TABLESPACES 3） alert日志	1）V$RECOVER_FILE 2）DBA_TABLESPACES
增加或删除数据文件或表空间	1）DBA_DATA_FILES 2）alert日志	1）V$DATAFILE 2）alert日志
重命名数据文件	1）V$DATAFILE 2）alert日志	1）V$DATAFILE 2）alert日志
unlogged或unrecoverable操作	1）V$DATAFILE 2）V$DATABASE	alert日志
监控redo传输	1）V$ARCHIVE_DEST_STATUS 2）V$ARCHIVED_LOG 3）V$ARCHIVE_DEST 4）alert日志	1）V$ARCHIVED_LOG 2）alert日志
执行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES语句	alert日志	alert日志
更改初始化参数	alert日志	alert日志

5．从主数据库复制还原点到备数据库

在主数据库上创建的还原点会自动复制到备数据库。在备数据库上创建的还原点称为复制的还原点（replicated restore points）。不管主数据库的还原点是保证还原点（guaranteed restore point）还是正常还原点（normal restore point），相应的复制还原点总是正常还原点。

符合以下条件时，Oracle数据库自动复制主数据库的还原点到备数据库：
1）主备数据库的COMPATIBLE初始化参数都设置为19.0.0或更高
2）主数据库在打开的状态
当主数据库处于挂载状态时，主数据库上创建的还原不会被复制。具有这个限制是因为还原点信息需要通过redo来复制的。
复制的还原点的命令惯例是使用主数据库的还原点名称加上后缀_PRIMARY。如果有相同名称的复制还原点在备数据库上存在，那么复制还原点将不会创建。例如，当在主数据库上创建一个还原点PRE_MYTBS时，复制还原点命名为PRE_MYTBS_PRIMARY。当在主数据库上删除还原点时，备数据库上相应的复制还原点也会被删除。

管理Redo进程（MRP）管理创建和维护复制还原点。如果主数据库的还原点在MRP没有运行时创建，那么这些还原点在MRP启动后会复制到备数据库。

可以查询视图V$RESTORE_POINT来确认还原点已自动复制。

6．调整Redo Apply

参考Active Data Guard 11g Best Practices (includes best practices for Redo Apply)来优化Redo Apply和介质恢复性能，在Oracle Maximum Availability Architecture (MAA)主页（http://www.oracle.com/goto/maa）可以下载文档high-availability-overview-and-best-practices.pdf。

还可以参考文档454848.1安装和使用Standby Statspack，从备数据库上收集Redo Apply性能数据。

7．使用SQL Tuning Advisor调整Active Data Guard环境中的数据库

在Active Data Guard环境中，SQL Tuning Advisor可以在主数据库上调优备数据库的负载。
使用数据库链接，可以在一个数据库上发出SQL Tuning Advisor语句，但在另外的的数据库上执行该语句。

7.1. 在主数据库上调优备数据库负载

在某些情况下，备数据库除了数据保护角色外还可以承担报告角色。备数据库可以有自己的查询负载，有些可能需要调优。在这个场景中，可以在备数据库上发出调优语句来调优备数据库的负载，但SQL Tuning Advisor使用备到主数据库链接来在主数据库上执行分析。

下面的任务必须在主数据库上执行来调整备数据库的负载。使用DBMS_SQLTUNE PL/SQL包，这些任务必须按照指定的顺序在备数据库上执行：
1）执行DBMS_SQLTUNE.CREATE_TUNING_TASK语句从主数据库获取需要的数据创建任务。因为备数据库是只读数据库，关于任务的数据会远程写到主数据库。数据库链接参数要求在这个步骤中写到主数据库（数据库链接参数在接下来的步骤中是可选的，因为它绑定到这个步骤创建的任务中）。
2）执行DBMS_SQLTUNE.EXECUTE_TUNING_TASK语句。最初，执行任务要求的数据从远程主数据库获取。寻找可能建议的调优分析进程（tuning analysis process）被执行。因为备数据库是只读数据库，当结果可用时会远程存储到主数据库里。
3）执行DBMS_SQLTUNE.REPORT_TUNING_TASK语句。需要构建报告的数据远程存储在主数据库里。数据从主数据库远程获取，然后在备数据库上构建。
4）执行DBMS_SQLTUNE.ACCEPT_TUNING_TASK语句。profile数据写到远程主数据库因为备数据库是可读的。
5）使用Redo Apply让SQL Profile在备数据库上可用。

8．使用Oracle Diagnostic Pack来调优Oracle Active Data Guard备数据库

可以在以只读方式打开的Oracle Active Data Guard备数据库上使用Oracle Diagnostic Pack。这让你可以为Oracle Active Data Guard备数据库抓取性能数据到AWR（Automatic Workload Repository），然后在AWR数据上运行ADDM（Automatic Database Diagnostic Monitor）分析。关于如何执行这些操作的详情，请参考《Oracle Database Performance Tuning Guide》。

9．管理快照备数据库

快照备数据库是完全可更新的备数据库。它从主数据库接收和归档redo数据，但不会应用它。

当快照备数据库转换回物理备数据库时，在丢弃快照备数据库的所有本地更新以后，从主数据库接收的redo数据会被应用。

快照备数据库通常会随着时间与主数据库偏离，因为来自主数据库的redo数据不会在接收时应用。快照备数据库本地的更新导致额外的偏离。然而，主数据库的数据会完全得到保护，因为快照备数据库可以在任何时候转换回物理备数据库，然后应用从主数据库接收的redo数据。

快照备数据库提供与物理备数据库类似的灾难恢复和数据保护好处。快照备数据库适合用在拥有临时的可更新的主数据库快照的好处多于更短的时间从主数据库故障中恢复的场景。

9.1. 转换物理备数据库到快照备数据库

以下步骤描述如何转换物理备数据库到快照备数据库。
1）如果Redo Apply是活动的，停止它

2）确保数据库在挂载状态，不是打开状态。

3）确保已经配置快速恢复区域。启用闪回数据库时这不是必需的。

4）执行以下SQL语句进行转换：
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

5）打开快照备数据库到可读写模式：
SQL> ALTER DATABASE OPEN READ WRITE;

9.2. 使用快照备数据库

快照备数据库可以以读写模式打开和是完全可更新的。

快照备数据库有以下特性：
1）快照备数据库不能作为正常切换或故障切换的目标数据库。快照备数据库必须先转换回物理备数据库，然后再执行角色转换。
2）快照备数据库在Oracle Data Guard最大保护配置中不能作为唯一的备数据库。

注：闪回数据库用来转换快照备数据库回物理备数据库。任何不能使用闪回数据库技术撤销的操作都会阻止快照备数据库转换回物理备数据库。

9.3. 转换快照备数据库到物理备数据库

以下步骤描述如何转换快照备数据库到物理备数据库。
1）在Oracle RAC数据库环境中，关闭除其中一个以外的其它所有实例

2）确保数据库在挂载状态，不是打开状态。

3）执行以下SQL语句进行转换：
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

当数据库是快照备数据库时接收的redo数据会在Redo Apply启动时自动应用。

注：在转换回物理备数据库前，快照备数据库必须至少一次以读写模式打开。

10．恢复主数据库的丢失写（Lost-Write）错误

在Oracle Data Guard配置的介质恢复中，物理备数据库可以用来检测主数据库上的丢失写数据损坏错误。

通过比较存储在主数据库的redo日志中存储的数据块的SCN与物理备数据库上的数据块的SCN来完成。如果主数据库的数据块的SCN比备数据库的SCN低，那么主数据库上存在丢失写错误。

在这种情况中，如果丢失写检测（设置DB_LOST_WRITE_PROTECT初始化参数）在主备数据库上都已启用，那么在备数据库上的恢复尝试会导致ORA-00752错误。如果丢失写检测没有启用，那么恢复尝试会导致ORA-600[3020]错误。然而，不是所有ORA-600[3020]错误都是因为主数据库的丢失写错误导致。因此，在遵循这个部分的指南之前，与支持人员确认ORA-00600 [3020]错误的根本原因是否真的是主数据库上发生了丢失写错误。也请查看Oracle Support Note 1265884 “Resolving ORA-752 or ORA-600 [3020] During Standby Recovery”。

当在备数据库上检测到主数据库丢失写错误时，类似于下面的每个失效数据块错误日志会输出到备数据库的alert.log文件中：

Tue Dec 12 19:09:48 2006
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 26, FILE 7
NO REDO AT OR AFTER SCN 389667 CAN BE USED FOR RECOVERY.

然后alert.log日志文件显示一条备数据库的错误ORA-00752和管理恢复被取消：

Slave exiting with ORA-752 exception
Errors in file /oracle/log/diag/rdbms/dgstwrite2/stwrite2/trace/
stwrite2_pr00_23532.trc:
ORA-00752: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 7, block# 26)
ORA-10564: tablespace TBS_2
ORA-01110: data file 7: '/oracle/dbs/btbs_21.f'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 57503

然后备数据库恢复到一致的状态，在alert文件中打印的SCN处，没有该错误导致的数据文件损坏：

Recovery interrupted!
Recovered data files to a consistent state at change 389569

最后一条日志可能会相当迟才会在alert文件中出现，它可能会比数据块错误日志更低的SCN。同时，主数据库可能会没有可见的错误在运行，即使它的数据文件可能已经损坏 。

建议的恢复这些错误的过程是failover到物理备数据库上，如下面的步骤描述一样。

在主数据库检测到丢失写错误之后failover到物理备数据库的步骤

1）关闭主数据库。所有在数据块错误日志中打印的SCN时或之后的数据已经丢失。

2）在备数据库上执行以下SQL语句将它转换为主数据库：
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Tue Dec 12 19:15:23 2006
alter database activate standby database
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (stwrite2)
RESETLOGS after incomplete recovery UNTIL CHANGE 389569
Resetting resetlogs activation ID 612657558 (0x24846996)
Online log /oracle/dbs/bt_log1.f: Thread 1 Group 1 was previously
cleared
Online log /oracle/dbs/bt_log2.f: Thread 1 Group 2 was previously
cleared
Standby became primary SCN: 389567
Tue Dec 12 19:15:23 2006
Setting recovery target incarnation to 3
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (stwrite2)
Completed: alter database activate standby database

3）备份新的主数据库。立即执行备份是必要的安全措施，因为如果没有完整的数据库备份拷贝的话，不能恢复在failover以后的更改。作为failover的结果，原主数据库不再参与Oracle Data Guard的配置，所有其它备数据库现在接收和应用来自新主数据库的redo数据。

4）打开新的主数据库。

5）一个可选的步骤是重建故障主数据库为物理备数据库。可以使用步骤3里的新主数据库备份来完成。在这种情况中，不能使用闪回数据库或Oracle Data Guard broker来重建旧主数据库。

11．使用DBCOMP存储过程来检测丢失写和其它不一致

可以使用PL/SQL存储过程DBMS_DBCOMP.DBCOMP来检测丢失写和主备数据库之间的不一致。

DBMS_DBCOMP.DBCOMP存储过程比较主备数据库上相同的数据块。这个存储过程可以在任何时间执行。（它不需要DB_LOST_WRITE_PROTECT初始化参数启用。）可以查询视图V$SESSION_LONGOPS监控进行中的块比较操作的进度。

注：逻辑备数据库，far sync实例，和层叠备数据库不能作为DBMS_DBCOMP.DBCOMP存储过程的目标数据库。

存储过程DBMS_DBCOMP.DBCOMP假设存在一个主数据库和一个或更多的物理备数据库。数据库至少应该在块比较前处于挂载状态。

在下面的示例情况中，假设主数据库的唯一名称为dgmain，物理备数据库的名称为dgmainb，dgmainc，dgmaind等。

示例1，主数据库和所有备数据库处于挂载或打开状态，DBCOMP从主数据库执行
在这种情况中，当DBCOMP存储过程从主数据库上执行时，指定的数据文件在主备物理数据库之间逐个数据块进行比较。例如，假设执行以下查询：
SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);

产生的输出文件是BlockCompare_dgmainb_1和BlockCompare_dgmainc_d_1。

示例2，主数据库和所有备数据库处于挂载或打开状态，DBCOMP从备数据库执行
在这种情况中，当DBCOMP存储过程从其中一个备数据库上执行时，指定的数据文件只在主数据库和执行命令的物理备数据库之间进行比较。其它的备数据库不考虑在内。例如，假设执行以下查询：
SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);

产生的输出文件是BlockCompare_dgmain_1。

示例3，主数据库处于挂载或打开状态，不是所有备数据库处于挂载或打开状态，DBCOMP从主数据库执行
在这种情况中，当DBCOMP存储过程从主数据库上执行时，指定的数据文件在主数据库和所有挂载或打开的物理备数据库之间进行比较。对于那些没有挂载或打开的备数据库，不采取任何行动。

来源：《Oracle Data Guard Concepts and Administration, 19c》