windowsTB 非归档Oracle数据库恢复小case

这是友情支持一个朋友的数据库恢复case,昨天圣诞节的时候来个求助，只能速度帮忙解决了好过节去了。首先我们来看下的alert log都有哪些信息：

Wed Dec 23 15:19:21 2015
SMON: enabling tx recovery
Wed Dec 23 15:19:21 2015
Database Characterset is ZHS16GBK
Opening with internal Resource Manager plan
where NUMA PG = 2, CPUs = 8
Wed Dec 23 15:19:22 2015
Errors in file d:\oracle\product\10.2.0\admin\ajzq\udump\ajzq_ora_1712.trc:
ORA-00600: internal error code, arguments: [4194], [45], [45], [], [], [], [], []
 
Doing block recovery for file 2 block 1618943
Block recovery from logseq 4, block 63 to scn 7662329350
Wed Dec 23 15:19:23 2015
Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\xxxx\REDO01.LOG
Block recovery completed at rba 4.4749.16, scn 1.3367362055
Doing block recovery for file 2 block 121
Block recovery from logseq 4, block 63 to scn 7662329346
Wed Dec 23 15:19:23 2015
Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\xxxx\REDO01.LOG
Block recovery completed at rba 4.3977.16, scn 1.3367362051
Wed Dec 23 15:19:24 2015
SMON: Restarting fast_start parallel rollback
Wed Dec 23 15:19:24 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\udump\xxxx_ora_1712.trc:
ORA-00600: internal error code, arguments: [4194], [45], [45], [], [], [], [], []
 
Wed Dec 23 15:19:24 2015
DEBUG: Replaying xcb 0xf0adfbe0, pmd 0x20588f48 for failed op 8
Doing block recovery for file 2 block 1618943
Block recovery from logseq 4, block 63 to scn 7662329350
Wed Dec 23 15:19:24 2015
Recovery of Online Redo Log: Thread 1 Group 1 Seq 4 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\xxxx\REDO01.LOG
Block recovery completed at rba 4.4749.16, scn 1.3367362055
Wed Dec 23 15:21:28 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\udump\xxxx_ora_1712.trc:
ORA-00600: internal error code, arguments: [4194], [45], [45], [], [], [], [], []
ORA-00600: internal error code, arguments: [4194], [45], [45], [],
.....
Wed Dec 23 16:47:26 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_p005_8980.trc:
ORA-00600: internal error code, arguments: [2037], [141460651], [141460651], [162], [6], [1], [3367403517], [3141222167]
Wed Dec 23 16:47:26 2015
Hex dump of (file 92, block 3926982) in trace file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw0_8864.trc
Corrupt block relative dba: 0x173bebc6 (file 92, block 3926982)
Bad header found during preparing block for write
Data in bad block:
 type: 23 format: 7 rdba: 0xbd3b3f17
 last change scn: 0x0001.c8b6be51 seq: 0x5 flg: 0x00
 spare1: 0x3b spare2: 0xbc spare3: 0xc
 consistency value in tail: 0xbe511705
 check value in block header: 0x0
 block checksum disabled
Wed Dec 23 16:47:26 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_p005_8980.trc:
ORA-00600: internal error code, arguments: [2037], [141460651], [141460651], [162], [6], [1], [3367403517], [3141222167]
 
Wed Dec 23 16:47:27 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw0_8864.trc:
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], []
 
Wed Dec 23 16:47:27 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw0_8864.trc:
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], []
 
DBW0: terminating instance due to error 471
我们可以看到，这个数据库已经宕机好几天了，在23号的时候就已经无法正常open了。上述的结果错误也很常见很简单。朋友经过处理后顺利把数据库open了，可是打开之后创建新的undo 表空间之后尝试重启后就再也打开不开了。遇到了如下的错误：

Fri Dec 25 11:44:17 2015
Recovery of Online Redo Log: Thread 1 Group 3 Seq 6 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\xxxx\REDO03.LOG
Fri Dec 25 11:44:17 2015
Completed redo application
Fri Dec 25 11:44:17 2015
Hex dump of (file 44, block 518322) in trace file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw2_21232.trc
Corrupt block relative dba: 0x0b07e8b2 (file 44, block 518322)
Bad header found during preparing block for write
Data in bad block:
 type: 82 format: 2 rdba: 0x1c4ee895
 last change scn: 0x0001.c8bbad54 seq: 0x21 flg: 0xf0
 spare1: 0x52 spare2: 0x4d spare3: 0x895b
 consistency value in tail: 0xad545221
 check value in block header: 0x0
 block checksum disabled
Fri Dec 25 11:44:18 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw2_21232.trc:
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], []
 
Fri Dec 25 11:44:18 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_dbw2_21232.trc:
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], []
 
DBW2: terminating instance due to error 471
Fri Dec 25 11:44:18 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_p014_20704.trc:
ORA-00471: DBWR process terminated with error
这个错误我也是第一次遇见。从kcbzpbuf函数来看，是dbwr进出写脏块时发现了坏块。很明显，从上面的坏块信息来看，dba地址0x0b07e8b2 和 rdba地址0x1c4ee895是不匹配，这肯定没法正常写入的。
针对这个错误我事后在metalink 搜索了一下，还是有不少相关的文档甚至是bug，这里不多说了。处理方式很简单，首先加入如下2个隐含参数尝试打开数据库：
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE
做了不完全恢复后，尝试open resetlogs时发现遇到了如下错误：

ri Dec 25 12:20:03 2015
SMON: enabling cache recovery
Fri Dec 25 12:20:04 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\udump\xxxx_ora_20176.trc:
ORA-00600: internal error code, arguments: [2662], [1], [3367742663], [1], [3367742798], [4194313], [], []
 
Fri Dec 25 12:20:05 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\udump\xxxx_ora_20176.trc:
ORA-00600: internal error code, arguments: [2662], [1], [3367742663], [1], [3367742798], [4194313], [], []
 
Fri Dec 25 12:20:05 2015
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Fri Dec 25 12:20:05 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_p015_21472.trc:
ORA-00600: internal error code, arguments: [15784], [600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
 
Fri Dec 25 12:20:05 2015
Errors in file d:\oracle\product\10.2.0\admin\xxxx\bdump\xxxx_p014_9072.trc:
ORA-00600: internal error code, arguments: [15784], [600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
看到这里2个错误，很多人可能会很迷惑，到底数据库无法open是因为哪个错误导致的呢？ 这里稍微注意一下前后报错的顺序就知道了，很明显是前面的ora-00600 [2662]错误导致无法open resetlogs完成。
对于ora-00600 [2662]错误这里不再解释了，SCN的问题。这里直接推进scn即可。
将数据库启动到mount状态，执行如下命令：

SQL> alter system set job_queue_processes=0;
 
Session altered.
 
SQL> startup mount
ORACLE instance started.
 
Total System Global Area 7516192768 bytes
Fixed Size                  2175728 bytes
Variable Size            1232850192 bytes
Database Buffers         6274678784 bytes
Redo Buffers                6488064 bytes
Database mounted.
SQL> alter session set events 'IMMEDIATE trace name adjust_scn level 10';
 
Session altered.
 
SQL> alter database open;
 
Database altered.
很顺利就打开了数据库。由于之前朋友已经创建了新的undo表空间，我只需要帮忙把undo重建就完事了，结束支持任务。尝试进行drop tablespace undotbs1 including contents and datafiles时，遇到ora-01548错误。
在alter session set “_smu_debug_mode” = 4; 后都无法进行drop，那只能继续使用下隐含参数了：

_offline_rollback_segments
_corrupted_rollback_segments
通过这2个隐含参数，可以顺利将旧的undo 表空间drop掉，然后修改pfile文件去掉不需要的一些隐含参数，顺利打开数据库。
到这里结束我的半小时支持友情支持任务！悲剧的下午又开始优化某客户的SQL。。。。。
备注：
1) 对于这种异常强制打开的数据库，建议进行全库检查，包括是否有坏块等，甚至检查数据字典是否一致等等（实际上检查之前的alert log发现，    之前数据库在恢复过程中就报了不少的坏块)
2) 在这个年代，还有3TB的数据库，而且是windows，更悲剧的还是非归档，没有备份，这是不应该的。
3) 我们应该多考虑下系统的容灾建设，哪怕是有备份。

时间： 2024-12-25 09:05:58

windowsTB 非归档Oracle数据库恢复小case的相关文章

Oracle 数据库 恢复

导入工具imp交互式命令行方式: 在Windows cmd命令窗口输入imp回车,出现下面的信息 Import: Release 11.2.0.1.0- Production on Tue Sep 27 23:48:11 2011 Copyright (c) 1982,2009, Oracle and/or its affiliates.  Allrights reserved. 下面输入的用户名及密码是执行导出操作时使用的用户和相应口令. Username: 用户名 Password: 输入对

Oracle数据库数据丢失恢复的几种方法总结_oracle

根据oracle数据库的特点和提供的工具,主要方法有以下几种方法:      利用逻辑备份使用import工具丢失数据的表      利用物理备份来通过还原数据文件并进行不完全恢复      利用dbms_logmnr包从redo log文件中恢复      利用flashback特性恢复数据 前提 为了方便使用方法的介绍,上述恢复方法都将基于以下场景进行:系统管理员在前一天晚上11点用export对数据库做了全库逻辑备份,然后对所有数据文件进行了热备份.第二天上午10点,系统管理员在修改表TF

Oracle归档模式和非归档模式

Oracle归档模式和非归档模式 解释归档和非归档模式之间的不同和它们各自的优缺点? 答:归档模式是指可以备份所有的数据库transactions并恢复到任意一个时间点.         非归档模式则相反,不能恢复到任意一个时间点.         但是非归档模式可以带来数据库性能上的少许提高. 记忆方式:归档模式>热备份>恢复任意时间点>性能少许下降                       非归档模式>冷备份>恢复完全备份>性能少许提高 一.查看oracle数据库

Oracle数据库异常恢复前备份保护现场建议

无论是在各种会议上,还是在朋友/网友私下请教Oracle数据库恢复的问题之时,我都强调,如果你没有十足的把握,请你对您的现场进行备份,确保别对现场进行二次损坏.你不能恢复数据库,但绝对不能再次破坏数据库,给二次恢复增加难度.这里对恢复前备份提供一些指导思想和简单脚本,希望对大家有帮助. 哪些文件需要备份 熟悉数据库恢复的朋友可能都情况,Oracle在异常恢复的过程中主要修改的是system表空间里面数据,其他数据文件,redo数据,控制文件(当然由于redo,undo导致其他数据文件内部的blo

Oracle实例恢复和介质恢复

Oracle恢复基础概述  一.恢复解决方案 错误类型及解决方案 错误分类 恢复解决方案 介质失败 如果是少量的块损坏,使用块介质恢复:如果是大量的块.数据文件.表空间的损坏,可能需要对损坏的数据文件或者表空间执行完全恢复:如果是归档Redo日志文件或者联机Redo日志文件的丢失,那么只需要不完全恢复方式. 逻辑损坏 如果是程序员错误导致出现的问题,可通过补丁应用修复问题.对于无法修复的问题,也可采用介质恢复手段来恢复数据. 用户错误 根据不同用户错误,选择不同的Flashback技术恢复,使用

Oracle数据库的启动和关闭方式小结

oracle|数据|数据库 Oracle数据库的启动和关闭方式 一.几种启动方式: 1.startup nomount     非安装启动,这种方式启动下可执行:重建控制文件.重建数据库     启动instance,即启动SGA和后台进程,这种启动只需要init.ora文件.  2.startup mount dbname     安装启动,这种方式启动下可执行:数据库日志归档.数据库恢复.重新命名一些数据库文件     如:系统表空间或日志文件.     执行"nomount",然

Windows Server 2008 下ASP程序连接ORACLE数据库驱动错误

今天开发那边升级.改造系统过程中,在测试服务器碰到关于ASP程序连接ORACLE数据库的小问题,虽然是小问题,但是整起来真要命啊,花了不少时间,主要是ASP程序啊,这种上古神器,哥还是当年毕业的时候弄过半年,现在基本上忘得七七八八了. 环境介绍:在系统Windows Server 2008下部署了ASP应用程序,IIS为7.0版本,ORACLE 客户端为 11g,测试连接数据库报错的情况如下: 数据库链接方式如下: application("Connection_ConnectionString

Oracle RMAN还原与恢复讲解（四）如何在非归档模式中还原与恢复数据库

如果数据库在noarchivelog模式下,我们将从完全的脱机备份中恢复这个数据库,并且不可能实现时间点恢复. 1.还原的准备工作 如果在noarchivelog 模式中运行数据库并且假定拥有数据库的一个备份,就可以非常容易地执行数据库的完全恢复. 首先要清理所有的数据文件,以及旧的重做日志和控制文件. 虽然不是一定要这么做,但由于使用了noarchivelog模式,我们希望一切从头开始. 清理完数据文件,控制文件和重做日志后,就可以开始启动恢复进程. 首先,可以从最近生成的备份中恢复控制文件,

Oracle RMAN还原与恢复讲解（五）如何在归档模式中恢复数据库

1.故障点数据库恢复 对于故障点(point-of-failure)的恢复,也称为完全数据库恢复,此时必须要求联机重做日志是完整无损的. 如果丢失了联机重做日志,就必须对数据库做不完全恢复. 我们假设联机重做日志和控制文件完整无损,此时我们通过以下步骤来完全恢复数据库: Shutdown immediate; Startup mount; Restore database; Recover database; Alter database open; 这种恢复操作比较简单,但是有几点需要注意.