标签云
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,883)
- DB2 (22)
- MySQL (82)
- Oracle (1,708)
- 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备份恢复 (662)
- 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)
-
最近发表
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起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典型故障:The controlfile header block returned by the OS has a sequence number that is too old
这个是一例子客户数据库运行过程中突然报:The controlfile header block returned by the OS has a sequence number that is too old.然后数据库无法正常启动的数据库恢复case
以前处理过一些类似case:Controlfile sequence number in file header is different from the one in memory
故障现象
alert日志中报The controlfile header block returned by the OS has a sequence number that is too old.错误,然后数据库crash
Wed Mar 18 12:00:44 2026
********************* ATTENTION: ********************
The controlfile header block returned by the OS
has a sequence number that is too old.
The controlfile might be corrupted.
PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE
without following the steps below.
RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE
TO THE DATABASE, if the controlfile is truly corrupted.
In order to re-start the instance safely,
please do the following:
(1) Save all copies of the controlfile for later
analysis and contact your OS vendor and Oracle support.
(2) Mount the instance and issue:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
(3) Unmount the instance.
(4) Use the script in the trace file to
RE-CREATE THE CONTROLFILE and open the database.
*****************************************************
USER (ospid: 15912): terminating the instance
这个错误比较明显是由于控制文件的sequence number比较老导致,出现这种问题,一般是由于io过慢,或者底层不稳定(比如虚拟化平台,文件系统异常,硬件不稳定等)导致(官方参考文档:The controlfile header block returned by the OS has a sequence number that is too old.)
尝试重启数据库报ORA-01207错误
Wed Mar 18 18:51:54 2026 alter database mount exclusive Successful mount of redo thread 1, with mount id 1534819594 Database mounted in Exclusive Mode Lost write protection disabled Completed: alter database mount exclusive alter database open Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2992.trc: ORA-01122: ????? 18 ???? ORA-01110: ???? 18: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\XIFENFEI.DBF' ORA-01207: ????????? - ?????? ORA-1122 signalled during: alter database open... Wed Mar 18 18:52:01 2026 Checker run found 1 new persistent data failures
该错误的官方解释
[oracle@xifenfei.com ~]$ oerr ora 1207 01207, 00000, "file is more recent than control file - old control file" // *Cause: The control file change sequence number in the data file is // greater than the number in the control file. This implies that // the wrong control file is being used. Note that repeatedly causing // this error can make it stop happening without correcting the real // problem. Every attempt to open the database will advance the // control file change sequence number until it is great enough. // *Action: Use the current control file or do backup control file recovery to // make the control file current. Be sure to follow all restrictions // on doing a backup control file recovery.
由于数据文件比控制文件更新,导致该问题,通过查询v$datafile_header发现更多类似异常文件(可以使用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)收集信息)

alert日志文件中也有明显的写错日志信息

这些二进制内容和监听日志内容被写入到了alert日志中,证明当时文件系统或者操作系统甚至更底层出现了异常,这个客户是运行在云平台上的,具体运营需要平台厂商才能分析
故障处理
重建控制文件并进行recover
SQL> startup nomount pfile='e:/pfile.txt' ; ORACLE 例程已经启动。 Total System Global Area 2.9931E+10 bytes Fixed Size 2190296 bytes Variable Size 1946158120 bytes Database Buffers 2.7917E+10 bytes Redo Buffers 64905216 bytes SQL> @rectl.sql 控制文件已创建。 SQL> recover database; 完成介质恢复。
尝试启动数据库,报ora-600 2662错误
SQL> alter database open; alter database open * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [1], [45773288], [1], [45777527], [301990016] ORA-00600: internal error code, arguments: [2662], [1], [45773287], [1], [45777527], [301990016] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [1], [45773285], [1], [45777527], [301990016] 进程 ID: 2708 会话 ID: 148 序列号: 5
数据库启动报ORA-600 2662错误,这个是典型的文件头scn过小的问题,通过自研小工具Patch_SCN可以快速解决,以前类似文章:
Patch SCN一键解决ORA-600 2662故障
Patch SCN工具一键恢复ORA-600 kcbzib_kcrsds_1
ORA-600 kcratr_nab_less_than_odr和ORA-600 2662故障处理

修改scn之后,数据库顺利打开
SQL> startup mount pfile='e:/pfile.txt'; ORACLE 例程已经启动。 Total System Global Area 2.9931E+10 bytes Fixed Size 2190296 bytes Variable Size 1946158120 bytes Database Buffers 2.7917E+10 bytes Redo Buffers 64905216 bytes 数据库装载完毕。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01113: 文件 1 需要介质恢复 ORA-01110: 数据文件 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF' SQL> recover database; 完成介质恢复。 SQL> alter database open; 数据库已更改。
国产信创库fio破坏主备库以及备份故障处理
去年恢复过一个case(达梦数据库,主备节点同时被fio破坏fio测试io,导致磁盘文件系统损坏故障恢复),这两天又接到一个类似的case
故障背景描述
1. 客户达梦数据库运行在arm服务器的linux环境
2. 两台机器做了达梦的DataWatch(类似oracle的dataguard)
3. 主库上有多份数据库备份,但是备份和数据库文件放都放在同一块磁盘的同一个分区上
4. 由于数据库运行较慢,应用厂商先在主库上进行了fio性能测试,然后数据库发生自动切换,切换到备库(当时现场没有发现异常),然后还继续在主库上进行了一次fio测试
5. 再在数据库备库(现在已经切换为主库)的机器上又进行了一次fio测试,然后数据库也异常,至此达梦的主备环境全部异常,三次的fio具体操作命令:
fio --direct=1 --iodepth=32 --rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --numjobs=4 --group_reporting \ --time_based --runtime=60 --filename=/dev/vdb --name=4k_iops_test
6. 根据当时测试的fio结果显示主库两次测试一共写入数据大概2G左右,备库写入大概1.2G左右数据
7. 当前数据库的block size设置为32k(也就是说在32k里面随机写中任何4k的数据这个block就破坏)
8. 虽然客户是央企但是由于商务招标等原因导致达梦现在不是他们的数据库中标厂商,而且这个库没有正式授权和任何售后服务,甚至安装实施都非达梦工程师.基于这样的情况,应用厂商通过多种途径联系上达梦管理人员,才给予了一定的技术支持.
恢复过程和思路
1. 对于当前的情况,是选择优先恢复主库还是备库的磁盘考虑:虽然主库破坏写入的多一些,但是由于主库中有多份有效备份,因此考虑先让客户对现场主库环境被破坏的vdb磁盘进行镜像,然后使用专业的软件对文件系统进行分析后,可以直接看到达梦相关的数据文件,而且文件系统元数据较为完整

另外分析备份文件,确认备份文件文件数量正确,而且状态良好

2. 恢复出来达梦相关数据文件和所有有效备份文件,上传到新准备的和以前操作系统,数据库版本一样的机器上,然后进行尝试恢复.
3. 非常不幸所有备份集通过dmrman的check backupset命令检测返回无效备份包,但是达梦官方无法提供进一步信息,这个想通过备份集来恢复的思路基本上走死.
4. 考虑让达梦厂商基于恢复的数据文件强制拉库,但是比较不幸由于fio的随机写入破坏导致拉库过程中报page check error,而且达梦工程师经过多次尝试均无法跳过,推断可能是涉及核心字典对象异常,无法规避,数据库无法打开.



5. 达梦工程师考虑通过dmdul工具进行提取,结果无法成功加载字典信息,反馈给研发说该工具不支持当前数据库版本,短期内无法让工具支持,这个希望也放弃.
6. 基于这种情况,再次对备库的fio破坏的磁盘进行恢复,然后通过备库恢复出来的数据文件和主库的数据文件的启动坏块进行互补,然后由达梦工程师打开数据库.
7. 然后尝试dmexpdp导出数据,由于还有字典异常导致导出失败(虽然可以进一步通过替代的方式修复一些坏块,也许可以绕过但是每次报错一个坏块,然后修复导出效率太低,放弃该方法)
8. 尝试通过dmdbcheck检查全库坏块情况,也非常不幸,这个命令也需要检查很多字典,虽然通过人工修复了一些字典报错数据块,但是还是无法执行,最后放弃
9. 在达梦工程师建议下,他们采用了达梦的数据迁移工具按照表迁移到新库中,对于报错的块进行修复,然后再次尝试迁移,这样不停的尝试完成了大部分的迁移工作
10. 少量表通过block修复之后依旧报坏块,而且达梦工程师那边反馈当前版本无法通过表级别和全局方式跳过坏块,导致这些表如果有一个坏块无法修复,数据就无法正常迁移
11. 对于这种情况,提供给他们类似oracle rowid抢救数据的思路进一步抢救数据(打开的主备库都进行类似操作,然后进行对比获取最大限度的数据恢复)
12. 再由开发商进行整合调试业务,最大限度完成本次恢复任务
故障恢复回顾
1. 在客户没有购买最终授权和服务,甚至可能最终整体出局的情况下,达梦厂商给予了非常大的支持,这点值的表扬
2. 达梦数据库对于异常库的诊断分析功能不够完善,主要体现在:
2.1)在数据库非正常关闭的情况下无法检测数据文件坏块情况,对于这个故障,如果有类似oracle的dbv功能,然后配合脚本可以快速的实现坏块填补,会节省大量的反复尝试报错,然后修复,再尝试,再修复的工作
2.2)数据库在open的过程中提示信息不够明确友好,不便于恢复调试,比如类似oracle数据库open过程的明确日志,如果有整个启动过程的类似10046跟踪到具体sql和数据块更好
2.3)达梦的离线提取工具,对版本依赖太强,没有更好的兼容低版本,使得极端情况下,达梦售后工程师缺少兜底工具和底气
2.4)现场达梦工程师反馈当前客户的达梦数据库版本,无法全局和当个表的跳过坏块,严重不合理
2.5)dmdbcheck工具对系统字典依赖太强,如果部分字典不能被正常解析(比如有坏块),直接导致检查终止,不合理
2.6)在我接触另外一些国产库中,研发的响应速度要比达梦的迅速,也许是当前客户协调的资源不够导致(以前有客户其他国产库故障比这个小,客户也比这个小,但是直接协调不错的研发资源快速解决问题)
3. 又一次在主备库上面同时执行了fio,又是把备份和生产数据放在同一个磁盘上,这些非常不合理,希望所有人引以为戒
.wman扩展名勒索mysql数据库恢复
有客户mysql数据库被勒索加密,扩展名为.[[9BZyIXRkRaQ1F]].[[dawsones@cock.li]].wman


通过分析,确认ibd文件破坏较少

可以通过人工处理直接打开数据库并导出数据

对于类似这种被加密的勒索的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。

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

