标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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)
- 操作系统 (112)
- 数据库 (1,875)
- DB2 (22)
- MySQL (82)
- Oracle (1,701)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (658)
- Oracle安装升级 (107)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
-
最近发表
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
- ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
标签归档:oracle 8.0.5
2025年的Oracle 8.0.5数据库恢复
在10多年前恢复过几个Oracle 8.0版本的库
记录8.0.5数据库恢复过程
ORACLE 8.0.5 ORA-01207故障恢复
记录一次AIX 4.3.0+ORACLE 8.0.5恢复过程
没有想到在2025年的7月份还有朋友咨询8.0.5的库恢复case.心中一阵小激动,回想到当年的很多过往(在邮储的机房里面恢复从保险柜中拿出来的小带库恢复8.0.5的库,问领导bbed资料答复网上都有的失落,朋友给我发一个dul的激动,拿到oracle vpn畅游在oracle的internal资料库的爽快等等),感觉这个8.0.5的库不单是一个case,更是一种情怀,大环境的去o,也是一种大浪逝去留下的无奈,不过总的来说也算为Oracle已经奉献了最好的青春和精力,也挺自豪的.这次的库恢复本身不难,简单的总结下:
准备环境
把数据文件发给了我,准备win xp环境的虚拟机并安装8.0.5的库(安装版本要和数据库文件版本一致)

把数据文件,redo等拷贝到虚拟机中,并使用rename file方式重命名文件路径
SVRMGR> alter database rename file 'D:\ORANT\DATABASE\SYS1ORCL.ORA' to 'C:\805\SYS1ORCL.ORA'; 语句已处理。 SVRMGR> alter database rename file 'D:\ORANT\DATABASE\USR1ORCL.ORA' to 'C:\805\USR1ORCL.ORA'; 语句已处理。 SVRMGR> alter database rename file 'D:\ORANT\DATABASE\RBS1ORCL.ORA' to 'C:\805\RBS1ORCL.ORA'; 语句已处理。 SVRMGR> alter database rename file 'D:\ORANT\DATABASE\TMP1ORCL.ORA' to 'C:\805\TMP1ORCL.ORA'; 语句已处理。 SVRMGR> alter database rename file 'D:\DATA\OXFF01' to 'C:\805\OXFF01'; 语句已处理。 ……………… SVRMGR> alter database rename file 'D:\DATA\XFF15' to 'C:\805\XFF15'; 语句已处理。 SVRMGR> alter database rename file 'D:\DATA\XFF16' to 'C:\805\XFF16'; 语句已处理。 Thu Jul 10 00:05:41 2025 alter database rename file 'D:\ORANT\DATABASE\LOG4ORCL.ORA' to 'C:\805\LOG4ORCL.ORA' Thu Jul 10 00:05:41 2025 Completed: alter database rename file 'D:\ORANT\DATABASE\LOG4 Thu Jul 10 00:05:41 2025 alter database rename file 'D:\ORANT\DATABASE\LOG3ORCL.ORA' to 'C:\805\LOG3ORCL.ORA' Completed: alter database rename file 'D:\ORANT\DATABASE\LOG3 Thu Jul 10 00:05:41 2025 alter database rename file 'D:\ORANT\DATABASE\LOG2ORCL.ORA' to 'C:\805\LOG2ORCL.ORA' Completed: alter database rename file 'D:\ORANT\DATABASE\LOG2 Thu Jul 10 00:05:43 2025 alter database rename file 'D:\ORANT\DATABASE\LOG1ORCL.ORA' to 'C:\805\LOG1ORCL.ORA' Completed: alter database rename file 'D:\ORANT\DATABASE\LOG1
尝试recover数据库
SVRMGR> recover database; ORA-00283: ?????????? ORA-01122: ?????29???? ORA-01110: ????29?'C:\805\XFF15' ORA-01200: 974848?????????2048000??????
报ORA-01200错误,比较明显29号文件本身大小应该是2048000个block,但是现在只有974848个
2025-06-30 11:30 4,194,306,048 XFF14 2022-06-30 09:02 1,996,490,752 XFF15 2022-06-30 09:02 4,194,306,048 XFF16
明显该XFF15文件大小和文件头记录的不匹配,对文件头进行修改(或者修改文件大小)类似处理方法:
bbed处理ORA-01200故障
记录一次ORA-01200完美恢复
ORA-01122 ORA-01200故障处理
ORA-1200/ORA-1207数据库恢复
BBED> map File: XFF15 (0) Block: 1 Dba:0x00000000 ------------------------------------------------------------ Data File Header struct kcvfh, 360 bytes @0 ub4 tailchk @2044 BBED> p kcvfhhdr.kccfhfsz ub4 kccfhfsz @44 0x001f4000 为16进制===>>等同10进制的2048000
继续尝试恢复并打开数据库
SVRMGR> recover database; 完成介质的恢复。 SVRMGR> alter database open; 语句已处理。 SVRMGR>
由于29号文件部分丢失,导出数据遭遇ORA-08103错误
模拟普通ORA-08103并解决
模拟极端ORA-08103并解决
数据库启动ORA-08103故障恢复
数据库打开遭遇ORA-08103故障处理
ORA-01092 ORA-00604 ORA-08103故障处理

对于这种错误,可以按照行的方式使用plsql进行逐行抽取,但是由于涉及的表比较多,比较麻烦,我这里直接使用dul对其进行抽取异常表

然后把导出来的dmp,结合dul恢复出来的异常表数据,整合到一起,完成本次8.0.5的数据库恢复
下次遇到该版本不知道是什么时候,截个图纪念下


加我微信(17813235971)
加我QQ(107644445)

