标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,769)
- DB2 (22)
- MySQL (77)
- Oracle (1,610)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (592)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
标签归档: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的数据库恢复
下次遇到该版本不知道是什么时候,截个图纪念下
