联系：手机/微信(+86 17813235971) QQ(107644445)标题：数据库文件变成32k故障恢复作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]最近一个客户数据库重启系统之后,数据文件大小变为了32kb,我接手的不是第一现场(客户那边尝试了rman还原操作),查看alert日志,数据库最初报错Wed Jun 18 13:09:23 2025 alter database open Block change tracking file is current. Read of datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF' (fno 14) header failed with ORA-01210 Hex dump of (file 14, block 1) in trace file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_11208.trc Corrupt block relative dba: 0x03800001 (file 14, block 1) Completely zero block found during datafile header read Rereadi ...继续阅读 (3)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]数据库监听启动报TNS-12532、TNS-12560、TNS-00502错误,无法正常启动C:\Users\Administrator>lsnrctl start LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 20-6月 -2025 22:5 6:40 Copyright (c) 1991, 2010, Oracle. All rights reserved. 启动tnslsnr: 请稍候... TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Production 写入e:\app\administrator\diag\tnslsnr\WIN-3D3QHVQUU65\listener\alert\log.xml的日志信息 监听该对象时出错: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PARTIAL=yes)(QUEUESIZE=1)) 不再监听: ...继续阅读 (4)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：文件系统格式化MySQL数据库恢复作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]有客户在做迁移的时候,不慎把存放mysql数据库的硬盘进行了重新分区格式化,重新初始化mysql,并且导入了部分历史数据,不能满足客户需求,希望我们帮忙进行数据恢复.里面大概有100套左右mysql数据库,每个库里面表结构相同,数据不一样.接手这个故障,第一操作就是对磁盘进行镜像,然后使用恢复工具进行底层分析,尝试从文件系统层面恢复出来被格式化之前的数据库文件(需要有对应库目录,不然也没有意义,因为每个库里面表结构一样的,没有正确的库名字无法做到有效的区分),通过底层扫描分析,没有发现一个有效数据文件对于这样的情况,只能寄希望于mysql 数据块层面扫描恢复,通过工具扫描发现大量的数据块page文件然后尝试分析字典信息,主要是对于0000000000000001.page对应的表创建语句为:CREATE TABLE `SYS_TABLES` ( `NAME` varchar(255) NOT NULL DEFAULT '', `ID` bigint(20) unsigned NOT NULL DEFAULT '0', `N_COLS` int(10) DEFA ...继续阅读 (6)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：.sstop勒索加密数据库恢复作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]数据库文件被加密,扩展名类似:.[[dataserver@airmail.cc]].sstop,通过工具进行坏块检测确认破坏数据文件三段,每段8个block根据经验可以确认,数据文件前面8个block肯定没有业务数据(主要是文件头信息和位图信息),可以使用Oracle数据文件勒索加密恢复工具对其文件头进行构造尝试open数据库,在open过程中遭遇多次ORA-01555错误,参考以前类似文章:在数据库open过程中常遇到ORA-01555汇总数据库open过程遭遇ORA-1555对应sql语句补充Oracle Recovery Tools恢复—ORA-00704 ORA-01555故障SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00704: bootst ...继续阅读 (17)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：解决一次硬件恢复之后数据文件0kb的故障恢复case作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]客户一个比较久远系统,由于长期没有人维护,导致硬件故障,客户找人进行了硬件恢复之后,发现大量数据文件为0kb客户这个系统是17年上线,19年进行了一次升级,提出要求,只要能够恢复到19年升级之后的系统状态即可(因为是制造业系统,大量配置信息在里,至于后续产生的数据,无所谓),基于目前的数据文件情况,肯定无法恢复出来(因为字典数据在system01.dbf中)基于这种情况,我这边在客户恢复的整个目录文件中,再三查找,发现了一个类似rman备份的文件(是21年的),对其进行还原尝试在还原过程中发现大量坏块,没有办法,最后只能采用一些方法强制rman还原出来备份中的部分文件Corrupt block 653695 found during reading backup piece, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, corr_type=-2 Reread of blocknum=653695, file=H:\BAIDUNETDISK\ORA_DF1080446471_S8590_S1, found ...继续阅读 (16)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]最近在redhat 8.x系列系统中安装Oracle 19c,编译的过程中出现类似:[FATAL] Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’ of makefile ‘/u01/app/oracle/product/19c/db_1/rdbms/lib/ins_rdbms.mk’.错误[oracle@xifenfei db_1]$ ./runInstaller -ignorePrereq -waitforcompletion -silent \ > oracle.install.option=INSTALL_DB_SWONLY \ > UNIX_GROUP_NAME=oinstall \ > INVENTORY_LOCATION=${O ...继续阅读 (14)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：ORA-01171: datafile N going offline due to error advancing checkpoint作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]最近接到一个客户有一个数据文件offline的恢复咨询,通过分析日志,当时是由于在启动的时候数据文件被占用导致后续数据库open之后,该文件被强制offline掉Fri May 16 20:01:05 2025 Database mounted in Exclusive Mode Completed: ALTER DATABASE MOUNT Fri May 16 20:01:05 2025 ALTER DATABASE OPEN Fri May 16 20:01:06 2025 LGWR: STARTING ARCH PROCESSES ARC0 started with pid=70, OS id=4628 Fri May 16 20:01:06 2025 ARC0: Archival started ARC1 started with pid=74, OS id=4840 Fri May 16 20:01:06 2025 ARC1: Archival star ...继续阅读 (13)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]最近有一个客户使用了xx厂商的erp软件的Oracle数据库服务被勒索加密(运行在linux平台)文件加密结果文件名称被加上.babyk,每个目录下面会留下一个README_babyk.txt文件README_babyk.txt文件内容___ ______ ______ ______ .' `. ______ ______ ______ |______||______||______| / .-. \ .--. _ .--. .--. |______||______||______| ______ ______ ______ | | | |/ .'`\ \[ '/'`\ \( (`\] ______ ______ ______ |______||______||______| \ `-' /| \__. | ...继续阅读 (16)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：ORA-600 ksvworkmsgalloc: bad reaper作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]有一个朋友说他们想把12c的库还原到19c版本中然后进行升级测试,结果在打开库的过程中发现几个错误,让我给帮忙分析下resetlogs 报ORA-00392 ORA-00312SQL> alter database open resetlogs upgrade; alter database open resetlogs upgrade * ERROR at line 1: ORA-00392: log 7 of thread 1 is being cleared, operation not allowed ORA-00312: online log 7 thread 1: '/DBS1/data/NDBS/onlinelog/redo07_m1.log ' ORA-00312: online log 7 thread 1: '/DBS1/arch/NDBS/onlinelog/redo07_m2.log '这个错误一般是由于redo状态不对,比如标记为了CLEARING_CURRENT,处理操作SQL> select group#, ...继续阅读 (24)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：ORA-600 krccfl_chunk故障处理作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]一个数据库启动包ORA-600 krccfl_chunk错误2025-05-06T10:37:47.428203+08:00 Completed: ALTER DATABASE MOUNT /* db agent *//* {2:50212:2} */ ALTER DATABASE OPEN /* db agent *//* {2:50212:2} */ 2025-05-06T10:37:47.433709+08:00 This instance was first to open Block change tracking file is current. Ping without log force is disabled: not an Exadata system. start recovery: pdb 0, passed in flags x4 (domain enable 5) 2025-05-06T10:37:48.203383+08:00 Beginning crash recovery of 2 threads 2025-05-06 ...继续阅读 (29)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：Oracle Recovery Tools恢复案例总结—202505作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]开发出来Oracle Recovery Tools小工具已经一段时间,而且在大量的客户恢复case中使用,大大的提高的恢复效率,特别是win平台需要bbed或者类似工具的时候.现在对该工具在实战中的一些case进行总结:Oracle Recovery Tools修复空闲坏块Oracle Recovery Tools实战批量坏块修复Oracle Recovery Tools快速恢复ORA-19909Oracle Recovery Tools 解决ORA-600 3020故障Oracle Recovery Tools恢复csc higher than block scnOracle Recovery Tools恢复MISSING00000文件故障Oracle Recovery Tools快速恢复重建ctl遗漏数据文件故障一键恢复ORA-01113 ORA-01110—Oracle Recovery ToolsOracle Recovery Tools 解决ORA-01190 ORA-01248等故障Oracle Recovery ...继续阅读 (30)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：ORA-600 kddummy_blkchk 数据库循环重启作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]一个运行在hp平台的10g rac突然异常,之后运行一段时间就自动重启,客户让对其进行分析和解决Thu May 8 06:23:21 2025 ALTER DATABASE OPEN Picked broadcast on commit scheme to generate SCNs Thu May 8 06:23:21 2025 Thread 1 opened at log sequence 74302 Current log# 1 seq# 74302 mem# 0: /dev/vgdata/rrac_redo01 Successful open of redo thread 1 Thu May 8 06:23:21 2025 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Thu May 8 06:23:21 2025 SMON: enabling cache recovery Thu May 8 06:23:22 2025 Success ...继续阅读 (31)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：记录一次asm disk加入到vg通过恢复直接open库的案例作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]客户在不清楚磁盘被asm disk使用的情况下,直接分区做pv,加入到vg中并且分配给了lv,导致数据库异常通过操作系统层面分析,确认客户把data磁盘组的一个磁盘给处理掉了,导致数据库报错WARNING: ASMB force dismounting group 2 (DATA) due to failover SUCCESS: diskgroup DATA was dismounted 2025-05-04T07:03:19.910082+08:00 KCF: read, write or open error, block=0x201544 online=1 file=102 '+DATA/ORCL/F7D939D6DBE06C71E053C30114AC1F10/DATAFILE/xifenfei_61.dbf' error=15078 txt: '' 2025-05-04T07:03:19.918972+08:00 Errors in file /u01/app/oracle/diag/rdbms/or ...继续阅读 (25)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：CHECKDB 发现了 N 个分配错误和 M 个一致性错误作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]接到一个朋友的数据库故障请求,dbcc checkdb报以下错误服务器: 消息 8905，级别 16，状态 1，行 1 扩展盘区 (1:5144)（属于数据库 ID 8）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。 服务器: 消息 8929，级别 16，状态 1，行 1 对象 ID 2: 在文本 ID 800849920 中发现错误，该文本的所有者是由 RID = (1:143:7) id = 1218103380 and indid = 4 标识的数据记录。 服务器: 消息 8961，级别 16，状态 1，行 1 表错误: 对象 ID 2。text、ntext 或 image 节点（位于页 (1:3813)，槽 0，文本 ID 800849920）与该节点位于页 (1:489)，槽 4 处的引用不匹配。 'myhis' 的 DBCC 结果。 CHECKDB 发现了 1 个分配错误和 0 个一致性错误，这些错误并不与任何单个的对象相关联。 'sysobjects' 的 DBCC 结果。 对象 'sysobjects' 有 ...继续阅读 (23)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：达梦数据库dm.ctl文件异常恢复作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]达梦数据库中也有类似oracle的控制文件(control0x.ctl),在达梦数据库中一般叫做dm.ctl,具体是有dm.ini(达梦默认参数文件名)中的CTL_PATH参数确定.在某些情况下,由于参数文件损坏或者丢失,导致数据库异常,这里dm.ctl文件丢失故障恢复创建表空间和表并插入数据SQL> create tablespace tbs_xff datafile 'tbs_xff01.dbf' size 128; 操作已执行 已用时间: 52.996(毫秒). 执行号:1303. SQL> create table t_xff tablespace tbs_xff as 2 select * from dba_objects; 操作已执行 已用时间: 71.055(毫秒). 执行号:1304. SQL> insert into t_xff select * from dba_objects; 影响行数 1094 已用时间: 28.759(毫秒). 执行号:1305. SQL> insert into t_xff select * from dba_obj ...继续阅读 (23)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]接到客户反馈,一套运行在虚拟化平台中的Oracle数据库,由于机房断电,导致数据库无法启动,最初启动报错2025-04-22T16:59:48.922227+08:00 Completed: alter database mount exclusive alter database open 2025-04-22T16:59:52.609726+08:00 Ping without log force is disabled: instance mounted in exclusive mode. 2025-04-22T16:59:52.937852+08:00 Beginning crash recovery of 1 threads parallel recovery started with 15 processes Thread 1: Recovery starting at checkpoint rba (logseq 11031 block 1 ...继续阅读 (28)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：可能是 tempdb 空间用尽或某个系统表不一致故障处理作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]有客户sql server数据库由于异常断电,导致数据库访问异常对其做dbcc检查发现报：检查已终止。收集事实数据时检测到错误。可能是 tempdb 空间用尽或某个系统表不一致。请检查前面的错误消息。错误查看sql server 日志,发现报错日志内容为:04/22/2025 10:50:26,spid58,未知,DBCC CHECKDB (SHINVA) WITH no_infomsgs executed by sa terminated abnormally due to error state 5. Elapsed time: 0 hours 0 minutes 1 seconds.04/22/2025 10:50:26,spid58,未知,The Database ID 7 Page (1:147440) slot 0 for LOB data type node does not exist. This is usually caused by transactions that can read uncommitted data on a ...继续阅读 (23)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]今天有一个客户11.2.0.4的库由于断电报ORA-600 kcratr_nab_less_than_odr的故障C:\Users\Administrator>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期二 4月 22 10:56:36 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> select * from v$version; BANNER -------------------------------------- ...继续阅读 (28)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：[MY-013183] [InnoDB] Assertion failure故障处理作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]在一个存储故障的环境中,通过做硬件恢复,恢复出来一个mysql数据库,但是直接启动报错[mysql@localhost bin]$ ./mysqld2025-04-17T03:34:50.352302Z 0 [System] [MY-010116] [Server] /data/mysql/mysql/bin/mysqld (mysqld 8.0.34) starting as process 582392025-04-17T03:34:50.356910Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.2025-04-17T03:34:51.031054Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=160] log sequence number ...继续阅读 (22)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：Oracle 19c 202504补丁（RUs+OJVM）-19.27作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.] 19.0.0.0DescriptionDatabase UpdateGI UpdateWindows Bundle PatchAPR2025 (19.27.0.0.0)376429013764195837532350JAN2025 (19.26.0.0.0)372609743725788637486199OCT2024 (19.25.0.0.0)369125973691669036878821JUL2024 (19.24.0.0.0)365827813658262936521936APR2024 (19.23.0.0.0)362332633623312636219938JAN2024 (19.22.0.0.0)359431573594098935962832OCT2023 (19.21.0.0.0)356431073564282235681552JUL2023 (19.20.0.0.0)353200813531949035348034APR2023 (19.19.0.0.0)350420683503784035046439JAN202 ...继续阅读 (21)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]数据库异常断电,然后启动异常,我接手该库,尝试recover恢复SQL> recover database; ORA-10562: Error occurred while applying redo to data block (file# 2, block# 63710) ORA-10564: tablespace SYSAUX ORA-01110: ???????? 2: 'H:\TEMP\GDLISNET\SYSAUX01.DBF' ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 179030 ORA-00600: ????????????, ????: [6101], [0], [700], [32], [], [], [], [], [], [], [], [] SQL> recover datafile 1; 完成介质恢复。 SQL> recover datafile 3; 完 ...继续阅读 (26)

联系：手机/微信(+86 17813235971) QQ(107644445)标题：pdu完美支持金仓数据库恢复(KingbaseES)作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]最近朋友对pdu进行了一些完善,让其可以比较好的支持电科金仓数据库（KingbaseES）的v8/v9版本使用pdu直接unload数据[kingbase@xifenfei ~]$ isql -Usystem test Password for user system: isql (V9.0) Licesen Type: SALES-企业版. Type "help" for help. test=# select version(); version ------------------------- KingbaseES V009R002C010 (1 row) test=# \dt List of relations Schema | Name | Type | Owner --------+-------+-------+-------- public | t_xff | table | system (1 row) test=# drop table walminer_co ...继续阅读 (29)

...继续阅读 (21)

...继续阅读 (21)

...继续阅读 (20)

...继续阅读 (18)

...继续阅读 (17)

...继续阅读 (17)

...继续阅读 (16)

...继续阅读 (21)