标签云
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
分类目录归档:数据库
docker回收和mysql备份导入导致数据丢失恢复
最近遇到两例MySQL异常被删除的案例,一例是在docker环境中,由于对docker执行了删除操作,并回收了相关的挂载卷,导致数据彻底丢失

另外一个客户使用备份导入生产库,导致生产库的数据全部被重置为了当时备份的状态,这是由于mysqldump导出数据的时候,默认带有DROP TABLE IF EXISTS `xifenfei`;语句,因此导入备份的时候会先删除掉存在的表,然后创建新表,再insert插入数据.

上述的这两个case,故障发生之后,都没有第一时间保护现场,反而对数据所在分区进行了不少的写入操作,导致覆盖概率相对增加很多.对于这样的故障,一般处理思路:
1. 停掉对该分区写入的业务,如果可以尽可能umount分区,然后做快照或者进项
2. 使用反删除软件对镜像的或者快照的分区进行分析,尝试恢复出来没有被覆盖的MySQL数据,主要是ibd和frm等文件
3. 使用碎片工具对镜像的或者快照的分区进行扫描,根据数据类型生产index和blob的page文件

4. 对于2中恢复的ibd,frm文件,可以尝试通过DISCARD TABLESPACE/IMPORT TABLESPACE方式进行恢复,如果不行对ibd文件进行解析恢复,参考:又一起mysql rm删除数据库目录事故
5. 对于3中恢复出来的page文件,利用工具结合表结构对其进行解析,恢复数据
通过上述恢复,基本上是对于MySQL数据的drop table/truncate table/drop database/rm -rf/格式化等相关误操作的终极恢复思路,对于类似MySQL故障,我们可以实现比较好的恢复效果,如果需要专业恢复技术支持请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
服务器断电引起的一例ORA-01207故障处理
有一个客户反馈服务器异常断电,导致数据库无法正常启动(启动报ORA-01207: file is more recent than control file – old control file 错误)
SQL> startup mount ORACLE 例程已经启动。 Total System Global Area 5.4784E+10 bytes Fixed Size 2188768 bytes Variable Size 4.2010E+10 bytes Database Buffers 1.2751E+10 bytes Redo Buffers 20566016 bytes 数据库装载完毕。 SQL> recover database ORA-00283: recovery session canceled due to errors ORA-01122: database file 6 failed verification check ORA-01110: data file 6: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\HSHIS1' ORA-01207: file is more recent than control file - old control file
怀疑文件系统或者底层磁盘有损坏,进一步检查系统日志,确认发现大量ntfs层面异常提示(而且多个盘都有)

对于这样的情况,先对数据文件进行了备份,运气还不错,文件全部备份成功,并通过Oracle Database Recovery Check 脚本进行检查当前故障库状态,确认很多文件的checkpoint点相差很远

对于这样的一个非归档数据库,肯定无法正常打开,只能通过屏蔽一致性尝试强制打开库,结果在打开过程中出现ORA-600 4194错误
SQL> alter database open ; alter database open * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] 进程 ID: 7820 会话 ID: 177 序列号: 147
解决异常undo,数据库正常open成功,但是在数据库导出数据过程中报ORA-600 2662和ORA-600 2663错误(这种情况一般比较少见,大部分ORA-600 2662/2663都是在open过程中,这种库已经open成功,后续查询报该错误的比较少见,但是原理上有可能[启动的时候没有读到这些block,后面放到这些表的block scn大于文件头scn,所以报该错误])
Fri Sep 05 01:04:12 2025 QMNC started with pid=54, OS id=7708 Completed: alter database open Fri Sep 05 01:04:13 2025 Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_m001_8624.trc (incident=10058): ORA-00600: internal error code, arguments: [2662], [2], [1384717872], [2], [1385084764], [41943042], Incident details in: d:\app\administrator\diag\rdbms\his\his\incident\incdir_10058\his_m001_8624_i10058.trc Fri Sep 05 01:04:13 2025 Starting background process CJQ0 Fri Sep 05 01:04:13 2025 CJQ0 started with pid=62, OS id=6852 Fri Sep 05 01:04:13 2025 db_recovery_file_dest_size of 3912 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_ora_9220.trc (incident=10084): ORA-00600: 内部错误代码, 参数: [2662], [2], [1384717989], [2], [1385446402], [37802453], [], [], [], Fri Sep 05 01:04:18 2025 Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_j017_11248.trc (incident=10059): ORA-00600: internal error code, arguments: [2662], [2], [1384717990], [2], [1385446402], [37802453], Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_j017_11248.trc: ORA-00600: internal error code, arguments: [2662], [2], [1384717990], [2], [1385446402], [37802453], ORA-06512: at "HOSPITAL.RPT_CASE", line 5684 ORA-06512: at line 3 Errors in file d:\app\administrator\diag\rdbms\his\his\trace\his_ora_9220.trc (incident=10085): ORA-00600: 内部错误代码, 参数: [2662], [2], [1384717990], [2], [1385446402], [37802453], [], [], [],
这个问题相对比较简单,通过Patch SCN小工具修改正确的Oracle SCN即可

RMAN SBT_TAPE备份通过小程序修改实现直接DISK通道还原
有朋友把oracle rman备份从cv带库里拷贝到文件系统,然后希望把他还原到数据库中.通过尝试发现直接带库的文件无法直接在文件系统中被rman调用还原
C:\Users\XFF>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期三 9月 3 18:07:58 2025 Copyright (c) 1982, 2013, Oracle. All rights reserved. 已连接到空闲例程。 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> exit 从 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开 C:\Users\XFF> C:\Users\XFF> C:\Users\XFF> C:\Users\XFF>rman target / 恢复管理器: Release 11.2.0.4.0 - Production on 星期三 9月 3 18:08:38 2025 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 已连接到目标数据库: ORCL (未装载) RMAN> restore controlfile from 'H:\TEMP\Oracle_Restore\405\c-1737595250-20250822-00'; 启动 restore 于 03-9月 -25 使用目标数据库控制文件替代恢复目录 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: SID=28 设备类型=DISK 通道 ORA_DISK_1: 正在还原控制文件 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: restore 命令 (在 09/03/2025 18:08:54 上) 失败 ORA-19870: 还原备份片段 H:\TEMP\ORACLE_RESTORE\405\C-1737595250-20250822-00 时出错 ORA-19505: 无法识别文件"H:\TEMP\ORACLE_RESTORE\405\C-1737595250-20250822-00" ORA-27046: 文件大小不是逻辑块大小的倍数 OSD-04000: 逻辑块大小不匹配 (OS 512)
以前也写过相关的文章,由于tape的备份和disk通道备份的文件头本身格式都不一样,具体参考:RMAN SBT_TAPE备份无法被DISK通道识别
尝试使用dbms_backup_restore还原依旧失败
C:\Users\XFF>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期三 9月 3 18:19:23 2025 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> DECLARE 2 devtype varchar2(256); 3 done boolean; 4 BEGIN 5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1'); 6 sys.dbms_backup_restore.restoreSetDatafile; 7 sys.dbms_backup_restore.restoreControlfileTo(cfname=>'H:\CONTROL01.CTL'); 8 sys.dbms_backup_restore.restoreBackupPiece(done=>done, 9 handle=>'H:\TEMP\Oracle_Restore\405\c-1737595250-20250822-00', params=>null); 10 sys.dbms_backup_restore.deviceDeallocate; 11 END; 12 / DECLARE * 第 1 行出现错误: ORA-19624: 操作失败, 如果可能请重试 ORA-19870: 还原备份片段 H:\TEMP\ORACLE_RESTORE\405\C-1737595250-20250822-00 时出错 ORA-19505: 无法识别文件"H:\TEMP\ORACLE_RESTORE\405\C-1737595250-20250822-00" ORA-27046: 文件大小不是逻辑块大小的倍数 OSD-04000: 逻辑块大小不匹配 (OS 512) ORA-06512: 在 "SYS.X$DBMS_BACKUP_RESTORE", line 5940 ORA-06512: 在 line 8
对于这种情况,我尝试自己开发一个小程序,来模拟disk通道备份集,欺骗数据库来实现还原操作.

通过程序模拟出来的disk通道的文件,每个后缀加上了disk

再次通过尝试通过disk通道还原操作
C:\Users\XFF>rman target / 恢复管理器: Release 11.2.0.4.0 - Production on 星期三 9月 3 18:23:14 2025 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 已连接到目标数据库: ORCL (未装载) RMAN> restore controlfile from 'H:\TEMP\Oracle_Restore\405\c-1737595250-20250822-00.disk'; 启动 restore 于 03-9月 -25 使用目标数据库控制文件替代恢复目录 分配的通道: ORA_DISK_1 通道 ORA_DISK_1: SID=28 设备类型=DISK 通道 ORA_DISK_1: 正在还原控制文件 通道 ORA_DISK_1: 还原完成, 用时: 00:00:01 输出文件名=H:\CONTROL01.CTL 完成 restore 于 03-9月 -25 RMAN> alter database mount; 数据库已装载 释放的通道: ORA_DISK_1 RMAN> catalog start with 'H:\TEMP\Oracle_Restore\405\*.disk'; 搜索与样式 H:\TEMP\Oracle_Restore\405\*.disk 匹配的所有文件 数据库未知文件的列表 ===================================== 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0141onds_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0241onec_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0441onev_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\c-1737595250-20250822-00.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\c-1737595250-20250822-01.disk 是否确实要将上述文件列入目录 (输入 YES 或 NO)? yes 正在编制文件目录... 目录编制完毕 已列入目录的文件的列表 ======================= 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0141onds_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0241onec_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0441onev_1_1.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\c-1737595250-20250822-00.disk 文件名: H:\TEMP\ORACLE_RESTORE\405\c-1737595250-20250822-01.disk RMAN>
RMAN> report schema;
RMAN-06139: 警告: 控制文件对于 REPORT SCHEMA 不是最新
db_unique_name 为 ORCL 的数据库的数据库方案报表
永久数据文件列表
===========================
文件大小 (MB) 表空间 回退段数据文件名称
---- -------- -------------------- ------- ------------------------
1 0 SYSTEM *** /data/oracle/oradata/orcl/system01.dbf
2 0 SYSAUX *** /data/oracle/oradata/orcl/sysaux01.dbf
3 0 UNDOTBS1 *** /data/oracle/oradata/orcl/undotbs01.dbf
4 0 USERS *** /data/oracle/oradata/orcl/users01.dbf
5 0 EXAMPLE *** /data/oracle/oradata/orcl/example01.dbf
临时文件列表
=======================
文件大小 (MB) 表空间 最大大小 (MB) 临时文件名称
---- -------- -------------------- ----------- --------------------
1 20 TEMP 32767 /data/oracle/oradata/orcl/temp01.dbf
RMAN> run
2> {
3> set newname for datafile 1 to 'h:\system01.dbf';
4> set newname for datafile 2 to 'h:\sysaux01.dbf';
5> set newname for datafile 3 to 'h:\undotbs01.dbf';
6> set newname for datafile 4 to 'h:\users01.dbf';
7> set newname for datafile 5 to 'h:\example01.dbf';
8> restore database;
9> switch datafile all;
10> }
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
启动 restore 于 03-9月 -25
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=28 设备类型=DISK
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00001 还原到 h:\system01.dbf
通道 ORA_DISK_1: 将数据文件 00002 还原到 h:\sysaux01.dbf
通道 ORA_DISK_1: 将数据文件 00003 还原到 h:\undotbs01.dbf
通道 ORA_DISK_1: 将数据文件 00004 还原到 h:\users01.dbf
通道 ORA_DISK_1: 将数据文件 00005 还原到 h:\example01.dbf
通道 ORA_DISK_1: 正在读取备份片段 H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0141ONDS_1_1.DISK
通道 ORA_DISK_1: 段句柄 = H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0141ONDS_1_1.DISK 标记 = TAG20250822T124236
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
完成 restore 于 03-9月 -25
数据文件 1 已转换成数据文件副本
输入数据文件副本 RECID=7 STAMP=1210875892 文件名=H:\SYSTEM01.DBF
数据文件 2 已转换成数据文件副本
输入数据文件副本 RECID=8 STAMP=1210875892 文件名=H:\SYSAUX01.DBF
数据文件 3 已转换成数据文件副本
输入数据文件副本 RECID=9 STAMP=1210875892 文件名=H:\UNDOTBS01.DBF
数据文件 4 已转换成数据文件副本
输入数据文件副本 RECID=10 STAMP=1210875892 文件名=H:\USERS01.DBF
数据文件 5 已转换成数据文件副本
输入数据文件副本 RECID=11 STAMP=1210875892 文件名=H:\EXAMPLE01.DBF
RMAN>
RMAN> run
2> {
3> set archivelog destination to 'h:/';
4> restore archivelog all;
5> }
正在执行命令: SET ARCHIVELOG DESTINATION
启动 restore 于 03-9月 -25
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在开始将归档日志还原到用户指定的目标
归档日志目标=h:/
通道 ORA_DISK_1: 正在还原归档日志
归档日志线程=1 序列=6
通道 ORA_DISK_1: 正在还原归档日志
归档日志线程=1 序列=7
通道 ORA_DISK_1: 正在读取备份片段 H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0441ONEV_1_1.DISK
通道 ORA_DISK_1: 段句柄 = H:\TEMP\ORACLE_RESTORE\405\322_ORCL_0441ONEV_1_1.DISK 标记 = TAG20250822T124311
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
完成 restore 于 03-9月 -25
通过上述操作,证明写的小程序oracle rman 备份集从tape通道备份方式修改为直接走disk 通道还原完整没有问题.


加我微信(17813235971)
加我QQ(107644445)

