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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题: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: 不能指定表分区的此物理属性错误
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)QQ咨询惜分飞

标题:一次断电引起的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.

然后数据库顺利打开
open1


在expdp导出数据过程中遇到了硬件错误
ora-27072
io-error

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

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题: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 扫描磁盘设备(常用场景)
• 按照软件界面提示,选择对应的磁盘设备;
• 调整偏移量和实际扫描大小(不清楚的话,直接选择默认值即可,无需修改)。
orascan1


1.2 扫描镜像文件
• 按照软件界面提示,选择对应的镜像文件;
• 关键注意点:不要勾选“设备”选项(与扫描磁盘设备的核心区别)。
orascan2


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


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

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


步骤4:数据文件提取(核心操作,恢复数据文件)
解析完成后,即可提取需要恢复的数据文件,新手按以下步骤操作:
1. 勾选左侧数据文件列表中,需要恢复的数据文件;
orascan6

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


步骤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)QQ咨询惜分飞

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

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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


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

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

然后重建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;

表空间已创建。

QQ20260425-170758


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

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

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

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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


根据以前恢复经验,这个故障会把前面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来确认
orcldisk


再次通过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启动过程依旧无法找到表决盘
vote


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

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

磁盘 /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,一切自动恢复成功
acfs-mysql


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