如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
数据库运行报ORA-00600错误，重启后日志中显示有数据块损坏情况出现。
请问该数据库是否有RMAN的备份？
请先shutdown immediate数据库，手工copy 所有的数据文件，日志文件和控制文件到另外一个磁盘路径下。
然后按以下步骤看是否能启动DB
1. Use Trial Recovery to determine the extent of the problem:
SQL> recover database test;
This will tell you how many blocks (n) would be left corrupted after recovery – check the alert
log for details of the blocks affected. If there are a large number of corruptions reported you may decide to restore from backup and issue point in time recovery. However, if only a few blocks are reported as corrupt you could proceed with recovery :
2. Skip the corrupted block(s)
SQL> recover database allow 1 corruption;
Do this <n> times, <n> being the number of blocks reported as corrupt in step 1 above.
This will allow recovery to continue, ‘skipping’ the blocks that cannot be recovered and leaving them marked as ‘corrupt’ after which the database can be opened.
SQL> alter database open ;
3. Take the corrupt blocks reported in the alert log and for each, identify the object that the block belongs to::
SQL> SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = <file#>
and <block> between block_id AND block_id + blocks – 1;
Replacing <file#> and <block> with the file# and block ids reported in the alert log.
For each object identified – take steps to resolve the corruption:
– if it belongs to an index then simply drop and recreate the index
– if it belong to a user object then consider recreating the object or extracting what you can from the object; if necessary raise a Service Request with Oracle and request assistance with extracting data from a corrupt object.
Resolving ORA-600[3020] Raised During Recovery ( Doc ID 361172.1 )
现在只能按一些可能的方法去试，但不能确保能起来。
请先shutdown immediate数据库，手工copy 所有的数据文件，日志文件和控制文件到另外一个磁盘路径下。
然后按以下步骤看是否能启动DB
1. Use Trial Recovery to determine the extent of the problem:
SQL> recover database test;
This will tell you how many blocks (n) would be left corrupted after recovery – check the alert
log for details of the blocks affected. If there are a large number of corruptions reported you may decide to restore from backup and issue point in time recovery. However, if only a few blocks are reported as corrupt you could proceed with recovery :
2. Skip the corrupted block(s)
SQL> recover database allow 1 corruption;
Do this <n> times, <n> being the number of blocks reported as corrupt in step 1 above.
This will allow recovery to continue, ‘skipping’ the blocks that cannot be recovered and leaving them marked as ‘corrupt’ after which the database can be opened.
SQL> alter database open ;
3. Take the corrupt blocks reported in the alert log and for each, identify the object that the block belongs to::
SQL> SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents
WHERE file_id = <file#>
and <block> between block_id AND block_id + blocks – 1;
Replacing <file#> and <block> with the file# and block ids reported in the alert log.
For each object identified – take steps to resolve the corruption:
– if it belongs to an index then simply drop and recreate the index
– if it belong to a user object then consider recreating the object or extracting what you can from the object; if necessary raise a Service Request with Oracle and request assistance with extracting data from a corrupt object.
Resolving ORA-600[3020] Raised During Recovery ( Doc ID 361172.1 )
如果Datafile 5可以删除，可以尝试下面的方法：
[oracle@nascds18 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 – Production on Thu Jan 29 16:00:31 2015
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 2083656 bytes
Variable Size 201327800 bytes
Database Buffers 96468992 bytes
Redo Buffers 14692352 bytes
Database mounted.
ORA-01122: database file 7 failed verification check
ORA-01110: data file 7: ‘/opt/oracle/oradata/R10204/test01.dbf’
ORA-01251: Unknown File Header Version read for file number 7
SQL> alter database datafile 7 offline drop;
Database altered.
SQL> alter database open;
Database altered.
file id 是固定的，5 号数据文件只能是同一个文件。
目前来看没什么好办法恢复了。
最后一招就是尝试force open。
在尝试force open之前请先shutdown immediate数据库，手工copy 所有的数据文件，日志文件和控制文件到另外一个磁盘路径下。
Please use the following steps to force open the database:
1. Get all the rollback segment information:
$strings /u01/database/system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU
==>Please replace the path and system01.dbf to the datafile name of the system tablespace.
2. Create pfile:
$sqlplus / as sysdba
SQL>create pfile from spfile;
3. Add the following parameter in init.ora:
UNDO_MANAGEMENT=MANUAL
_ALLOW_RESETLOGS_CORRUPTION = TRUE
_CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc)
==>In the generated file listSMU, there will be many rollback segments listed, please add these rollback segments to the ()
Please don’t forget to rename the _SYSSMU9 to _SYSSMU9$ (add $ in the end)…
4. Startup the database using pfile:
SQL>startup mount pfile=’/…./initORCL.ora’
SQL>show parameter corrupt;
5. Recover and open the database:
SQL>RECOVER DATABASE UNTIL CANCEL;
Cancel
SQL>ALTER DATABASE OPEN RESETLOGS;
6. Then check if the database can be opened successfully.
If startup failed with error:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
…
Need to follow Note 741227.1 to adjust SCN:
SQL>startup pfile=’…’;
SQL>select checkpoint_change# from v$database;
1450301
Found the following expected SCN in the trace file:
Searching by the “seg/obj”:
data
scn 0x0000.00000132 306
fsc 0x0000.0016a414
hex: 0x0000.0016a414 ==>decimal: 1483796
so 1450301 <1483796, which is not correct
SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual;
Enter value for decimal_scn_expected: 1483796
old 1: select ceil(&decimal_scn_expected/1024/1024/1024) from dual
new 1: select ceil(1483796/1024/1024/1024) from dual ;
CEIL(1483796/1024/1024/1024)
——————————
1
那么需要调整SCN， 请在参数文件中添加下面的参数
_minimum_giga_scn=<Value get by above command>
然后再：
SQL> startup pfile=’…’;
SQL>RECOVER DATABASE UNTIL CANCEL;
Cancel
SQL>ALTER DATABASE OPEN RESETLOGS;
请注意上面的命令会把SCN跳高，不要让这个数据库和其他数据库通过dblink连接，否则可能把其他数据库的SCN也跳高。
Note: After opened the database, it is a desupported DB and you must export , recreate a new DB and import the data to the new DB.
Be aware that the use of _OFFLINE_ROLLBACK_SEGMENTS may lead to the recreation
of the database, depending on whether there were active transactions in the
dropped undo segments. If so, then this may lead to logical corruption, and
hence to the recreation of the database. (Refer Note:106638.1 that explains
how to check the transaction table : you can use the same SELECT statements)
Be aware that the use of _CORRUPTED_ROLLBACK_SEGMENTS requires the recreation
of the database.
Handling Rollback Segment Corruptions in Oracle7.3 to 8.1.7 ( Doc ID 106638.1 )
_offline_rollback_segment 和_corrupt_rollback_segment 的作用不一致，有些时候必须用_corrupt_rollback_segment 才能强制打开损坏的数据库。
_OFFLINE_ROLLBACK_SEGMENTS 的作用：
允许数据库的逻辑corruption，用了这个参数之后，在删除回滚段时，Oracle不会检查这个回滚段是否有active的transaction, 你可以删除一个拥有active transaction的rollback segment，这时会导致字典表corruption。 这个参数也可以阻止SMON对某些回滚段中的事务进行恢复，所以当SMON在recovery transaction时如果发生异常导致数据库不断crash，那么这时使用这个参数有用。
_CORRUPTED_ROLLBACK_SEGMENTS 的作用：
Oracle不会访问这个参数中列出的任何回滚段的段头，而且认为这些回滚段的所有事物都是commit的。
对于使用了_OFFLINE_ROLLBACK_SEGMENTS的回滚段，它们的 transaction table 仍然可以读取。但是对于_CORRUPTED_ROLLBACK_SEGMENTS 中列出的回滚段，它们的transaction table就不被读取了。
如果不是万不得已，要谨慎使用上面的这些参数，尤其是_CORRUPTED_ROLLBACK_SEGMENTS，因为使用了_CORRUPTED_ROLLBACK_SEGMENTS之后的数据库Oracle就不支持了，必须要重建。
改成下面的方法，如果不行，就没办法了
Please use the following steps to force open the database:
1. Create pfile:
$sqlplus / as sysdba
SQL>create pfile from spfile;
2. Add the following parameter in init.ora:
UNDO_MANAGEMENT=MANUAL
_ALLOW_RESETLOGS_CORRUPTION = TRUE
3. Startup the database using pfile:
SQL>startup mount pfile=’/…./initORCL.ora’
SQL>show parameter corrupt;
4. Recover and open the database:
SQL>RECOVER DATABASE UNTIL CANCEL;
Cancel
SQL>ALTER DATABASE OPEN RESETLOGS;
数据库启动的时候报了ORA-00600: [2662] 的错误A data block SCN is ahead of the current SCN.
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
Check the SCN difference [argument d]-[argument b].
If the SCNs in the error are very close, then try to shutdown and startup
the instance several times.
这里看到ORA-00600: 内部错误代码, 参数: [2662], [0], [3721315789], [0], [3721365100], [8388617], [], [] <<<<<<<<<<============3721365100-3721315789=49311 looks like not big
建议再重启几次看是否这两个值会接近相同，并可以open DB。
但这里还有其他的600错误，是没有参数的，这很难确定是什么样的报错，所以只能试一下。
1. Create pfile:
$sqlplus / as sysdba
SQL>create pfile from spfile;
2. Add the following parameter in init.ora:
UNDO_MANAGEMENT=MANUAL
_ALLOW_RESETLOGS_CORRUPTION = TRUE
3. Startup the database using pfile:
SQL>startup mount pfile=’/…./initORCL.ora’
SQL>show parameter corrupt;
4. Recover and open the database:
SQL>RECOVER DATABASE UNTIL CANCEL;
Cancel
SQL>ALTER DATABASE OPEN RESETLOGS;
客户force open后发现有以下错误
Fri Jan 30 11:10:08 2015
Errors in file d:\oracle\product\10.2.0\admin\mddb\udump\mddb_ora_4760.trc:
ORA-00600: 内部错误代码, 参数: [2662], [0], [3721315789], [0], [3721365100], [8388617], [], []
尝试重启DB 几次后可以open了
Leave a Reply