> 데이터 베이스 > MySQL 튜토리얼 > Oracle Rman backup 产生的错误信息

Oracle Rman backup 产生的错误信息

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB
풀어 주다: 2016-06-07 17:15:55
원래의
932명이 탐색했습니다.

没有什么过多的错误信息显示,基本上也是一些说明性的东西。只在metalink的forum中有这样的提问和回答。其中一位ORACLE的support

周日手工做RMAN备份的时候,,在alert.log中产生了错误信息。
     
Sat Jun 25 16:39:08 2012
Errors in file /home/Oracle/app/oracle/admin/XXX/udump/XXX_ora_22899.trc:
Sat Jun 25 16:39:08 2012
Errors in file /home/oracle/app/oracle/admin/XXX/udump/XXX_ora_22899.trc:
Sat Jun 25 16:39:08 2012
Errors in file /home/oracle/app/oracle/admin/XXX/udump/XXX_ora_22899.trc:

      奇怪呀,RMAN也没有报错信息,赶快看看trc文件:
     
*** 2012-06-25 16:18:53.310
*** ACTION NAME:(0000071 STARTED16) 2012-06-25 16:18:53.284
*** MODULE NAME:(backup incr datafile) 2012-06-25 16:18:53.284
*** SERVICE NAME:(SYS$USERS) 2012-06-25 16:18:53.284
*** SESSION ID:(192.52848) 2012-06-25 16:18:53.284

      没有什么过多的错误信息显示,基本上也是一些说明性的东西。只在metalink的forum中有这样的提问和回答。其中一位ORACLE的support的回答比较严谨吧:
     
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.

      好了,这个问题可以不追究了。
      记录一下吧。
      对一个数据的管理人员来讲,不要放过任何数据库产生的信息才对。严谨,是必须的。-:)

linux

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿