预备知识 控制文件相关 scn v$database. checkpoint_change# v$datafile. checkpoint_change# 点击输入文字 数据文件相关 scn v$datafile_header.checkpoint_change# 数据库干净判断 v$datafil

Oracle 数据库非常规恢复之道 程飞 网名 : 惜分飞 QQ 号 :107644445 邮箱 :dba@xifenfei.com 技术 BLOG:www.xifenfie.com

预备知识 控制文件相关 scn v$database. checkpoint_change# v$datafile. checkpoint_change# 点击输入文字 数据文件相关 scn v$datafile_header.checkpoint_change# 数据库干净判断 v$datafile_header.fuzzy( 数据文件头 ) v$datafile.last_change#( 控制文件 ) dump 分析 alter system dump datafile /u01/oradata/orcl/system01.dbf block 60;--dump block(mount 状态 ) ALTER SESSION SET EVENTS 'immediate trace name file_hdrs level 10';--File Header ALTER SESSION SET EVENTS 'immediate trace name controlf level 10';--Control file ALTER SESSION SET EVENTS 'immediate trace name redohdr level 10 ;--Redo log Header 数据库 open 过程 (10046 跟踪 ) alter session set events '10046 trace name context forever, level 12';

Oracle 数据库非常规恢复招式 招式一 : 点击输入文字 通过隐含参数,event 等方式强制 open 数据库 ; 招式二 : 通过 bbed,kfed,dd,ue 等工具欺骗数据库然后 open 数据库 ; 招式三 : 通过 dul 之类工具直接绕过数据库验证直接读取文件恢复数据

招式一 : 隐含参数,event 等方式强制 open 数据库 _allow_resetlogs_corruption Actvie/Current redo log 坏块,IO 错误, 丢失等因为 redo log 异常导致数据库不能启动主要是屏蔽 redo 前滚, 强制打开数据库, 可能导致 redo 中数据丢失, 使用需要慎重 _offline/corrupted_rollback_segments Undo 段出现异常无法正常回滚回滚事务, 导致数据库无法打开, 例如含回滚事务的回滚段 block 出现坏块,undo 文件丢失, 回滚段和 redo 前滚信息不一致等 通过设置该参数屏蔽回滚段 ( 该回滚段未提交事务自动提交 ), 将导致数据不一致, 使用需要慎重 部分 event event= 10513 trace name context forever, level 2 -- 设置 10513 事件来临时禁止 SMON 恢复事务 event= 10231 trace name context forever, level 10 跳过全表扫描坏块

举例说明 ( 一 ) SQL> startup ORACLE 例程已经启动 Total System Global Area 1581916160 bytes Fixed Size Variable Size Database Buffers Redo Buffers 1336060 bytes 964693252 bytes 603979776 bytes 11907072 bytes 数据库装载完毕 ORA-00368: 重做日志块中的校验和错误 ORA-00353: 日志损坏接近块 12014 更改 9743799889 时间 12/05/2011 09:21:11 ORA-00312: 联机日志 3 线程 1: 'R:\ORADATA\HZYL\REDO03.LOG SQL> col member for a35 SQL> select a.group#,a.status,b.member from v$log a,v$logfile b 2 where a.group#=b.group#; GROUP# STATUS MEMBER ---------- ---------------- ----------------------------------- 3 CURRENT R:\ORADATA\HZYL\REDO03.LOG 2 INACTIVE R:\ORADATA\HZYL\REDO02.LOG 1 INACTIVE R:\ORADATA\HZYL\REDO01.LOG

SQL> recover database until cancel; SQL>alter database open resetlogs ORA-01547: 警告 : RECOVER 成功但 OPEN RESETLOGS 将出现如下错误 ORA-01194: 文件 1 需要更多的恢复来保持一致性 ORA-01110: 数据文件 1: 'R:\ORADATA\HZYL\SYSTEM01.DBF 设置 _allow_resetlogs_corruption=true recover database until cancel; alter database open resetlogs; 导出导入重建数据库

举例说明 ( 二 ) 数据库启动 alert 日志报如下错误 Tue Feb 14 09:34:11 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_smon_2784.trc: ORA-01595: error freeing extent (2) of rollback segment (3)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [6], [30], [], [], [], [], [] Tue Feb 14 09:35:34 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\udump\interlib_ora_2824.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], []

设置 undo manual 管理模式 undo_tablespace=system undo_management=manual 数据库未启动成功, 依然报 ORA-600[4193/4194] _offline_rollback_segments=_syssmu3$ 启动数据库成功, 创建新 undo, 删除故障 undo 导出导入重建数据库

招式二 : 通过 bbed,kfed,dd,ue 等工具 欺骗数据库然后 open 数据库 bbed BBED 是 Oracle 的一款内部工具, 可以直接修改 Oracle 数据文件块的内容, 在一些极端恢复场景下比较有用 使用起来也很方便, 但该工具 不受 Oracle 支持, 所以默认是没有生成可执行文件的, 在使用前需要编译 (11g 开始 Oracle 软件不含编译文件需要从 10g 中拷贝 ) kfed kfed 是一个没有官方文档记录的 ASM 工具, 它可以用来读取和修改 ASM 的元数据块 它本身是一个独立的工具, 独立于 ASM 实例, 因此不 管实例是否启动,ASM 磁盘组是否 mount, 它都可以正常使用 kfed 最为强大的地方在于它可以修复 ASM 损坏的元数据 10g 需要人工编 译,11.2 及其以后版本直接使用 dd 主要是为了实现数据文件填充, 或者跳过坏块拼接文件 ue 主要是在某些特殊情况下, 用来分析二进制文件, 修改二进制文件等

bbed 修改 block 试验 SQL> create table hr.b(id number,name varchar2(100)) tablespace xff; SQL> insert into hr.b values(1, aaa ); SQL> Commit SQL> select rowid, 2 dbms_rowid.rowid_relative_fno(rowid)rel_fno, 3 dbms_rowid.rowid_block_number(rowid)blockno, 4 dbms_rowid.rowid_row_number(rowid) rowno 5 from hr.b; ROWID REL_FNO BLOCKNO ROWNO - - - AAAHytAACAAAAIKAAA 2 522 0 SQL> shutdown immediate

[oracle@localhost ~]$ bbed parfile=/tmp/parfile.cnf Password: BBED: Release 2.0.0.0.0 Limited Production on Sat Aug 20 17:10:24 2011 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. *************!!! For Oracle Internal Use only!!! *************** BBED> set dba 2,522 DBA 0x0080020a (8389130 2,522) BBED> find /c aaa File: /opt/oracle/oradata/xifenfei/xff01.dbf (2) Block: 522 Offsets: 8185 to 8191 Dba:0x0080020a 61616101 067735 BBED> dump /v offset 8185 File: /opt/oracle/oradata/xifenfei/xff01.dbf (2) Block: 522 Offsets: 8185 to 8191 Dba:0x0080020a - 61616101 067735 l aaa..w5

BBED> modify /c bbb Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /opt/oracle/oradata/xifenfei/xff01.dbf (2) Block: 522 Offsets: 8185 to 8191 Dba:0x0080020a 62626201 067735 BBED> sum apply Check value for File 2, Block 522: current = 0xa286, required = 0xa286 SQL> startup SQL> select * from hr.b; ID NAME - 1 bbb

通过 ue 修改 oracle 二进制文件修改执行计划 Ue 打开 oracle 二进制文件发现 sql 语句 数据库启动执行计划

通过 ue 修改后语句 修改之后的执行计划

招式三 : 通过 dul 之类的工具恢复 dul 是 oracle internal 工具, 在数据库不正常 open 情况下, 直接读取数据文件恢复数据内容 dul 主要用于以下场景恢复 1) 使用前面方法无法 open 的数据库 2)drop table 恢复 3)truncate table 恢复 4) 丢失 system 表空间 / 数据文件恢复 5) 删除表空间 ( 对应数据文件还存在 ) 6)asm 无法正常 mount 情况下, 恢复数据文件和表中数据

dul 使用基本演示 --init.dul 文件配置 osd_big_endian_flag=false osd_dba_file_bits=10 osd_c_struct_alignment=32 osd_file_leader_size=1 osd_word_size = 32 dc_columns=2000000 dc_tables=10000 dc_objects=1000000 dc_users=400 dc_segments=100000 Buffer=10485760 control_file = control.txt db_block_size=8192 export_mode=true compatible=10

dul 使用基本演示 --control 文件配置 通过启动数据库到 mount 执行 select ts#,rfile#,name from v$datafile 获得 [oracle@xifenfei dul]$ more control.txt 0 1 /u01/oracle/oradata/system01.dbf 1 2 /u01/oracle/oradata/undotbs01.dbf 2 3 /u01/oracle/oradata/sysaux01.dbf 4 4 /u01/oracle/oradata/users01.dbf 6 5 /u01/oracle/oradata/datfttuser.dbf

dul 使用基本演示 unload 数据 [oracle@xifenfei dul]$./dul Data UnLoader: 11.2.0.1.1 - Internal Only - on Sat Jan 07 07:02:34 2017 with 64-bit io functions and the decompression option Copyright (c) 1994 2016 Bernard van Duijnen All rights reserved. Strictly Oracle Internal Use Only Found db_id = 3426707456 Found db_name = xifenfei 加载数据字典 DUL> BOOTSTRAP; Unload table DUL> UNLOAD TABLE hr.test;

ORA-600[kcrf_resilver_log_1] 分享 Unpblished Bug 9056657: BOX REBOOT DURING UPGRADE CAUSED ORA-600 [KCRF_RESILVER_LOG_1] There has been a lost write to the online redolog as a result of the crash. The fix for this bug will raise a more meaning log corruption error rather than an ORa-00600 error. Instance recovery is not possible - restore the database and do point in time recovery to the most recent archivelog. 参考 :ORA-00600 [kcrf_resilver_log_1] on restart after system crash ( 文档 ID 1227666.1)

ORA-600[kcrf_resilver_log_1] 案例一 alert 日志报错 Sat Mar 01 18:40:44 2014 alter database open Beginning crash recovery of 1 threads parallel recovery started with 3 processes Started redo scan Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_6432.trc (incident=61360): ORA-00600: 内部错误代码, 参数 : [kcrf_resilver_log_1], [0x7FF61C56E30], [2], [], [], [], [], [], [], [], [], [] Incident details in: f:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_61360\orcl_ora_6432_i61360.trc Aborting crash recovery due to error 600 Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_6432.trc: ORA-00600: 内部错误代码, 参数 : [kcrf_resilver_log_1], [0x7FF61C56E30], [2], [], [], [], [], [], [], [], [], [] Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_6432.trc: ORA-00600: 内部错误代码, 参数 : [kcrf_resilver_log_1], [0x7FF61C56E30], [2], [], [], [], [], [], [], [], [], [] ORA-600 signalled during: alter database open...

数据文件 SCN( 来自控制文件 v$datafile) 数据文件头 SCN( 来自数据文件头 v$datafile_header)

SQL> recover database using backup controlfile until cancel; ORA-00279: 更改 16574746 ( 在 03/01/2014 13:10:11 生成 ) 对于线程 1 是必需的 ORA-00289: 建议 : F:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2014_03_01\O1_MF_1_1510_%U_.ARC ORA-00280: 更改 16574746 ( 用于线程 1) 在序列 #1510 中 指定日志 : {<RET>=suggested filename AUTO CANCEL} F:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG 已应用的日志 完成介质恢复 SQL> alter database open resetlogs; 数据库已更改

ORA-600[kcrf_resilver_log_1] 案例二 Tue Mar 04 09:19:22 2014 ALTER DATABASE OPEN Beginning crash recovery of 1 threads parallel recovery started with 32 processes Started redo scan Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4093.trc (incident=13393): ORA-00600: internal error code, arguments: [kcrf_resilver_log_1], [0x7C0E59B40], [2], [], [], [], [], [], [], [], [], [] Incident details in: /opt/oracle/diag/rdbms/orcl/orcl/incident/incdir_13393/orcl_ora_4093_i13393.trc Aborting crash recovery due to error 600 Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4093.trc: ORA-00600: internal error code, arguments: [kcrf_resilver_log_1], [0x7C0E59B40], [2], [], [], [], [], [], [], [], [], [] Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4093.trc: ORA-00600: internal error code, arguments: [kcrf_resilver_log_1], [0x7C0E59B40], [2], [], [], [], [], [], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN...

数据库 SCN 数据文件 SCN(v$datafile) 数据文件头 SCN(v$datafile_header)

直接应用 redo 恢复失败 增加 _allow_resetlogs_corruption 参数 ORA-00600: internal error code, arguments: [2662], [0], [48503075], [0], [48508238], [12583040], [], [], [], [], [], [] 推进 SCN(event, 隐含参数,bbed,oradebug 等等 ) ORA-01595: error freeing extent (3) of rollback segment (1)) ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] 使用 _offline_rollback_segments 屏蔽回滚段 数据库 open 成功, 逻辑导出导入重建库

故障后现场备份 FS 条件允许 对数据文件,redo 文件, 控制文件全备 FS 条件不允许 备份控制文件,system 数据文件, 其他文件头,redo 文件 ASM 磁盘组可以 mount 备份使用相关 v$ 或者 x$ 表备份文件头 ( 类似 FS 条件不允许情况下备份 ) ASM 不能 mount 条件允许直接对 asm disk 进行镜像 (dd, 存储复制 ) ASM 无法 mount 备份条件不允许 使用 dd 备份磁盘头前 100M

数据库异常恢复注意事项 1. 了解现场 ( 这个故障是怎么发生的, 为什么会发生这样的问题, 触发这类问题的原因, 正常运行 时库是怎么样的 ) 2. 备份现场 ( 进行操作之后, 不管什么后果都可以回退到初始介入状态 ) 3. 能够为自己的操作负责 ( 一个命令下去, 需要知道后果, 了解原理, 最好的效果是什么, 最坏的 后果是什么 ) 4. 通过非常规方法打开库之后, 建议逻辑方式重建库 (redo,undo, 推 scn,bbed 修改事务槽 / 文件 头等 ) 5. 尽可能最大限度恢复数据 ( 比如能够 open 的库, 一般不使用 dul), 尽快恢复业务, 当两者有冲突的时候 给多种恢复方案由客户决定

THANKS