在物理 standby 数据库上如何解决 MRP 进程卡住的问题？ (Doc ID 2331842.1)

How to resolve MRP stuck issues on a physical standby database? (Doc ID 1221163.1)

在物理 standby 数据库上如何解决 MRP 进程卡住的问题？ (Doc ID 2331842.1)

适用于:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 12.1.0.2 [发行版 10.1 到 12.1]
Oracle Database Cloud Schema Service - 版本 N/A 和更高版本
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - 版本 N/A 和更高版本
Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本
Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本
本文档所含信息适用于所有平台

目标

您是否希望与其他 Oracle 客户、Oracle 员工和业内专家进一步探讨此主题？

您可以直接在本文档底部关于本文档的讨论主题中展示您的经验或就其提出疑问。

如果您想发现和本文档有关的进一步的讨论并提交新的发现，请您访问社区 My Oracle Support Community Page for High Availability Data Guard。

当您从 grid control 上发现物理 standby 数据库应用的日志 sequence# 不再增加，或者 MRP 卡住不再应用任何日志，您需要做些什么来找到问题的原因并且解决问题使 standby 库重新和主库同步？

通常来讲，可以从执行下面的步骤开始：

1. 使用下面任意一种方式找到 MRP 卡住在哪个归档日志上：

a. 如果 MRP 是启动着的，那么从 standby 数据库上查询 v$managed_standby。

% ps -ef |grep -i mrp
SQL>select process, thread#, sequence#, status from v$managed_standby where process='MRP0';

PROCESS THREAD# SEQUENCE# STATUS

---

MRP0 1 548 WAIT_FOR_GAP

b. 停止自动恢复并且启动手工恢复。

SQL>recover managed standby database cancel;
SQL>recover automatic standby database;

如果使用了 data guard broker，您需要使用 DGMGRL 或者 grid control 来操作。

对于 11g data guard broker，

DGMGRL> EDIT DATABASE '' SET STATE='APPLY-OFF';
DGMGRL> EDIT DATABASE '' SET STATE='APPLY-ON';

如果 standby 是 RAC 数据库，那么

DGMGRL> EDIT DATABASE '' SET STATE='APPLY-ON' WITH APPLY INSTANCE = ;

是要进行日志应用的实例的名字。

对于 10g Data Guard broker，

DGMGRL> EDIT DATABASE '' SET STATE='LOG-APPLY-OFF'; DGMGRL> EDIT DATABASE '' SET STATE='ONLINE';

如果 standby 是 RAC 数据库，那么

DGMGRL> EDIT DATABASE '' SET STATE='ONLINE' WITH APPLY INSTANCE = ;

要在 grid control 上修改 10g 和 11g 的 standby 数据库的状态，需要执行下面的步骤：

1. 在 Data Guard Overview 页面，选择要操作的 standby 数据库。
2. 点击 Edit 来进入 Edit Properties 页面。
3. 选择 Log Apply Off（或者在线）。
4. 点击 Apply。
5. 完成后，会看到操作成功的提示。

对于 9i Data Guard Broker，

DGMGRL> ALTER RESOURCE '' ON SITE '' SET STATE='PHYSICAL-APPLY-READY';
DGMGRL> ALTER RESOURCE '' ON SITE '' SET STATE='PHYSICAL-APPLY-ON';

要在 grid control 上修改 9i 的 standby 数据库的状态，需要执行下面的步骤：

1. 在导航树上，选择 standby 数据库。
2. 在右手边属性栏上，点击 Set State。
3. 选择 Log Apply Off（或者在线）。
4. 点击 OK。

c. 使用数据文件头的最小的 checkpoint_change# 来查找需要从哪个归档日志开始恢复：

SQL>select min(fhscn),fhrba_Seq SEQUENCE from x$kcvfh group by fhrba_Seq;

2. 检查从上个步骤得到的归档日志文件是否在 standby 主机上由 standby 数据库初始化参数 standby_archive_dest 指定的目录里（或者 log_archive_dest_1 指定的目录上，如果 standby_archive_dest 并未指定的情况下）。

如果存在，使用命令 cksum 检查主库以及 standby 端这个文件的大小是否一致。比如

% cksum <archive log file full path/file name>

注意：如果 cksum 在您的 UNIX 平台上不存在，那么参照下面的文档来使用其它命令，比如， SHA-1 和 MD5 checksum 工具。

Note 549617.1 How To Verify The Integrity Of A Patch/Software Download?

也可以在主库或者 Standby 上执行下面的命令来验证归档日志文件是否已经损坏：

SQL>alter system dump logfile '<full path/archive log file name>' validate;

如果 SQL 并未返回错误，说明归档日志并未损坏。

3. 如果步骤一里找到的归档日志不存在 standby 端或者已损坏，那么需要从主库重新拷贝一份。请参照下面的文档来手工解决 gap。

   Note 1537316.1 Data Guard Gap Detection and Resolution Possibilities

4. 如果归档日志文件存在 standby 端并且没有损坏，那么请检查它是否已经被注册在 standby 控制文件中，比如：

SQL>select name from v$archived_log where (thread#=1 and sequence#=192917) or (thread#=2 and sequence#=26903);

如果 thread 1 最后一个应用的 sequence# 是192916并且 thread 2 最后一个应用的 sequence# 是26902。或者 thread# 和 sequence# 是步骤一找到的 MRP 卡住的地方。

2. 请使用下面的查询来确定主库各个 thread 对应的当前的 sequence#，standby 上各个 thread 最新收到的 sequence# 以及最近应用的 sequence#，以发现 standby 是否和主库完全同步，或者存在传输延迟或者日志应用延迟。

Primary: SQL > select thread#, max(sequence#) "Last Primary Seq Generated"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

PhyStdby: SQL > select thread#, max(sequence#) "Last Standby Seq Received"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

PhyStdby: SQL > select thread#, max(sequence#) "Last Standby Seq Applied"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and applied='YES'
group by thread# order by 1;

=======================================================================

请参考下面的关于物理 standby 数据库的 MRP 卡住的各种问题以及解决方案。如果仍不能解决问题，则可以使用 rman 增量备份的方式来前滚物理 standby 数据库。

注意: 使用 RMAN 的增量备份来前滚逻辑 standby 数据库是不支持的。

Note 290817.1 Rolling a Standby Forward using an RMAN Incremental Backup in 9i
Note 836986.1 Steps to perform for Rolling forward a standby database using RMAN incremental backup when primary and standby are in ASM filesystem

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#CIHIAADC
Oracle� Data Guard Concepts and Administration
10g Release 2 (10.2)

如果您的主库比较小，那么可以简单的做一个主库的全库备份并且恢复到 standby 主机上来刷新或者创建您的物理 standby 数据库。
您可以参考下面的文档：

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ps.htm#i63561
Oracle� Data Guard Concepts and Administration
10g Release 2 (10.2)

http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/create_ps.htm#i63561 Oracle� Data Guard Concepts and Administration
11g Release 1 (11.1)

http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/create_ps.htm#i63561
Oracle� Data Guard Concepts and Administration
11g Release 2 (11.2)

解决方案

问题 1：日志传输问题。

因为主库无法正常传输日志到备库导致 MRP 卡住。可以在主库检查远程归档目标的状态，比如：

SQL> SELECT DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2;

它可能会给出不同的错误，我们需要据此解决日志传输问题。

这里仅仅给出一些特别常见的和密码文件有关的错误，比如 ora-1031，ora-1017，ora-16191，ora-12154 等等。

解决方案1：可以使用 cksum 命令分别在主库和 standby 库所在的主机上验证密码文件的大小，并确认在 11g 和更高的版本上 SEC_CASE_SENSITIVE_LOGON 设置为 false。

- 使用 cksum 命令分别在主库和 standby 库所在的主机上验证密码文件的大小

% cd $ORACLE_HOME/dbs

% cksum <密码文件名字> / cksum 命令只可以在 UNIX 平台上使用/

注意：如果 cksum 在您的 UNIX 平台上不存在，那么参照下面的文档来使用其它命令，比如，SHA-1 和 MD5 checksum 工具。

Note 549617.1 How To Verify The Integrity Of A Patch/Software Download?

如果文件大小是不同的，您需要在主库的一个节点上创建一个新的密码文件，并拷贝到其它节点以及 standby 主机上。

UNIX
orapwd file=$ORACLE_HOME/dbs/orapw password= entries=5

Windows
orapwd file=$ORACLE_HOME/database/PWD.ora password= entries=5

注意：如果 standby 数据库的实例名字和主库的实例名字不同，那么它们的密码文件的名字也需要不同。

您可以通过下面的方式检查本地数据库的实例名字

SQL>show parameter instance_name;

- 对于 11g 以及以上版本的数据库，请确保初始化参数 SEC_CASE_SENSITIVE_LOGON 同时在主库和 standby 上设置为 false。

如果基于安全考虑不得不把 SEC_CASE_SENSITIVE_LOGON 设置为 true，那么在创建密码文件时务必指定 ignorecase=y 参数。比如

orapwd file=$ORACLE_HOME/dbs/orapw password= ignorecase=y entries=5

请参考文档 Note 799353.1 - How to Resolve Error in Remote Archiving for more about log shipping issues。

Adding an new Standby fails with error Ora-12154: TNS:could not resolve the connect identifier specified (Doc ID 1240558.1)

问题 2：防火墙导致归档日志不能被完整传输。

mrp trace 显示：

Media Recovery Log /oracle/archive/ERI3/1_5903.dbf
ORA-00332: archived log is too small - may be incompletely archived
ORA-00334: archived log: '/oracle/archive/ERI3/1_5903.dbf'
Background Media Recovery terminated with error 332
ORA-00332: archived log is too small - may be incompletely archived
ORA-00334: archived log: '/oracle/archive/ERI3/1_5903.dbf'
----- Redo read statistics for thread 1 -----

另一个常见的错误是 ora-3135，建议您检查问题的原因并找到解决方案。

ORA-03135: connection lost contact when shipping redo log to standby database

ORA-03135: connection lost contact

ARC2: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)

解决方案2：请确保以下防火墙功能被禁用。

- SQLNet fixup protocol
- Deep Packet Inspection (DPI)
- SQLNet packet inspection
- SQL Fixup
- SQL ALG (Juniper firewall)

功能的名字和功能可能因供应商而异，但以上所有功能对某些数据包都有一些影响（并非所有数据包都受到影响）。 某些防火墙可能会对通过它们传输的某些 SQL 数据包产生不利影响（某些不是全部）。

您可以按照 Note 1537316.1 Data Guard Gap Detection and Resolution Possibilities 来解决 gap。

请参阅以下与 ora-3135 相关的文章。

Note 404724.1 ORA-03135 when connecting to Database
Note 739522.1 ORA - 03135 connection lost contact while shipping from Primary Server to Standby server
Note 730066.1 Diagnosis of ORA-3135/ORA-3136 Connection Timeouts when the Fault is in the Database
Note 787354.1 Troubleshooting ORA - 3135 Connection Lost Contact

问题 3：由于 bug 6113783，负责网络上的心跳的主库 ARC 进程卡住。

您可以看到不同的症状。 例如，主库 arch 出现 fal 归档错误，并且不会将缺少的归档日志文件发送到 standby 数据库。 最糟糕的情况就是所有的 arch 进程都会出现问题，没有 arch 进程进行本地归档，并且所有联机重做日志文件都已满并导致主库挂起。 请参阅以下与此原因相关的错误。

FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 2262-2266
DBID 2591313681 branch 686760021
FAL[client]: All defined FAL servers have been attempted.

SQL> alter session set nls_date_format='YYYY-MON-DD HH24:MI:SS';
SQL> select message, timestamp
from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp;

MESSAGE
-------------------------------------------------------------------------------
TIMESTAMP
--------------------------
Error 12154 received logging on to the standby
OCT-12-2010 15:55:45

PING[ARC1]: Heartbeat failed to connect to standby 'STDBY'. Error is 12154.
OCT-12-2010 15:55:45

解决方案 3：bug 6113783 在 11.2.0.2 中被修复。您可以通过杀死主库上的 arch 进程来解决问题。

这完全不会损害您的主库，因为 arch 进程会立即被自动重新启动。

% ps -ef |grep -i arc
% kill -9 ...

注意：如果您在 Windows 平台上，您可以使用'orakill'-命令或任何操作系统工具来终止 Windows 线程。

问题 4：Standby recovery 时提示要求已经被应用的归档日志的 sequence#。

a. 这可能是 bug 6029179 引起的，这个 bug 已在 10.2.0.4.1 上解决。
Bug 6029179 Abstract: MRP WAITING FOR LOGS THAT ARE ALREADY APPLIED (with RAC primary)

b. 这可能是因为 Bug 6113783 – 负责 standby heartbeat 的 ARC 进程卡在网络心跳上。

解决方案 4：打补丁 6029179 或者杀掉负责 heartbeat 的 arch 进程（如果是 RAC，那么所有的主库实例的 arch 都需要被杀掉）。

a. 打补丁 Bug 6029179（这个补丁已经包含在 10.2.0.4.1 中）。

b. 可以在主库的 alert log 中找到 heartbeat arch 进程。检查上次启动时的信息，比如：

Starting ORACLE instance (normal)
...
processes = 1800
.....
ARC4 started with pid=27, OS id=8805
ARC2: Archival started
ARC3: Archival started
ARC3: Becoming the 'no FAL' ARCH
ARC3: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
...........
Completed: ALTER DATABASE OPEN

所以这次是 ARC2 负责 heartbeat 工作。当然，上上次的启动信息里可能负责 heartbeat 工作的是其它的 arch 进程。接下来找到 arc2 进程并且杀死它。

% ps -ef |grep -i arc2
% kill -9

注意：如果您在 Windows 平台上，您可以使用'orakill'-命令或任何操作系统工具来终止 Windows 线程。
如果是 RAC 数据库，那么需要对所有的主库的实例都做这样的操作。

c. 最坏的情况则是使用 rman 增量备份的方式来前滚物理 standby 数据库。
如果您的主库比较小，那么可以简单的做一个主库的全库备份并且恢复到 standby 主机上来刷新或者创建您的物理 standby 数据库。

问题 5：恢复是从错误的目录里进行的。

a. 在 10g 或者更低版本里，初始化参数 standby_archive_dest 没有被定义，默认的目录是 $ORACLE_HOME/dbs。

b. 您使用 rman 或者手工的方式来 restore 或者传输归档日志到非 standby 里参数 log_archive_dest_1 或者 standby_archive_dest 定义的目录。

解决方案 5：把物理 standby 的参数 standby_archive_dest 指向 log_archive_dest_1 相同的目录。在手工恢复的语句里使用’location’选项。

a. 对于 10g 或者更低版本的物理 standby 数据库，总是把 standby_archive_dest 指定和 log_archive_dest_1 相同的目录 。

这个参数在 11g 中被废弃。

b. 如果归档日志存放的目录和期望的不同，那么可以在手工恢复的语句中显式指定 'location' 属性。比如

SQL>alter database recover managed standby database cancel;
SQL>alter database recover automatic from '/tmp/archive/' standby database;

/tmp/archive 是归档日志存放的目录。

问题 6：所有的 standby redo 日志文件都处于 active 的状态。

因此 standby 无法从主库上接收新的归档日志。

SQL> select group#,thread#,bytes/1024/1024 as mbytes,used,archived,status
from v$standby_log

GROUP# THREAD# MBYTES USED ARC STATUS

15 2 100 33292288 NO ACTIVE
16 2 100 3323904 NO ACTIVE
17 1 100 98733056 NO ACTIVE
18 2 100 3813376 NO ACTIVE
19 2 100 4763648 NO ACTIVE
...........

38 1 100 98072576 NO ACTIVE
39 2 100 7388672 NO ACTIVE
40 2 100 4899328 NO ACTIVE

Standby alert log 显示：

ORA-16014: log 15 sequence# 13234 not archived, no available destinations
ORA-00312: online log 15 thread 2: '+DG_DATA01/up626dn/onlinelog/group_15.457.
682446507'
ORA-00312: online log 15 thread 2: '+DG_DATA01/up626dn/onlinelog/group_15.456.
682446509'
ORA-00312: online log 15 thread 2: '+DG_FRA01/up626dn/onlinelog/group_15.490.
682446509'

解决方案 6：请确保 archive 目录上有足够的空间。 log_archive_dest_1 的定义中包含准确的 valid_for 以及 db_unique_name。 standby_archive_dest 被正确指定。

a. 请确保 log_archive_dest_1 指定的本地归档目录有足够的空间，这样 standby redo 日志才能被归档。
请同时确保 standby_archive_dest 指定的目录有足够的空间，这样主库的 arch 进程可以成功把归档日志发送到对应的目录。
当 log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST...'，您需要检查初始化参数 db_recovery_file_dest 指定的目录。比如：

log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(ALL_LOGFILE,ALL_ROLES)
db_unique_name=BOSTON'

db_recovery_file_dest=+DG_FRA01
db_recovery_file_dest_size=214748364800

b. 请确保本地归档目录 log_archive_dest_1 包含有 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 和 DB_UNIQUE_NAME=。
比如：

Oracle® Data Guard Concepts and Administration
3 Creating a Physical Standby Database

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME='

c. 请在 standby 数据库上正确设置 standby_archive_dest。比如，

STANDBY_ARCHIVE_DEST=/arch1/boston/

当 LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME='，您指定 STANDBY_ARCHIVE_DEST='LOCATION=USE_DB_RECOVERY_FILE_DEST'。

初始化参数 standby_archive_dest 已在 11g 中被废弃。

您可以使用 alter system 命令修改或者定义 LOG_ARCHIVE_DEST_1 或者 STANDBY_ARCHIVE_DEST。
如果数据库是 RAC 数据库，那么需要使用选项 sid='*'，这样修改可以在 RAC 所有的实例上生效。比如，

SQL>alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=BOSTON' scope=both sid='*';

如果您使用了 data guard broker，那么在执行下面的命令前需要先停掉 broker。比如，

SQL>alter system set dg_Broker_start=false sid='*' scope=both;

在修改完成后，再启动 broker

SQL>alter system set dg_Broker_start=true sid='*' scope=both;

SQL>alter system set standby_archive_dest = 'LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=both sid='*';

如果'scope'没有显式指定，那么默认值是'both'。

如果使用 broker，您需要修改 StandbyArchiveLocation：

DGMGRL> EDIT DATABASE '' SET PROPERTY 'StandbyArchiveLocation'='LOCATION=USE_DB_RECOVERY_FILE_DEST';

如果 standby 数据库是 RAC 数据库，那么需要在所有的 standby 实例执行这些命令。

d. 请确保 standby 数据库上的 standby redo 日志大小和主库的在线日志文件大小一致；并且对于每一个 thread，在 standby 数据库上的 standby redo 日志组比主库上的在线日志多一组。比如，如果您在主库上有2个 threads，每个thread 有3组在线日志，那么对于 thread 1，您需要4个 standby redo 日志组，对于 thread 2 需要4个 standby redo 日志组，不管 standby 数据库上有多少实例。

如果发生切换数据库的角色改变，这个原理仍然适用。比如，如果当前 standby 数据库只有一个实例，三组在线日志文件，那么当前的主库您需要4组 standby 日志组，不管主库有多少实例。

参照：

MAA - Creating a RAC Physical Standby for a RAC Primary (Doc ID 380449.1)

e. 请清除所有的 standby 日志组

SQL> alter database clear standby logfile group <#>;

问题 7：缺损的归档日志文件应用于备用数据库。

standby alert 日志显示：

Fri Jan 9 20:11:18 2009
MRP0: Background Managed Standby Recovery process started (arrap)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 7 processes
Media Recovery Log /u150/backup/archive/arrap/arprd-656901558185964.arc
Fri Jan 9 20:11:24 2009
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
SESSION
Fri Jan 9 20:11:24 2009
Incomplete Recovery applied until change 14025537844
Fri Jan 9 20:11:24 2009
MRP0: Media Recovery Complete (arrap)
Fri Jan 9 20:11:26 2009
MRP0: Background Media Recovery process shutdown (arrap)

可以查询 v$archived_log 来找到哪个归档日志包含 change# 14025537844 。

SQL>select thread#, sequence#, name, first_change#, next_Change#, deleted, status from v$archived_log where 14025537844 between first_change# and next_Change#;

解决方案 7：可以使用 rman 增量备份的方式来前滚物理 standby 数据库。

如果您的主库比较小，那么可以简单的做一个主库的全库备份并且恢复到 standby 主机上来刷新或者创建您的物理 standby 数据库。

为了避免问题再次发生，请在取消物理 standby 数据库的自动恢复前或者关闭物理 standby 数据库前执行下面的操作。

a. 在主库上把远程日志传输设置为 Defer。比如，如果 log_archive_dest_2 设置的是远程归档目录，

SQL>alter system set log_archive_dest_state_2=defer; （单实例数据库）
SQL>alter system set log_archive_dest_state_2=defer sid='*'; （RAC 主库）

b. 请确保备库上已经恢复了最后收到的归档日志。
可以检查 log_archive_dest_1 或者 standby_archive_dest 设置的目录来检查最近收到的归档日志。
然后在 standby 上执行下面的语句检查最近应用的归档日志 sequence 号码：

SQL>select thread#, max(sequence#) from v$archived_log where applied='YES' group by thread#;

问题 8：归档日志不是通过 dataguard 日志传输服务传输的，而是手工拷贝的。

所以它们并没有被注册到 standby 控制文件，而 MRP (Managed Recovery Process) 也不能识别它们。
比如它们是通过 ftp 或者 scp 等传输的，或者通过 rman 备份又恢复到 standby。

standby alert 日志显示：

Media Recovery Waiting for thread 1 sequence 13615 (in transit)

解决方案 8：注册这些归档日志或者手工恢复。

a. 注册这些手工传输过来的归档日志，并且自动恢复它们。

SQL> alter database recover managed standby database cancel;
SQL> alter database register logfile '<full path/archive log file name>';

或者可以使用 rman 命令来编目所有的手工传输过来需要添加到 standby 控制文件中的归档日志。

rman> catalog start with 'PATH_TO_ARCHIVELOGS/';

SQL> alter database recover managed standby database disconnect;

b. 如果要注册的归档日志太多，那么可以不注册它们而直接手工恢复。确保这些归档日志都存放在 log_archive_dest_1 或者 standby_archive_dest 对应的目录里。 如果不能做到的话，那么可以在手工恢复的命令里直接指定'location'参数。

SQL> alter database recover managed standby database cancel;
SQL> alter database recover automatic standby database;
或者
SQL> alter database recover automatic from '/tmp/archive/' standby database;

问题 9：归档日志被传输应用到 standby 备库前就被删除。

使用 rman 备份，导致归档日志被传输到 standby 前就被删除了。

解决方案 9：从备份中恢复归档日志，注册并且恢复它们。或者不注册直接手工恢复。

具体步骤请参照解决方案8。

如果无法找到归档日志，那么需要 rman 增量备份的方式来前滚物理 standby 数据库。

如果您的主库比较小，那么可以简单的做一个主库的全库备份并且恢复到 standby 主机上来刷新或者创建您的物理 standby 数据库。

为了避免问题再次发生，请考虑设置 rman 删除策略。

如果归档日志被存放在 flash recovery area，那么你可以把 rman 删除策略设置为 APPLIED ON STANDBY，这样只有在归档日志应用到 standby 数据库之后才会被删除。

具体步骤请参考下面的文档：

Configure RMAN to purge archivelogs after applied on standby (Doc ID 728053.1)

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rman.htm#SBYDB00750

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。