本文是Oracle support对11GR2 RMAN备份过程中的问题总结
11GR2 中的常见 RMAN 问题
11gR2 中少数几个结构更改对 RMAN 设置产生了广泛的影响
1. Snapshot/Backup（快照/备份）控制文件位置必须位于 RAC 环境中的共享位置。
在 11gR2 及更高版本号中，控制文件的备份在运行时不会持有 CF enqueue。
对于非 RAC 数据库，这不会造成不论什么影响。可是，对于 RAC数据库，因为在 11gR2 中控制文件备份机制发生了更改，集群中的不论什么实例都能够写入到 snapshot/backup（快照/备份）控制文件。因此，Snapshot（快照）控制文件须要对全部实例都可见。从 SQL*Plus 直接创建控制文件的备份时也存在这样的情况。
集群中的不论什么实例都能够写入到备份控制文件。
控制文件备份，即使使用 SQL“alter database backup controlfile...”。也必须在共享设备上创建备份。
Snapshot（快照）控制文件必须可由 RAC 数据库的全部节点訪问；假设 snapshot（快照）控制文件不在共享设备上，则在 RMAN备份获取控制文件的 snapshot（快照）时会引发错误。这适用于使用 SQL*Plus 备份控制文件和在非共享位置配置了控制文件自己主动备份的情况。
RMAN-00571: ========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: =========================================================
RMAN-03009: failure of resync command on default channel at 03/13/2012 10:19:41
ORA-00245: control file backup operation failed
解决方式是将 Snapshot/backup（快照/备份）控制文件位置更改到共享设备上。否则将会失败。并出现 ORA-245: control file backup operation failed。
提醒：Note 1472171.1 In RAC environment from 11.2 onwards Backup Or Snapshot controlfile needs to be in shared location 是针对此问题而公布的。
2. MMON 进程在结构发生变化之后自己主动进行控制文件备份
在 11GR2 之前的发行版中，更改数据库结构的每一个 DDL 命令都会创建一个控制文件自己主动备份。在 alert.log 中能够看到。运行每一个 DDL 命令之后都会有一条关于控制文件自己主动备份创建的消息。在同一时候进行多个结构更改时。这可能会导致严重的性能问题。
从 Oracle Database 11g 发行版 2 開始实施了 Controlfile Autobackup Deferral 功能。在应用的脚本中包括多个结构更改时（比如。加入表空间、变更表空间或数据文件的状态、加入新的联机重做日志、重命名文件等），RMAN 仅仅进行一次控制文件自己主动备份。在 11gR2 中。控制文件自己主动备份由 MMON 从属进程在结构更改后的几分钟时间内创建。这能够提升性能。因此，在对数据库的结构更改数分钟之后获取控制文件自己主动备份是正常行为。同一时候在 alert.log 中不显示有关控制文件自己主动备份创建的消息也是正常的。
负责怪份控制文件的 MMON 从属进程会产生包括了创建控制文件所需信息的跟踪文件并命名为：<SID>_m000_<OS_PID>.trc
3. 能够在磁盘上运行恢复区备份
在 11gR2 之前。仅仅能在磁带上运行 Flash Recovery Area（高速恢复区，简称 FRA）的备份。
从 11GR2 開始，能够在磁盘上运行 FRA备份。
BACKUP 命令中加入了“TO DESTINATION”子句。这个加入的选项可指定特定文件夹位置，以便备份到磁盘。该选项主要用于 BACKUP RECOVERY AREA 命令。假设启用了 BACKUP OPTIMIZATION，则 RMAN 仅跳过已存在于“TO DESTINATION”子句所指定文件夹位置中同样文件的备份。
RMAN> Backup recovery area TO DESTINATION ‘+DATA’;
11GR2 中影响 RMAN 稳定性的常见 BUG。
1. BUG 9877980: SR11.2.0.2CSHAR_FORCE - TRC - KKSLMARKLITERALBINDS
症状：
数据库版本号：11.2.0.2。CURSOR_SHARING 为 FORCE 或 SIMILAR
RMAN 备份失败。出现 ORA-01008，或者显示各种错误
DBGSQL: TARGET> select count(*) into :dbstate from v$parameter where lower(name) = '_dummy_instance' and upper(value) = 'TRUE'
DBGSQL: sqlcode = 1008
RMAN-00571: =========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ==============
RMAN-00571: =========================================================
ORA-01008: not all variables bound
或者
RMAN-00571: =====================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ============
RMAN-00571: =====================================================
RMAN-03002: failure of allocate command at 12/07/2011 00:38:14
ORA-03114: not connected to ORACLE
而且 alert.log 中显示
ORA-07445: exception encountered: core dump [kkslMarkLiteralBinds()+240] [SIGBUS] [ADDR:0x18222D0202020D29] [PC:0x1049E96D0] [Invalid address alignment] []
或者
ORA-07445: exception encountered: core dump [kkslpli()+212] [SIGSEGV] [ADDR:0xFFFFFFFF7A973288] [PC:0x1049FEE14] [Invalid permissions for mapped object] []
根本原因是 BUG 9877980。此 Bug 的修复包括在 11.2.0.3 中。
此 Bug 有one-off patch可用。
Workaround: 清空共享池
Ref:
Bug 9877980 - ORA-7445[kkslMarkLiteralBinds] / Assorted Errors on 11.2.0.2 if cursor sharing is enabled Note 9877980.8
Alert: Note 1472116.1 RMAN backup fails with Assorted Errors on 11.2.0.2 if cursor sharing is enabled
2. Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT
假设控制文件自己主动备份目标文件系统为 NFS，则要求使用“NOAC”选项装载该文件系统；否则将报错 ORA-27054
症状：
假设 snapshot（快照）控制文件定位到 NFS 文件系统而且不是使用选项“NOAC”装载的，则 RMAN 备份将失败，并出现 ORA-27054 错误。依据 Bug 5064356 的修复，假设运行的是 10.2.0.4.0 或更高版本号，则不再须要 NFS 装载点的 NOAC 选项。
可是。此修复似乎仅适用于特定文件类型。也就是：联机重做日志、归档重做日志、备份片（比如：RMAN）和跟踪文件。
Starting Control File and SPFILE Autobackup at 07-APR-12
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 04/07/2012 10:29:17
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not
mounted with correct options
Additional information: 3
在 alert.log 文件里
Starting control autobackup
WARNING:NFS file system /oracle/product mounted with incorrect options
WARNING:Expected NFS mount options:
rsize>=32768,wsize>=32768,hard, actimeo=0
Autobackup failed with following error
ORA-1580: error creating control backup file
/oracle/product/10.2.0/db_1/dbs/snapcf_COPA1.f
ORA-27054: NFS file system where the file is created or resides is not mounted with correct options
Additional information: 3
出现此问题是因为 Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT. 此 Bug 已在 11.2.0.2 中修复
Workaround:
1) 对于保存snapshot（快照）控制文件的 NFS 文件系统。使用 NOAC 选项装载。
或者
2) 将 snapshot（快照）控制文件的位置更改到非 NFS。
Ref: Bug 8482162 Snapshot controlfile still needs "noac" on NFS mount points (ORA-27054) Note 8482162.8
3. Bug 9577583: FALSE ORA-942 OR OTHER ERRORS WITH MULTIPLE SCHEMAS HAVING IDENTICAL OBJECTS
当 RMAN 文件夹数据库（catalog）保存了多个 RMAN 文件夹 schema（方案）时，文件夹数据库上将提醒出现错误 ORA-00942。
症状：
用户发现多个 ORA-942 错误
不论什么在多个 schema（方案）下有同名对象的数据库都可能会遇到此问题。
这是间歇性问题。无法重现。但会多次出现。
这是通用的 Bug，主要影响 RMAN 文件夹备份。影响 11.2.0.1，在 11.2.0.2 中已提供了修复。
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03015: error occurred in stored script incremental_level0
RMAN-03002: failure of backup command at 06/25/2010 13:21:22
RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
RMAN-06031: could not translate database keyword
Debug跟踪信息显示
DBGSQL: EXEC SQL AT RCVCAT begin dbms_rcvman . translateDatabase ; end ; [13:21:22.794]
DBGSQL: sqlcode=-942 [13:21:22.795]
DBGMISC: krmksqlerror called from file krmk.c, line 12649 [13:21:22.796]
DBGRCVMAN: ENTERING translateDatabase
DBGRCVMAN: ENTERING validateState
DBGRCVMAN: EXITING validateState validateState
DBGRCVMAN: OPENING cursor translateDatabase_c in translateDatabase
DBGMISC: krmicomp: error 6004 signalled during compilation [13:21:22.797]
DBGMISC: ENTERED krmkmrsr [13:21:22.797]
RMAN-06004: ORACLE error from recovery catalog database: ORA-00942: table or view does not exist
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 4590
ORA-06512: at "CALYPP.DBMS_RCVMAN", line 16168
ORA-06512: at line 1
RMAN-06097: text of failing SQL statement: begin dbms_rcvman . translateDatabase ; end ;
RMAN-06099: error occurred in source file: krmk.pc, line: 7618
RMAN-06031: could not translate database keyword
解决方式：
应用针对 Bug 9577583 的 Patch 9577583
Ref: Note 9577583.8 False ORA-942 or other errors when multiple schemas have identical object names.
4. BUG 10635701 - BACKUP OF FRA CONSUMES 15GB OF PGA AND FAIL WITH ORA-4030
RMAN 在备份大量文件时。会因为消耗过多内存而失败，并出现 ORA-4030。错误出如今heap（堆）KSFQ，当中包括带有凝视“KSFQ Buffers”的块。
影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中修复
症状：
RMAN 跟踪信息显示下面 function（函数）中出错。
dbms_backup_restore.validationvalidate。带有相似下文的跟踪行：
krmxrpc - channel t1 kpurpc2 err=4030 db=target proc=SYS.DBMS_BACKUP_RESTORE.VALIDATIONVALIDATE
失败进程的调用堆栈：
kghalf <- ksfqbalo <- ksfqbcre <- ksfqxc <- ksfqxcrx <- ksfqxcre <- krbrvv
分配的内存为 KSFQ的 heap（堆）。当中 KSFQ heap（堆）包括带有凝视“KSFQ Buffers”的块。该信息会被转储到错误 ORA-4030 生成的跟踪文件里
下面文件里的错误： /cihcissdb028/dump01/oracle/dxls/udump/diag/rdbms/dxls/dxls/incident/incdir_68404/dxls_ora_27140_i68404.trc:
ORA-04030: out of process memory when trying to allocate 824492 bytes (pga heap,kco buffer)
ORA-04030: out of process memory when trying to allocate 1052684 bytes (KSFQ heap,KSFQ Buffers)
解决方式：
应用 Patch 10635701， 这个问题没有办法绕过。
影响 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中包括修复。
Ref: Note 10635701.8 RMAN backup many files consumes lots of PGA / fails with ORA-4030
5. BUG 12370722 - CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]
升级到 11.2.0.2 之后。归档进程持续引发 ORA_0600 [krr_highest_scn_tim_8]。升级之后在 11.2.0.2 中报错。影响升级，导致停机。解决方法是清除联机重做日志。此问题已在 11.2.0.3 中修复。
下面列出的 Bug。其症状相似于父 bug 12370722
Bug 11872889: ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [KRR_HIGHEST_SCN_TIM_8]
Bug 12534566: DATABASE OPEN FAILED ORA-00600 [KRR_HIGHEST_SCN_TIM_8]
Bug 11062394: ORA-600 [KRR_HIGHEST_SCN_TIM_8] REPORTED BY AN ARCHIVER PROCESS
全部这些 Bug 均已关闭。与下面 Bug 反复：
Bug 12370722: CATUPGRD.SQL HANGS WITH ARCH ERROR ORA-600 [KRR_HIGHEST_SCN_TIM_8]
症状：
查找错误：
?运行 Oracle 版本号 11.2.0.2
?数据库最近从 10.2（或 10.1）升级到 11.2.0.2，为确认这一点。11.2.0.2 alert log 应显示“ALTER DATABASE OPEN MIGRATE”。
归档进程定期（比如每分钟）报错 ORA-00600:[krr_highest_scn_tim_8]。然后终止，调用堆栈例如以下：
-> ksbrdp -> krsv_abs -> ksbabs -> kcrrwk -> kcrrwkx -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]
或者
尝试打开数据库的进程报错 ORA-00600:[krr_highest_scn_tim_8]。调用堆栈例如以下：
-> adbdrv -> kcfopd -> kcttsc -> krsq_arch_to_force_ -> krse_arc_driver -> krse_arc_driver_cor -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]
或者
运行 alter system archive log all; 的进程报错 ORA-00600:[krr_highest_scn_tim_8]。调用堆栈例如以下：
-> kkyasy -< krsq_arch_all_or_next -> krsq_arch_one_log -> krse_arc_driver->krse_arc_driver_core -> krse_arc_spool -> krr_highest_scn_tim -> ora600:[krr_highest_scn_tim_8]
一个特定联机重做日志未归档，下面查询会显示未归档的日志序列号：
SQL> select sequence# from v$log where archived='NO' and status = 'CURRENT';
错误：
RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of sql command on default channel at 05/20/2011 01:26:24
RMAN-11003: failure during parse/execution of SQL statement: alter system archive log current
ORA-00600: internal error code, arguments: [krr_highest_scn_tim_8], [], [], [], [], [], [], [], [], [], []
Workaround:
为防止出现 ORA-00600:[krr_highest_scn_tim_8]，请在開始升级到 11.2.0.2 之后。不要返回并使用 Oracle 版本号 10 打开数据库。
假设数据库因为无法切换到下一个（未归档的）联机重做日志而挂起，或者因为前台进程尝试归档联机重做日志并出现 ORA-00600:[krr_highest_scn_tim_8] 错误而终止，导致无法打开数据库，则尝试加入还有一个重做日志组
SQL> startup mount
alter database add logfile group <n> ('<filename>') size <x>M;
假设已经报错 ORA-00600:[krr_highest_scn_tim_8]，而且定期持续报错，则能够通过下面方法之中的一个来解决：
- 安装补丁程序，
- 或者通过下面方法清除联机重做日志：
SQL> select group# from v$log
where archived='NO' and status = 'CURRENT';
alter database clear logfile group <group#>;
注：清除联机重做日志表示该序列号的日志中的重做无法用于恢复。因此应该在清除日志之后尽可能早地运行完整备份。
6. BUG 10170431 - CTWR CONSUMING LOTS OF CPU CYCLES
假设启用了 Block Change Tracking（块更改跟踪，简称 BCT）。则 CTWR进程会消耗 CPU，而数据库总体性能将会受到严重影响。
这样的现象会在 11.2.0.2 中发生，解决方法是禁用块更改跟踪或应用one-off补丁程序。
该问题已在 11.2.0.3 中修复
症状：
在最低负载的情况下，CTWR 后台进程消耗 90% 到 100% 的 CPU。
ALTER SYSTEM CHECKPOINT 会显著减少 CTWR CPU 负载。稍后将返回到 90% 到 100% CPU 负载（CTWR处理块更改之后）。这样的现象非常有可能也是这个问题。
CTWR 的调用堆栈非常可能显示在下面函数中不断循环（spinning）：
kcmgtsf ()
krcptmo ()
ksbabs ()
krcpabs ()
ksbrdp ()
Workaround: 禁用 BLOCK CHANGE TRACKING (BCT) 或者应用针对 bug 10170431 的 Patch 10170431。
7. BUG 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE
RMAN备份或者又一次同步RMAN文件夹（resync catalog）命令失败，出现错误RMAN-20052: invalid datafile create SCN
将数据文件加入到transportable表空间，然后恢复文件夹出现故障。
因为插入(plug in) SCN 为零。导致在尝试使用恢复文件夹时出现故障。
解决方法是应用 patch 13000553.
Bug 13877582 - RMAN SOME DATAFILES AT STANDBY SITE APPEAR WITH NULL NAME
发现与下面 Bug 反复：
Bug 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE
症状：
目标数据库是 dataguard（物理备用）环境
表空间已插入(plug in)了主数据库。
插入(plug in)表空间之后，一些数据文件被加入到当中。
恢复文件夹为 11.2.0.3
已在下面版本号中修复：12.1
解决方式
在恢复文件夹数据库中应用 patch 13000553，并在主网站与备用网站之间又一次同步文件夹。假设在应用补丁之后，文件名称仍显示为空白。则又一次创建恢复文件夹，在新文件夹中注冊主网站。然后将备用网站与新文件夹又一次同步。
Ref:
Note 1446934.1 Some Datafiles At Standby Site Appear With NULL Name in RMAN
Note 1411883.1 RMAN-20052: invalid datafile create SCN During Resync or Backup using Recovery Catalog 11.2.0.3
8. BUG 12312133 - RMAN INCREMENTAL BACKUP WITH BLOCK CHANGE TRACKING MAY CAUSE STANDBY DB CRASH
假设在备用数据库上启用了 BCT 而且 RMAN 运行增量备份，则 CTWR 会使备用数据库出现 ORA-0600[krcccb_busy]，并崩溃。此问题影响 11.2.0.2、11.2.0.3。绕过问题的方法是禁用块更改跟踪。
症状：
在备用数据库上启用了 BCT
RMAN 运行增量备份。
CTWR会出现 ora-0600[krcccb_busy]。使备用数据库崩溃。
Errors in file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_ctwr_499736.trc:
ORA-00600: internal error code, arguments: [krcccb_busy], [], [], [], [], [], [], [], [], [], [], []
CTWR (ospid: 499736): terminating the instance due to error 487
System state dump requested by (instance=1, osid=499736 (CTWR)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/oracle/diag/rdbms/mbcdwps/MBCDWPS1/trace/MBCDWPS1_diag_1884206.trc
Workaround: 解决方法：禁用块更改跟踪。应用 patch 12312133
Ref: Note 12312133.8 Standby DB crashes with ORA-600 [krcccb_busy] /Ora-00600 [krccckp_scn] with block change tracking
9. BUG 10318078 - RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY
在 11.2 中，RMAN 到磁带的备份成功完毕并退出 RMAN 时生成 core dump。
症状：
Backup（备份）成功完毕, RMAN 退出时，生成core dump（转储）。
core stack（堆栈）显示：/oracle/movt/11G/app/product/release/lib/libskgxp11.so
Workaround: 将 Oracle 可运行文件与 Media Manager API 库的静态版本号链接，而不是动态链接库
关闭全部使用此 ORACLE_HOME 的实例
% cd $ORACLE_HOME/rdbms/lib
% make -f ins_rdbms.mk ioracle LLIBMM=/usr/lib/libnwora.a
% ln -s /usr/lib/libnwora.so libobk.so
使用静态链接的库“libnwora.a”而不是动态库“libnwora.so”
Ref: Note 1296704.1 RMAN COREDUMPS ON EXIT : BACKUP (TO TAPE) COMPLETES SUCCESFULLY.
解决方式：
应用针对 Bug:10318078 的修复
Patch 11774404: TRACKING BUG FOR 10318078 FOR AIX11.2- 212 - IBM AIX on POWER Systems (64-bit)
Patch 11774413: TRACKING BUG FOR 10318078 FOR SOLARIS SPARC64
10. BUG 13602883 - BLOCK CHANGE TRACKING NOT USED FOR INCREMENTAL BACKUPS
症状：
假设在数据库（cluster_database=TRUE）运行期间意外禁用了增量备份的块更改跟踪 (BCT)、RMAN 会话或实例在上一次备份期间终止，而且 RDBMS 发行版早于 11.2.0.4，则可能命中这个 Bug。
该 Bug 影响 11.2.0.2/3（也可能影响更早的版本号），随意平台都可能发生。可是。它仅仅影响 RAC。即数据库设置了參数 cluster_database=true。
该 Bug 已在 11.2.0.4 及更高版本号中修复。
11. MML 不兼容问题：使用 Oracle 11.2 运行 RMAN备份或恢复到磁带的操作期间出现 ORA-07445 [Strcpy()+48]
不兼容的 MML 软件在使用 RMAN备份数据库时将导致 core dump。alert.log 中报告 core dump 错误 ORA-07445 [Strcpy()]。而且备份通道意外终止。
症状：
Errors in file /apps/oh/admin/PPMP/bdump/diag/rdbms/ppmp/PPMP/trace/PPMP_ora_32421.trc (incident=29135):
ORA-07445: exception encountered: core dump [strcpy()+16] [SIGSEGV] [ADDR:0x9] [PC:0x3E2B170D00] [Address not mapped to object] []
RMAN-00571: =======================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03009: failure of backup command on t1 channel at 11/18/2011 23:13:19
RMAN-10038: database session for channel t1 terminated unexpectedly
Call Stack（调用堆栈）：
__restore_rt strcpy put_string send_bprdreq bprd_get_features bsa_checkFeatureIdVxBSAValidateFeatureId xbsa_ValidateFeatureId int_StartJob sbtbackup skgfqcre ksfq_cre ksfqfcrx krbbOpenOutput krbbpc krbibpc
Ref: Note 959015.1 ORA-07445 [Strcpy()+48] during RMAN backup or restore to tape using Oracle 11.2
解决方式：
检查 MML 软件与 11.2 的兼容性。 如需帮助。请联系供应商技术支持
比如：在下面网址能够找到与 Veritas netbackup 相关的具体信息
http://www.symantec.com/business/support/index?page=content&id=TECH77071
12. Bug 11694127 - RMAN DUPLICATE not honoring TIME portion of date for "UNTIL TIME" [ID 11694127.8]
症状：
DUPLICATE 期间，当 NLS_DATE_FORMAT 不包括 TIME 规范时。
UNTIL TIME 将被截断。
因此，构建的duplicate数据库可能会处于错误的时间点
比如：
假设 RMAN 复制使用命令： set until time "to_date('Jan 27 2011 17:05:00','Mon DD YYYY HH24:MI:SS')";
alert.log 文件将显示： start until time 'JAN 27 2011 00:00:00' using backup controlfile
Rediscovery Notes:
恢复期间 DUPLICATE 失败。原因是 NLS_DATE_FORMAT 不包括 TIME 部分，导致 UNTIL TIME 被截断。
Workaround
将 NLS_DATE_FORMAT 设置为具有时间精度的格式，然后
使用 UNTIL TIME 运行 RMAN 复制命令。
演示样例：
setenv NLS_DATE_FORMAT 'DD-MON-YYYY HH24:MI:SS'
setenv NLS_LANG 'AMERICAN_AMERICA.UTF8'
使用 RMAN 连接到目标和 auxiliary(辅助)实例
运行带有 UNTIL TIME 的 RMAN 复制命令
有关受影响/修复的版本号。请參阅： Note 11694127.8