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

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

0

积分

1

好友

1

主题
1#
发表于 2013-5-9 15:48:23 | 查看: 3849| 回复: 7
[oracle@dams incdir_35032]$ more DAMS_ora_10187_i35032.trc
Dump file /u01/app/oracle/diag/rdbms/dams/DAMS/incident/incdir_35032/DAMS_ora_10187_i35032.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
System name:    Linux
Node name:      dams
Release:        2.6.32-279.11.1.el6.x86_64
Version:        #1 SMP Tue Oct 16 15:57:10 UTC 2012
Machine:        x86_64
Instance name: DAMS
Redo thread mounted by this instance: 1
Oracle process number: 24
Unix process pid: 10187, image: oracle@dams (TNS V1-V3)


*** 2013-05-09 15:41:11.009
*** SESSION ID:(130.5) 2013-05-09 15:41:11.009
*** CLIENT ID:() 2013-05-09 15:41:11.009
*** SERVICE NAME:(SYS$USERS) 2013-05-09 15:41:11.009
*** MODULE NAME:(SQL*Plus) 2013-05-09 15:41:11.009
*** ACTION NAME:() 2013-05-09 15:41:11.009

Dump continued from file: /u01/app/oracle/diag/rdbms/dams/DAMS/trace/DAMS_ora_10187.trc
ORA-00600: internal error code, arguments: [kqlInvObj:user], [97], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 35032 (ORA 600 [kqlInvObj:user]) ========

*** 2013-05-09 15:41:11.009
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=4sr56z3w21qwb) -----
create table ffff (id number)

----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
skdstdst()+36        call     kgdsdst()            000000000 ? 000000000 ?
                                                   7FFFD4B1A058 ? 000000001 ?
                                                   7FFFD4B1E558 ? 000000000 ?
ksedst1()+98         call     skdstdst()           000000000 ? 000000000 ?
                                                   7FFFD4B1A058 ? 000000001 ?
                                                   000000000 ? 000000000 ?
ksedst()+34          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFD4B1A058 ? 000000001 ?
                                                   000000000 ? 000000000 ?
dbkedDefDump()+2736  call     ksedst()             000000000 ? 000000001 ?
                                                   7FFFD4B1A058 ? 000000001 ?
2#
发表于 2013-5-9 15:52:05
trace 打包上传

回复 只看该作者 道具 举报

3#
发表于 2013-5-9 16:05:03
请在帮忙看下~~~~~

trace.tar.gz

2.19 MB, 下载次数: 666

回复 只看该作者 道具 举报

4#
发表于 2013-5-9 20:37:18
你的压缩包不小, 但就是 要的那个文件没有。。。

回复 只看该作者 道具 举报

5#
发表于 2013-5-10 13:38:58
现在好了  我把obj$的用户=97的数据删除就好了~~~

回复 只看该作者 道具 举报

6#
发表于 2013-12-19 15:42:55
你把数据删除了,那数据不是都没了,我按你的测试了下,delete from sys.obj$ where owner# in (84);这个用户的对象都没了,那怎么行。

回复 只看该作者 道具 举报

7#
发表于 2013-12-19 15:44:44
要是按照这个http://blog.itpub.net/11088128/viewspace-711751 解决的话,那新对象时可以创建了,但是之前的不是都没了

回复 只看该作者 道具 举报

8#
发表于 2013-12-19 16:01:26
我的理解错误了,sorry,这个方法的确解决了

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-21 09:54 , Processed in 0.050517 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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