expdp dmp 导出不完整导入ORA-39059 ORA-39246 故障抢救数据

发表于 2025 年 12 月 3 日 由 惜分飞

客户一套nc系统,由于安装时候把库建在了比较小的分区上,运行一些时间之后,出现空间不足,现场技术人员对oracle不太熟悉,经过一系列操作(删除业务表空间,复制pdb,创建表空间等等操作),无法恢复数据库,准备使用备份的dmp进行还原,结果分析发现仅保留的最后一份dmp,是一份导出不完全的dmp文件,无法正常导入(以前处理过一个类似case:ORA-39773: parse of metadata stream failed故障处理,尝试导入报ORA-39246错:

C:\Users\XFF>impdp system/oracle@127.0.0.1/orapdb directory=expdp_dir dumpfile=xxxxx_2025-12-01_0230.dmp logfile=1.log

Import: Release 19.0.0.0.0 - Production on 星期三 12月 3 21:00:19 2025
Version 19.3.0.0.0

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

连接到: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
ORA-39002: 操作无效
ORA-39059: 转储文件集不完整
ORA-39246: 无法在提供的转储文件中定位主表

分析当时当初的dmp日志,由于expdp的job表所在表空间不足导致expdp导出失败
dmp1

TABLE:"XIFENFEI"."EOM_MEASURE_POINT"
ORA-30032: 挂起的 (可恢复) 语句已超时
ORA-01691: Lob 段 XIFENFEI.SYS_LOB0000161267C00111$$ 无法通过 32 (在表空间 NNC_DATA01 中) 扩展
ORA-06512: 在 "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: 在 "SYS.KUPW$WORKER", line 12620
ORA-06512: 在 "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: 在 "SYS.KUPW$WORKER", line 11414
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
0xda5dae50     33476  package body SYS.KUPW$WORKER.WRITE_ERROR_INFORMATION
0xda5dae50     12641  package body SYS.KUPW$WORKER.DETERMINE_FATAL_ERROR
0xda5dae50     11602  package body SYS.KUPW$WORKER.CREATE_OBJECT_ROWS
0xda5dae50     15268  package body SYS.KUPW$WORKER.FETCH_XML_OBJECTS
0xda5dae50      3907  package body SYS.KUPW$WORKER.UNLOAD_METADATA
0xda5dae50     13736  package body SYS.KUPW$WORKER.DISPATCH_WORK_ITEMS
0xda5dae50      2429  package body SYS.KUPW$WORKER.MAIN
0x6524a4f0         2  anonymous block
KUPW: Object row index into parse items is: 1
KUPW: Parse item count is: 19
KUPW: In function CHECK_FOR_REMAP_NETWORK
KUPW: Nothing to remap
KUPW: In procedure BUILD_OBJECT_STRINGS - non-base info
KUPW: In procedure BUILD_SUBNAME_LIST with TABLE:XIFENFEI.EOM_MEASURE_POINT
KUPW: In function NEXT_PO_NUMBER
KUPW: PO number assigned: 34198
FORALL
KUPW: In procedure DETERMINE_FATAL_ERROR with ORA-30032: 挂起的 (可恢复) 语句已超时
ORA-01691: Lob 段 XIFENFEI.SYS_LOB0000161267C00111$$ 无法通过 32 (在表空间 NNC_DATA01 中) 扩展
作业 "XIFENFEI"."SYS_EXPORT_SCHEMA_01" 因致命错误于 星期一 12月 1 06:33:21 2025 elapsed 0 04:03:18 停止

从导出日志看,在导出大量”0 KB 0 行”记录之后提示表空间不足,expdp的job表无法扩展导致导出挂起然后超时导出终止(这个导出操作没有完全完成),从而在导入的时候出现了ORA-39059: 转储文件集不完整 ORA-39246: 无法在提供的转储文件中定位主表 的错误.对于这种故障,分析导出日志,发现运气不错,所有有数据的表都导出完成,基于这个心中就有了第一层底气,所有表数据不会丢失(因为都导出到了这个dmp中),但是非表的字典数据不完整,要想业务完整跑起来,需要找到一个完整的业务字典信息.对于大量的备份dmp被删除,然后对应分区还写入了很多数据,只能尝试看运气,通过对磁盘文件镜像,然后进行反删除恢复,找出来一个11月26日的dmp的压缩文件是完整的
good-dmp

通过这个dmp导入业务字典信息,然后再利用expdp dmp解析工具(expdp dmp被加密破坏恢复)把所有表数据出来,经过这两者组合,顺利完成数恢复,可以测试业务完全正常

发表在 Oracle, 非常规恢复 | 标签为 , , , | 留下评论

mysql drop database 恢复思路

发表于 2025 年 11 月 30 日 由 惜分飞

今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构，xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)
mysql

对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件
ibd
对于这些文件,选择出来客户需要的表,采用discard+import方式进行恢复,类似命令

alter table tablename discard tablespace;
alter table tablename import tablespace;

对于有些部分block损坏的ibd文件,直接这样操作可能会报Data structure corruption错误,这样的情况,可以通过工具解析ibd文件进行恢复

对于有些表,可能在文件系统层面反删除无法恢复,我们通过对磁盘进行mysql的数据块层面扫描(识别在磁盘上没有覆盖的mysql的block),按照pageid的方式进行重组成一个个page文件
page
然后基于这些page进行恢复需要的表数据
11
基本上通过上述的方法实现最大限度mysql删除数据的恢复(比如drop database，drop table，truncate table)
如果MySQL数据库恢复问题,需要专业恢复技术支持，请联系我们提供专业MySql数据库恢复服务:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

发表在 MySQL恢复 | 标签为 , , , , | 留下评论

PRVG-11975 : The I/O scheduler parameter of device “/dev/sdm” did not match the expected value on nodes

发表于 2025 年 11 月 24 日 由 惜分飞

今天在oracle linux 7.9的系统中装Oracle 19.29集群采用gridSetup applyRU 的方式安装

su – grid
cd $ORACLE_HOME
./gridSetup.sh -applyRU /soft/38298204/

在检测的步骤I/O scheduler warning
PRVG-11975

具体内容类似:

I/O scheduler - This task checks the I/O scheduler parameter configured Error: 
PRVG-11975:The I/O scheduler parameter of device "/dev/sdm" did not match the expected value on nodes "hisdb2,hisdb2". 
[Expected scheduler = "none" ; Found scheduler = "mq-deadline"] ? Cause:?The I/O scheduler parameter of the indicated 
device was not  the expected value on the indicated nodes. ? Action:?Change the I/O scheduler parameter using 
'echo deadline > /sys/block/<device>/queue/scheduler' command of the indicated device to ensure it is the expected value.

大概的意思是磁盘的I/O scheduler parameter被检查出来是mq-deadline,实际要求为:deadline,并建议使用echo deadline > /sys/block//queue/scheduler命令来修改,检查存储磁盘的实际值

[grid@hisdb1 grid]$ cat /sys/block/sdm/queue/scheduler
[mq-deadline] kyber bfq none

确实I/O scheduler为mq-deadline,查询了相关描述:
mq-deadline 是 deadline 调度器的多队列升级版，核心设计目标一致（按 “截止时间” 调度以保证 I/O 延迟），但适配的硬件场景、性能表现差异显著 —— 简单说：deadline 是为传统单队列设备（如 HDD）设计的老版本，mq-deadline 是为现代多队列设备（如 SSD/NVMe）优化的新版本。
21

客户这边刚好是华为的ssd存储,使用mq-deadline是非常合理的,如果调整为deadline反而不太合理了.初步感觉这个问题应该是Oracle 本身检测不合理导致,进一步查询MOS,Oracle自己也承认了该问题:
bug-36183757
对于ssd环境,可以忽略该警告,继续安装

发表在 Oracle安装升级 | 标签为 , | 留下评论