RMAN备份alert日志报奇怪错误


布置Rman备份计划，执行之后发现alert.log中产生错误信息：
Fri Jul  6 00:30:16 2012
Errors in file /Oracle/admin/live/udump/*****_ora_3652.trc:
Fri Jul  6 00:30:16 2012
Errors in file /oracle/admin/live/udump/*****_ora_3652.trc:
Fri Jul  6 00:30:16 2012
Errors in file /oracle/admin/live/udump/*****_ora_3652.trc
 
然后检查备份日志，没有发现错误，奇怪，查看一下trace文件
[oracle]$cat  /oracle/admin/*****/udump/*****_ora_3652.trc
/oracle/admin/*****/udump/*****_ora_3652.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0
System name:   Linux
Node name:     servera
Release:       2.6.9-78.ELsmp
Version:       #1 SMP Wed Jul 9 15:39:47 EDT 2008
Machine:       i686
Instance name: *****
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 3652, image:oracle@servera(TNS V1-V3)
*** 2012-07-06 00:30:16.959
*** ACTION NAME:(0000051 STARTED16) 2012-07-06 00:30:16.958
*** MODULE NAME:(backup full datafile) 2012-07-06 00:30:16.958
*** SERVICE NAME:(SYS$USERS) 2012-07-06 00:30:16.958
*** SESSION ID:(1620.20640) 2012-07-06 00:30:16.957

metalink 解释是一个bug 4596065，只发生在Linux X86平台的Oracle 10.2.0.1.0下，而且只在11g里解决。这个并不是真正意义的error，可以不用管它,Just ignore it
 
bug  4596065 信息如下
------------------------------------------------------------------------------------------
Bug No.     4596065
Filed     07-SEP-2005     Updated     18-OCT-2005
Product     Oracle Server - Enterprise Edition     Product Version     10.2.0.1.0
Platform.     Linux x86     Platform. Version     No Data
Database Version     10.2.0.1.0     Affects Platforms     Generic
Severity     Severe Loss of Service     Status     Development to Q/A
Base Bug     N/A     Fixed in Product Version     11.0

Problem statement:

RMAN BACKUP GENERATES EMPTY TRACE FILES WHEN DB_RECOVERY_FILE_DEST IS SET

 
网上搜索发现很多人亦遇到此情况
见链接
有如下解释亦可接受：
There seems to be apparently no problem with the trace file that is getting generated.
However is it the full trace file or have you just pasted the heading of the trace file.
You are correct in interpreting that this is related to the backup.
If this is not the full tracefile you can update the thread with some more information or atleast the call stack part of the trace file.
If this is the full file, then there is nothing much that can be inferred from it, and can be ignored.
 
该错误信息根不必去追究和关心了，Just ignore it

相关内容