标签云
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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- 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备份恢复 (661)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- 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)
- MongoDB (1)
-
最近发表
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次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
分类目录归档:数据库
一次非常幸运的ORA-600 16703(tab$被清空)故障恢复
这次的ORA-600 16703的故障比较特殊,客户的一套rac运行了5年多没有重启,这次由于异常导致其中一个节点重启,然后触发了tab$被清空,异常节点启动报ORA-600 16703错误.朋友在故障之后,第一时间没有对在运行的节点进行重启(虽然也无法对外提供业务服务),使得恢复工作相对简单一些,恢复效果也是最完美的.这个是我在对于软件安装介质注入恶意脚本,300天之后重启触发tab$被清空的相关恢复case中,最完美的一次(以前遇到过一次客户是虚拟化环境通过cdp回退然后类似方法处理ORA-600 16703直接把orachk备份表插入到tab$恢复),凸显了这位朋友在故障发生之后对于问题的准确判断和果断的应对能力.
有朋友和我反馈,他们数据库突然报大量ORA-600错误,业务无法正常操作,我分析相关日志确认:节点2重启之后节点1开始报大量ORA-600错误,但是节点一直处于open状态
Fri Jul 25 15:28:53 2025 Decreasing number of real time LMS from 3 to 0 Fri Jul 25 15:29:18 2025 Reconfiguration started (old inc 13, new inc 15) List of instances: 1 2 (myinst: 1) Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Fri Jul 25 15:29:18 2025 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Fri Jul 25 15:29:18 2025 LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Fri Jul 25 15:29:18 2025 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Set master node info Submitted all remote-enqueue requests Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted Submitted all GCS remote-cache requests Fix write in gcs resources Reconfiguration complete Fri Jul 25 15:29:20 2025 minact-scn: Master returning as live inst:2 has inc# mismatch instinc:0 cur:15 errcnt:0 Fri Jul 25 15:30:07 2025 Errors in file /u01/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_252634.trc (incident=77234): ORA-00600: internal error code, arguments: [ktsircinfo_num1], [0], [0], [0], [],[],[],[],[],[],[],[] Incident details in: /u01/oracle/diag/rdbms/orcl/orcl1/incident/incdir_77234/orcl1_ora_252634_i77234.trc Fri Jul 25 15:30:18 2025 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Fri Jul 25 15:30:19 2025 Sweep [inc][77234]: completed Sweep [inc2][77234]: completed Fri Jul 25 15:30:27 2025 Errors in file /u01/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_261587.trc (incident=76487): ORA-00600: internal error code, arguments: [ktsircinfo_num1],[0],[0],[0], [], [], [], [], [], [], [], []
通过grep筛选报错信息
[root@iZbp11c0qyuuo1gr7j98upZ tmp]# egrep "ORA-00600|ORA-07445" alert_1.txt |sort -u ORA-00600: internal error code, arguments: [25027], [0], [0], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [kkpo_rcinfo_defstg:delseg], [28941391], [], [], [], [] ORA-00600: internal error code, arguments: [ktsircinfo_num1], [0], [0], [0], [], [], [], [], [], [] ORA-00600: 内部错误代码, 参数: [16659], [kqldtu], [DEL], [0], [35038924], [], [], [], [], [], [], [] ORA-00600: 内部错误代码, 参数: [16659], [kqldtu], [INS], [0], [277736], [], [], [], [], [], [], [] ORA-00600: 内部错误代码, 参数: [16659], [kqldtu], [INS], [0], [28829570], [], [], [], [], [], [], [] ORA-07445: exception encountered: core dump [qknSetParent()+9] [SIGSEGV] [ADDR:0x10354] [PC:0x1A48B9B] [Address not mapped to object] [] ORA-07445: exception encountered: core dump [qksxaMoveQbAnnotations()+168] [SIGSEGV] [ADDR:0x20304] [PC:0x1594954] [Address not mapped to object] [] ORA-07445: 出现异常错误: 核心转储 [qknExpRegIni_int()+87] [SIGSEGV] [ADDR:0x8C] [PC:0x1A4D729] [Address not mapped to object] [] ORA-07445: 出现异常错误: 核心转储 [qksxaMoveQbAnnotations()+168] [SIGSEGV] [ADDR:0x0] [PC:0x1594954] [SI_KERNEL(general_protection)] []
既然是由于节点2重启导致节点1报错,那分析节点2重启相关情况,第一次重启成功之后,数据库开始报ORA-600错误
Fri Jul 25 15:29:29 2025
QMNC started with pid=46, OS id=363757
Fri Jul 25 15:29:31 2025
minact-scn: Inst 2 is a slave inc#:15 mmon proc-id:363622 status:0x2
minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000
Fri Jul 25 15:29:33 2025
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_m003_363779.trc (incident=248519):
ORA-00600: internal error code, arguments: [kgmfvmi#3], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl2/incident/incdir_248519/orcl2_m003_363779_i248519.trc
Starting background process SMCO
Fri Jul 25 15:29:35 2025
SMCO started with pid=57, OS id=363802
Fri Jul 25 15:29:35 2025
Completed: ALTER DATABASE OPEN /* db agent *//* {2:23784:2} */
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_m003_363779.trc (incident=248520):
ORA-00600: internal error code, arguments: [kgmfvmi#3], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl2/incident/incdir_248520/orcl2_m003_363779_i248520.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x10] [PC:0x2FDA4BB,kgmdelsis()+219][flags:0x0,count:1]
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_m003_363779.trc (incident=248521):
ORA-07445: exception encountered: core dump [kgmdelsis()+219] [SIGSEGV]
[ADDR:0x10] [PC:0x2FDA4BB] [Address not mapped to object] []
ORA-00600: internal error code, arguments: [kgmfvmi#3], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl2/incident/incdir_248521/orcl2_m003_363779_i248521.trc
Use ADRCI or Support Workbench to package the incident.
Fri Jul 25 15:29:47 2025
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_363808.trc (incident=248559):
ORA-00600: internal error code, arguments: [kkposds2], [18446744073709551615], [18446744073709551615],
[18446744073709551615], [], [], [], [], [], [], [], []
然后第二次重启数据库无法open成功,而是报ORA-600 16703错误
ALTER DATABASE OPEN /* db agent *//* {2:21799:2} */
Picked broadcast on commit scheme to generate SCNs
ARCH: STARTING ARCH PROCESSES
Fri Jul 25 15:41:23 2025
ARC0 started with pid=39, OS id=369231
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Fri Jul 25 15:41:24 2025
ARC1 started with pid=40, OS id=369242
Fri Jul 25 15:41:24 2025
ARC2 started with pid=41, OS id=369244
Fri Jul 25 15:41:24 2025
ARC3 started with pid=42, OS id=369246
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Thread 2 opened at log sequence 33585
Current log# 7 seq# 33585 mem# 0: +DATA/orcl/onlinelog/group_7.269.1011373611
Successful open of redo thread 2
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_369210.trc (incident=260494):
ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl2/incident/incdir_260494/orcl2_ora_369210_i260494.trc
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
SUCCESS: diskgroup FRA was mounted
Fri Jul 25 15:41:30 2025
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_369210.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_369210.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [], [], [], [], [], [], []
Error 704 happened during db open, shutting down database
USER (ospid: 369210): terminating the instance due to error 704
Instance terminated by USER, pid = 369210
ORA-1092 signalled during: ALTER DATABASE OPEN /* db agent *//* {2:21799:2} */...
opiodr aborting process unknown ospid (369210) as a result of ORA-1092
Fri Jul 25 15:41:31 2025
ORA-1092 : opitsk aborting process
到这一步基本上就清晰了,大概率是遭遇到以前恢复的类似case,tab$数据被清空导致,类似案例
ORA-600 16703故障解析—tab$表被清空
警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703
通过在故障主机上找到安装介质,验证md5确认该程序是被注入恶意代码程序

这个库由于还有一个节点处于open状态,相对处理比较简单,直接把备份的表数据反向插入回去即可
SYS@orcl1> select count(1) from ORACHK3C08C86E063530510ACD937;
COUNT(1)
----------
20696
SYS@orcl1> insert into tab$ select * from ORACHK3C08C86E063530510ACD937;
20696 rows created.
SYS@orcl1> commit;
Commit complete.
SYS@orcl1> select object_name,to_char(CREATED,'yyyy-mm-dd hh24:mi:ss') from dba_objects
2 where object_name in('DBMS_SUPPORT_DBMONITOR','DBMS_SUPPORT_DBMONITORP');
OBJECT_NAME TO_CHAR(CREATED,'YY
-------------------------------------------- -------------------
DBMS_SUPPORT_DBMONITORP 2019-06-19 17:06:46
DBMS_SUPPORT_DBMONITOR 2019-06-19 17:06:46
这次故障能够快速顺利的恢复,和客户发现故障之后保留第一现场,没有把一个open的节点也重启有很大关系,open的节点也重启了,那后续恢复工作会麻烦很多,效果可能也没有这样的完美.
发表在 非常规恢复
标签为 DBMS_SUPPORT_DBMONITOR, ktsircinfo_num1, ORA-600 16703, ora-600 kgmfvmi#3, tab$恢复, tab$清空恢复
评论关闭
Oracle 19c 202507补丁(RUs+OJVM)-19.28
| 19.0.0.0 | |||
| Description | Database Update | GI Update | Windows Bundle Patch |
| JUL2025 (19.28.0.0.0) | 37960098 | 37957391 | 37962957 |
| APR2025 (19.27.0.0.0) | 37642901 | 37641958 | 37532350 |
| JAN2025 (19.26.0.0.0) | 37260974 | 37257886 | 37486199 |
| OCT2024 (19.25.0.0.0) | 36912597 | 36916690 | 36878821 |
| JUL2024 (19.24.0.0.0) | 36582781 | 36582629 | 36521936 |
| APR2024 (19.23.0.0.0) | 36233263 | 36233126 | 36219938 |
| JAN2024 (19.22.0.0.0) | 35943157 | 35940989 | 35962832 |
| OCT2023 (19.21.0.0.0) | 35643107 | 35642822 | 35681552 |
| JUL2023 (19.20.0.0.0) | 35320081 | 35319490 | 35348034 |
| APR2023 (19.19.0.0.0) | 35042068 | 35037840 | 35046439 |
| JAN2023 (19.18.0.0.0) | 34765931 | 34762026 | 34750795 |
| Oct2022 (19.17.0.0.0) | 34419443 | 34416665 | 34468114 |
| JUL2022 (19.16.0.0.0) | 34133642 | 34130714 | 34110685 |
| APR2022 (19.15.0.0.0) | 33806152 | 33803476 | 33829175 |
| JAN2022 (19.14.0.0.0) | 33515361 | 33509923 | 33575656 |
| OCT2021(19.13.0.0.0) | 33192793 | 33182768 | 33155330 |
| JUL2021 (19.12.0.0.0) | 32904851 | 32895426 | 32832237 |
| APR2021 (19.11.0.0.0) | 32545013 | 32545008 | 32409154 |
| JAN2021 (19.10.0.0.0) | 32218454 | 32226239 | 32062765 |
| OCT2020 (19.9.0.0.0) | 31771877 | 31750108 | 31719903 |
| JUL2020 (19.8.0.0.0) | 31281355 | 31305339 | 31247621 |
| APR2020 (19.7.0.0.0) | 30869156 | 30899722 | 30901317 |
| JAN2020 (19.6.0.0.0) | 30557433 | 30501910 | 30445947 |
| OCT2019 (19.5.0.0.0) | 30125133 | 30116789 | 30151705 |
| JUL2019 (19.4.0.0.0) | 29834717 | 29708769 | NA |
| APR2019 (19.3.0.0.0) | 29517242 | 29517302 | NA |
| 19.0.0.0 | |||
| Description | OJVM Update | OJVM + DB Update | OJVM + GI Update |
| JUL2025 (19.28.0.0.250715) | 37847857 | 37952354 | 37952382 |
| APR2025 (19.27.0.0.250415) | 37499406 | 37591483 | 37591516 |
| JAN2025 (19.26.0.0.250121) | 37102264 | 37262172 | 37262208 |
| OCT2024 (19.25.0.0.241015) | 36878697 | 36866623 | 36866740 |
| JUL2024 (19.24.0.0.240716) | 36414915 | 36522340 | 36522439 |
| APR2024 (19.23.0.0.240416) | 36199232 | 36209492 | 36209493 |
| JAN2024 (19.22.0.0.240116) | 35926646 | 36031426 | 36031453 |
| OCT2023 (19.21.0.0.231017) | 35648110 | 35742413 | 35742441 |
| JUL2023 (19.20.0.0.230718) | 35354406 | 35370174 | 35370167 |
| APR2023 (19.19.0.0.230418) | 35050341 | 35058163 | 35058172 |
| JAN2023 (19.18.0.0.230117) | 34786990 | 34773489 | 34773504 |
| OCT2022 (19.17.0.0.221018) | 34411846 | 34449114 | 34449117 |
| JUL2022 (19.16.0.0.220719) | 34086870 | 34160831 | 34160854 |
| APR2022 (19.15.0.0.220419) | 33808367 | 33859194 | 33859214 |
| JAN2022 (19.14.0.0.220118) | 33561310 | 33567270 | 33567274 |
| OCT2021 (19.13.0.0.211019) | 33192694 | 33248420 | 33248471 |
| JUL2021 (19.12.0.0.210720) | 32876380 | 32900021 | 32900083 |
| APR2021 (19.11.0.0.210420) | 32399816 | 32578972 | 32578973 |
| JAN2021 (19.10.0.0.210119) | 32067171 | 32126828 | 32126842 |
| OCT2020 (19.9.0.0.201020) | 31668882 | 31720396 | 31720429 |
| JUL2020 (19.8.0.0.200714) | 31219897 | 31326362 | 31326369 |
| APR2020 (19.7.0.0.200414) | 30805684 | 30783543 | 30783556 |
| JAN2020 (19.6.0.0.200114) | 30484981 | 30463595 | 30463609 |
| OCT2019 (19.5.0.0.191015) | 30128191 | 30133124 | 30133178 |
| JUL2019 (19.4.0.0.190716) | 29774421 | 29699079 | 29699097 |
| APR2019 (19.3.0.0.190416) | 29548437 | 29621253 | 29621299 |
参考:Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)
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)

