ORA-00600 [3020] ORA-10560问题处理
2015-07-07 16:02
381 查看
渠道一用户,断电后数据库无法启动,渠道技术人员做了一些恢复尝试,包括重建控制文件、介质恢复提示如下错误:
可能介质恢复过程中出现了坏块,还好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.
版权声明:本文为博主原创文章,未经博主允许不得转载。
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.
版权声明:本文为博主原创文章,未经博主允许不得转载。
相关文章推荐
- android 开发小记
- ubuntu 安装 qt等软件
- 亲和串
- LeetCode-Min Stack-解题报告
- Mac 批量删除 .svn 文件
- 如何在spring官网上下载source code
- WPF 自定义属性和触发器
- [深入学习C#]C#实现多线程的方式:Task——任务
- MySQL查看和修改表的存储引擎
- Java——集合工具类和jdk1.5有关集合的新特性
- GRE写作必备句型
- SQL Server 跨服务器 不同数据库之间复制表的数据的方法!
- cas-server异常不会后台显示而是变成json显示在页面。
- php类的定义与继承用法实例
- 自定义“菊花dialog”
- Guide to understanding XSS – XSS payloads, attack vectors, BeEF hooking, MiTM with Shank and some hi
- AIX Study之--AIX用户资源访问限制配置
- 不用浏览器,直接用代码发送文件给webservices所在服务器 并且可以周期行的发送
- AsyncTask的使用
- leetcode - Reverse Words in a String