Duplicate database完成后数据库无法OPEN，报ORA-00600[25012], [42], [...

ricky

操作：duplicate数据库
版本：源库ORACLE9206 目标库9207
描述：已经使用CV备份软件将源库数据全部复制到了复制库，复制库在open的时候报错，无法OPEN
日志：
Errors in file /recover/stathf/udump/stathf_ora_966908.trc:
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: '/recover/stathf/rlv_redo_g3_002'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 3 thread 1: '/recover/stathf/rlv_redo_g3_001'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
Thu Dec  6 13:48:13 2012
Errors in file /recover/stathf/udump/stathf_ora_966908.trc:
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/recover/stathf/rlv_redo_g4_002'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 4 thread 1: '/recover/stathf/rlv_redo_g4_001'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
Thu Dec  6 13:48:19 2012
Errors in file /recover/stathf/udump/stathf_ora_966908.trc:
ORA-00313: open failed for members of log group 5 of thread 1
ORA-00312: online log 5 thread 1: '/recover/stathf/rlv_redo_g5_002'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 5 thread 1: '/recover/stathf/rlv_redo_g5_001'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
Thu Dec  6 13:48:26 2012
LGWR: Primary database is in CLUSTER CONSISTENT mode
Assigning activation ID 167245762 (0x9f7f7c2)
Thread 1 opened at log sequence 1
  Current log# 5 seq# 1 mem# 0: /recover/stathf/rlv_redo_g5_001
  Current log# 5 seq# 1 mem# 1: /recover/stathf/rlv_redo_g5_002
Successful open of redo thread 1
Thu Dec  6 13:48:26 2012
SMON: enabling cache recovery
Thu Dec  6 13:48:26 2012
Errors in file /recover/stathf/udump/stathf_ora_966908.trc:
ORA-00600: internal error code, arguments: [25012], [42], [349], [], [], [], [], []
Thu Dec  6 13:48:27 2012
Errors in file /recover/stathf/udump/stathf_ora_966908.trc:
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [25012], [42], [349], [], [], [], [], []
Thu Dec  6 13:48:27 2012

ricky

2.我重建日志文件步骤，仍报错
SQL> alter database clear unarchived logfile group 1;

Database altered.

SQL> alter database clear unarchived logfile group 2;

Database altered.

SQL> alter database clear unarchived logfile group 3;
Database altered.

SQL> alter database clear unarchived logfile group 4;

Database altered.

SQL> alter database clear unarchived logfile group 5;
alter database clear unarchived logfile group 5
*
ERROR at line 1:
ORA-01624: log 5 needed for crash recovery of thread 1
ORA-00312: online log 5 thread 1: '/recover/stathf/rlv_redo_g5_001'
ORA-00312: online log 5 thread 1: '/recover/stathf/rlv_redo_g5_002'
SQL> alter database open;

SQL> recover until cancel;
Media recovery complete.
SQL> alter database open resetlogs;  
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
SQL>

ricky

我将复制数据库版本从9207降到9206，结果不在报
ORA-00704: bootstrap process failure

可是，复制数据仍然打不开，报
KSTDUMP: End of in-memory trace dump
ORA-00600: internal error code, arguments: [25012], [42], [351], [], [], [], [], []

Liu Maclean(刘相兵

9.2.0.7.0

1. ORA-00704: bootstrap process failure
   
2. ORA-00600: internal error code, arguments: [25012], [42], [349], [], [], [], [], []
   
3. 
   
4. 
   
5. 
   
6. 
   
7. *** 2012-12-06 13:48:26.872
   
8. ksedmp: internal or fatal error
   
9. ORA-00600: internal error code, arguments: [25012], [42], [349], [], [], [], [], []
   
10. Current SQL statement for this session:
    
11. select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
    
12. ----- Call Stack Trace -----
    
13. calling              call     entry                argument values in hex      
    
14. location             type     point                (? means dubious value)     
    
15. -------------------- -------- -------------------- ----------------------------
    
16. ksedmp+0148          bl       ksedst               102917BE4 ?
    
17. ksfdmp+0018          bl       01FCB8B0            
    
18. kgeriv+0118          bl       _ptrgl               
    
19. kgesiv+0080          bl       kgeriv               700000000027A58 ?
    
20.                                                    70000000001DD08 ? 102990C90 ?
    
21.                                                    70000000001DC58 ?
    
22.                                                    70000003CE8CFF0 ?
    
23. ksesic2+005c         bl       kgesiv               102990DE4 ? 700000000027A58 ?
    
24.                                                    FFFFFFFFFFE5550 ? 1103B4224 ?
    
25.                                                    000000000 ?
    
26. kftr2ah+01ec         bl       ksesic2              61B4000061B4 ? 000000000 ?
    
27.                                                    00000002A ? 000000000 ?
    
28.                                                    00000015D ? 000006D70 ?
    
29.                                                    00024331F ? 000001770 ?
    
30. kftr2bz+0054         bl       kftr2ah              000000000 ? 000000000 ?
    
31.                                                    000000000 ? 000000000 ?
    
32. ktugct+0410          bl       kftr2bz              3300000033 ?
    
33.                                                    FFFFFFFFFFE5588 ?
    
34. ktbgcl1+0bb0         bl       ktugct               000000000 ? 000000000 ?
    
35.                                                    000000000 ? 000000000 ?
    
36.                                                    000000000 ?
    
37. ktrgcm+0d94          bl       ktbgcl1              000000000 ? 002170000 ?
    
38.                                                    000020004 ? 000008000 ?
    
39.                                                    000000000 ?
    
40. ktrget+02d8          bl       ktrgcm               000000000 ?
    
41. kdsgrp+00cc          bl       ktrget               000000000 ? 000000000 ?
    
42.                                                    FFFFFFFFFFE6948 ?
    
43. kdsfbr+0298          bl       kdsgrp               000000000 ? 70000003DED4B08 ?
    
44.                                                    700000037E55288 ?
    
45. qertbFetchByRowID+0  bl       kdsfbr               000000000 ? 000000000 ?
    
46. 9c8                                                000000000 ? 000000000 ?
    
47.                                                    000000000 ? 000000000 ?
    
48.                                                    000000000 ? 000000000 ?
    
49. kpofrws+0118         bl       01FCB5DC            
    
50. opifch2+0c50         bl       kpofrws              110005B20 ? 100000000 ?
    
51.                                                    000000000 ? 700000037C03C28 ?
    
52.                                                    000000000 ?
    
53.                                                                        

复制代码

BOOTSTRAP 系统字典自举过程中遇到了        ORA-600[25012],相关对象为重要的  obj$  基表

ORA-00600        [25012], [42], [349]

42 Tablespace Number
349 Relative file number                                                                                  



这应当是 9i的一个BUG， 且9i的duplicate并不成熟。


方案1

重新备份(最好是冷备)，在做一次duplicate 或常规恢复


方案2

考虑 尝试用  _allow_resetlogs_corruption=true 试着打开数据库


alter system set "_allow_resetlogs_corruption"=true scope=spfile;
startup force mount;
recover database until cancel;

alter database open;

uj12best

ORACLE11之前的完全可以把备好的RMAN常规备份+STANDBY CONTROLFILE转入备机，再RESTORE，直接ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT即可。个人感觉11G之前的DUPLICATE TARGET DATABASE没有什么必要。

ricky

uj12best 发表于 2012-12-7 15:03
ORACLE11之前的完全可以把备好的RMAN常规备份+STANDBY CONTROLFILE转入备机，再RESTORE，直接ALTER DATABAS ...

我在做数据库的部份恢复，有一张重要的表被删了

ricky

我已经恢复成功：
成功恢复和前期不成功恢复的区别是
（1）使用和生产库一样的数据库版本ORACLE9206
(2)前期duplicate过程中i复制库的init文件*.undo_tablespace参数设为'UNDOTBS1'，经过仔细比对，生产库init文件*.undo_tablespace为UNDOTBS3'，后将恢复环境上的*.undo_tablespace改为UNDOTBS3

更改了以上两步，恢复正常，个人觉得第二点相对关键