SYSTEM01出问题了,如何解决(在线等)
打开数据库,发现以下错误.
SQL> alter database open;
alter database open
*
ERROR 位于第 1 行:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 16)
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF'
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 5009885
2 5009885
3 5009885
4 5009885
5 5009885
6 5009885
7 5009885
8 5009885
9 5009885
10 5009885
11 5009885
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 5009885
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 10602 1048576 1 NO INACTIVE
4989881 19-6? -06
2 1 10601 1048576 1 NO INACTIVE
4969878 19-6? -06
3 1 10603 1048576 1 NO CURRENT
5009884 19-6? -06
发现这个FIRST_CHANGE#比数据文件的SCN要小一位.
通过DBV检查,发现Found block already marked corrupted:
C:\Documents and Settings\>dbv file=D:\Oracle\oradata\orcl\SYSTEM01.DBF bloc
ksize=8192
DBVERIFY: Release 8.1.6.0.0 - Production on 星期一 6月 19 01:16:35 2006
(c) Copyright 1999 Oracle Corporation. All rights reserved.
DBVERIFY - 检验开始：FILE = D:\Oracle\oradata\orcl\SYSTEM01.DBF
Block Checking: DBA = 4194320, Block Type = Undo data block
Found block already marked corrupted
DBVERIFY - 完成检验
检查的页面总数 ：13904
处理的页面总数（数据）：5408
失败的页面总数（数据）：0
处理的页面总数（索引）：2013
失败的页面总数（索引）：0
处理的页面总数（其它）：4025
空的页面总数 ：2458
标记损坏的页面总数：0
汇集的页面总数 ：0
打不开.
SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
select * from V$DATABASE_BLOCK_CORRUPTION
*
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only
现在打开数据库,还报以下错误:
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: , , , , ,
, [], []
跟踪文件的错误:
*** 2006-06-19 14:00:12.111
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: , , , , , , [], []
Current SQL statement for this session:
alter database open
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_ksedmp+a8 CALLrel _ksedst+0
69C088
_ksfdmp+e CALLrel _ksedmp+0 3
_kgeriv+95 CALLreg 00000000
5B2D8
3
_kgesiv+49 CALLrel _kgeriv+0
28810
DF16274
E54 5
269C208
_ksesic5+3c CALLrel _kgesiv+0
5B2D8
DF16274
E54 5
269C208
_kcvcrv+cd2 CALLrel _ksesic5+0 E54 0
1 0 2
0
29CF
0
29CF
0 4
_kcfopd+211 CALLrel _kcvcrv+0
69C5F4
0
_adbdrv+8eb CALLrel _kcfopd+0 0 0 0
_opiexe+1cd1 CALLrel _adbdrv+0
_opiosq0+9a9 CALLrel _opiexe+0 4 0
269DCE8
_opiall0+1c7 CALLrel _opiosq0+0 3 E
269DE18
0
_kpoal8+54e CALLrel _opiall0+0
_opiodr+504 CALLreg 00000000 5E 12
69F3F4
_ttcpip+df8 CALLreg 00000000 5E 12
269F3F4
0
_opitsk+608 CALLrel _ttcpip+0
_opiino+4eb CALLrel _opitsk+0 0
_opiodr+504 CALLreg 00000000 3C 4
269FBF8
_opidrv+384 CALLrel _opiodr+0 3C 4
269FBF8
0
_sou2o+19 CALLrel _opidrv+0
_opimai+10c CALLrel _sou2o+0
_OracleThreadStart@4+49f CALLrel _opimai+0 2
269FE74
7C80B508 CALLreg 00000000
----- Argument/Register Address Dump -----
我只要把用户的业务数据挖出来就可以了.
SYSTEM的数据,就不管了啥.
已经成功的使用PRM把数据挖掘出来,并恢复了系统.
这也是最后一招.没有办法。
页:
[1]