MongoDB 离线提取工具—mongoext

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:MongoDB 离线提取工具—mongoext

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在某些情况下,由于断电、硬件故障、软件bug等导致mongodb数据库无法正常启动,甚至使用repair依然无法启动,对于这样的情况.我专门开发了mongodb离线提取工具mongoext,在离线情况下直接提取mongodb的数据
整体命令支持

G:\mongodb\mongoext>mongoext.exe -h
usage: mongoext [-h] {scan,recover,info} ...

脱机 MongoDB 数据文件提取工具

positional arguments:
  {scan,recover,info}
    scan               扫描 dbPath 并导出
    recover            恢复孤立的单个 collection 文件(无 catalog)
    info               打印 dbPath 元信息

options:
  -h, --help           show this help message and exit

scan 是基于mongodb字典直接提取数据
recover是直接恢复单个集合文件中数据
info是获取字典信息以及集合对应关系

mongoext scan 命令介绍

G:\mongodb\mongoext>mongoext.exe scan -h
usage: mongoext scan [-h] [--db DB] [--collection COLLECTION] [--include-system] [--out OUT]
                     [--format {jsonl,sql,bson,mongo}] [--uri URI] [--batch BATCH] [--no-indexes] [--ttl-indexes]
                     [--keep-existing] [--sql-dialect {postgres,mysql}] [--dedup] [--no-progress] [--dry-run]
                     [--allocation-size ALLOCATION_SIZE]
                     dbpath

positional arguments:
  dbpath                dbPath 路径

options:
  -h, --help            show this help message and exit
  --db DB               只导出指定数据库
  --collection COLLECTION
                        只导出指定集合
  --include-system      连 admin/config/local 也一起导入(默认跳过,会污染目标实例)
  --out OUT             输出目录(--format mongo 时不需要)
  --format {jsonl,sql,bson,mongo}
                        输出格式;mongo = 直接写入运行中的 mongod(BSON 类型保真)
  --uri URI             --format mongo 的目标连接串
  --batch BATCH         --format mongo 每批 insert_many 的条数
  --no-indexes          --format mongo 导入后不重建索引
  --ttl-indexes         --format mongo 连 TTL 索引也重建(默认不建:建了会立刻按过期时间删数据)
  --keep-existing       --format mongo 不 drop 目标集合,追加写入
  --sql-dialect {postgres,mysql}
                        SQL 方言
  --dedup               按 _id 去重(多版本 leaf page 残留时开启)
  --no-progress         关闭 tqdm 进度条
  --dry-run             只统计不写盘,用于核对提取完整性与文档计数
  --allocation-size ALLOCATION_SIZE
                        手工指定块对齐粒度(默认从 turtle / 元数据读,读不到才穷举探测)

mongoext-scan


mongoext recover命令介绍

G:\mongodb\mongoext>mongoext.exe recover -h
usage: mongoext recover [-h] [--orphans DBPATH] [--db DB] [--collection COLLECTION] [--meta-dir META_DIR] [--out OUT]
                        [--format {jsonl,sql,bson,mongo}] [--uri URI] [--batch BATCH] [--no-indexes] [--ttl-indexes]
                        [--keep-existing] [--sql-dialect {postgres,mysql}] [--dedup] [--no-progress] [--dry-run]
                        [--allocation-size ALLOCATION_SIZE]
                        [wt_file]

positional arguments:
  wt_file               孤立的 collection-*.wt 文件

options:
  -h, --help            show this help message and exit
  --orphans DBPATH      批量恢复该 dbPath 里 catalog 未记录的 collection 文件
  --db DB               手工指定库名(与 --collection 一起用)
  --collection COLLECTION
                        手工指定集合名(与 --db 一起用)
  --meta-dir META_DIR   伴生文件(turtle / _mdb_catalog.wt / WiredTiger.wt)所在目录,用来反查 namespace;
                        文件已拷走但原 dbPath 还在时指过去即可
  --out OUT             输出目录(--format mongo 时不需要)
  --format {jsonl,sql,bson,mongo}
                        输出格式;mongo = 直接写入运行中的 mongod(BSON 类型保真)
  --uri URI             --format mongo 的目标连接串
  --batch BATCH         --format mongo 每批 insert_many 的条数
  --no-indexes          --format mongo 导入后不重建索引
  --ttl-indexes         --format mongo 连 TTL 索引也重建(默认不建:建了会立刻按过期时间删数据)
  --keep-existing       --format mongo 不 drop 目标集合,追加写入
  --sql-dialect {postgres,mysql}
                        SQL 方言
  --dedup               按 _id 去重(多版本 leaf page 残留时开启)
  --no-progress         关闭 tqdm 进度条
  --dry-run             只统计不写盘,用于核对提取完整性与文档计数
  --allocation-size ALLOCATION_SIZE
                        手工指定块对齐粒度(默认从 turtle / 元数据读,读不到才穷举探测)

mongoext-recover


常使用命令说明

# 看库结构
mongoext.exe info DBPATH

# 只统计不写盘
mongoext.exe scan DBPATH --out ./out --dry-run --dedup

# 全库导 JSON Lines(人看 / 给别的程序吃)
mongoext.exe scan DBPATH --out ./out --format jsonl --dedup

# 全库导 BSON(给 mongorestore 用)
mongoext.exe scan DBPATH --out ./out --format bson --dedup

# 全库导 SQL
mongoext.exe scan DBPATH --out ./out --format sql --sql-dialect mysql --dedup

# 保真导入运行中的 MongoDB(推荐路径)
mongoext.exe scan DBPATH --format mongo --dedup

# 只导一个集合
mongoext.exe scan DBPATH --format mongo --db mydb --collection users --dedup

# 导到远程实例
mongoext.exe scan DBPATH --format mongo \
    --uri "mongodb://user:pass@host:27017/?authSource=admin" --dedup

# 恢复孤立的单个 collection 文件(无 dbPath / 无 catalog)
mongoext.exe recover FILE.wt --dry-run --dedup          # 先看探测结论
mongoext.exe recover FILE.wt --db mydb --collection users --format mongo --dedup
mongoext.exe recover FILE.wt --meta-dir /原/dbPath --format mongo --dedup

# 批量恢复一个 dbPath 里的孤儿文件
mongoext.exe recover --orphans DBPATH --out ./out --dedup

.bres勒索病毒加密数据库dmp文件可恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.bres勒索病毒加密数据库dmp文件可恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

近期.bres勒索病毒较多,加密文件名称一般为:原始文件名.id.bres
bres_jm


勒索信息为:id.readme文件
bres_readme

一般是勒索5000或者7500美元.通过我们对加密的oracle数据库文件和dmp的逻辑备份分析,确认该病毒对于两种类型的文件破坏比例不一样
一、对于bres勒索病毒数据库层面恢复探讨
1. 对于dbf/ora类型文件破坏比例非常大,达到1/3左右,而且还是间隔加密,对于这种情况,基于数据库文件基本上没有太大恢复价值,但是我们也遇到一些客户,由于某些原因导致这类病毒加密文件没有全部完成(数据文件被加密中途终止),这样的情况下,可以恢复没有被破坏的block中数据.
bres_dbf

2.对于exp/expdp备份出来的dmp文件,该病毒一般只是加密前面30M的block,后续其他block全部是完整的,可以恢复出来后续数据,整体数据丢失较少,如果有历史完整的备份,可以实现较为完整的恢复效果
bres2

二、病毒入侵渠道与内网扩散逻辑
.bres病毒主要有四类入侵入口,其中内网共享权限漏洞是最高发渠道。
第一,共享存储与NAS弱口令入侵。工贸企业、工程公司大量使用NAS存放图纸、合同,为方便异地办公,直接开放外网访问,账号密码长期不修改。黑客会批量扫描公网设备,尝试默认密码登录,拿到权限后植入后门程序,长期潜伏在内网。这也是.bres最标志性的入侵方式,区别于其他病毒以钓鱼邮件为主要入口。
第二,钓鱼邮件投递。伪装成供应商对账函、项目验收单、物流通知单,压缩包内放置恶意程序。员工解压运行之后,木马悄悄植入电脑,建立持久后门,为后续内网横向扩散铺路。
第三,RDP远程桌面爆破。部分小微企业为远程管理服务器,3389端口对外暴露,使用简单密码。黑客利用工具批量爆破账号密码,登陆服务器投放病毒载荷。
第四,根据我们近期恢复的一些case,大量是同一个软件厂商的软件在不同客户现场几乎同一时间被勒索加密,怀疑可能是由于应用某组件有漏洞被黑客利用进行攻击,建议加强应用版本管理,及时更新应用修复漏洞。

ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户由于断电,导致一个19c数据库无法正常启动,接手时候报错为:ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch

2026-09-15T06:36:24.908317-07:00
ALTER DATABASE OPEN RESETLOGS
2026-09-15T06:36:24.912251-07:00
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 22297188690 time 
NET  (PID:36760): Unable to create archive log file '/u19/dbs/arch1_1_1243990641.dbf'
2026-09-15T06:36:24.919696-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_36760.trc:
ORA-19504: failed to create file "/u19/dbs/arch1_1_1243990641.dbf"
ORA-27038: created file already exists
Additional information: 1
NET  (PID:36760): Error 19504 Creating archive log file to '/u19/app/dbs/arch1_1_1243990641.dbf'
NET  (PID:36760): Archiving not possible: error count exceeded
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_36760.trc  (incident=119876):
ORA-00600: internal error code, arguments: [krsm_mrp_rebuild_lf_list.lno_mismatch], [3], [1], [1], [0], []
Incident details in: /u19/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_119876/orcl_ora_36760_i119876.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
NET  (PID:36760): Archive all ORLs failed, error=600
ORA-600 signalled during: ALTER DATABASE OPEN RESETLOGS...

通过alert日志大概回溯现场人员的恢复过程,最初数据库断电重启之后报ORA-00742错误

2026-09-14T20:52:37.294285-07:00
ALTER DATABASE OPEN
Ping without log force is disabled:
  instance mounted in exclusive mode.
2026-09-14T20:52:37.313266-07:00
Beginning crash recovery of 1 threads
 Thread 1: Recovery starting at checkpoint rba (logseq 63111 block 286483), scn 0
2026-09-14T20:52:37.370330-07:00
Started redo scan
2026-09-14T20:52:37.419944-07:00
Aborting crash recovery due to error 742
2026-09-14T20:52:37.420039-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_68055.trc:
ORA-00742: Log read detects lost write in thread 1 sequence 63111 block 326157
ORA-00312: online log 3 thread 1: '/u19/app/oracle/oradata/ORCL/redo03.log'
2026-09-14T20:52:37.420977-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_68055.trc:
ORA-00742: Log read detects lost write in thread 1 sequence 63111 block 326157
ORA-00312: online log 3 thread 1: '/u19/app/oracle/oradata/ORCL/redo03.log'
ORA-742 signalled during: ALTER DATABASE OPEN...

现场人员加上隐含参数强制拉库,然后数据库报ORA-600 kcbzib_kcrsds_1错误

2026-09-14T21:35:21.425310-07:00
ALTER DATABASE OPEN RESETLOGS
2026-09-14T21:35:21.429136-07:00
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 22297188666 time 
Resetting resetlogs activation ID 1680209845 (0x6425f7b5)
2026-09-14T21:35:34.017515-07:00
Setting recovery target incarnation to 3
2026-09-14T21:35:34.028360-07:00
Ping without log force is disabled:
  instance mounted in exclusive mode.
Endian type of dictionary set to little
2026-09-14T21:35:34.043771-07:00
Assigning activation ID 1771732361 (0x699a7d89)
2026-09-14T21:35:34.125473-07:00
TT00 (PID:47466): Gap Manager starting
2026-09-14T21:35:34.127554-07:00
Redo log for group 1, sequence 1 is not located on DAX storage
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u19/app/oracle/oradata/ORCL/redo01.log
Successful open of redo thread 1
2026-09-14T21:35:34.165332-07:00
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
stopping change tracking
2026-09-14T21:35:35.507453-07:00
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1],  , [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
SYSTEM DUMP REDO DBA MIN 4 128 DBA MAX 4 128 SCN MIN 1;
2026-09-14T21:35:37.154962-07: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.
*****************************************************************
Undo initialization recovery: err:600 start: 3433752 end: 3435865 diff: 2113 ms (2.1 seconds)
2026-09-14T21:35:37.475752-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_46217.trc:
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1],  , [], [], [], [], []
2026-09-14T21:35:37.475831-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_46217.trc:
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1],  , [], [], [], [], []
Error 600 happened during db open, shutting down database
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_46217.trc  (incident=48128):
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1],  , [], [], [], [], []

现场人员重建控制文件,然后启动库报ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch

2026-09-15T04:26:41.297637-07:00
Successful mount of redo thread 1, with mount id 1771762176
Completed: CREATE CONTROLFILE REUSE SET DATABASE "ORCL" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 1
    MAXLOGHISTORY 16
LOGFILE
  GROUP 1 '/u19/app/oracle/oradata/ORCL_NEW/redo01.log' SIZE 200M,
  GROUP 2 '/u19/app/oracle/oradata/ORCL_NEW/redo02.log' SIZE 200M
DATAFILE
  '/u19/app/oracle/oradata/ORCL_NEW/system01.dbf',
  '/u19/app/oracle/oradata/ORCL_NEW/sysaux01.dbf',
  '/u19/app/oracle/oradata/ORCL_NEW/undotbs01.dbf',
…………
2026-09-15T04:26:52.121793-07:00
ALTER DATABASE OPEN RESETLOGS
2026-09-15T04:26:52.126848-07:00
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 22297188686 time 
NET  (PID:27130): Unable to create archive log file '/u19/dbs/arch1_1_1243990641.dbf'
2026-09-15T04:26:52.233538-07:00
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_27130.trc:
ORA-19504: failed to create file "/u19/dbs/arch1_1_1243990641.dbf"
ORA-27038: created file already exists
Additional information: 1
NET  (PID:27130): Error 19504 Creating archive log file to '/u19/dbs/arch1_1_1243990641.dbf'
NET  (PID:27130): Archiving not possible: error count exceeded
Errors in file /u19/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_27130.trc  (incident=102102):
ORA-00600: internal error code, arguments: [krsm_mrp_rebuild_lf_list.lno_mismatch], [2], [1], [1], [0], []
Incident details in: /u19/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_102102/orcl_ora_27130_i102102.trc

接手故障开始处理,尝试open库,重现ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch错误

SQL> recover database using backup controlfile;
ORA-00279: change 22297188689 generated at 09/15/2026 00:57:22 needed for thread 1
ORA-00289: suggestion : /u19/dbs/arch/1_1_1243990641.dbf
ORA-00280: change 22297188689 for thread 1 is in sequence #1


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u19/app/oracle/oradata/ORCL/redo01.log
Log applied.
Media recovery complete.
SQL>        
SQL> 
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [krsm_mrp_rebuild_lf_list.lno_mismatch], [3], [1], [1], [0]

分析alert日志,是由于归档无法被正常创建导致该问题,对/u19/dbs/arch/进行创建并授权之后,再次尝试打开数据库,数据库报ORA-600 kcbzib_kcrsds_1错误

SQL> startup nomount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area       6442448984 bytes
Fixed Size			  8910936 bytes
Variable Size		       3858759680 bytes
Database Buffers	       2566914048 bytes
Redo Buffers			  7864320 bytes
SQL> alter database mount;

Database altered.

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], []
Process ID: 42259
Session ID: 1 Serial number: 19675

使用obet的patch scn功能修改scn之后(obet patch_scn使用说明),顺利打开库
patch_scn
open


记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

由于服务器断电导致数据库启动报错

Mon Sep 07 12:47:52 2026
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 32 processes
Started redo scan
ORA-00354: 损坏重做日志块标头
ORA-00353: 日志损坏接近块 41735 更改 2385313823 时间 09/07/2026 10:35:04
ORA-00312: 联机日志 5 线程 1: 'D:\APP\LIMSADMIN\ORADATA\ORCL\REDO05.LOG'
Mon Sep 07 12:47:58 2026
Trace dumping is performing id=[cdmp_20260907124758]
Errors in file d:\app\limsadmin\diag\rdbms\primary\orcl\trace\orcl_ora_3040.trc:
ORA-00354: 损坏重做日志块标头
ORA-00353: 日志损坏接近块 41735 更改 2385313823 时间 09/07/2026 10:35:04
ORA-00312: 联机日志 5 线程 1: 'D:\APP\LIMSADMIN\ORADATA\ORCL\REDO05.LOG'
ORA-354 signalled during: ALTER DATABASE OPEN...

从这里看,数据库在启动的时候实例恢复需要读取REDO05.LOG日志,但是发现该日志中有block损坏,而且损坏日志的时间点为09/07/2026 10:35:04,scn为2385313823(ORA-00353: 日志损坏接近块 41735 更改 2385313823 时间 09/07/2026 10:35:04),导致实例恢复无法完成,从而数据库无法正常启动.通过Oracle Recovery Check脚本检查数据库当前状态,数据库的checkpoint time为:09/07/2026 10:37:37,checkpoint scn为:2385314357
13
12


这个就比较明显,数据库文件正在需要的日志是sequence 19001 REDO01.LOG(而不是报错的sequence 19000 REDO05.LOG),基于这样的情况,出现这种问题,是由于control中记录的Thread Checkpoint RBA不正确导致.解决这个问题相对比较简单,重建ctl即可
14

由于redo05.log有损坏,该库为归档模式,需要先clear redo05.log(不然会导致redo无法归档,数据库hang住),然后对全库发起备份

不当数据库恢复操作导致一个月数据丢失

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:不当数据库恢复操作导致一个月数据丢失

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

今天分享一个本不该发生的故障,结果由于现场人员没有合适的判断导致客户丢失近一个月数据,事故经过大概是这样的
1. 客户数据库由于断电,启动之后报ORA-600 kcratr_scan_lastbwr错误

2026-09-03T11:22:58.998379+08:00
Beginning crash recovery of 2 threads
 parallel recovery started with 31 processes
 Thread 1: Recovery starting at checkpoint rba (logseq 37738 block 7724), scn 0
 Thread 2: Recovery starting at checkpoint rba (logseq 43821 block 37937), scn 0
2026-09-03T11:22:59.158232+08:00
Started redo scan
Hex dump of (file 20, block 2720) in trace file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_34049.trc

Reading datafile '+DATA/ORCL/DATAFILE/undotbs01.dbf' for corrupt data at rdba: 0x05000aa0 (file 20, block 2720)
Reread Not Encrypted (file 20, block 2720) found same data 
physically corrupt:No, logically corrupt:No, and is not expected version by upper layer. 
Write verification failed for File 20 Block 2720 (rdba 0x5000aa0)
*****************************************************************
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.
*****************************************************************
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_34049.trc  (incident=430645):
ORA-00600: internal error code, arguments: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_430645/orcl1_ora_34049_i430645.trc
2026-09-03T11:23:00.484486+08:00
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2026-09-03T11:23:00.510512+08:00
Slave encountered ORA-10388 exception during crash recovery

这个是一个比较常见的错误一般是由于redo写丢失导致(数据库open报ORA-600 kcratr_scan_lastbwr故障处理)

2. 现场操作的技术人员看了下这个错误,觉得数据库有备份,直接决定使用备份进行恢复
rman_bak


结果发现读取的是20260719的备份,而且原始的数据文件在asm里面,已经被覆盖。这个时候如果归档或者增量备份完整,还能够最大限度抢救数据,检查备份发现只有8月7日的增量备份,没有任何归档的备份(使用crontab 直接清理3天之前的归档)
1811

基于这样的情况,应用到最后一个增量备份(也就是8月7日),后面的数据由于归档已经被清理(而且没有备份)
arch

出现这个问题的原因是由于备份脚本本身备份归档,导致备份无法按照策略清理历史备份,导致磁盘空间满,从而后续备份无法继续(直接清理归档了)
ORA-27027

恢复只能到此为止,查询最终的文件头恢复时间点
header_rman

3. 基于这种情况只能尝试强制打开数据库,结果报ORA-600 kcbzibmlt_kcrsds_1错误

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kcbzibmlt_kcrsds_1], [], [], []
Process ID: 30365
Session ID: 2180 Serial number: 43414

4. 这种错误类似ORA-600 kcbzib_kcrsds_1的处理思路,使用obet的patch_scn功能直接进行处理

OBET> patch_scn 89103 0x60017e98 3182707622

=== Oracle SCN Patch ===
PID:     89103
Address: 0x60017e98
New Value: 0xbdb443a6 (3182707622)
Original SCN: 0x0

Are you sure you want to modify Oracle SCN? (yes/no): y

SCN modified: 0x0 -> 0xbdb443a6
Oracle SCN successfully modified.

然后打开数据库

SQL> alter database open;

Database altered.

导出数据,导入新库完成本次恢复任务,可惜没有办法帮客户找回来丢失的那一个月数据.

案例总结:
1. rman备份脚本尽量不要有直接删除归档的操作,尽可能是先备份然后再删除(确认备份成功之后删除)
2. 备份还原操作之前,需要看备份文件和日志,大概评估下备份的可用性
3. 尽可能不要在损坏的现场环境上直接做rman还原操作(万一备份无法正常还原,比如中途有备份文件异常呢?)
4. 这个故障,如果不做还原操作,直接异常恢复,基本上也就丢失了当前redo中的数据,损失是最小的