标签云
asm恢复 asm 恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (101)
- 数据库 (1,629)
- DB2 (22)
- MySQL (71)
- Oracle (1,493)
- Data Guard (50)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle 23ai (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (48)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (545)
- Oracle安装升级 (89)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- oracle 23ai(23.5.0.24.07)完整功能版安装体验
- win平台安装oracle遭遇INS-30131处理
- 配置win环境ssh和sftp并实现免密登录
- 11.2.0.4最新psu-202407
- Oracle 19c 2024.07补丁(RUs+OJVM)
- ORA-00756 ORA-10567故障处理
- ORA-01092 ORA-00604 ORA-08103故障处理
- 数据库启动报ORA-600 6711故障分析处理
- RMAN SBT_TAPE备份无法被DISK通道识别
- ORA-27154 ORA-27300 ORA-27301 ORA-27302故障处理
- Patch SCN工具for Linux
- awr创建snapshot等待library cache: mutex X
- exadata换flash卡的一些操作
- RMAN-06207 RMAN-06208报错解决
- RAC主机相差超过10分钟导致crs无法启动
- O/S-Error: (OS 23) 数据错误(循环冗余检查)—故障处理
- 异常断电数据库恢复-从ORA-600 2131到ORA-08102: 未找到索引关键字, 对象号 39
- 数据泵迁移Wrapped PLSQL之后报PLS-00753
- 数据库open报ORA-600 kcratr_scan_lastbwr故障处理
- resetlogs强制拉库失败并使用备份system文件还原数据库故障处理
标签归档:system 删除恢复
dul无法加载bootstrap实现unload table/user恢复
最近有朋友误操作引起了非常大的事故,差点吃了官司.在做数据库迁移的时候,远程误操作删除了原库的system等几个数据库初始安装的文件,而且该磁盘空间使用率非常高,还有少量写入.最后结果比较悲剧,通过文件系统层面无法直接恢复出来数据文件,而且该库无任何有效备份,又没有表名,列名等信息,无奈之下只能通过底层io block重组来恢复数据文件,可是悲剧又一次发生,这个磁盘上以前也有一份system等文件,最后经过多方重组恢复出来一份相对理想的数据文件.但是第三方公司通过这样重组出来的数据文件和未被删除的业务文件恢复出来的数据大量有问题,依旧需要我们进一步分析恢复处理.这篇文章主要描述了dul在无法加载bootstrap命令之后通过一些方法依旧可以正常使用unload table/user 等命令实现数据尽可能恢复.你要知道几百张表没有表名/列名要把他们区分出来那是什么样的工作量……
在dul中配置system文件
D:\xifenfei\system01.dbf D:\TEMP\recover\dul\bak>dul Data UnLoader: 11.2.0.0.4 - Internal Only - on Wed Sep 28 17:01:56 2016 with 64-bit io functions Copyright (c) 1994 2016 Bernard van Duijnen All rights reserved. Strictly Oracle Internal Use Only DUL> show datafiles; Sorry, no valid data files found in control.txt
使用默认的dul中数据文件配置方法,让dul自己发现数据文件方法不可行
随意表空间号和文件号dul识别
0 0 D:\xifenfei\system01.dbf D:\TEMP\recover\dul\bak>dul Data UnLoader: 11.2.0.0.4 - Internal Only - on Wed Sep 28 17:00:27 2016 with 64-bit io functions Copyright (c) 1994 2016 Bernard van Duijnen All rights reserved. Strictly Oracle Internal Use Only DUL: Warning: File Type mismatch 1 != 8 DUL: Warning: D:\xifenfei\system01.dbf Header tablespace number 3 != 0 DUL: Warning: D:\xifenfei\system01.dbf Header relative file number 1 != 0 Found db_id = 2948357999 Found db_name = XIFENFEI DUL: Warning: Found mismatch while checking file D:\xifenfei\system01.dbf DUL: Warning: DUL osd_parameter or control.dul configuration error DUL: Warning: Given file number(0) in control file does not match file# in dba(1)
通过这个识别我们可以知道system的表空间号为3,文件号为1
再次配置system让dul识别
3 1 D:\xifenfei\system01.dbf D:\TEMP\recover\dul\bak>dul Data UnLoader: 11.2.0.0.4 - Internal Only - on Wed Sep 28 17:03:46 2016 with 64-bit io functions Copyright (c) 1994 2016 Bernard van Duijnen All rights reserved. Strictly Oracle Internal Use Only DUL: Warning: File Type mismatch 1 != 8 Found db_id = 2948357999 Found db_name = XIFENFEI DUL> show datafiles; ts# rf# start blocks offs open err file name 3 1 0 320257 0 1 0 D:\xifenfei\system01.dbf
dul正常识别出来system文件但是根据经验我们知道tablespace 3肯定是有问题的,因此后续操作依旧问题非常多
尝试dul bootstrap恢复失败
DUL> bootstrap; Scanning SYSTEM tablespace to locate compatibility segment ... DUL: Warning: No files found for tablespace 0 Reading EXT.dat 0 entries loaded and sorted 0 entries Reading SEG.dat 0 entries loaded Reading COMPATSEG.dat 0 entries loaded Reading SCANNEDLOBPAGE.dat 0 entries loaded and sorted 0 entries DUL: Error: No compatibility segments found
由于表空间号错误,dul无法加载到bootstrap$表,另外根据bbed分析恢复出来的system文件中bootstrap$这部分丢失
尝试人工加载dul所需数据字典
DUL> unload table OBJ$ 2 storage ( tablespace 3 segobjno 18 file 1 block 240); . unloading table OBJ$ 79074 rows unloaded DUL> unload table TAB$( OBJ# number, DATAOBJ# number, 2 cluster C_OBJ#(OBJ#) 3 storage ( tablespace 3 segobjno 2 tabno 1 file 1 block 144); . unloading table TAB$ 4482 rows unloaded DUL> unload table COL$ ( OBJ# number, COL# number , SEGCOL# number, 2 cluster C_OBJ#(OBJ#) 3 storage ( tablespace 3 segobjno 2 tabno 5 file 1 block 144); . unloading table COL$ 114491 rows unloaded DUL> unload table USER$ 2 cluster C_USER#(USER#) 3 storage ( tablespace 3 segobjno 10 tabno 1 file 1 block 208); . unloading table USER$ 96 rows unloaded ----其他表省略,根据需要的依次处理
尝试使用dul恢复数据
DUL> desc portal_emr.BASEELEMENT; Table PORTAL_EMR.BASEELEMENT obj#= 87200, dataobj#= 87200, ts#= 9, file#= 7, block#=458 tab#= 0, segcols= 8, clucols= 0 Column information: icol# 01 segcol# 01 BENAME len 30 type 1 VARCHAR2 cs 852(ZHS16GBK) icol# 02 segcol# 02 TYPENAME len 30 type 1 VARCHAR2 cs 852(ZHS16GBK) icol# 03 segcol# 03 TYPETYPE len 22 type 2 NUMBER(0,0) icol# 04 segcol# 04 BEXMLTEXT len 4000 type 1 VARCHAR2 cs 852(ZHS16GBK) icol# 05 segcol# 05 DEPTGROUPCODE len 30 type 1 VARCHAR2 cs 852(ZHS16GBK) icol# 06 segcol# 06 ISCOMMON len 22 type 2 NUMBER(0,0) icol# 07 segcol# 07 BESPELL len 15 type 1 VARCHAR2 cs 852(ZHS16GBK) icol# 08 segcol# 08 ELEMTYPE len 22 type 2 NUMBER(0) DUL> show datafiles; ts# rf# start blocks offs open err file name 3 1 0 320257 0 1 0 D:\xifenfei\system01.dbf 9 7 0 4170425 0 1 0 D:\BaiduYunDownload\PORTAL_EMR DUL> unload table portal_emr.BASEELEMENT; . unloading table BASEELEMENT 1913 rows unloaded
这里描述了在dul无法加载bootstrap命令之后,通过人工加载数据字典实现正常的unload table/user功能,丢弃了一般处理思路中的只能通过scan 然后unload没有表名,列名的处理方法,从而实现了恢复的最大化.
我们对原厂官方oracle dual工具有深入研究,如果在oracle dul恢复方面有搞不定的问题.
请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com