Database SOS – Professional Database Recovery Support@+8617813235971

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-06T10:37:48.568120+08:00
 parallel recovery started with 32 processes
2025-05-06T10:37:48.610951+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.611037+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.611243+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.611438+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.614947+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.616591+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617188+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617253+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617428+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617606+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617676+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.617809+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.636568+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.636568+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.636620+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.637156+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.637300+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.637881+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.637999+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.638112+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.638241+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.638304+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.638338+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.638347+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.641621+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.642926+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643092+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643192+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643204+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643372+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643516+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.643573+08:00
start recovery: pdb 0, passed in flags x5 (domain enable 5) 
2025-05-06T10:37:48.748956+08:00
Started redo scan
2025-05-06T10:37:49.849382+08:00
Completed redo scan
 read 469347 KB redo, 1213 data blocks need recovery
2025-05-06T10:37:50.007840+08:00
Started redo application at
 Thread 1: logseq 369323, block 651514, offset 0
 Thread 2: logseq 132962, block 1319944, offset 0
2025-05-06T10:37:50.016910+08:00
Recovery of Online Redo Log: Thread 1 Group 13 Seq 369323 Reading mem 0
  Mem# 0: +DATA/orcl/ONLINELOG/group_13.349.978709791
  Mem# 1: +FRA/orcl/ONLINELOG/group_13.12992.978709793
2025-05-06T10:37:50.025725+08:00
Recovery of Online Redo Log: Thread 2 Group 18 Seq 132962 Reading mem 0
  Mem# 0: +DATA/orcl/ONLINELOG/group_18.354.978710003
  Mem# 1: +FRA/orcl/ONLINELOG/group_18.12997.978710005
2025-05-06T10:37:51.063556+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_68031.trc(incident=868005)(PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [krccfl_chunk], [0x7F9BBB30BE58], [166528],[],[],[],[],[],[],[],[],[]
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_868005/orcl2_ora_68031_i868005.trc
2025-05-06T10:37:52.269823+08:00
Dumping diagnostic data in directory=[cdmp_20250506103752],requested by(instance=2,osid=68031),summary=[incident=868005].
2025-05-06T10:37:52.306517+08:00
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-05-06T10:37:52.310723+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310813+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310820+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310853+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310902+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310907+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310945+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.310950+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.310987+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311002+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311009+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311017+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311055+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311055+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311064+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-05-06T10:37:52.311071+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311080+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311107+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311119+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311126+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311135+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p000_69617.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311156+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311184+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311203+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311205+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311211+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p001_69619.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311276+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p002_69621.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311276+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311280+08:00
Recovery slave process is holding some recovery locks. Killing the instance now.
2025-05-06T10:37:52.311308+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p003_69623.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311329+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p004_69625.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311341+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p005_69627.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311345+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p007_69631.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311353+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p008_69633.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311374+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p006_69629.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311386+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p009_69635.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311402+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p00a_69637.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311513+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p00c_69641.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.311515+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_p00b_69639.trc:
ORA-10388: parallel query server interrupt (failure)
2025-05-06T10:37:52.348331+08:00
USER (ospid: 69617): terminating the instance due to error 10388
2025-05-06T10:37:52.585589+08:00
System state dump requested by (instance=2, osid=69617 (P000)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_diag_67490_20250506103752.trc
2025-05-06T10:37:54.016704+08:00
License high water mark = 34
2025-05-06T10:37:55.387072+08:00
Instance terminated by USER, pid = 69617
2025-05-06T10:37:55.388683+08:00
Warning: 2 processes are still attach to shmid 2850830:
 (size: 45056 bytes, creator pid: 65902, last attach/detach pid: 67492)
2025-05-06T10:37:56.018027+08:00
USER (ospid: 69907): terminating the instance
2025-05-06T10:37:56.021711+08:00
Instance terminated by USER, pid = 69907

查询mos发现类似文章:
Database doesn’t open after crash ORA-00600 [krccfl_chunk] (Doc ID 2967548.1)
Bug 33251482 – ORA-487 / ORA-600 [krccfl_chunk] : CTWR process terminated during PDB creation (Doc ID 33251482.8)

分析这个客户情况，通过trace信息:Block change tracking file is current. 可以确认是启用了BCT,而且日志信息也反应出来是pdb环境。进一步分析客户的情况,发现他们在以前有一个数据文件创建到了本地（实际是rac环境）

2024-12-23T11:07:09.168322+08:00
PDBODS(5):Completed: alter tablespace PDBODS_DATA add datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS02.DBF'
 size 5000M autoextend on next 1000M maxsize 32000M

数据库中现在实际存储路径/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/D:APPADMINISTRATORORADATAORCLUSERS 02.DBF
基于这种情况,解决问题比较简单:在本地数据文件所在节点禁用BCT,然后open库,把数据文件拷贝到asm中即可

Oracle Recovery Tools恢复案例总结—202505

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle Recovery Tools恢复案例总结—202505

ORA-600 kddummy_blkchk 数据库循环重启

联系：手机/微信(+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
Successfully onlined Undo Tablespace 1.
Thu May  8 06:23:22 2025
SMON: enabling tx recovery
Thu May  8 06:23:22 2025
Database Characterset is ZHS16CGB231280
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 4
replication_dependency_tracking turned off (no async multimaster replication found)
Thu May  8 06:23:23 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Starting background process QMNC
QMNC started with pid=22, OS id=15792
Thu May  8 06:23:25 2025
ORACLE Instance orcl1 (pid = 13) - Error 607 encountered while recovering transaction (9, 33) on object 775794.
Thu May  8 06:23:25 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Thu May  8 06:23:26 2025
Completed: ALTER DATABASE OPEN
Thu May  8 06:23:26 2025
Doing block recovery for file 118 block 333578
Block recovery from logseq 74302, block 22 to scn 46740761996
Thu May  8 06:23:26 2025
Recovery of Online Redo Log: Thread 1 Group 1 Seq 74302 Reading mem 0
  Mem# 0: /dev/vgdata/rrac_redo01
Block recovery stopped at EOT rba 74302.33.16
Block recovery completed at rba 74302.33.16, scn 10.3791089036
Thu May  8 06:23:33 2025
Trace dumping is performing id=[cdmp_20250508062324]
Thu May  8 06:25:55 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Thu May  8 06:25:58 2025
ORACLE Instance orcl1 (pid = 13) - Error 607 encountered while recovering transaction (9, 33) on object 775794.
Thu May  8 06:27:32 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
Doing block recovery for file 118 block 333578
Block recovery from logseq 74302, block 372 to scn 46740952565
Thu May  8 06:27:41 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
ORACLE Instance orcl1 (pid = 13) - Error 607 encountered while recovering transaction (9, 33) on object 775794.
Thu May  8 06:27:43 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Doing block recovery for file 118 block 333578
Block recovery from logseq 74302, block 372 to scn 46740952565
Thu May  8 06:27:45 2025
Recovery of Online Redo Log: Thread 1 Group 1 Seq 74302 Reading mem 0
  Mem# 0: /dev/vgdata/rrac_redo01
Block recovery completed at rba 74302.394.16, scn 10.3791279606
Thu May  8 06:27:47 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_smon_15721.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [118], [333578], [18019], [], [], [], []
Thu May  8 06:28:07 2025
Errors in file /users/oracle/admin/orcl/bdump/orcl1_pmon_15690.trc:
ORA-00474: SMON process terminated with error
Thu May  8 06:28:07 2025
PMON: terminating instance due to error 474

这个数据库重启是由于smon进程异常导致数据库关闭,然后rac自动拉起数据库,从而出现了循环重启启动,smon异常的主要原因是由于“ORACLE Instance orcl1 (pid = 13) – Error 607 encountered while recovering transaction (9, 33) on object 775794.”这个表示有实物要回滚,但是遇到了ORA-600 kddummy_blkchk异常,无法完成回滚从而使得smon进程异常进而使得数据实例crash.对于这个问题处理相对比较简单
1. 通过ORA-600 kddummy_blkchk找出来报错对象

ORA-00600: internal error code, arguments: [kddummy_blkchk], [a], [b], 1

ARGUMENTS:
Arg [a] Absolute file number
Arg [b] Block number
Arg 1 Internal error code returned from kcbchk() which indicates the problem encountered.

2. 屏蔽实物回滚,打开数据库,然后对通过dba_extents 查询出来的对象/或者根据事务报错的object信息查询出来对象进行重建,完成本次恢复任务

关于ORA-00600: internal error code, arguments: [kddummy_blkchk], [a], [b], 相关目前已知bug

Bug	Fixed	Description
12349316	11.2.0.4, 12.1.0.2, 12.2.0.1	DBMS_SPACE_ADMIN.TABLESPACE_FIX_BITMAPS fails with ORA-600 [kddummy_blkchk] / ORA-600 [kdBlkCheckError] / ORA-607
17325413	11.2.0.3.BP23, 11.2.0.4.2, 11.2.0.4.BP04, 12.1.0.1.3, 12.1.0.2, 12.2.0.1	Drop column with DEFAULT value and NOT NULL definition ends up with Dropped Column Data still on Disk leading to Corruption
13715932	11.2.0.4, 12.1.0.1	ORA-600 [kddummy_blkchk] [18038] while adding extents to a large datafile
12417369	11.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.1	Block corruption from rollback on compressed table
10324526	10.2.0.5.4, 11.1.0.7.8, 11.2.0.2.3, 11.2.0.2.BP06, 11.2.0.3, 12.1.0.1	ORA-600 [kddummy_blkchk] [6106] / corruption on COMPRESS table in TTS
10113224	11.2.0.3, 12.1.0.1	Index coalesce may generate invalid redo if blocks in the buffer cache are invalid/corrupted
9726702	11.2.0.3, 12.1.0.1	DBMS_SPACE_ADMIN.assm_segment_verify reports HWM related inconsistencies
9724970	11.2.0.1.BP08, 11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	Block Corruption with PDML UPDATE. ORA_600 [4511] OERI[kdblkcheckerror] by block check
9711859	10.2.0.5.1, 11.1.0.7.6, 11.2.0.2, 12.1.0.1	ORA-600 [ktsptrn_fix-extmap] / ORA-600 [kdblkcheckerror] during extent allocation caused by bug 8198906
9581240	11.1.0.7.9, 11.2.0.2, 12.1.0.1	Corruption / ORA-600 [kddummy_blkchk] [6101] / ORA-600 [7999] after RENAME operation during ROLLBACK
9350204	11.2.0.3, 12.1.0.1	Spurious ORA-600 [kddummy_blkchk] .. [6145] during CR operations on tables with ROWDEPENDENCIES
9231605	11.1.0.7.4, 11.2.0.1.3, 11.2.0.1.BP02, 11.2.0.2, 12.1.0.1	Block corruption with missing row on a compressed table after DELETE
9119771	11.2.0.2, 12.1.0.1	OERI [kddummy_blkchk]…[6108] from ‘SHRINK SPACE CASCADE’
9019113	11.2.0.1.BP02, 11.2.0.2, 12.1.0.1	ORA-600 [17182] ORA-7445 [memcpy] ORA-600 [kdBlkCheckError] for OLTP COMPRESS table in OLTP Compression REDO during RECOVERY
8951812	11.2.0.2, 12.1.0.1	Corrupt index by rebuild online. Possible OERI [kddummy_blkchk] by SMON
8720802	10.2.0.5, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1	Add check for row piece pointing to itself (db_block_checking,dbv,rman,analyze)
8331063	11.2.0.3, 12.1.0.1	Corrupt Undo. ORA-600 [2015] in Undo Block During Rollback
6523037	11.2.0.1.BP07, 11.2.0.2.2, 11.2.0.2.BP01, 11.2.0.3, 12.1.0.1	Corruption / ORA-600 [kddummy_blkchk] [6110] on update
8277580	11.1.0.7.2, 11.2.0.1, 11.2.0.2, 12.1.0.1	Corruption on compressed tables during Recovery and Quick Multi Delete (QMD).
9964102	11.2.0.1	OERI:2015 / OERI:kddummy_blkchk / undo corruption from supplementat logging with compressed tables
8613137	11.1.0.7.2, 11.2.0.1	ORA-600 updating table with DEFERRED constraints
8360192	11.1.0.7.6, 11.2.0.1	ORA-600 [kdBlkCheckError] [6110] / corruption from insert
8239658	10.2.0.5, 11.2.0.1	Dump / corruption writing row to compressed table
8198906	10.2.0.5, 11.2.0.1	OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents
7715244	11.1.0.7.2, 11.2.0.1	Corruption on compressed tables. Error codes 6103 / 6110
7662491	10.2.0.4.2, 10.2.0.5, 11.1.0.7.4, 11.2.0.1	Array Update can corrupt a row. Errors OERI[kghstack_free1] or OERI[kddummy_blkchk][6110]
7411865	10.2.0.4.2, 10.2.0.5, 11.1.0.7.1, 11.2.0.1	OERI:13030 / ORA-1407 / block corruption from UPDATE .. RETURNING DML with trigger
7331181	11.2.0.1	ORA-1555 or OERI [kddummy_blkchk] [file#] [block#] [6126] during CR Rollback in query
7293156	11.1.0.7, 11.2.0.1	ORA-600 [2023] by Parallel Transaction Rollback when applying Multi-block undo Head-piece / Tail-piece
7041254	11.1.0.7.5, 11.2.0.1	ORA-19661 during RMAN restore check logical of compressed backup / IOT dummy key
6760697	10.2.0.4.3, 10.2.0.5, 11.1.0.7, 11.2.0.1	DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY does not detect certain segment header block corruption
6647480	10.2.0.4.4, 10.2.0.5, 11.1.0.7.3, 11.2.0.1	Corruption / OERI [kddummy_blkchk] .. [18021] with ASSM
6134368	10.2.0.5, 11.2.0.1	ORA-1407 / block corruption from UPDATE .. RETURNING DML with trigger – SUPERCEDED
6057203	10.2.0.4, 11.1.0.7, 11.2.0.1	Corruption with zero length column (ZLC) / OERI [kcbchg1_6] from Parallel update
6653934	10.2.0.4.2, 10.2.0.5, 11.1.0.7	Dump / block corruption from ONLINE segment shrink with ROWDEPENDENCIES
6674196	10.2.0.4, 10.2.0.5, 11.1.0.6	OERI / buffer cache corruption using ASM, OCFS or any ksfd client like ODM
5599596	10.2.0.4, 11.1.0.6	Block corruption / OERI [kddummy_blkchk] on clustered or compressed tables
5496041	10.2.0.4, 11.1.0.6	OERI[6006] / index corruption on compressed index
5386204	10.2.0.4.1, 10.2.0.5, 11.1.0.6	Block corruption / OERI[kddummy_blkchk] after direct load of ASSM segment
5363584	10.2.0.4, 11.1.0.6	Array insert into table can corrupt redo
4602031	10.2.0.2, 11.1.0.6	Block corruption from UPDATE or MERGE into compressed table
4493447	11.1.0.6	Spurious ORA-600 [kddummy_blkchk] [file#] [block#] [6145] on rollback of array update
4329302	11.1.0.6	OERI [kddummy_blkchk] [file#] [block#] [6145] on rollback of update with logminer
6075487	10.2.0.4	OERI[kddummy_blkchk]..[18020/18026] for DDL on plugged ASSM tablespace with FLASHBACK
4054640	10.1.0.5, 10.2.0.1	Block corruption / OERI [kddummy_blkchk] at physical standby
4000840	10.1.0.4, 10.2.0.1, 9.2.0.7	Update of a row with more than 255 columns can cause block corruption
3772033	9.2.0.7, 10.1.0.4, 10.2.0.1	OERI[ktspfmb_create1] creating a LOB in ASSM using 2k blocksize

记录一次asm disk加入到vg通过恢复直接open库的案例

联系：手机/微信(+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/orcl/orcl1/trace/orcl1_dbwc_18507.trc:
2025-05-04T07:03:19.952045+08:00
KCF: read, write or open error, block=0x2013e7 online=1
        file=102 '+DATA/ORCL/F7D939D6DBE06C71E053C30114AC1F10/DATAFILE/xifenfei_61.dbf'
        error=15078 txt: ''
2025-05-04T07:03:19.964538+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_dbw7_18486.trc:
2025-05-04T07:03:19.967133+08:00
KCF: read, write or open error, block=0x230e71 online=1
        file=105 '+DATA/ORCL/F7D939D6DBE06C71E053C30114AC1F10/DATAFILE/xifenfei_64.dbf'
        error=15078 txt: ''
2025-05-04T07:03:19.973289+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_dbw2_18466.trc:
2025-05-04T07:03:19.978514+08:00
KCF: read, write or open error, block=0x1f6e91 online=1
        file=86 '+DATA/ORCL/F7D939D6DBE06C71E053C30114AC1F10/DATAFILE/xifenfei_52.dbf'
        error=15078 txt: ''
2025-05-04T07:03:19.991060+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_dbwd_18511.trc:
2025-05-04T07:03:19.995762+08:00
KCF: read, write or open error, block=0x7f8 online=1
        file=15 '+DATA/ORCL/F7D939D6DBE06C71E053C30114AC1F10/DATAFILE/undotbs01.dbf'
        error=15078 txt: ''
2025-05-04T07:03:20.006862+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_dbwa_18498.trc:
2025-05-04T07:03:20.020739+08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_imr0_18937.trc:

这个客户比较幸运,处理该磁盘之后,没有往对应的lv中写入太多数据,导致覆盖部分很少

[root@rac01 rules.d]# df -h
文件系统               容量  已用  可用 已用% 挂载点
/dev/mapper/nlas-root  800G  272G  528G   34% /
devtmpfs               284G     0  284G    0% /dev
tmpfs                  284G  637M  283G    1% /dev/shm
tmpfs                  284G  4.0G  280G    2% /run
tmpfs                  284G     0  284G    0% /sys/fs/cgroup
/dev/mapper/nlas-home  200G   64M  200G    1% /home
/dev/sda1              197M  158M   40M   80% /boot
tmpfs                   57G   40K   57G    1% /run/user/0
tmpfs                   57G   48K   57G    1% /run/user/1000
[root@rac01 rules.d]# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  nlas lvm2 a--  564.00g    0 
  /dev/sdb1  nlas lvm2 a--   <2.00t 1.51t
[root@rac01 rules.d]# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  nlas   2   3   0 wz--n- 2.55t 1.51t
[root@rac01 rules.d]# lvs
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home nlas -wi-ao---- 200.00g                                                    
  root nlas -wi-ao---- 800.00g                                                    
  swap nlas -wi-ao----  64.00g

通过底层对磁盘进行分析,发现备份的磁盘头均以损坏,通过深入分析确认f1b1在sdb磁盘的第10个au上,通过相关信息,使用dul工具加载磁盘组,并分析元数据信息,发现恢复数据需要的元数据都可以正常加载

直接使用dul抽取数据到文件系统,然后open数据库成功

然后通过rman 检测坏块(3T多的库只有不到5000个坏块,相对来说效果非常好),对于坏块对象进行处理,完美完成本次恢复工作.对于这次能够有这样好的恢复效果有几个因素:
1)asm disk 加入到vg,并分配给lv之后,立刻停止写入操作,避免了因为写入数据而覆盖asm 磁盘的带来的风险
2)由于是19c库,默认au为4M,使得数据库文件数据相对比较靠后,覆盖几率小了一点
3)由于文件系统是xfs,相对覆盖比ext4会少很多
4)是云环境的ssd磁盘,没有触发trim功能
以前类似asm disk异常恢复的相关case汇总:
asm磁盘加入vg恢复
asm磁盘dd破坏恢复
asm磁盘分区丢失恢复
pvid=yes导致asm无法mount
win asm disk header 异常恢复
又一例asm disk 加入vg故障
pvcreate asm disk导致asm磁盘组异常恢复
asm disk被加入到另外一个磁盘组故障恢复
再一例asm disk被误加入vg并且扩容lv恢复
再一起asm disk被格式化成ext3文件系统故障恢复
一次完美的asm disk被格式化ntfs恢复
asm disk误设置pvid导致asm diskgroup无法mount恢复
asm disk被分区,格式化为ext4恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例

CHECKDB 发现了 N 个分配错误和 M 个一致性错误

联系：手机/微信(+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' 有 905 行，这些行位于 13 页中。
'sysindexes' 的 DBCC 结果。
对象 'sysindexes' 有 635 行，这些行位于 26 页中。
CHECKDB 发现了 0 个分配错误和 2 个一致性错误（在表 'sysindexes' 中，该表的对象 ID 为 2）。
'syscolumns' 的 DBCC 结果。
………………
对象 'yj_sqd_taoc' 有 0 行，这些行位于 0 页中。
'h_zdytj' 的 DBCC 结果。
对象 'h_zdytj' 有 0 行，这些行位于 0 页中。
CHECKDB 发现了 1 个分配错误和 4 个一致性错误（在数据库 'myhis' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

主要为:
1. 扩展盘区 (1:5144)（属于数据库 ID 8）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
2. 表错误: 对象 ID 2。text、ntext 或 image 节点（位于页 (1:3813)，槽 0，文本 ID 800849920）与该节点位于页 (1:489)，槽 4 处的引用不匹配。
3. CHECKDB 发现了 0 个分配错误和 2 个一致性错误（在表 ‘sysindexes’ 中，该表的对象 ID 为 2）

这个库是sql server 2000的版本,处理起来相对麻烦一些(由于该版本太老,很多工具软件对sql 2000版本支持不太好),后面通过sql恢复工具和sql控制台中的所有任务–>数据导入功能,对于个表异常表进行单独迁移完成本次任务

再次使用dbcc进行检测,一切正常,客户业务也恢复正常

达梦数据库dm.ctl文件异常恢复

联系：手机/微信(+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_objects;
影响行数 1094

已用时间: 13.395(毫秒). 执行号:1306.
SQL> insert into t_xff select * from dba_objects;
影响行数 1094

已用时间: 13.867(毫秒). 执行号:1307.
SQL> insert into t_xff select * from dba_objects;
影响行数 1094

已用时间: 13.838(毫秒). 执行号:1308.
SQL> insert into t_xff select * from t_xff;
影响行数 5470

已用时间: 5.677(毫秒). 执行号:1309.
SQL> select count(1) from t_xff;

行号     COUNT(1)            
---------- --------------------
1          10940

已用时间: 1.949(毫秒). 执行号:1310.
SQL> insert into t_xff select * from t_xff;
影响行数 10940

已用时间: 35.035(毫秒). 执行号:1311.
SQL> insert into t_xff select * from t_xff;
影响行数 21880

已用时间: 38.489(毫秒). 执行号:1312.
SQL> insert into t_xff select * from t_xff;
影响行数 43760

已用时间: 86.242(毫秒). 执行号:1313.
SQL> insert into t_xff select * from t_xff;
影响行数 87520

已用时间: 272.804(毫秒). 执行号:1314.
SQL> insert into t_xff select * from t_xff;
影响行数 175040

已用时间: 529.733(毫秒). 执行号:1315.
SQL> insert into t_xff select * from t_xff;
影响行数 350080

已用时间: 00:00:01.090. 执行号:1316.
SQL> select count(1) from t_xff;

行号     COUNT(1)            
---------- --------------------
1          700160

已用时间: 0.352(毫秒). 执行号:1317.

kill达梦进程并删除dm.ctl文件

[dmdba@localhost ctl_bak]$ ps -ef|grep dmserver
dmdba     2216  1963  1 21:25 pts/1    00:00:10 dmserver /home/dmdba/dmdbms/data/htdb/dm.ini
dmdba     2401  1963  0 21:40 pts/1    00:00:00 grep --color=auto dmserver
[dmdba@localhost ctl_bak]$ kill -9 2216
[dmdba@localhost ctl_bak]$ 
[1]+  已杀死               nohup dmserver /home/dmdba/dmdbms/data/htdb/dm.ini(工作目录：~/dmdbms/log)
(当前工作目录：~/dmdbms/data/htdb/ctl_bak)
[dmdba@localhost htdb]$ 
[dmdba@localhost htdb]$ rm -rf dm.ctl 
[dmdba@localhost htdb]$

启动达梦数据库报错

[dmdba@localhost htdb]$ dmserver /home/dmdba/dmdbms/data/htdb/dm.ini
file dm.key not found, use default license!
Read ini error, name:CTL_PATH, value:/home/dmdba/dmdbms/data/htdb/dm.ctl
dmserver startup failed, code = -803 [Invalid ini config value]
nsvr_ini_file_read failed, 1
[dmdba@localhost htdb]$

使用备份ctl文件直接启动库
备份文件在dm.ini中的CTL_BAK_PATH参数控制备份控制文件路径（一般在达梦数据库目录的ctl_bak中）,CTL_BAK_NUM控制备份文件数量

[dmdba@localhost htdb]$ cd ctl_bak/
[dmdba@localhost ctl_bak]$ ls -lhtra
总用量 96K
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  26 21:25 dm_20250426212532_981690.ctl
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  26 21:36 dm_20250426213636_596321.ctl
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  26 21:36 dm_20250426213636_599137.ctl
-rw-r--r--. 1 dmdba dmsys 6.0K 4月  26 21:36 dm_20250426213636_604672.ctl
-rw-r--r--. 1 dmdba dmsys 6.0K 4月  26 21:36 dm_20250426213636_607133.ctl
-rw-r--r--. 1 dmdba dmsys 6.0K 4月  26 21:36 dm_20250426213636_610925.ctl
drwxr-xr-x. 2 dmdba dmsys 4.0K 4月  26 21:36 .
-rw-r--r--. 1 dmdba dmsys 6.0K 4月  26 21:36 dm_20250426213636_630282.ctl
drwxr-xr-x. 6 dmdba dmsys 4.0K 4月  26 21:41 ..
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  27 2025 dm_20250427034852_563000.ctl
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  27 2025 dm_20250427034905_993889.ctl
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  27 2025 dm_20250427035646_961400.ctl
-rw-r--r--. 1 dmdba dmsys 5.5K 4月  27 2025 dm_20250427041036_574397.ctl
[dmdba@localhost ctl_bak]$ 
[dmdba@localhost ctl_bak]$ cp dm_20250427041036_574397.ctl ../dm.ctl
[dmdba@localhost ctl_bak]$ dmserver /home/dmdba/dmdbms/data/htdb/dm.ini
file dm.key not found, use default license!
version info: develop
csek2_vm_t = 1440
nsql_vm_t = 328
prjt2_vm_t = 176
ltid_vm_t = 216
nins2_vm_t = 1120
nset2_vm_t = 272
ndlck_vm_t = 192
ndel2_vm_t = 768
slct2_vm_t = 352
nli2_vm_t = 200
aagr2_vm_t = 304
pscn_vm_t = 376
dist_vm_t = 960
DM Database Server 64 V8 03134284336-20250117-257733-20132 startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 0, oguid = 0
License will expire on 2026-01-17
begin redo pwr log collect, last ckpt lsn: 46175 ...
redo pwr log collect finished
main rfil[/home/dmdba/dmdbms/data/htdb/htdb01.log]'s grp collect 0 valid pwr record, discard 1135 invalid pwr record
EP[0]'s cur_lsn[61627], file_lsn[61627]
begin redo log recover, last ckpt lsn: 46175 ...
redo log recover finished 0
ndct db load finished, code:0
ndct second level fill fast pool finished
ndct third level fill fast pool finished
ndct second level fill fast pool finished
ndct third level fill fast pool finished
ndct fill fast pool finished
pseg_set_gtv_trxid_low next_trxid in mem:[26039]
pseg_collect_mgr_items, total collect 0 active_trxs, 0 cmt_trxs, 0 pre_cmt_trxs, 0 to_release_trxs,
    0 active_pages, 0 cmt_pages, 0 pre_cmt_pages, 0 to_release_pages, 0 mgr pages, 0 mgr recs!
next_trxid in mem:[28041]
next_trxid = 30043.
pseg recv finished
nsvr_startup end.
uthr_pipe_create, create pipe[read:10, write:11]
uthr_pipe_create, create pipe[read:12, write:13]
uthr_pipe_create, create pipe[read:14, write:15]
uthr_pipe_create, create pipe[read:16, write:17]
uthr_pipe_create, create pipe[read:18, write:19]
uthr_pipe_create, create pipe[read:20, write:21]
uthr_pipe_create, create pipe[read:22, write:23]
uthr_pipe_create, create pipe[read:24, write:25]
uthr_pipe_create, create pipe[read:26, write:27]
uthr_pipe_create, create pipe[read:28, write:29]
uthr_pipe_create, create pipe[read:30, write:31]
uthr_pipe_create, create pipe[read:32, write:33]
uthr_pipe_create, create pipe[read:34, write:35]
uthr_pipe_create, create pipe[read:36, write:37]
uthr_pipe_create, create pipe[read:38, write:39]
uthr_pipe_create, create pipe[read:40, write:41]
aud sys init success.
aud rt sys init success.
systables desc init success.
ndct_db_load_info finished, code:0.
nsvr_process_before_open begin.
nsvr_process_before_open success.
SYSTEM IS READY.
purg2_crash_cmt_trx end, total 0 trx, 0 pages purged

启动数据库成功,查询相关信息

SQL> select TABLESPACE_NAME from dba_tablespaces;

行号     TABLESPACE_NAME
---------- ---------------
1          SYSTEM
2          ROLL
3          TEMP
4          MAIN
5          TBS_XFF
6          MAIN

6 rows got

已用时间: 4.257(毫秒). 执行号:602.
SQL> select count(*) from t_xff;

行号     COUNT(*)            
---------- --------------------
1          700160

已用时间: 2.893(毫秒). 执行号:603.

使用重建ctl文件方式恢复
1. 使用dmctlcvt把备份ctl转换为txt文件

[dmdba@localhost htdb]$ dmctlcvt  help
DMCTLCVT V8
version: 03134284336-20250117-257733-20132

格式: ./dmctlcvt KEYWORD=value
注意: 控制文件名称必须指定为dm.ctl、dmmpp.ctl、dss.ctl

关键字              说明
--------------------------------------------------------------------------------
TYPE                1 转换控制文件为文本文件（源文件路径中控制文件名称必须是dm.ctl或dmmpp.ctl或dss.ctl）
                    2 转换文本文件为控制文件（目标文件路径中控制文件名称必须是dm.ctl或dmmpp.ctl或dss.ctl）
SRC                 源文件路径
DEST                目标文件路径
DCR_INI             dmdcr.ini文件路径
HELP                打印帮助信息

示例：
./dmctlcvt TYPE=1 SRC=/opt/dmdbms/data/dameng/dm.ctl DEST=/opt/dmdbms/data/dameng/dmctl.txt
./dmctlcvt TYPE=2 SRC=/opt/dmdbms/data/dameng/dmctl.txt DEST=/opt/dmdbms/data/dameng/dm.ctl
[dmdba@localhost htdb]$ dmctlcvt TYPE=1 SRC=dm_20250426213636_630282.ctl DEST=/tmp/ctl.txt
DMCTLCVT V8
convert ctl to txt success!

2. 查看ctl.txt文件中是的表空间和数据文件信息是否正确,如果确实可以参考达梦日志中相关创建信息参考其他表空间信息进行完善,并注意修改next_ts_id=6值
2025-04-26 21:36:36.600 [INFO] database P0000002216 T0000000000000002387 ifun_add_file_low initialize file[0] of ts[5], file_path[/home/dmdba/dmdbms/data/htdb/tbs_xff01.dbf]!

3. 利用该txt文件重建ctl文件

[dmdba@localhost ctl_bak]$ dmctlcvt TYPE=2 SRC=/tmp/ctl.txt DEST=/home/dmdba/dmdbms/data/htdb/dm.ctl
DMCTLCVT V8
convert txt to ctl success!

4. 启动数据库并进行验证

[dmdba@localhost ~]$ dmserver path=/home/dmdba/dmdbms/data/htdb/dm.ini
file dm.key not found, use default license!
version info: develop
csek2_vm_t = 1440
nsql_vm_t = 328
prjt2_vm_t = 176
ltid_vm_t = 216
nins2_vm_t = 1120
nset2_vm_t = 272
…………
aud sys init success.
aud rt sys init success.
systables desc init success.
ndct_db_load_info finished, code:0.
nsvr_process_before_open begin.
nsvr_process_before_open success.
SYSTEM IS READY.
purg2_crash_cmt_trx end, total 0 trx, 0 pages purged

[dmdba@localhost ctl_bak]$ disql
disql V8
用户名:sysdba
密码:
[-2501]:用户名或密码错误.
用户名:sysdba
密码:

服务器[LOCALHOST:5236]:处于普通打开状态
登录使用时间 : 4.624(ms)
SQL> select tablespace_name from dba_tablespaces;

行号     TABLESPACE_NAME
---------- ---------------
1          SYSTEM
2          ROLL
3          TEMP
4          MAIN
5          TBS_XFF
6          MAIN

6 rows got

已用时间: 9.326(毫秒). 执行号:701.
SQL> select count(1) from t_xff;

行号     COUNT(1)            
---------- --------------------
1          700160

已用时间: 2.916(毫秒). 执行号:702.
SQL>

基于此,对于dm的control损坏/丢失一般可以通过以上两种方法实现恢复,这里可以明显感觉到dm的control相对于oracle的control文件中少了相关的一致性检测

Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障

联系：手机/微信(+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 139863), scn 0
2025-04-22T16:59:53.094081+08:00
Started redo scan
2025-04-22T16:59:53.203464+08:00
Completed redo scan
 read 15533 KB redo, 1140 data blocks need recovery
2025-04-22T16:59:53.515972+08:00
Hex dump of (file 3,block 82642) in trace file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p001_6612.trc

Corrupt block relative dba: 0x00c142d2 (file 3,block 82642)
Fractured block found during crash/instance recovery
Data in bad block:
 type: 6 format: 2 rdba: 0x00c142d2
 last change scn: 0x0000.0001.7a0219e2 seq: 0x1 flg: 0x06
 spare3: 0x0
 consistency value in tail: 0x0fcb0601
 check value in block header: 0x82eb
 computed block checksum: 0x172a

2025-04-22T16:59:53.563004+08:00
Reading datafile 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF' for corrupt data at rdba: 0x00c142d2 (file 3,block 82642)
Reread (file 3,block 82642) found same corrupt data (no logical check)
2025-04-22T16:59:54.578467+08:00
Hex dump of (file 3,block 207498) in trace file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p000_6064.trc
2025-04-22T16:59:54.578467+08:00

Corrupt block relative dba: 0x00c32a8a (file 3,block 207498)
Fractured block found during crash/instance recovery
Data in bad block:
 type: 6 format: 2 rdba: 0x00c32a8a
 last change scn: 0x0000.0001.731ec74f seq: 0x2 flg: 0x06
 spare3: 0x0
 consistency value in tail: 0x10520601
 check value in block header: 0x61c3
 computed block checksum: 0xe27a

Reading datafile 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF' for corrupt data at rdba: 0x00c32a8a (file 3,block 207498)
Reread (file 3,block 207498) found same corrupt data (no logical check)
Hex dump of (file 4, block 3959) in trace file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p000_6064.trc

Corrupt block relative dba: 0x01000f77 (file 4, block 3959)
Fractured block found during crash/instance recovery
Data in bad block:
 type: 2 format: 2 rdba: 0x01000f77
 last change scn: 0x0000.0001.79fa3621 seq: 0x4 flg: 0x04
 spare3: 0x0
 consistency value in tail: 0xcf6c0201
 check value in block header: 0x99d2
 computed block checksum: 0x79e0

Reading datafile 'D:\APP\ADMINISTRATOR\ORADATA\HIS\UNDOTBS01.DBF' for corrupt data at rdba: 0x01000f77 (file 4,block 3959)
Reread (file 4, block 3959) found same corrupt data (no logical check)
2025-04-22T16:59:54.640991+08:00
Started redo application at
 Thread 1: logseq 11031, block 139863, offset 0
2025-04-22T16:59:54.672246+08:00
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11031 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO03.LOG
2025-04-22T16:59:54.703494+08:00
Hex dump of (file 3,block 89738) in trace file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc

Corrupt block relative dba: 0x00c15e8a (file 3,block 89738)
Fractured block found during crash/instance recovery
Data in bad block:
 type: 6 format: 2 rdba: 0x00c15e8a
 last change scn: 0x0000.0001.7a09108a seq: 0x2 flg: 0x06
 spare3: 0x0
 consistency value in tail: 0x278e0602
 check value in block header: 0xd721
 computed block checksum: 0x2705

Reading datafile 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF' for corrupt data at rdba: 0x00c15e8a (file 3,block 89738)
Reread (file 3,block 89738) found same corrupt data (no logical check)
2025-04-22T16:59:54.734756+08:00
Hex dump of (file 3,block 9504) in trace file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p005_3660.trc

Reading datafile 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF' for corrupt data at rdba: 0x00c02520 (file 3,block 9504)
Reread (file 3,block 9504) found same corrupt data (logically corrupt)
*****************************************************************
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.
*****************************************************************
2025-04-22T16:59:54.750364+08:00
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xC] [PC:0x7FF64221F2F8, kdxlin()+4824]
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p008_3964.trc  (incident=521460):
ORA-07445: 出现异常错误: 核心转储 [kdxlin()+4824][ACCESS_VIOLATION][ADDR:0xC][PC:0x7FF64221F2F8][UNABLE_TO_READ][]
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_521460\his_p008_3964_i521460.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-04-22T16:59:55.156605+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p005_3660.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00312: 联机日志 1 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
2025-04-22T16:59:55.828516+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p00a_3428.trc  (incident=521476):
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_521476\his_p00a_3428_i521476.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-04-22T16:59:56.844113+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc  (incident=521444):
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_521444\his_p006_5236_i521444.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-04-22T16:59:59.062944+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p005_3660.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00334: 归档日志: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
2025-04-22T16:59:59.156645+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p00a_3428.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00312: 联机日志 1 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_521477\his_p00a_3428_i521477.trc
2025-04-22T17:00:04.250414+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00334: 归档日志: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
2025-04-22T17:00:04.344200+08:00
Slave encountered ORA-10388 exception during crash recovery
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc  (incident=521445):
ORA-01578: ORACLE 数据块损坏 (文件号 3, 块号 299732)
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10564: tablespace SYSAUX
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 11351
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_521445\his_p006_5236_i521445.trc
2025-04-22T17:00:05.312967+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p00a_3428.trc:
ORA-01578: ORACLE 数据块损坏 (文件号 3, 块号 216445)
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10564: tablespace SYSAUX
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 11171
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
2025-04-22T17:00:05.359805+08:00
Slave encountered ORA-10388 exception during crash recovery
2025-04-22T17:00:06.172286+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc:
ORA-01578: ORACLE 数据块损坏 (文件号 3, 块号 299732)
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10564: tablespace SYSAUX
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 11351
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
2025-04-22T17:00:06.172286+08:00
Slave encountered ORA-1578 exception during crash recovery
Slave exiting with ORA-1578 exception
2025-04-22T17:00:06.172286+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_p006_5236.trc:
ORA-01578: ORACLE 数据块损坏 (文件号 3, 块号 299732)
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10564: tablespace SYSAUX
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 11351
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
ORA-1578 signalled during: alter database open...

这里面主要报错有几大类:
1.在需要实例恢复的block中有坏块,而且主要集中在3号文件(sysaux)上
2. ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
3. ORA-600 ktbair2: illegal inheritance错误
对于这些问题的本质都是数据库无法正常实例恢复,尝试按照数据文件级别进行恢复操作,结果只有datafile 3 不成功

2025-04-22T20:11:36.724880+08:00
ALTER DATABASE RECOVER  datafile 3  
2025-04-22T20:11:36.740523+08:00
Media Recovery Start
2025-04-22T20:11:36.771771+08:00
Serial Media Recovery started
2025-04-22T20:11:36.896781+08:00
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11031 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO03.LOG
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xC] [PC:0x7FF64221F2F8, kdxlin()+4824]
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_2512.trc  (incident=721216):
ORA-07445: ??????: ???? [kdxlin()+4824] [ACCESS_VIOLATION] [ADDR:0xC] [PC:0x7FF64221F2F8] [UNABLE_TO_READ] []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_721216\his_ora_2512_i721216.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-04-22T20:12:56.585813+08:00
ALTER DATABASE RECOVER  datafile 3  
2025-04-22T20:12:56.601434+08:00
Media Recovery Start
2025-04-22T20:12:56.601434+08:00
Serial Media Recovery started
2025-04-22T20:12:57.351435+08:00
Recovery of Online Redo Log: Thread 1 Group 3 Seq 11031 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO03.LOG
2025-04-22T20:12:58.492071+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_5332.trc  (incident=721217):
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\his\his\incident\incdir_721217\his_ora_5332_i721217.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-04-22T20:13:00.710878+08:00
*****************************************************************
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.
*****************************************************************
2025-04-22T20:13:01.398399+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_5332.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00312: 联机日志 1 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
2025-04-22T20:13:03.820304+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_mz00_2200.trc:
ORA-01110: 数据文件 3: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\SYSAUX01.DBF'
2025-04-22T20:13:06.070340+08:00
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\his\his\trace\his_ora_5332.trc:
ORA-00742: 日志读取在线程 1 序列 11029 块 51218 中检测到写入丢失情况
ORA-00334: 归档日志: 'D:\APP\ADMINISTRATOR\ORADATA\HIS\REDO01.LOG'
ORA-00600: 内部错误代码, 参数: [ktbair2: illegal  inheritance], [], [], [], [], [], [], [], [], [], [], []
2025-04-22T20:13:06.085990+08:00
Media Recovery failed with error 10562
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 3  ...

对于这样的故障,前段时间通过Oracle Recovery Tools工具处理过类似异常:Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障

然后尝试recover datafile 3,并打开数据库成功

至此数据库open成功,由于该库有不少坏块(包括system的一些字典),后续使用逻辑方式迁移数据到新库中(其中由于C_OBJ#簇中有坏块,导致迁移过程中大量index丢失,通过一些方法使用obj$,inde$等基表人工生成index.sql对于丢失的index进行弥补),最终客户业务正常运行

可能是 tempdb 空间用尽或某个系统表不一致故障处理

联系：手机/微信(+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 data page. Run DBCC CHECKTABLE.
04/22/2025 10:50:26,spid58,未知,错误: 7105，严重性: 22，状态: 9。
对于这种情况,尝试重建LDF,和REPAIR_ALLOW_DATA_LOSS方案都失败,最终确认通过逻辑迁移的方式完成恢复,然后再次尝试dbcc一切正常,完成本次恢复任务

11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错

联系：手机/微信(+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
--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for 64-bit Windows: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production

SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area 1.9174E+10 bytes
Fixed Size                  2289320 bytes
Variable Size            3355443544 bytes
Database Buffers         1.5771E+10 bytes
Redo Buffers               45932544 bytes
数据库装载完毕。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4653],
[50575], [50922], [], [], [], [], [], [], []

alert日志报错信息

Tue Apr 22 05:08:12 2025
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 3880792636
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Tue Apr 22 05:08:17 2025
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 15 processes
Started redo scan
Completed redo scan
 read 2451 KB redo, 1442 data blocks need recovery
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\ydhl\ydhl\trace\ydhl_ora_2164.trc  (incident=240429):
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4653], [50575], [50922],[],[],[],[],[],[],[]
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\ydhl\ydhl\incident\incdir_240429\ydhl_ora_2164_i240429.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Aborting crash recovery due to error 600
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\ydhl\ydhl\trace\ydhl_ora_2164.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4653], [50575], [50922],[],[],[],[],[],[],[]
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\ydhl\ydhl\trace\ydhl_ora_2164.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4653], [50575], [50922],[],[],[],[],[],[],[]
ORA-600 signalled during: ALTER DATABASE OPEN...

这个故障在一般在11.2.0.1版本中最为常见,处理起来比较简单,一般数据也会0丢失
12c启动报kcratr_nab_less_than_odr
又一例ORA-600 kcratr_nab_less_than_odr
ORA-600 kcratr_nab_less_than_odr故障解决
 差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
这里处理比较简单,重建控制文件就完成了恢复工作

[MY-013183] [InnoDB] Assertion failure故障处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：[MY-013183] [InnoDB] Assertion failure故障处理

在一个存储故障的环境中,通过做硬件恢复,恢复出来一个mysql数据库,但是直接启动报错

[mysql@localhost bin]$ ./mysqld
2025-04-17T03:34:50.352302Z 0 [System] [MY-010116] [Server] /data/mysql/mysql/bin/mysqld (mysqld 8.0.34) starting as process 58239
2025-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 1728577790947 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031090Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031118Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=131] log sequence number 1728577833027 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031124Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031138Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=3621] log sequence number 1728577635513 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031142Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031193Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=167] log sequence number 1728577760219 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042480Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_001′ Page [page id: space=4294967279, page number=184] log sequence number 1728577792529 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042486Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.042359Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_001′ Page [page id: space=4294967279, page number=1975] log sequence number 1728577800027 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042681Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.059937Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-04-17T03:34:51.159245Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘xff/t_xifenfei’ Page [page id: space=153, page number=4] log sequence number 1728577926919 is in the future! Current system log sequence number 1728577498088.
2025-04-17T03:34:51.159280Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.163187Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: fut0lst.ic:81:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA thread 140491735693056
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2025-04-17T03:34:51Z UTC – mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=f183cd3ecfc35a4aa5da997063d5e8c97ffca986
Thread pointer: 0x7fc6bc000b60
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 7fc6c7ffeaf0 thread_stack 0×100000
/data/mysql/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0×41) [0x21323b1]
/data/mysql/mysql/bin/mysqld(print_fatal_signal(int)+0x2a2) [0xfef932]
/data/mysql/mysql/bin/mysqld(my_server_abort()+0×75) [0xfefb75]
/data/mysql/mysql/bin/mysqld(my_abort()+0xe) [0x212c24e]
/data/mysql/mysql/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0×309) [0x237cde9]
/data/mysql/mysql/bin/mysqld() [0x2349cf0]
/data/mysql/mysql/bin/mysqld() [0x234aa54]
/data/mysql/mysql/bin/mysqld(trx_purge(unsigned long, unsigned long, bool)+0xeb) [0x234d56b]
/data/mysql/mysql/bin/mysqld(srv_purge_coordinator_thread()+0×450) [0x23224b0]
/data/mysql/mysql/bin/mysqld(void Detached_thread::operator()<void (*)()>(void (*&&)())+0xca) [0x224bcaa]
/lib64/libstdc++.so.6(+0xc2ba3) [0x7fc731c11ba3]
/lib64/libpthread.so.0(+0x814a) [0x7fc732fe614a]
/lib64/libc.so.6(clone+0×43) [0x7fc7312eef23]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

这个报错主要含义是：

多个表空间（特别是innodb_undo_*）的日志序列号(LSN)比当前系统LSN要大，这表明可能存在数据损坏或不一致
系统最终因为断言失败而崩溃

对于这样的情况,可以通过mysql强制拉库的方式启动mysql,如果可以启动成功直接使用mysqldump导出数据,然后重建新库,如果无法启动mysql成功,那就考虑通过对单个的ibd基表进行discard+import方式进行恢复参考:MySQL 8.0版本ibd文件恢复，如果这个方法不能成功考虑直接通过工具读取ibd文件参考:frm和ibd文件数据库恢复