11GR2 中的常见 RMAN 问题
本文是Oracle support對11GR2 RMAN備份過程中的問題總結
11GR2 中的常見 RMAN 問題
?
11gR2 中少數(shù)幾個結構更改對 RMAN 設置產(chǎn)生了廣泛的影響
?
1. Snapshot/Backup（快照/備份）控制文件位置必須位于 RAC 環(huán)境中的共享位置。
?
在 11gR2 及更高版本中，控制文件的備份在執(zhí)行時不會持有 CF enqueue。對于非 RAC 數(shù)據(jù)庫，這不會造成任何影響。但是，對于 RAC數(shù)據(jù)庫，由于在 11gR2 中控制文件備份機制發(fā)生了更改，集群中的任何實例都可以寫入到 snapshot/backup（快照/備份）控制文件。因此，Snapshot（快照）控制文件需要對所有實例都可見。從 SQL*Plus 直接創(chuàng)建控制文件的備份時也存在這種情況。集群中的任何實例都可以寫入到備份控制文件。控制文件備份，即使使用 SQL“alter database backup controlfile...”，也必須在共享設備上創(chuàng)建備份。
?
Snapshot（快照）控制文件必須可由 RAC 數(shù)據(jù)庫的所有節(jié)點訪問；如果 snapshot（快照）控制文件不在共享設備上，則在 RMAN備份獲取控制文件的 snapshot（快照）時會引發(fā)錯誤。這適用于使用 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（快照/備份）控制文件位置更改到共享設備上，否則將會失敗，并出現(xiàn) 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 是針對此問題而發(fā)布的。
?
?
?
2. MMON 進程在結構發(fā)生變化之后自動進行控制文件備份
?
在 11GR2 之前的發(fā)行版中，更改數(shù)據(jù)庫結構的每個 DDL 命令都會創(chuàng)建一個控制文件自動備份。在 alert.log 中可以看到，執(zhí)行每個 DDL 命令之后都會有一條關于控制文件自動備份創(chuàng)建的消息。在同時進行多個結構更改時，這可能會導致嚴重的性能問題。
?
從 Oracle Database 11g 發(fā)行版 2 開始實施了 Controlfile Autobackup Deferral 功能。在應用的腳本中包含多個結構更改時（例如，添加表空間、變更表空間或數(shù)據(jù)文件的狀態(tài)、添加新的聯(lián)機重做日志、重命名文件等），RMAN 只進行一次控制文件自動備份。在 11gR2 中，控制文件自動備份由 MMON 從屬進程在結構更改后的幾分鐘時間內(nèi)創(chuàng)建，這可以提升性能。因此，在對數(shù)據(jù)庫的結構更改數(shù)分鐘之后獲取控制文件自動備份是正常行為，同時在 alert.log 中不顯示有關控制文件自動備份創(chuàng)建的消息也是正常的。
?
負責備份控制文件的 MMON 從屬進程會產(chǎn)生包含了創(chuàng)建控制文件所需信息的跟蹤文件并命名為：<SID>_m000_<OS_PID>.trc
?
?
?
3. 可以在磁盤上執(zhí)行恢復區(qū)備份
?
在 11gR2 之前，只能在磁帶上執(zhí)行 Flash Recovery Area（快速恢復區(qū)，簡稱 FRA）的備份。從 11GR2 開始，可以在磁盤上執(zhí)行 FRA備份。BACKUP 命令中添加了“TO DESTINATION”子句。這個添加的選項可指定特定目錄位置，以便備份到磁盤，該選項主要用于 BACKUP RECOVERY AREA 命令。如果啟用了 BACKUP OPTIMIZATION，則 RMAN 僅跳過已存在于“TO DESTINATION”子句所指定目錄位置中相同文件的備份。
?
RMAN> Backup recovery area TO DESTINATION ‘+DATA’;
?
?
11GR2 中影響 RMAN 穩(wěn)定性的常見 BUG。
?
1. BUG 9877980: SR11.2.0.2CSHAR_FORCE - TRC - KKSLMARKLITERALBINDS
?
癥狀：
?
數(shù)據(jù)庫版本：11.2.0.2，CURSOR_SHARING 為 FORCE 或 SIMILAR
?
RMAN 備份失敗，出現(xiàn) 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
?
如果控制文件自動備份目標文件系統(tǒng)為 NFS，則要求使用“NOAC”選項裝載該文件系統(tǒng)；否則將報錯 ORA-27054
?
癥狀：
?
如果 snapshot（快照）控制文件定位到 NFS 文件系統(tǒng)并且不是使用選項“NOAC”裝載的，則 RMAN 備份將失敗，并出現(xiàn) ORA-27054 錯誤。根據(jù) Bug 5064356 的修復，如果運行的是 10.2.0.4.0 或更高版本，則不再需要 NFS 裝載點的 NOAC 選項。但是，此修復似乎僅適用于特定文件類型，也就是：聯(lián)機重做日志、歸檔重做日志、備份片（例如：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
?
?
?
出現(xiàn)此問題是因為 Bug 8482162: SNAPSHOT CONTROLFILE STILL NEED NOAC ON NFS MOUNT POINT. 此 Bug 已在 11.2.0.2 中修復
?
Workaround:
?
1) 對于保存snapshot（快照）控制文件的 NFS 文件系統(tǒng)，使用 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 目錄數(shù)據(jù)庫（catalog）保存了多個 RMAN 目錄 schema（方案）時，目錄數(shù)據(jù)庫上將提醒出現(xiàn)錯誤 ORA-00942。
?
癥狀：
?用戶發(fā)現(xiàn)多個 ORA-942 錯誤
?任何在多個 schema（方案）下有同名對象的數(shù)據(jù)庫都可能會遇到此問題。
?這是間歇性問題，無法重現(xiàn)，但會多次出現(xiàn)。
?這是通用的 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 在備份大量文件時，會由于消耗過多內(nèi)存而失敗，并出現(xiàn) ORA-4030。錯誤出現(xiàn)在heap（堆）KSFQ，其中包含帶有注釋“KSFQ Buffers”的塊。影響 11.2.0.1 和 11.2.0.2，已在 11.2.0.3 中修復
?
癥狀：
?
RMAN 跟蹤信息顯示以下 function（函數(shù)）中出錯。
?
dbms_backup_restore.validationvalidate，帶有類似下文的跟蹤行：
krmxrpc - channel t1 kpurpc2 err=4030 db=target proc=SYS.DBMS_BACKUP_RESTORE.VALIDATIONVALIDATE
?
失敗進程的調(diào)用堆棧：
?
????????????? kghalf <- ksfqbalo <- ksfqbcre <- ksfqxc <- ksfqxcrx <- ksfqxcre <- krbrvv
?
分配的內(nèi)存為 KSFQ的 heap（堆），其中 KSFQ heap（堆）包含帶有注釋“KSFQ Buffers”的塊。該信息會被轉(zhuǎn)儲到錯誤 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 之后，歸檔進程持續(xù)引發(fā) ORA_0600 [krr_highest_scn_tim_8]。升級之后在 11.2.0.2 中報錯；影響升級，導致停機，解決方法是清除聯(lián)機重做日志。此問題已在 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
??數(shù)據(jù)庫近期從 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]，然后終止，調(diào)用堆棧如下：
-> 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]
?
或者
?
嘗試打開數(shù)據(jù)庫的進程報錯 ORA-00600:[krr_highest_scn_tim_8]，調(diào)用堆棧如下：
-> 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]
?
或者
?
執(zhí)行 alter system archive log all; 的進程報錯 ORA-00600:[krr_highest_scn_tim_8]，調(diào)用堆棧如下：
?
-> 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]
?一個特定聯(lián)機重做日志未歸檔，以下查詢會顯示未歸檔的日志序列號：
?
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:
?
為防止出現(xiàn) ORA-00600:[krr_highest_scn_tim_8]，請在開始升級到 11.2.0.2 之后，不要返回并使用 Oracle 版本 10 打開數(shù)據(jù)庫。
?
如果數(shù)據(jù)庫由于無法切換到下一個（未歸檔的）聯(lián)機重做日志而掛起，或者由于前臺進程嘗試歸檔聯(lián)機重做日志并出現(xiàn) ORA-00600:[krr_highest_scn_tim_8] 錯誤而終止，導致無法打開數(shù)據(jù)庫，則嘗試添加另一個重做日志組
?
?
?
SQL> startup mount
?
???? alter database add logfile group <n> ('<filename>') size <x>M;
?
如果已經(jīng)報錯 ORA-00600:[krr_highest_scn_tim_8]，并且定期持續(xù)報錯，則可以通過以下方法之一來解決：
?
- 安裝補丁程序，
?
- 或者通過以下方法清除聯(lián)機重做日志：
?
SQL> select group# from v$log
?
???? where archived='NO' and status = 'CURRENT';
?
???? alter database clear logfile group <group#>;
?
注：清除聯(lián)機重做日志表示該序列號的日志中的重做無法用于恢復，因此應該在清除日志之后盡可能早地執(zhí)行完整備份。
?
?
?
6. BUG 10170431 - CTWR CONSUMING LOTS OF CPU CYCLES
?
如果啟用了 Block Change Tracking（塊更改跟蹤，簡稱 BCT），則 CTWR進程會消耗 CPU，而數(shù)據(jù)庫整體性能將會受到嚴重影響。這種現(xiàn)象會在 11.2.0.2 中發(fā)生，解決方法是禁用塊更改跟蹤或應用one-off補丁程序。該問題已在 11.2.0.3 中修復
?
癥狀：
?
?
?
在最低負載的情況下，CTWR 后臺進程消耗 90% 到 100% 的 CPU。
ALTER SYSTEM CHECKPOINT 會顯著降低 CTWR CPU 負載，稍后將返回到 90% 到 100% CPU 負載（CTWR處理塊更改之后），這種現(xiàn)象很有可能也是這個問題。
CTWR 的調(diào)用堆棧很可能顯示在以下函數(shù)中不斷循環(huán)（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）命令失敗，出現(xiàn)錯誤RMAN-20052: invalid datafile create SCN
?
將數(shù)據(jù)文件添加到transportable表空間，然后恢復目錄出現(xiàn)問題。
?
由于插入(plug in) SCN 為零，導致在嘗試使用恢復目錄時出現(xiàn)問題。
?
解決方法是應用 patch 13000553.
?
Bug 13877582 - RMAN SOME DATAFILES AT STANDBY SITE APPEAR WITH NULL NAME
?
發(fā)現(xiàn)與以下 Bug 重復：
?
Bug 13000553 - RMAN BACKUP FAILS WITH RMAN-20999 ERROR AT STANDBY DATABASE
?
癥狀：
?目標數(shù)據(jù)庫是 dataguard（物理備用）環(huán)境
?表空間已插入(plug in)了主數(shù)據(jù)庫。
?插入(plug in)表空間之后，一些數(shù)據(jù)文件被添加到其中。
?恢復目錄為 11.2.0.3
?
已在以下版本中修復：12.1
?
解決方案
?
在恢復目錄數(shù)據(jù)庫中應用 patch 13000553，并在主站點與備用站點之間重新同步目錄。如果在應用補丁之后，文件名仍顯示為空白，則重新創(chuàng)建恢復目錄，在新目錄中注冊主站點，然后將備用站點與新目錄重新同步。
?
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
?
如果在備用數(shù)據(jù)庫上啟用了 BCT 并且 RMAN 執(zhí)行增量備份，則 CTWR 會使備用數(shù)據(jù)庫出現(xiàn) ORA-0600[krcccb_busy]，并崩潰。此問題影響 11.2.0.2、11.2.0.3，繞過問題的方法是禁用塊更改跟蹤。
?
癥狀：
?在備用數(shù)據(jù)庫上啟用了 BCT
?RMAN 執(zhí)行增量備份。
?CTWR會出現(xiàn) ora-0600[krcccb_busy]，使備用數(shù)據(jù)庫崩潰。
?
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（轉(zhuǎn)儲）。
?core stack（堆棧）顯示：/oracle/movt/11G/app/product/release/lib/libskgxp11.so
?
Workaround: 將 Oracle 可執(zhí)行文件與 Media Manager API 庫的靜態(tài)版本鏈接，而不是動態(tài)鏈接庫
?
關閉所有使用此 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
?
使用靜態(tài)鏈接的庫“l(fā)ibnwora.a”而不是動態(tài)庫“l(fā)ibnwora.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
?
癥狀：
?
如果在數(shù)據(jù)庫（cluster_database=TRUE）運行期間意外禁用了增量備份的塊更改跟蹤 (BCT)、RMAN 會話或?qū)嵗谏弦淮蝹浞萜陂g終止，并且 RDBMS 發(fā)行版早于 11.2.0.4，則可能命中這個 Bug。
?
該 Bug 影響 11.2.0.2/3（也可能影響更早的版本），任意平臺都可能發(fā)生。但是，它只影響 RAC，即數(shù)據(jù)庫設置了參數(shù) cluster_database=true。
該 Bug 已在 11.2.0.4 及更高版本中修復。
?
?
?
11. MML 不兼容問題：使用 Oracle 11.2 執(zhí)行 RMAN備份或恢復到磁帶的操作期間出現(xiàn) ORA-07445 [Strcpy()+48]
?
不兼容的 MML 軟件在使用 RMAN備份數(shù)據(jù)庫時將導致 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（調(diào)用堆棧）：
__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 的兼容性。 如需幫助，請聯(lián)系供應商技術支持
?
例如：在以下網(wǎng)址可以找到與 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 規(guī)范時，
??? UNTIL TIME 將被截斷。因此，構建的duplicate數(shù)據(jù)庫可能會處于錯誤的時間點
??? 例如：
????? 假設 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 執(zhí)行 RMAN 復制命令。
???? 示例：
????? setenv NLS_DATE_FORMAT 'DD-MON-YYYY HH24:MI:SS'
????? setenv NLS_LANG 'AMERICAN_AMERICA.UTF8'
????? 使用 RMAN 連接到目標和 auxiliary(輔助)實例
????? 執(zhí)行帶有 UNTIL TIME 的 RMAN 復制命令
?
? 有關受影響/修復的版本，請參閱： Note 11694127.8
總結
以上是生活随笔為你收集整理的11GR2 中的常见 RMAN 问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
