久久精品国产亚洲怮怮_奇米网777色在线精品_亚洲色中文字幕制服丝袜_久久精品人人做人人看

始創(chuàng)于2000年 股票代碼:831685
咨詢熱線:0371-60135900 注冊有禮 登錄
  • 掛牌上市企業(yè)
  • 60秒人工響應
  • 99.99%連通率
  • 7*24h人工
  • 故障100倍補償
您的位置: 網站首頁 > 幫助中心>文章內容

RMAN備份alert日志報奇怪錯誤

發(fā)布時間:  2012/7/9 18:18:58

布置Rman備份計劃,執(zhí)行之后發(fā)現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
 
然后檢查備份日志,沒有發(fā)現錯誤,奇怪,查看一下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,只發(fā)生在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

 
網上搜索發(fā)現很多人亦遇到此情況
見鏈接 http://www.linuxidc.com/Linux/2012-07/64645.htm
有如下解釋亦可接受:
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

本篇文章來源于 Linux公社網站(www.linuxidc.com)  原文鏈接:http://www.linuxidc.com/Linux/2012-07/64644.htm


本文出自:億恩科技【prubsntakaful.com】

服務器租用/服務器托管中國五強!虛擬主機域名注冊頂級提供商!15年品質保障!--億恩科技[ENKJ.COM]

  • 您可能在找
  • 億恩北京公司:
  • 經營性ICP/ISP證:京B2-20150015
  • 億恩鄭州公司:
  • 經營性ICP/ISP/IDC證:豫B1.B2-20060070
  • 億恩南昌公司:
  • 經營性ICP/ISP證:贛B2-20080012
  • 服務器/云主機 24小時售后服務電話:0371-60135900
  • 虛擬主機/智能建站 24小時售后服務電話:0371-60135900
  • 專注服務器托管17年
    掃掃關注-微信公眾號
    0371-60135900
    Copyright© 1999-2019 ENKJ All Rights Reserved 億恩科技 版權所有  地址:鄭州市高新區(qū)翠竹街1號總部企業(yè)基地億恩大廈  法律顧問:河南亞太人律師事務所郝建鋒、杜慧月律師   京公網安備41019702002023號
      0
     
     
     
     

    0371-60135900
    7*24小時客服服務熱線