ORA-00600 [3020] ORA-10560问题处理

在数据库出现故障导致无法启动时,通过介质恢复尝试解决问题,遇到坏块导致的ORA-00600错误。提供了解决方案,包括使用Trial Recovery确定损坏程度、跳过坏块进行恢复、识别并解决每个坏块对应的对象问题,如索引重建、用户对象重新创建或数据提取等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

渠道一用户,断电后数据库无法启动,渠道技术人员做了一些恢复尝试,包括重建控制文件、介质恢复提示如下错误:

Errors in filed:\oracle\diag\rdbms\orcl\orcl1\trace\orcl1_pr0g_5100.trc  (incident=259565):
ORA-00600: internal error code, arguments:[3020], [2], [102936], [8491544], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with datablock (file# 2, block# 102936, file offset is 843251712 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2:'G:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type 'FIRST LEVEL BITMAPBLOCK'
Incident details in:d:\oracle\diag\rdbms\orcl\orcl1\incident\incdir_259565\orcl1_pr0g_5100_i259565.trc
Slave exiting with ORA-600 exception
Errors in file d:\oracle\diag\rdbms\orcl\orcl1\trace\orcl1_pr0g_5100.trc:
ORA-00600: internal error code, arguments:[3020], [2], [102936], [8491544], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with datablock (file# 2, block# 102936, file offset is 843251712 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2:'G:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type 'FIRST LEVEL BITMAPBLOCK'

可能介质恢复过程中出现了坏块,还好recover database有个命令可以允许坏块,如下:

If you do not have a backup available, than the options are VERY limited. Please open a Service Request with Oracle Support Services for assistance on this.  Otherwise:

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.

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. 

版权声明:本文为博主原创文章,未经博主允许不得转载。



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值