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

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

0

积分

1

好友

1

主题
1#
发表于 2013-4-2 10:31:06 | 查看: 5161| 回复: 5
数据库平台aix5.3
数据库版本:
$ sqlplus /nolog

SQL*Plus: Release 9.2.0.8.0 - Production on Tue Apr 2 10:02:37 2013

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved

alert文件报错:
Mon Apr  1 11:25:11 2013
Errors in file /gdhome/oracle/admin/ossdb2/udump/ossdb2_ora_934702.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00900: invalid SQL statement
Mon Apr  1 11:29:56 2013
$ errpt
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
C69F5C9B   0401112513 P S SYSPROC        SOFTWARE PROGRAM ABNORMALLY TERMINATED
DCB47997   0219010313 T H hdisk0         DISK OPERATION ERROR

$ errpt -aj C69F5C9B
---------------------------------------------------------------------------
LABEL:          CORE_DUMP
IDENTIFIER:     C69F5C9B

Date/Time:       Mon Apr  1 11:25:12 BEIST 2013
Sequence Number: 8601
Machine Id:      00C1ED244C00
Node Id:         gddb
Class:           S
Type:            PERM
Resource Name:   SYSPROC         

Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED

Probable Causes
SOFTWARE PROGRAM

User Causes
USER GENERATED SIGNAL

        Recommended Actions
        CORRECT THEN RETRY

Failure Causes
SOFTWARE PROGRAM

        Recommended Actions
        RERUN THE APPLICATION PROGRAM
        IF PROBLEM PERSISTS THEN DO THE FOLLOWING
        CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
SIGNAL NUMBER
           6
USER'S PROCESS ID:
                934702
FILE SYSTEM SERIAL NUMBER
          13
INODE NUMBER
           0      143360
CORE FILE NAME
/gdhome/oracle/admin/ossdb2/cdump/core_934702/core
PROGRAM NAME
oracle
STACK EXECUTION DISABLED
           0
COME FROM ADDRESS REGISTER
bmAssign 154

PROCESSOR ID
  hw_fru_id: 3
  hw_cpu_id: 6

ADDITIONAL INFORMATION
slcra 40C
??
ssexhd 2C0
??

Symptom Data
REPORTABLE
1
INTERNAL ERROR
0
SYMPTOM CODE
PCSS/SPI2 FLDS/oracle SIG/6 FLDS/slcra VALU/40c
2#
发表于 2013-4-2 10:44:15
more trace文件:
$ more /gdhome/oracle/admin/ossdb2/udump/ossdb2_ora_934702.trc
/gdhome/oracle/admin/ossdb2/udump/ossdb2_ora_934702.trc
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /gdhome/oracle/product/9.2.0
System name:    AIX
Node name:      gddb
Release:        3
Version:        5
Machine:        00C1ED244C00
Instance name: ossdb2
Redo thread mounted by this instance: 1
Oracle process number: 378
Unix process pid: 934702, image: oracle@gddb (TNS V1-V3)

*** SESSION ID:(348.5817) 2013-04-01 11:25:11.853
*** 2013-04-01 11:25:11.853
Exception signal: 11    0x1000a0464 (kghini+00bc) 940a0004
Registers:
iar: 00000001000a0464, msr: a00000000000d0b2
lr: 00000001000a02a0,  cr: 0000000022822444
r00: 0000000000000000, r01: 0ffffffffffe6e80, r02: 00000001101faa70,
r03: 0000000110006858, r04: 0000000000000000, r05: 0000000000000400,
r06: 0000000000000400, r07: 0000000000007fff, r08: 0000000000000000,
r09: 0000000000007fff, r10: fffffffffffffffc, r11: 0000000000000000,
r12: 0000000000000000, r13: 0000000110246b18, r14: 00000001103eb180,
r15: 0000000000000000, r16: 0000000102952378, r17: 0000000110349aa8,
r18: 0000000000000000, r19: 0000000000000000, r20: 0000000110006998,
r21: 0ffffffffffe7658, r22: 0000000000000001, r23: 0000000000000000,
r24: 0000000000000000, r25: 0000000000000001, r26: 0000000000000001,
r27: 0000000110006858, r28: 0000000000000020, r29: 0700000000000058,
r30: 0000000000000000, r31: 0000000000000000,
----- Call Stack Trace -----

回复 只看该作者 道具 举报

3#
发表于 2013-4-2 10:53:42
完整的trace上传为压缩附件

回复 只看该作者 道具 举报

4#
发表于 2013-4-2 11:26:28
Maclean Liu(刘相兵 发表于 2013-4-2 10:53
完整的trace上传为压缩附件

javascript:;

ossdb2_ora_934702.rar

562.2 KB, 下载次数: 765

trace文件

回复 只看该作者 道具 举报

5#
发表于 2013-4-2 11:32:15
  1.     SO: 70000025a347e90, type: 4, owner: 70000025b39a0c8, flag: INIT/-/-/0x00
  2.     (session) trans: 70000025f87b020, creator: 70000025b39a0c8, flag: (100041) USR/- BSY/-/-/-/-/-
  3.               DID: 0001-017A-0000178E, short-term DID: 0000-0000-00000000
  4.               txn branch: 70000025e7d6c68
  5.               oct: 47, prv: 0, sql: 700000269e87700, psql: 700000269e87700, user: 107/TELECOM
  6.     O/S info: user: Administrator, term: 20130125-1135, ospid: 3880:3152, machine: WORKGROUP\20130125-1135
  7.               program: plsqldev.exe
  8.     client info: 210.56.193.98
  9.     application name: PL/SQL Developer, hash value=1190136663
  10.     action name: Ӣ˔԰ࠚ - тݨ, hash value=3604520210
  11.     last wait for 'pipe get' blocking sess=0x0 seq=616 wait_time=1672298
  12.                 handle address=700000271dfcb00, buffer length=1000, timeout=e10
  13.     temporary object counter: 0
  14.        
  15.               SO: 700000279ab99f0, type: 51, owner: 70000025a347e90, flag: INIT/-/-/0x00
  16.       LIBRARY OBJECT LOCK: lock=700000279ab99f0 handle=700000269e87700 mode=N
  17.       call pin=70000026b792ea8 session pin=0
  18.       htl=700000279ab9a60[70000025ec5d670,70000026304efa0] htb=70000026304efa0
  19.       user=70000025a347e90 session=70000025a347e90 count=1 flags=[00] savepoint=677
  20.       LIBRARY OBJECT HANDLE: handle=700000269e87700
  21.       name=declare ret binary_integer; begin ret := PBSDE.DEBUG_LOOP; end;
  22.       hash=f444e2b8 timestamp=04-01-2013 11:21:58
  23.       namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/[50010000]
  24.       kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=15
  25.       lwt=700000269e87730[700000269e87730,700000269e87730] ltm=700000269e87740[700000269e87740,700000269e87740]
  26.       pwt=700000269e87760[700000269e87760,700000269e87760] ptm=700000269e877f0[700000269e877f0,700000269e877f0]
  27.       ref=700000269e87710[700000269e87710, 700000269e87710] lnd=700000269e87808[700000269e87808,700000269e87808]
  28.         LIBRARY OBJECT: object=700000265225170
  29.         type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
  30.         CHILDREN: size=16
  31.         child#    table reference   handle
  32.         ------ -------- --------- --------
  33.              0 7000002652253d0 700000279aee790 70000026d6906d0
  34.         DATA BLOCKS:
  35.         data#     heap  pointer status pins change
  36.         ----- -------- -------- ------ ---- ------
  37.             0 70000027ddc6788 700000265225268 I/P/A     0 NONE
  38.                        
  39.                        
  40.                        
  41.                             LIBRARY OBJECT LOCK: lock=700000279ab99f0 handle=700000269e87700 mode=N
  42.       call pin=70000026b792ea8 session pin=0
  43.       htl=700000279ab9a60[70000025ec5d670,70000026304efa0] htb=70000026304efa0
  44.       user=70000025a347e90 session=70000025a347e90 count=1 flags=[00] savepoint=677
  45.       LIBRARY OBJECT HANDLE: handle=700000269e87700
  46.       name=declare ret binary_integer; begin ret := PBSDE.DEBUG_LOOP; end;
  47.       hash=f444e2b8 timestamp=04-01-2013 11:21:58
  48.       namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/[50010000]
  49.       kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=15
  50.       lwt=700000269e87730[700000269e87730,700000269e87730] ltm=700000269e87740[700000269e87740,700000269e87740]
  51.       pwt=700000269e87760[700000269e87760,700000269e87760] ptm=700000269e877f0[700000269e877f0,700000269e877f0]
  52.       ref=700000269e87710[700000269e87710, 700000269e87710] lnd=700000269e87808[700000269e87808,700000269e87808]
  53.         LIBRARY OBJECT: object=700000265225170
  54.         type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
  55.         CHILDREN: size=16
  56.         child#    table reference   handle
  57.         ------ -------- --------- --------
  58.              0 7000002652253d0 700000279aee790 70000026d6906d0
  59.         DATA BLOCKS:
  60.         data#     heap  pointer status pins change
  61.         ----- -------- -------- ------ ---- ------
  62.             0 70000027ddc6788 700000265225268 I/P/A     0 NONE  
复制代码
PBSDE.DEBUG_LOOP 这个过程是干什么的 ,为什么要用到pipe? 99%可以肯定是 有人用PL/SQL DEVELOPER登陆后 调用 PBSDE.DEBUG_LOOP 引起了该问题, 这说明PBSDE.DEBUG_LOOP 的代码是有问题的

回复 只看该作者 道具 举报

6#
发表于 2013-4-2 12:20:26
Maclean Liu(刘相兵 发表于 2013-4-2 11:32
PBSDE.DEBUG_LOOP 这个过程是干什么的 ,为什么要用到pipe? 99%可以肯定是 有人用PL/SQL DEVELOPER登陆后  ...

恩呢,这是开发人员执行的,谢谢刘大!

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-16 10:19 , Processed in 0.058468 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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