Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

41

积分

0

好友

8

主题
1#
发表于 2012-3-16 18:41:22 | 查看: 4121| 回复: 0
早上八点半左右客户oracle的应用均无法连接。他们无奈重启机器后一切恢复正常,上午我去收集一些报错信息。
环境:HPUX 11.23
oracle:RAC 环境,原来是9204,去年去给他们升级到9208了。
查看alert日志发现上午出现问题的时候有报错,在节点一上:下面的信息均为部分信息,详细报错信息见附件。
alert_hddms1.log
ARC1: Unable to archive log 2 thread 1 sequence 14832
      Log actively being archived by another process
Fri Mar 16 05:05:06 2012
ARC1: Evaluating archive   log 2 thread 1 sequence 14832
ARC1: Unable to archive log 2 thread 1 sequence 14832
      Log actively being archived by another process
Fri Mar 16 05:05:59 2012
ARC0: Completed archiving  log 2 thread 1 sequence 14832
Fri Mar 16 08:14:47 2012
Thread 1 advanced to log sequence 14834
Fri Mar 16 08:14:47 2012
ARC0: Evaluating archive   log 1 thread 1 sequence 14833
Fri Mar 16 08:14:47 2012
  Current log# 2 seq# 14834 mem# 0: /dev/vg02/rredo01_2.log
Fri Mar 16 08:14:47 2012
ARC0: Beginning to archive log 1 thread 1 sequence 14833
Creating archive destination LOG_ARCHIVE_DEST_2: '/arch/arch2/arch_14833_0001.arc'
Creating archive destination LOG_ARCHIVE_DEST_1: '/arch/arch1/arch_14833_0001.arc'
Fri Mar 16 08:15:08 2012
ARC1: Evaluating archive   log 1 thread 1 sequence 14833
ARC1: Unable to archive log 1 thread 1 sequence 14833
      Log actively being archived by another process
Fri Mar 16 08:16:08 2012
ARC1: Evaluating archive   log 1 thread 1 sequence 14833
ARC1: Unable to archive log 1 thread 1 sequence 14833
      Log actively being archived by another process
Fri Mar 16 08:17:09 2012
ARC1: Evaluating archive   log 1 thread 1 sequence 14833
ARC1: Unable to archive log 1 thread 1 sequence 14833
      Log actively being archived by another process
Fri Mar 16 08:18:06 2012
ARC0: Completed archiving  log 1 thread 1 sequence 14833
Fri Mar 16 08:19:45 2012
Errors in file /u01/app/oracle/admin/hddms/udump/hddms1_ora_24019.trc:
ORA-07445: exception encountered: core dump [__milli_memcpy()+2512] [SIGSEGV] [Address not mapped to object] [0x9FFFFFFFBF580000] [] []
Fri Mar 16 08:53:20 2012
Waited too long for library cache load lock. More info in file /u01/app/oracle/admin/hddms/udump/hddms1_ora_29929.trc.
Fri Mar 16 09:11:43 2012
ARCH: Possible network disconnect with primary database
Fri Mar 16 09:11:43 2012
ARCH: Possible network disconnect with primary database
-----------------------------------------------------------------------------------
hddms1_ora_29929.trc  
/u01/app/oracle/admin/hddms/udump/hddms1_ora_29929.trc
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /u01/app/oracle/product/9.2.0
System name: HP-UX
Node name: HDDB1
Release: B.11.23
Version: U
Machine: ia64
Instance name: hddms1
Redo thread mounted by this instance: 1
Oracle process number: 94
Unix process pid: 29929, image: [email=oracle@HDDB1]oracle@HDDB1[/email] (TNS V1-V3)
*** 2012-03-16 08:53:20.622
*** SESSION ID:(69.35019) 2012-03-16 08:53:20.571
LIBRARY OBJECT HANDLE: handle=c00000009b2c3110
name=PMIS.PM_UD_ALLBLOBS2
hash=5c315ef9 timestamp=04-15-2006 13:06:01
namespace=TABL/PRCD/TYPE flags=KGHP/TIM/SML/[02000000]
kkkk-dddd-llll=0000-0041-074d lock=S pin=S latch#=1
lwt=c00000009b2c3140[c00000009b2c3140,c00000009b2c3140] ltm=c00000009b2c3150[c00000009b2c3150,c00000009b2c3150]
pwt=c00000009b2c3170[c00000009b2c3170,c00000009b2c3170] ptm=c00000009b2c3200[c00000009b2c3200,c00000009b2c3200]
ref=c00000009b2c3120[c00000009b2c3120, c00000009b2c3120] lnd=c00000009b2c3218[c0000000853976e8,c000000094d9eb30]
  LOCK INSTANCE LOCK: id=LBfb296b302212bded
  PIN INSTANCE LOCK: id=NBfb296b302212bded mode=S release=F flags=[00]
  INVALIDATION INSTANCE LOCK: id=IV0001afde0f0e0702 mode=S
  LIBRARY OBJECT: object=c00000009b5ec940
  type=TABL flags=EXS/LOC[0005] pflags= [00] status=VALD load=X
  LOAD LOCK OWNERS:
      lock  process mode mask
  -------- -------- ---- ------
  c00000008344e318 c00000007d6eca70    X   0301
  LOAD LOCK WAITERS:
      lock  process mode mask
  -------- -------- ---- ------
  c00000008344e438 c00000007d6e1910    X   0301
  DATA BLOCKS:
  data#     heap  pointer status pins change  alloc(K)  size(K)
  ----- -------- -------- ------ ---- ------   -------- --------
      0 c000000085920478 c00000009b5eca38 I/P/A     0 NONE      14.98    16.71
      2 c0000000875f40c8        0 I/P/-     0 NONE       0.00     0.00
      3 c00000009ff7de38        0 I/P/-     0 NONE       0.00     0.00
      6 c00000009ff7dd88        0 -/P/-     0 NONE       0.00     0.00
      8 c00000009089e4f8 c00000008d330b20 I/P/A     2 NONE       0.49     2.05
      9 c00000009089e5a8        0 I/P/-     2 NONE       0.00     0.00
     10 c00000009089e6f8        0 I/P/-     0 NONE       0.00     0.00
===================================================
SYSTEM STATE
------------
System global information:
     processes: base c00000007d6c1fd0, size 500, cleanup c00000007d6c2a90
     allocation: free sessions c00000007d7d66d8, free calls 0000000000000000
     control alloc errors: 0 (process), 0 (session), 0 (call)
     system statistics:
         0    1334550 logons cumulative
         0        190 logons current
         0  279779815 opened cursors cumulative
         0     237247 opened cursors current
         0   85428723 user commits
----------------------------------------------------------------------------------
在看了群主的ORA-07455系列之后依然没有啥思路,苦于没有mos账号也不太方便。现在将信息提供给大家练练手,多多指点!
虽然有其它报错比如“ORA-1652: unable to extend temp segment by 128 in tablespace                 TEMP ”,根据此错出现时间与oracle出问题来分析是ORA-1652先造成的可能性较小,不至于造成应用都连不上的情况。

log.rar

719.18 KB, 下载次数: 472

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-24 04:09 , Processed in 0.071484 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569