Database SOS – Professional Database Recovery Support@+8617813235971

Oracle 19c 202604补丁（RUs+OJVM）-19.31

标题：Oracle 19c 202604补丁（RUs+OJVM）-19.31

Release	Database Update	GI Update	Windows Bundle Patch
APR2026 (19.31.0.0.0)	39034528	-	38818049
JAN2026 (19.31.0.0.0)	-	39036936	-
JAN2026 (19.30.0.0.0)	38632161	38629535	38597735
OCT2025 (19.29.0.0.0)	38291812	38298204	38111211
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	-
APR2019 (19.3.0.0.0)	29517242	29517302	-

Release	OJVM Update	OJVM + DB Update	OJVM + GI Update
APR2026 (19.31.0.0.260421)	38906621	39062931	39062956
JAN2026 (19.30.0.0.260120)	38523609	38658587	38658588
OCT2025 (19.29.0.0.251021)	38194382	38273545	38273558
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 KA958

Oracle故障第一现场被恢复混乱的数据库恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle故障第一现场被恢复混乱的数据库恢复

有客户数据库断电异常之后,由于第三方进行了一系列的恢复,现场比较混乱,无法判断最初情况,通过Oracle Database Recovery Check收集的结果进行初步判断
1. 有三个文件处于丢失状态，并且数据库在故障之后被人强制resetlogs拉过库

2. 数据文件头scn不一致,而且相差的日志序列还比较大(该数据库为非归档模式)

3. 该库多次重建ctl(alert日志中也有相关记录)

现在恢复这个库需要做的几件事情:
1. 由于没有任何原始故障之后的控制文件,需要从服务器上找出来所有故障之时的数据文件,担心被人重建ctl使用了错误的数据文件
2. 对于三个file missing的进行分析,并确认磁盘上是否存在,是否是好的,如果是好的需要和现在的文件一起作为一个整体进行恢复,并打开库
3. 打开数据库过程可能遇到的错误处理

通过obet中近期增加的get_dbinfo功能来解析所有可能的数据文件头（obet官方说明）,结合文件头的信息判断,发现磁盘上名称dbf结尾的文件号重复

这样的情况下,我们取filesize大,（scn大不一定正确,可能由于被强制resetlogs导致scn比正确的文件大）,同时也结合这个收集的信息,确认三个丢失的文件中两个为undotbs1表空间文件,另外一个为112k的数据文件,这里让我学习到了新知识,oracle的数据文件最小可以多少个block(通过试验测试,最小可以16个block,文件大小即为:16+1(block 0)*block_size)

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on 星期三 5月 13 22:05:52 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 8k;
create tablespace tbs datafile 'e:/tbs01.dbf' size 8k
*
第 1 行出现错误:
ORA-03214: 指定的文件大小小于所需的最小值


SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 80k;
create tablespace tbs datafile 'e:/tbs01.dbf' size 80k
*
第 1 行出现错误:
ORA-03214: 指定的文件大小小于所需的最小值


SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 96k;

表空间已创建。

确认好相关信息之后,然后对于三个file missing状态的文件进行dbv检测确认undotbs01.dbf(file 3)基本上全部损坏（大量全0块）,另外两个文件正常

对于正常的文件通过obet修改相关scn信息

然后重建控制文件(丢弃undotbs01.dbf文件),由于确认undo已经异常,直接设置undo为manual管理方式并屏蔽回滚段,然后屏蔽一致性,强制打开数据库,结果报ORA-600 2662错误

使用Patch_SCN工具修改数据库scn(Patch_SCN工具说明)

然后数据库顺利打开,重建新undo,增加temp,删除老undo,导出数据完成本次恢复任务

impdp报ORA-39083 ORA-14102错误处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：impdp报ORA-39083 ORA-14102错误处理

最近两次遇到impdp 报 ORA-39083 ORA-14102错误

[oracle@localhost tmp]$ impdp "'/as sysdba'" directory=expdp_dir  full=y dumpfile=1.dmp 

Import: Release 11.2.0.1.0 - Production on Mon May 11 20:57:00 2026

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" directory=expdp_dir full=y dumpfile=1.dmp
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39083: Object type TABLE:"AAA"."XXXXX" failed to create with error:
ORA-14102: only one LOGGING or NOLOGGING clause may be specified
Failing sql is:
CREATE TABLE "AAA"."XXXX" ("OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE, "OBJECT_TYPE" VARCHAR2(8 BYTE) NOT NULL ENABLE
……………………

这个错误比较明显由于AAA.XXXX表的创建语句中有多于一个LOGGING or NOLOGGING,从而导致该创建语句无法正常创建表.

[oracle@iZbp11c0qyuuo1gr7j98upZ ~]$ oerr ora 14102
14102, 00000, "only one LOGGING or NOLOGGING clause may be specified"
// *Cause: LOGGING was specified more than once, NOLOGGING was specified
//         more than once, or both LOGGING and NOLOGGING were specified.
// *Action: Remove all but one of the LOGGING or NOLOGGING clauses and
//          reissue the statement.

查看该表对应的expdp导出日志

[oracle@xff expdmp]$ expdp "'/as sysdba'"  tables="AAA"."XXXX" dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT  

Export: Release 11.2.0.4.0 - Production on Mon May 11 21:01:06 2026

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01":  tables=AAA.XXXX dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT 
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 3.207 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
. . exported "AAA"."XXXX":"F_GTG"            5.430 MB  968776 rows
. . exported "AAA"."XXXX":"F_CONS"           4.734 MB  920007 rows
…………

比较明显AAA.XXXX表是一个分区表,而且是从11.2.0.4中导出,然后准备导入到11.2.0.1版本数据库中.通过DBMS_METADATA.get_ddl来获取该表的ddl语句确实有多个LOGGING/NOLOGGING(主要是每个分区都有NOLOGGING)

SET ECHO OFF
SET PAGESIZE 0
SET LINES 3000
SET LONG 200000
SET FEEDBACK OFF
SET HEADING OFF
SET SERVEROUTPUT ON SIZE 1000000
COLUMN TXT FORMAT A3000 WORD_WRAPPED
SQL> SQL> SELECT DBMS_METADATA.GET_DDL('TABLE','XXXX','AAA') TXT FROM DUAL;

  CREATE TABLE "AAA"."XXXX"
   (	"OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE,
	"OBJECT_TYPE" VARCHAR2(8) NOT NULL ENABLE,
	"DL_TYPE" VARCHAR2(8) NOT NULL ENABLE,
        ………………
 	CONSTRAINT "PK_OBJECT_DL_DEF" PRIMARY KEY ("OBJECT_ID", "OBJECT_TYPE", "DL_TYPE")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOLOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"  ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255  NOLOGGING
  STORAGE(
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"
  PARTITION BY LIST ("OBJECT_TYPE")
 (PARTITION "F_SUBS"  VALUES ('1') SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS NOLOGGING
  STORAGE(INITIAL 8388608 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS" ,
  ……………………

尝试在11.2.0.1环境中人工执行该sql创建表,直接报ORA-14020: 不能指定表分区的此物理属性错误

基于此基本上可以确认是由于11.2.0.1默认情况下不支持这样的语法,解决该问题的办法：
1. 重新导出来expdp dmp,加上version=11.2.0.1参数
2. impdp加上impdp TRANSFORM参数TRANSFORM=segment_attributes:n进行导入(impdp TRANSFORM参数)

一次断电引起的Oracle故障恢复-ora-600 2662故障

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：一次断电引起的Oracle故障恢复-ora-600 2662故障

接手一个oracle恢复case,由于断电导致oracle数据库异常,现场人员进行了一系列的恢复成功,但是没有成功open库,我接手故障之后尝试做recover 报ORA-16433错误

[oracle@xifenfei.com ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sun May 10 09:27:51 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> 
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.

根据经验这种错误一般是由于强制打开库失败导致,回溯oracle alert日志发现类似操作

Fri May 08 18:47:59 2026
ALTER DATABASE OPEN RESETLOGS
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 138986145572
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_ora_37813.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/data/oracle/oradata/xff/redo01.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1 /data/oracle/oradata/xff/redo01.log
Clearing online log 1 of thread 1 sequence number 2389
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_ora_37813.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/data/oracle/oradata/xff/redo01.log'
………………
Clearing online redo logfile 3 complete
Resetting resetlogs activation ID 677485461 (0x28619b95)
Online log /data/oracle/oradata/xff/redo01.log: Thread 1 Group 1 was previously cleared
Online log /data/oracle/oradata/xff/redo02.log: Thread 1 Group 2 was previously cleared
Online log /data/oracle/oradata/xff/redo03.log: Thread 1 Group 3 was previously cleared
Fri May 08 18:48:17 2026
Setting recovery target incarnation to 4
Fri May 08 18:48:17 2026
Assigning activation ID 677634815 (0x2863e2ff)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data/oracle/oradata/xff/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri May 08 18:48:18 2026
SMON: enabling cache recovery
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_ora_37813.trc  (incident=170321):
ORA-00600: internal error code, arguments: [2662], [32], [1547192107], [32], [1547212241], [12583040], []
Fri May 08 18:48:20 2026
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 /data/oracle/diag/rdbms/xff/xff/trace/xff_ora_37813.trc:
ORA-00600: internal error code, arguments: [2662], [32], [1547192107], [32], [1547212241], [12583040]
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_ora_37813.trc:
ORA-00600: internal error code, arguments: [2662], [32], [1547192107], [32], [1547212241], [12583040]
Error 600 happened during db open, shutting down database
USER (ospid: 37813): terminating the instance due to error 600
Instance terminated by USER, pid = 37813
ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS...

对于这种情况,先重建控制文件

SQL> @/tmp/rectl.sql

Control file created.

尝试recover database恢复

ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 96 slaves
Sun May 10 09:33:03 2026
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /data/oracle/oradata/xff/redo02.log
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_pr00_250074.trc  (incident=254397):
ORA-00353: log corruption near block 3 change 138986165586 time 05/08/2026 18:55:37
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/xff/redo02.log'
Incident details in: /data/oracle/diag/rdbms/xff/xff/incident/incdir_254397/xff_pr00_250074_i254397.trc
Sun May 10 09:33:04 2026
Media Recovery failed with error 399
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_pr00_250074.trc:
ORA-00283: recovery session canceled due to errors
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 3 change 138986165586 time 05/08/2026 18:55:37
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/xff/redo02.log'
ORA-10877 signalled during: ALTER DATABASE RECOVER  database  ...
Sun May 10 09:33:04 2026
Sweep [inc][254397]: completed
Errors in file /data/oracle/diag/rdbms/xff/xff/trace/xff_m000_250348.trc  (incident=255173):
ORA-00353: log corruption near block 3 change 138986165586 time 05/08/2026 18:55:37
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/xff/redo02.log'
Errors in file /data/oracle/diag/rdbms/xff/xff/incident/incdir_254397/xff_m000_250348_i254397_a.trc:
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 3 change 138986165586 time 05/08/2026 18:55:37
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/xff/redo02.log'
Errors in file /data/oracle/diag/rdbms/xff/xff/incident/incdir_254397/xff_m000_250348_i254397_a.trc:
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 3 change 138986165586 time 05/08/2026 18:55:37
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/xff/redo02.log'
Sun May 10 09:34:05 2026

由于无法正常recover 操作，数据库需要强制打开,考虑到之前该库open的过程有ORA-600 2662错误,这次在打开之前使用Patch_SCN调整SCN(关于Patch_SCN文章:Patch_SCN for Linux 功能完善

[oracle@xifenfei.com tmp]$ ./Patch_SCN 249756 0x205D38954E
Successfully obtained address automatically: 0x6001ae70
Original Oracle SCN at Address 0x6001ae70: 0x0
Are you sure you want to modify Oracle SCN? (yes/no): yes
New SCN at Address 0x6001ae70: 0x205d38954e
Oracle SCN successfully modified.

然后数据库顺利打开

在expdp导出数据过程中遇到了硬件错误

为了安全性采用库只读情况下exp进行导出,运气不错所有数据顺利导出,完成本次数据恢复任务

OraScan(Oracle 碎片扫描工具) 使用说明

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：OraScan(Oracle 碎片扫描工具) 使用说明

一、软件概述
1.1 软件简介
OraScan 是由惜分飞（官方网址：www.xifenfei.com）自主研发的专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题，适用于以下场景（不限于此）：
• 文件系统损坏，无法正常访问数据文件，且文件系统工具无法恢复；
• 误删除数据文件，操作系统层面的反删除工具无法恢复；
• 断电、文件系统故障导致数据文件变为 0KB，或文件大小异常；
• 小文件覆盖了大数据文件；
• 需要扫描磁盘上所有未被覆盖的 Oracle 数据块。

1.2 功能限制
• 对 bigfile 表空间数据文件支持较差，需人工干预；
• 对于 rfile 超过 1024 的数据文件，需人工干预。

1.3 适配环境（新手必看）
请根据自己的操作系统和 .NET Framework 版本，选择对应的软件可执行文件，避免无法运行：
1. .NET Framework 版本适配
￮ OraScan_Net2.exe：适配 .NET Framework 2.0、3.0、3.5 版本，兼容 Windows Server 2008 及更早操作系统；
￮ OraScan_Net4.exe：适配 .NET Framework 4.0 及以上版本，兼容 Windows Server 2012 及更新操作系统。
2. 数据库版本：支持 Oracle 9i 及以后所有版本；
3. 数据块大小：支持 4k、8k、16k、32k（需与数据库实际数据块大小一致）。
4. 支持win磁盘和镜像，支持linux/aix/hp-unix镜像

1.4 版权与技术支持
• 软件版权：归惜分飞（www.xifenfei.com）所有，未经授权不得擅自传播、修改；
• 技术支持（遇到问题可联系）：
￮ QQ：107644445
￮邮箱：dba@xifenfei.com
￮微信/电话：+86-17813235971

1.5 软件下载和说明
OraScan下载
 OraScan使用说明

二、软件使用步骤
核心流程：选择扫描对象 → 扫描碎片 → 加载解析结果 → 提取数据/碎片 → 可选操作（筛选、保存等），每一步操作清晰说明，无需额外复杂操作。

步骤1：选择扫描对象（磁盘/镜像文件，二选一）
打开软件后，首先选择需要扫描的对象，根据实际情况二选一，操作如下：

1.1 扫描磁盘设备（常用场景）
• 按照软件界面提示，选择对应的磁盘设备；
• 调整偏移量和实际扫描大小（不清楚的话，直接选择默认值即可，无需修改）。

1.2 扫描镜像文件
• 按照软件界面提示，选择对应的镜像文件；
• 关键注意点：不要勾选“设备”选项（与扫描磁盘设备的核心区别）。

步骤2：执行文件/设备碎片扫描
选择好扫描对象后，按以下步骤操作，新手无需额外设置：
1. 确认设置：确保块大小、偏移量、文件/设备大小设置正确（块大小需与数据库实际一致，新手可先按默认尝试，若扫描失败再调整）；
2. 开始扫描：点击“开始扫描”按钮，启动碎片扫描；
3. 取消扫描：若需中断扫描，点击“取消扫描”按钮即可，建议尽量等待扫描完成，确保碎片不遗漏；
4. 扫描过程解读：进度条显示扫描进度，括号内显示“总操作系统块数量+已扫描数量”，“碎片数量”表示已找到的有效 Oracle 数据文件碎片；
5. 扫描完成标志：软件会提示“扫描完成”，并告知找到的碎片数量；同时，软件当前目录会自动生成“scandata”文件夹，里面有一个“Oracle_Block.map”文件（记录碎片信息的二进制文件，后续会用到，不要删除）。

步骤3：加载并解析扫描结果
扫描完成后，需加载扫描结果并解析，才能看到可恢复的数据文件，操作步骤如下：
1. 点击软件中的“加载扫描结果”按钮；
2. 在弹出的窗口中，选择生成的“Oracle_Block.map”文件（若扫描后生成的是其他文件，选择对应文件即可）；
3. 选择完成后，点击“解析扫描结果”按钮；
4. 解析完成标志：软件提示“解析碎片完成”，同时软件左侧会显示数据文件列表，包含数据库名称、表空间名字、文件号等关键信息（后续提取数据需用到这些信息）；

5. 可选操作：点击“全部碎片”或“未使用碎片”，可查看各个数据文件的详细碎片信息

步骤4：数据文件提取（核心操作，恢复数据文件）
解析完成后，即可提取需要恢复的数据文件，新手按以下步骤操作：
1. 勾选左侧数据文件列表中，需要恢复的数据文件；

2. 点击“提取数据文件”按钮，即可开始恢复；
3. 注意事项：若软件提示“未授权”，无法提取，需联系作者（联系方式见1.4）进行授权；
4. 进阶操作（可选）：若只需提取某个数据文件的部分数据段，可点击该数据文件，然后选择“全选”或勾选需要的数据段，再点击“提取数据文件”即可。

步骤5：提取碎片（按碎片追加形式提取）
若无需提取完整数据文件，仅需提取碎片（操作系统层面的文件），直接点击软件中的“提取碎片镜像”按钮即可，无需额外设置。

步骤6：保存镜像文件
若需将勾选的数据文件/碎片直接保存为镜像文件，勾选对应内容后，点击“保存镜像文件”按钮，按提示选择保存路径即可。

步骤7：筛选数据功能（可选，精准查找碎片）
当点击“全部碎片”或“未使用碎片”时，软件会显示筛选功能，新手可按以下方式使用：
• 在筛选框中，输入“文件号”和“block范围”；
• 输入完成后，软件会自动筛选出符合条件的碎片，方便精准查找。

步骤8：获取文件碎片
该功能与“提取碎片镜像”类似，在没有授权的情况下，直接提取碎片镜像：
• 在对应输入框中，输入文件号（例如：输入“1|3”表示提取文件号1和3的碎片，输入“1024”表示提取所有文件碎片）；
• 输入完成后，软件会自动生成碎片镜像文件，无需其他操作。

三、注意事项
• 首次使用前，务必确认操作系统和 .NET Framework 版本，选择对应版本的软件（OraScan_Net2.exe / OraScan_Net4.exe），避免无法运行；
• 扫描时，若不清楚“偏移量”“扫描大小”“块大小”，先按默认值操作，若扫描失败再联系技术支持；
• 扫描完成后，“scandata”文件夹和“Oracle_Block.map”文件不要删除，否则无法加载解析扫描结果；
• 提取数据文件时，若提示未授权，需联系作者授权后再操作；
• 遇到任何操作问题，可通过1.4中的联系方式联系技术支持，提高恢复效率。
• 为了防止恶意破坏软件，对软件进行了加壳处理，某些杀毒软件可能提示病毒，这个不是真的病毒是由于某些情况下壳被杀毒软件的病毒库误识别为病毒，可以加入到杀毒软件的例外中或者直接关闭杀毒软件之后进行操作。

.[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：.[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复

一家医院运行在win上点电子病例的Oracle数据库被加密成扩展名为:.[xueyuanjie@onionmail.org].AIR

通过obet工具对损坏文件的数据块进行检测（obet实现对数据文件坏块检测功能）

通过分析,该数据库被加密破坏了前面32个block(其中第一个为block 0,正在涉及数据文件中有效的block为31个),这个是oracle 11g版本,业务数据从block 128开始存储（被损坏的前面31个主要是文件头和数据文件中数据块分配的位图信息,不涉及业务数据）,因此对于这种情况直接使用OraFHR工具进行对文件头重构(Oracle数据库被勒索加密一键open工具–OraFHR)

然后重建ctl并打开库（这些脚本orafhr会自动生成）

SQL> startup nomount pfile='d:/pfile.txt';
ORACLE 例程已经启动。

Total System Global Area 4275781632 bytes
Fixed Size                  2288080 bytes
Variable Size             939525680 bytes
Database Buffers         3321888768 bytes
Redo Buffers               12079104 bytes
SQL> @rectl

控制文件已创建。

SQL>
SQL> alter database open resetlogs;

数据库已更改。

SQL> create tablespace expdptbs datafile 'H:\TEMP\oradata\emr\expdptbs01.dbf' size 32M autoextend on;

表空间已创建。

然后使用expdp导出数据,完成本次恢复任务

oracleasm createdisk破坏的acfs文件系统恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：oracleasm createdisk破坏的acfs文件系统恢复

接到一个朋友请求,客户12.2.0.1的asm被执行了oracleasm createdisk,把之前的asmdisk给重建了

根据以前恢复经验,这个故障会把前面1M的数据全部重置
删除asmlib磁盘导致磁盘组故障恢复
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例
这个客户有点特殊,他的asm 磁盘组中跑的不是oracle 数据库而是直接跑acfs,然后再里面跑mysql数据库,也就是利用grid实现mysql的底层高可用,acfs实现共享挂载(我的理解一次也只能启动一个节点的mysql),现在asm disk的头被oracleasm createdisk重置之后,导致asm磁盘组无法mount,从而acfs也无法mount.对于这个故障,让现场提供被破坏磁盘使用dd前面100M 发给我进行分析
使用kfed读取asm disk磁盘头信息

H:\TEMP\0423\0423>kfed read data3_100m
kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                  1096040823 ; 0x00c: 0x41544177
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
005B78600 00000000 00000000 00000000 41544177  [............wATA]
005B78610 00000000 00000000 00000000 00000000  [................]
005B78620 4C43524F 4B534944 41544144 00000033  [ORCLDISKDATA3...]
005B78630 00000000 00000000 00000000 00000000  [................]
  Repeat 252 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

这里可以发现比较明显的asmlib的标记信息ORCLDISKDATA3,证明该磁盘被oracleasm createdisk重建之后,没有再进行kfed修复或者重建新磁盘组

SUCCESS: CREATE DISKGROUP DATA EXTERNAL REDUNDANCY  DISK '/dev/oracleasm/disks/DATA1' SIZE 1430507M
 DISK '/dev/oracleasm/disks/DATA2' SIZE 1430507M
 DISK '/dev/oracleasm/disks/DATA3' SIZE 1430507M
 ATTRIBUTE 'compatible.asm'='12.2.0.1','compatible.advm'='12.2.0.1','au_size'='4M'

SUCCESS: CREATE DISKGROUP CRS EXTERNAL REDUNDANCY  DISK '/dev/oracleasm/disks/CRS' SIZE 190732M
 ATTRIBUTE 'compatible.asm'='12.2.0.1','compatible.advm'='12.2.0.1','au_size'='4M' /* ASMCA */

通过alert日志中磁盘组的创建语句,确认该磁组是ausize为4M,这样的情况下,asm的磁盘头备份备份和au备份应该都是好的,直接通过winhex来确认

再次通过kfed来确认相关磁盘头信息

H:\TEMP\0423\0423>kfed read data3_100m aus=4096k blkn=1022 aun=1|grep name
kfdhdb.dskname:               DATA_0002 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0002 ; 0x068: length=9
kfdhdb.capname:                         ; 0x088: length=0

H:\TEMP\0423\0423>kfed read data3_100m aus=4096k blkn=0 aun=11|grep name
kfdhdb.dskname:               DATA_0002 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0002 ; 0x068: length=9
kfdhdb.capname:                         ; 0x088: length=0

基于上述情况,证明磁盘头和au的备份都还在,而且au的备份是4M,完全包含了被createdisk破坏的1M数据,直接吧这个au给还原回去理论上就可以了,但是很不幸,这样处理之后,crs启动过程依旧无法找到表决盘

通过分析crs盘的情况,发现它的偏移量是错误的

通过分析是由于磁盘分区问题导致

磁盘 /dev/sdc：200.0 GB, 199996997632 字节，390619136 个扇区
Units = 扇区 of 1 * 512 = 512 bytes
扇区大小(逻辑/物理)：512 字节 / 512 字节
I/O 大小(最小/最佳)：512 字节 / 1048576 字节
磁盘标签类型：dos
磁盘标识符：0x00000000

   设备 Boot      Start         End      Blocks   Id  System
/dev/sdc1               1   390619135   195309567+  ee  GPT

磁盘 /dev/sdd：1500.0 GB, 1499996356608 字节，2929680384 个扇区
Units = 扇区 of 1 * 512 = 512 bytes
扇区大小(逻辑/物理)：512 字节 / 512 字节
I/O 大小(最小/最佳)：512 字节 / 1048576 字节
磁盘标签类型：gpt
Disk identifier: 99F1679E-DC32-4F6A-B85D-D91C87B09775


#         Start          End    Size  Type            Name
 1         2048   2929678335    1.4T  Linux LVM

处理好分区问题之后,重启crs,一切自动恢复成功

至此这个被oracleasm createdisk的case完美恢复,数据0丢失

先offline数据文件，再resetlogs导致恢复复杂的故障处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：先offline数据文件，再resetlogs导致恢复复杂的故障处理

本来是一个简单的数据文件被误删除,然后通过底层恢复出来数据文件,再启动库就可以的事情,结果由于对oracle的不了解和自以为是,直接把丢失的文件不存在的情况下,offline文件,然后尝试resetlogs打开库,并且进行了各种尝试,结果使得问题比较麻烦.
故障之后现象
通过分析alert日志大概的主要错误,大概梳理故障情况

1. 启动数据库报control03.ctl丢失

Fri Apr 17 21:53:03 2026
MMNL started with pid=16, OS id=3613 
ORACLE_BASE from environment = /data/oracle
Fri Apr 17 21:53:08 2026
alter database mount
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/data/oracle/oradata/orcl/control03.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/data/oracle/oradata/orcl/control02.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: alter database mount...

如果只是这个文件丢失（这里还没有看到其他数据文件丢失的报错）,本身是一个非常简单的故障,直接修改control_files参数即可

2. 结果当时操作的人直接rectl

Fri Apr 17 21:57:01 2026
Successful mount of redo thread 1, with mount id 1758675116
Completed: CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/data/oracle/oradata/orcl/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/data/oracle/oradata/orcl/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/data/oracle/oradata/orcl/redo03.log'  SIZE 50M BLOCKSIZE 512
DATAFILE
  '/data/oracle/oradata/orcl/system01.dbf',
  '/data/oracle/oradata/orcl/sysaux01.dbf',
  '/data/oracle/oradata/orcl/undotbs01.dbf',
  '/data/oracle/oradata/orcl/users01.dbf'
CHARACTER SET ZHS16GBK

3.然后启动数据库报错

Fri Apr 17 22:02:43 2026
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 3 processes
Started redo scan
Completed redo scan
 read 39020 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 11590, block 2, scn 137806010
Recovery of Online Redo Log: Thread 1 Group 1 Seq 11590 Reading mem 0
  Mem# 0: /data/oracle/oradata/orcl/redo01.log
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 11590, block 78042, scn 137831847
 0 data blocks read, 0 data blocks written, 39020 redo k-bytes read
Fri Apr 17 22:02:44 2026
Thread 1 advanced to log sequence 11591 (thread open)
Thread 1 opened at log sequence 11591
  Current log# 2 seq# 11591 mem# 0: /data/oracle/oradata/orcl/redo02.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Apr 17 22:02:44 2026
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Tablespace 'TEMP' #3  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ERP_XXXX' #6  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ERP_AAAA' #7  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ABCD' #8  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ERP_BBBB' #9  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ERP_XXD' #10  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ERP_12SF' #11  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'XXX14' #12  found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'P_ZY' #13 found in data dictionary,
but not in the controlfile. Adding to controlfile.
File #5 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00005' in the controlfile.
File #6 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00006' in the controlfile.
File #7 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00007' in the controlfile.
File #8 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00008' in the controlfile.
File #9 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00009' in the controlfile.
File #10  found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00010' in the controlfile.
File #11  found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00011' in the controlfile.
File #12 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00012' in the controlfile.

4.然后尝试resetlogs操作

Sat Apr 18 05:55:10 2026
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 1758652862
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Sat Apr 18 05:55:14 2026
ALTER DATABASE OPEN RESETLOGS
ORA-1139 signalled during: ALTER DATABASE OPEN RESETLOGS...
Sat Apr 18 05:56:29 2026
Starting ORACLE instance (normal)
ALTER DATABASE RECOVER  DATABASE UNTIL CANCEL  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 4 slaves
Sat Apr 18 05:56:29 2026
Warning: Datafile 5 (/data/oracle/orcl/xxxx.dbf) is offline during full database recovery and will not be recovered
Warning: Datafile 6 (/data/oracle/orcl/xxxx.dbf) is offline during full database recovery and will not be recovered
Warning: Datafile 7 (/data/oracle/orcl/xxxx.dbf) is offline during full database recovery and will not be recovered
Warning: Datafile 8 (/data/oracle/orcl/xxxx.dbf) is offline during full database recovery and will not be recovered
Media Recovery Not Required
Completed: ALTER DATABASE RECOVER  DATABASE UNTIL CANCEL  
Sat Apr 18 05:57:45 2026
ALTER DATABASE OPEN RESETLOGS
RESETLOGS after complete recovery through change 137865786
Resetting resetlogs activation ID 1645665187 (0x6216dba3)
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2549.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: '/data/oracle/oradata/orcl/redo01.log'
Sat Apr 18 05:57:45 2026
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_2554.trc:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: '/data/oracle/oradata/orcl/redo01.log'
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2549.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/orcl/redo02.log'
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_2554.trc:
ORA-00316: log 2 of thread 1, type 0 in header is not log file
ORA-00312: online log 2 thread 1: '/data/oracle/oradata/orcl/redo02.log'
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_2554.trc:
ORA-00322: log 3 of thread 1 is not current copy
ORA-00312: online log 3 thread 1: '/data/oracle/oradata/orcl/redo03.log'
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2549.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 3 of thread 1 is not current copy
ORA-00312: online log 3 thread 1: '/data/oracle/oradata/orcl/redo03.log'
Sat Apr 18 05:57:46 2026
Setting recovery target incarnation to 2
Sat Apr 18 05:57:46 2026
Assigning activation ID 1758652862 (0x68d2e9be)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Apr 18 05:57:46 2026
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
File #5 is offline, but is part of an online tablespace.
data file 5: '/data/oracle/oradata/orcl/xxxx.dbf'
File #6 is offline, but is part of an online tablespace.
data file 6: '/data/oracle/oradata/orcl/xxxx.dbf'
File #7 is offline, but is part of an online tablespace.
data file 7: '/data/oracle/oradata/orcl/xxxx.dbf'
File #8 is offline, but is part of an online tablespace.
data file 8: '/data/oracle/oradata/orcl/xxxx.dbf'

到这一步悲剧基本上已经发生，犯了一个在oracle恢复里面比较忌讳的事情，有数据文件offline的情况下，执行resetlogs操作，导致部分数据文件的resetlogs信息没有被及时更新，导致一套库里面，被offline的这个部分数据文件resetlogs信息小于其他online的数据文件的。

5. 后续其他操作各种报错

Completed: ALTER DATABASE   MOUNT
Sun Apr 19 08:13:02 2026
ALTER DATABASE DATAFILE 5 OFFLINE DROP
Sun Apr 19 08:13:02 2026
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_9212.trc  (incident=67094):
ORA-00600: internal error code, arguments: [3600], [5], [14], [], [], [], [], [], [], [], [], []
Incident details in: /data/oracle/diag/rdbms/orcl/orcl/incident/incdir_67094/orcl_dbw0_9212_i67094.trc
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_dbw0_9212.trc:
ORA-00600: internal error code, arguments: [3600], [5], [14], [], [], [], [], [], [], [], [], []
DBW0 (ospid: 9212): terminating the instance due to error 471

Tue Apr 21 22:31:23 2026
Assigning activation ID 1758985759 (0x68d7fe1f)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Apr 21 22:31:23 2026
SMON: enabling cache recovery
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4951.trc  (incident=87950):
ORA-00600: internal error code, arguments: [2662], [0], [137890858], [0], [137891091], [12583056], []
Incident details in: /data/oracle/diag/rdbms/orcl/orcl/incident/incdir_87950/orcl_ora_4951_i87950.trc
Errors in file /data/oracle/diag/rdbms/orcl/orcl/incident/incdir_87950/orcl_ora_4951_i87950.trc:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '/data/oracle/oradata/orcl/redo03.log'
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '/data/oracle/oradata/orcl/redo02.log'
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '/data/oracle/oradata/orcl/redo02.log'
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '/data/oracle/oradata/orcl/redo03.log'
ORA-00600: internal error code, arguments: [2662], [0], [137890858], [0], [137891091], [12583056], []
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4951.trc:
ORA-00600: internal error code, arguments: [2662], [0], [137890858], [0], [137891091], [12583056], []
Errors in file /data/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4951.trc:
ORA-00600: internal error code, arguments: [2662], [0], [137890858], [0], [137891091], [12583056], []
Error 600 happened during db open, shutting down database
USER (ospid: 4951): terminating the instance due to error 600

接手故障之后分析
使用obet工具直接快速的检查坏块情况和文件头信息，关于obet的介绍参考:
obet实现对数据文件坏块检测功能
 Oracle数据块编辑工具( Oracle Block Editor Tool)-obet

dbv检测没任何坏块，比较好好的消息

但是检测数据文件头信息，发现有三种类型的resetlogs的信息，证明进行了多次部分文件的情况下进行了resetlogs操作

恢复处理
1. 使用Oracle Recovery Tools工具修改 resetlogs 信息
由于大量reseltogs 信息不一致，先使用Oracle Recovery Tools修改scn等相关信息Oracle Recovery Tools恢复案例总结—202505（注意选择resetlogs scn最大的文件为参照文件）

2. 重建ctl，打开库

比较幸运直接打开成功（本来也就应该成功，因为客户本身之前丢失主要业务文件的时候多次打开过库）

3. 然后增加temp文件，并expdp导出数据，完成本次恢复工作

exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理

接到客户反馈,exp导出来的dmp无法导入到库中,而且原库已经被删除并且创建了新库,希望我们协助把dmp里面几个核心表给恢复出来
故障现象
imp导入dmp文件报 IMP-00098: INTERNAL ERROR: impgst2错误

imp导入操作直接终止,无法恢复需要的数据
故障原因
分析导出日志，发现”ORA-24801: 在 OCI lob 函数中非法的参数值” 错误

查询mos发现EXP-56 ORA-24801 During Export KB83982文章

进一步和客户确认，他们确实修改过该库的字符集。基本上可以确认是由于修改字符集导致lob数据损坏，然后exp导出dmp中这些损坏的lob破坏了dmp的完整性，使得dmp无法正常导入
故障解决
对于这样的情况,由于损坏的lob比较靠前,而且不是客户业务用户中数据.处理方法有两种：
1. 直接使用winhex把损坏的lob表从dmp中剔除掉，然后导入数据
2. 直接使用工具从dmp中提取需要的表数据,以前处理过类似文章:
解决imp导入数据报IMP-00098错误
IMP-00098: INTERNAL ERROR: impgst2
exp dmp文件损坏(坏块/corruption)恢复—跳过dmp坏块

Oracle 19c Grid Infrastructure Release Update-202604(19.31)

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle 19c Grid Infrastructure Release Update-202604(19.31)

Release Date	Version	Download Link	Additional CVEs Addressed
21-Apr-2026	GI Release Update 19.31.0	PATCH 39036936	CVE-2025-15467, CVE-2026-33870, CVE-2026-33013, CVE-2025-31948, CVE-2026-34312, CVE-2026-25210, CVE-2026-24400, and CVE-2026-35229
20-Jan-2026	GI Release Update 19.30.0	PATCH 38629535	CVE-2025-61795, and CVE-2025-67735
21-Oct-2025	GI Release Update 19.29.0	PATCH 38298204	CVE-2025-59375, CVE-2025-53047, CVE-2025-52520 and CVE-2025-26333	-
15-Jul-2025	GI Release Update 19.28.0	PATCH 37957391	CVE-2025-49125, CVE-2025-27363, CVE-2023-1436, CVE-2023-29162, CVE-2025-50066, CVE-2024-56406, CVE-2025-0725, CVE-2025-30751, CVE-2025-30750 and CVE-2025-26333
15-Apr-2025	GI Release Update 19.27.0	PATCH 37641958	CVE-2025-30701, CVE-2025-30733, CVE-2025-30694, CVE-2025-30702, CVE-2024-8176, CVE-2024-11053 and CVE-2025-24813
21-Jan-2025	GI Release Update 19.26.0	PATCH 37257886	CVE-2022-26345, CVE-2024-7254, CVE-2024-38998, CVE-2024-38999, CVE-2024-52316, CVE-2024-47554, and CVE-2024-52317
15-Oct-2024	GI Release Update 19.25.0	PATCH 36916690	CVE-2024-37371, CVE-2024-7264, CVE-2024-21242, CVE-2024-21233, CVE-2024-28887, CVE-2022-41342, CVE-2024-45492, CVE-2024-38999, and CVE-2024-34750
16-Jul-2024	GI Release Update 19.24.0	PATCH 36582629	CVE-2023-45853, CVE-2022-37434, CVE-2023-52425, CVE-2023-52426, CVE-2024-0853, CVE-2024-21123, CVE-2024-21184, and CVE-2024-21126
16-Apr-2024	GI Release Update 19.23.0	PATCH 36233126	CVE-2022-34381, CVE-2023-5363, CVE-2023-48795, CVE-2022-34169, CVE-2024-21058, CVE-2024-21066, CVE-2024-20995, CVE-2023-28823, CVE-2023-27391, CVE-2023-47038, CVE-2023-47039, CVE-2023-47100, CVE-2023-42503, CVE-2023-39975, CVE-2024-23672, and CVE-2024-24549
16-Jan-2024	GI Release Update 19.22.0	PATCH 35940989	CVE-2022-21432, CVE-2023-46589, CVE-2023-42794, CVE-2023-42795, CVE-2023-44487, CVE-2023-45648, CVE-2022-46337, CVE-2023-2976, CVE-2023-38545, CVE-2023-38039, and CVE-2023-38546
17-Oct-2023	GI Release Update 19.21.0	PATCH 35642822	CVE-2023-38039, CVE-2023-28320, CVE-2023-28321, CVE-2023-28322, CVE-2022-44729, CVE-2023-22071, CVE-2023-22077, CVE-2023-22073, CVE-2023-35116, CVE-2023-22075, CVE-2023-22074, CVE-2021-24031, CVE-2023-2976, and CVE-2022-46908
18-Jul-2023	GI Release Update 19.20.0	PATCH 35319490	CVE-2022-43680, CVE-2023-22034, CVE-2023-21949, CVE-2021-3520, CVE-2023-34981, CVE-2022-45143, CVE-2023-24998, CVE-2023-28708, and CVE-2023-28709
18-Apr-2023	GI Release Update 19.19.0	PATCH 35037840	CVE-2023-21918, CVE-2023-24998, and CVE-2022-45143
17-Jan-2023	GI Release Update 19.18.0	PATCH 34762026	CVE-2018-25032, CVE-2022-42003, CVE-2023-21829, CVE-2023-21827, CVE-2021-37750, CVE-2022-42889, CVE-2020-10878, CVE-2022-1122, CVE-2021-29338, CVE-2022-3171, CVE-2022-45047, and CVE-2022-42004
18-Oct-2022	GI Release Update 19.17.0	PATCH 34416665	CVE-2022-21596, CVE-2022-21603, CVE-2020-36518, CVE-2022-1586, CVE-2020-13956, CVE-2022-34305, CVE-2021-25122, CVE-2021-25329, CVE-2021-30129, CVE-2022-2047, CVE-2022-25647, and CVE-2019-2904
19-Jul-2022	GI Release Update 19.16.0	PATCH 34130714	CVE-2021-45943, CVE-2022-21432, CVE-2022-0839, CVE-2020-26185, CVE-2020-26184, CVE-2020-35169, and CVE-2022-29885
19-Apr-2022	GI Release Update 19.15.0	PATCH 33803476	CVE-2021-22569, CVE-2022-21410, CVE-2021-2464, and CVE-2021-42340
18-Jan-2022	GI Release Update 19.14.0	PATCH 33509923	CVE-2022-21247, CVE-2021-45105
19-Oct-2021	GI Release Update 19.13.0	PATCH 33182768	CVE-2021-2332, CVE-2021-35551, CVE-2021-35557, CVE-2021-35558, CVE-2021-35576, CVE-2021-29425, CVE-2021-35579, CVE-2020-27824, CVE-2021-25122, CVE-2020-9484, and CVE-2021-25329
20-Jul-2021	GI Release Update 19.12.0	PATCH 32895426	CVE-2021-2351, CVE-2021-2328, CVE-2021-2329, CVE-2021-2337, CVE-2021-2333, CVE-2019-17545, CVE-2021-2330, CVE-2020-7760, CVE-2021-2334, CVE-2021-2335, CVE-2021-2336, CVE-2021-2326
20-Apr-2021	GI Release Update 19.11.0	PATCH 32545008	CVE-2021-2207, CVE-2021-2175, CVE-2021-2173, CVE-2019-3738, CVE-2019-3739, CVE-2019-3740, CVE-2020-5360, CVE-2020-17527, CVE-2020-13943, CVE-2020-9484. CVE-2021-2245, and CVE-2020-5359
19-Jan-2021	GI Release Update 19.10.0	PATCH 32226239	CVE-2021-2035, CVE-2021-2000, CVE-2021-2054, CVE-2021-2045
20-Oct-2020	GI Release Update 19.9.0	PATCH 31750108	CVE-2020-14901, CVE-2020-14735, CVE-2020-14734, CVE-2020-9488, CVE-2020-11022, CVE-2020-14742, CVE-2019-17543, CVE-2019-11922, CVE-2019-12900, CVE-2020-13935, CVE-2016-1000031, CVE-2018-8013, CVE-2017-7658, CVE-2019-11358, CVE-2019-16335, CVE-2020-14745, CVE-2020-14744, CVE-2020-11022, CVE-2020-11023, CVE-2016-10244, CVE-2016-10328, CVE-2016-5300, CVE-2016-6153, CVE-2017-10989, CVE-2017-13685, CVE-2017-13745, CVE-2017-14232, CVE-2017-15286, CVE-2017-7857, CVE-2017-7858, CVE-2017-7864, CVE-2017-8105, CVE-2017-8287, CVE-2018-18873, CVE-2018-19139, CVE-2018-19539, CVE-2018-19540, CVE-2018-19541, CVE-2018-19542, CVE-2018-19543, CVE-2018-20346, CVE-2018-20505, CVE-2018-20506, CVE-2018-20570, CVE-2018-20584, CVE-2018-20622, CVE-2018-20843, CVE-2018-6942, CVE-2018-8740, CVE-2018-9055, CVE-2018-9154, CVE-2018-9252, CVE-2019-15903, CVE-2019-16168, CVE-2019-5018, CVE-2019-8457, CVE-2019-9936, CVE-2019-9937, and CVE-2016-3189
14-Jul-2020	GI Release Update 19.8.0	PATCH 31305339	CVE-2020-2969, CVE-2020-2978, CVE-2019-13990, CVE-2019-17569, CVE-2016-1000031, CVE-2018-10237, CVE-2018-8013, CVE-2020-1935 and CVE-2020-1938
14-Apr-2020	GI Release Update 19.7.0	PATCH 30899722	CVE-2019-2756, CVE-2019-2759, CVE-2019-2852, CVE-2019-2853, CVE-2019-12418, CVE-2019-17563, CVE-2020-2734, CVE-2020-2737
14-Jan-2020	GI Release Update 19.6.0	PATCH 30501910	CVE-2020-2510, CVE-2020-2511, CVE-2020-2512, CVE-2020-2515, CVE-2020-2516, CVE-2020-2517, CVE-2020-2527, CVE-2020-2731, CVE-2020-2568, CVE-2020-2569, CVE-2019-10072, CVE-2018-11784, CVE-2019-0199, CVE-2019-0221, CVE-2019-0232
15-Oct-2019	GI Release Update 19.5.0	PATCH 30116789	CVE-2019-2956, CVE-2019-2913, CVE-2019-2939, CVE-2018-2875, CVE-2019-2734, CVE-2018-11784, CVE-2019-2954, CVE-2019-2955, CVE-2018-8034, CVE-2018-1000873, CVE-2018-14719, CVE-2018-14720, CVE-2018-14721, CVE-2018-19360, CVE-2018-19361 and CVE-2018-19362
16-Jul-2019	GI Release Update 19.4.0	PATCH 29708769	CVE-2018-11058, CVE-2019-2776, CVE-2016-0701, CVE-2016-2183, CVE-2016-6306, CVE-2016-8610, CVE-2018-11054, CVE-2018-11055, CVE-2018-11056, CVE-2018-11057 and CVE-2018-15769
16-Apr-2019	GI Release Update 19.3.0	(patch suspended)