ORA-00756 ORA-10567故障数据0丢失恢复

Posted on 2025 年 06 月 29 日 by 惜分飞

客户虚拟化故障修复之后,数据库启动报ORA-600 kcratr_scan_lastbwr错误

这个是一个比较常见的错误,一般recover 下就ok了,但是有些时候会出现ORA-600 3020或者类似ORA-00756 ORA-10567的错误,比如这次不幸就遇到了该错误

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 10, block# 4005760, file
offset is 2750414848 bytes)
ORA-10564: tablespace PACS55
ORA-01110: data file 10: '/u02/oradata/pacsdb/pacs55.4.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 76649

然后尝试单个文件recover恢复

SQL> recover datafile 10;
ORA-00283: recovery session canceled due to errors
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 10, block# 4005760, file
offset is 2750414848 bytes)
ORA-10564: tablespace PACS55
ORA-01110: data file 10: '/u02/oradata/pacsdb/pacs55.4.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 76649

SQL> recover datafile 9;
ORA-00283: recovery session canceled due to errors
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 9, block# 4158754, file
offset is 4003741696 bytes)
ORA-10564: tablespace PACS55
ORA-01110: data file 9: '/u02/oradata/pacsdb/pacs55.3.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 76660

通过dbv检查这两个异常文件

[oracle@oradb ~]$ dbv file=/u02/oradata/pacsdb/pacs55.3.dbf

DBVERIFY: Release 19.0.0.0.0 - Production on Sat Jun 28 23:02:15 2025

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

DBVERIFY - Verification starting : FILE = /u02/oradata/pacsdb/pacs55.3.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 4194302
Total Pages Processed (Data) : 2482487
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1655515
Total Pages Failing   (Index): 0
Total Pages Processed (Lob)  : 25017
Total Pages Failing   (Lob)  : 0
Total Pages Processed (Other): 15919
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 15364
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 311133131196 (72.1895485884)
[oracle@oradb ~]$ dbv file=/u02/oradata/pacsdb/pacs55.4.dbf 

DBVERIFY: Release 19.0.0.0.0 - Production on Sat Jun 28 23:04:59 2025

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

DBVERIFY - Verification starting : FILE = /u02/oradata/pacsdb/pacs55.4.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 4194302
Total Pages Processed (Data) : 2466409
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1683244
Total Pages Failing   (Index): 0
Total Pages Processed (Lob)  : 16977
Total Pages Failing   (Lob)  : 0
Total Pages Processed (Other): 15909
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 11763
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 311133133727 (72.1895488415)

确定数据文件本身没有坏块,只是redo写丢失或者某种bug导致少量block应用redo的时候异常,而且报错是index,直接通过底层处理报错的block,让其这些报错的block直接不应用日志,然后完成recover操作,其他数据块数据不会丢失(最大限度减少损失,而不是直接修改文件头scn,或者强制拉库的方式来处理)

SQL> select file#,fuzzy from v$datafile_header;

     FILE# FUZ
---------- ---
	 1 NO
	 2 NO
	 3 NO
	 4 NO
	 5 NO
	 7 NO
	 8 NO
	 9 YES
	10 YES
	11 NO
	12 NO

     FILE# FUZ
---------- ---
	13 NO
	14 NO
	15 NO
	16 NO
	17 NO
	18 NO
	19 NO

18 rows selected.

SQL> recover  datafile 9 ;
Media recovery complete.
SQL> recover  datafile 10 ;
ORA-00283: recovery session canceled due to errors
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 10, block# 3822912, file
offset is 1252524032 bytes)
ORA-10564: tablespace PACS55
ORA-01110: data file 10: '/u02/oradata/pacsdb/pacs55.4.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 76649
 
SQL> recover  datafile 10;
Media recovery complete.

正常open数据库成功,并rebuild 异常的对象

SQL> alter database open;

Database altered.

SQL> select owner,object_name,object_type from dba_objects where data_object_id in(76649,76660);

OWNER
--------------------------------------------------------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_TYPE
-----------------------
PACS55
STUDYINFO_DIAGRPTID
INDEX

PACS55
PACS_STUDYINFO_PK
INDEX

OWNER
--------------------------------------------------------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_TYPE
-----------------------


SQL> alter index PACS55.STUDYINFO_DIAGRPTID rebuild online parallel 4;

Index altered.

SQL> alter index PACS55.PACS_STUDYINFO_PK rebuild online parallel 4;

Index altered.

SQL> 
SQL> 
SQL> 
SQL> alter index PACS55.STUDYINFO_DIAGRPTID noparallel;
alter index PACS55.PACS_STUDYINFO_PK noparallel;
Index altered.

SQL> 

Index altered.

至此该库完美恢复业务可以直接使用,业务数据0丢失.这次运气比较好,如果是表数据异常,可能会麻烦一点,但是也可以最大限度恢复(肯定比强制拉库,或者修改文件头的方式效果好)

数据库文件变成32k故障恢复

Posted on 2025 年 06 月 26 日 by 惜分飞

联系：手机/微信(+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
Rereading datafile 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
Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_11208.trc:
ORA-01122: 数据库文件 14 验证失败
ORA-01110: 数据文件 14: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF'
ORA-01210: 数据文件标头发生介质损坏
ORA-1122 signalled during: alter database open...
Wed Jun 18 13:09:23 2025
Checker run found 1 new persistent data failures

客户那边不知道做了什么操作之后报错（初步估计是把14号文件重命名了）

Thu Jun 19 16:04:19 2025
alter database open
Thu Jun 19 16:04:21 2025
Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_dbw0_13000.trc:
ORA-01157: ????/?????? 14 - ??? DBWR ????
ORA-01110: ???? 14: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF'
ORA-27041: ??????
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_12328.trc:
ORA-03113: 通信通道的文件结尾
ORA-3113 signalled during: alter database open...

根据客户反馈14号文件变成了32kb,就是被重命名的.bak文件

这其中有一个bak0618是通过rman还原出来的（备份中无有效的14号文件备份，还原出来的为该文件初始化创建大小）

Thu Jul 07 16:57:05 2022
alter tablespace wasion add datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.dbf' size 10g autoextend on
Completed: alter tablespace wasion add datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.dbf' size 10g autoextend on

基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件

这些本身没有问题,脚本的后面有直接通过系统级别命令删除两天之前的备份文件

这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,rman备份尽量使用rman本身的策略来管理不要使用系统命令来维护备份策略,基于这样的情况,可以使用反删除命令找出来了一些该文件的备份集,并注册到控制文件中

RMAN> list backup of datafile 14;


备份集列表
===================


BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
35251   Incr 0  10.89G     DISK        00:01:20     15-6月 -25
  备份集 35251 中的数据文件列表
  文件 LV 类型 Ckp SCN    Ckp 时间   名称
  ---- -- ---- ---------- ---------- ----
  14   0  Incr 758850903  15-6月 -25 D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF

  备份集 副本号 2 属于备份集 35251
  设备类型 经过时间 完成时间   压缩标记
  ----------- ------------ ---------- ---------- ---
  DISK        00:01:20     26-6月 -25 NO         TAG20250615T220003

    备份集 35251 副本号 2的备份片段列表
    BP 关键字  Pc# 状态      段名称
    ------- --- ----------- ----------
    78307   1   AVAILABLE   H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1
    78308   2   AVAILABLE   H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_2_1

BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
35266   Incr 0  1.81G      DISK        00:00:00     17-6月 -25
  备份集 35266 中的数据文件列表
  文件 LV 类型 Ckp SCN    Ckp 时间   名称
  ---- -- ---- ---------- ---------- ----
  14      Full 759283192  17-6月 -25 D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF

  备份集 副本号 1 属于备份集 35266
  设备类型 经过时间 完成时间   压缩标记
  ----------- ------------ ---------- ---------- ---
  DISK        00:00:00     26-6月 -25 NO         TAG20250617T220049

    备份集 35266 副本号 1的备份片段列表
    BP 关键字  Pc# 状态      段名称
    ------- --- ----------- ----------
            1   DELETED                        <---缺少一个备份集文件
    78309   2   AVAILABLE   H:\BAIDUNETDISK\202506191452\L0_ORCL_20250617_79022_5E3S94MC_2_1

尝试rman还原这些备份文件

RMAN> run
2> {
3> SET NEWNAME FOR DATAFILE 14 to 'H:\BaiduNetdisk\202506191452\14.dbf';
4> restore datafile 14;
5> }

正在执行命令: SET NEWNAME

启动 restore 于 26-6月 -25
使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00014 还原到 H:\BAIDUNETDISK\202506191452\14.DBF
通道 ORA_DISK_1: 正在还原段 1 (属于 2)
通道 ORA_DISK_1: 正在读取备份片段 H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: restore 命令 (在 06/26/2025 08:35:53 上) 失败
ORA-19870: 还原备份片段 H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1 时出错
ORA-00600: 内部错误代码, 参数: [krbvalmrange_badfno], [1], [14], [], [], [], [], [], [], [], [], []

alert日志报错

Thu Jun 26 08:25:26 2025
Checker run found 39 new persistent data failures
Thu Jun 26 08:35:51 2025
Datafile rdba reconstruction error, expected block greater than 804966, got 322047 for datafile 14
Corrupt block 804352 found during reading backup piece, 
file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1, corr_type=4
Reread of blocknum=804352, file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1. found valid data
Datafile rdba reconstruction error, expected block greater than 324095, got 55516 for datafile 14
Corrupt block 806400 found during reading backup piece, 
file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1, corr_type=4
Reread of blocknum=806400, file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1. found valid data
Errors in file C:\APP\XFF\diag\rdbms\ORCL\orcl\trace\orcl_ora_19208.trc  (incident=177):
ORA-00600: 内部错误代码, 参数: [krbvalmrange_badfno], [1], [14], [], [], [], [], [], [], [], [], []
Incident details in: C:\APP\XFF\diag\rdbms\ORCL\orcl\incident\incdir_177\orcl_ora_19208_i177.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Thu Jun 26 08:35:52 2025

后面通过工具分析以及ORA-600 krbvalmrange_badfno的错误,基本上可以确认在反删除恢复的备份集文件中部分rman的block是其他数据文件的,从而导致无法正常还原.基于这种情况,通过工具进行强制还原出来部分14号数据文件的block

然后再通过磁盘级别碎片,找到部分没有覆盖的block

把rman备份中强制抽取的部分block和底层碎片恢复的没有覆盖的block组合到一起,通过检测确认恢复了大概2/3的数据

基于恢复的该文件和这个表空间的其他文件一起,使用dul工具把数据恢复到新库中,最大限度完成本次数据的抢救工作.

本次故障本不该发生,或者说发生不该如此严重:
1. rman备份采用系统级别维护策略,在备份没有成功的情况下依旧通过系统层面删除文件,导致故障文件无一份有效备份
2. 发生故障之后,没有保护现场的意识:对于32kb的数据文件所在磁盘进行了大量的写入操作（近1T的数据文件直接在本盘做了一次拷贝,还有rman默认写入到了以前文件所在位置）

tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误

Posted on 2025 年 06 月 21 日 by 惜分飞

联系：手机/微信(+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))
不再监听: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=WIN-3D3QHVQUU65)(PORT=1521))
)
TNS-12532: TNS: 无效的参数
 TNS-12560: TNS: 协议适配器错误
  TNS-00502: 参数无效
   32-bit Windows Error: 22: Invalid argument

监听程序未能启动。请参阅上面的错误消息...

TNS-12560: TNS: 协议适配器错误
 TNS-00530: 协议适配器错误
  32-bit Windows Error: 55: Unknown error

尝试重建监听提示端口占用,对于这种情况,第一反应可能是数据库服务器的一些tcp链接异常.通过netstat -nao查看发现8080端口的应用占用TCP链接太多

通过分析发现该tcp链接已经达到7w多个,怀疑是该问题导致监听异常,重启应用释放这些连接之后,数据库监听恢复正常.

文件系统格式化MySQL数据库恢复

Posted on 2025 年 06 月 18 日 by 惜分飞

联系：手机/微信(+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) DEFAULT NULL,
  `TYPE` int(10) unsigned DEFAULT NULL,
  `MIX_ID` bigint(20) unsigned DEFAULT NULL,
  `MIX_LEN` int(10) unsigned DEFAULT NULL,
  `CLUSTER_NAME` varchar(255) DEFAULT NULL,
  `SPACE` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

通过上述信息可以获取到name和id列的值(其中name中包含库名/表名),然后再通过0000000000000003.page文件结合对应的表创建语句:

CREATE TABLE `SYS_INDEXES` (
  `TABLE_ID` bigint(20) unsigned NOT NULL DEFAULT '0',
  `ID` bigint(20) unsigned NOT NULL DEFAULT '0',
  `NAME` varchar(120) DEFAULT NULL,
  `N_FIELDS` int(10) unsigned DEFAULT NULL,
  `TYPE` int(10) unsigned DEFAULT NULL,
  `SPACE` int(10) unsigned DEFAULT NULL,
  `PAGE_NO` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`TABLE_ID`,`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

这个主要是或者表id和page id的对应关系(表id直接关联SYS_TABLES.ID,然后获取SYS_TABLES.NAME和SYS_INDEXES.ID对应关系,从而可以确定每一个表对应的需要恢复的page文件信息,再通过客户提供的表语句和对应的page关系,实现相关数据恢复,具体操作可以参考以往类似文章:
xfs文件系统mysql删库恢复
 又一起mysql rm删除数据库目录事故
 [MySQL异常恢复]恢复数据字典表讲解
 [MySQL异常恢复]mysql drop table 数据恢复
 mysql ibd文件反删除恢复之后异常处理
 [MySQL异常恢复]使用工具直接抽取MySQL数据字典
 MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)

.sstop勒索加密数据库恢复

Posted on 2025 年 06 月 16 日 by 惜分飞

联系：手机/微信(+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: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too
small
Process ID: 23720
Session ID: 243 Serial number: 13


SQL> alter database Open;
alter database Open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 5 with name
"_SYSSMU5_2520346804$" too small
Process ID: 26636
Session ID: 232 Serial number: 1

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