本文是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