由于con$.con#值达到极限，触发数据库增加约束报ORA-600 12807错误

Posted on 2026 年 10 月 22 日 by 惜分飞

标题：由于con$.con#值达到极限，触发数据库增加约束报ORA-600 12807错误

有客户数据库报ORA-600 12807错误，导致数据库无法创建任何约束(带约束条件的表也无法创建)，alert 日志报错如下

2026-10-19T09:33:41.779082+08:00
Errors in file /oracle/database/diag/rdbms/oradb/oradb1/trace/oradb1_ora_184458.trc
ORA-00600: 内部错误代码, 参数: [12807], [], [], [], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2026-10-19T09:33:42.080313+08:00
Errors in file /oracle/database/diag/rdbms/oradb/oradb1/trace/oradb1_ora_221081.trc
ORA-00600: 内部错误代码, 参数: [12807], [], [], [], [], [], [], [], [], [], [], []
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2026-10-19T09:33:42.401635+08:00
DDE: Problem Key 'ORA 600 [12807]' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes

对应的trace文件报错

*** 2026-10-20T23:01:14.835258+08:00
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
[TOC00004]
----- Current SQL Statement for this session (sql_id=czyqxdfu45w1c) -----
CREATE TABLE VT10RMC7BHYU76DDQ3DHV75RMV (KSQL_SEQ INT, FID VARCHAR2 (44) NOT NULL
…………………… 
FInPriceBizDate TIMESTAMP, CONSTRAINT ZC8SOAHBADTGB7OIBG PRIMARY KEY (FID)) NOLOGGING
[TOC00004-END]

[TOC00005]
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst1()+95         call     kgdsdst()            7FFF09990520 000000002
                                                   7FFF0998A860 ? 7FFF0998A978 ?
                                                   000000000 000000082 ?
ksedst()+58          call     ksedst1()            000000000 000000001
                                                   7FFF0998A860 ? 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
dbkedDefDump()+2344  call     ksedst()             000000000 000000001 ?
8                                                  7FFF0998A860 ? 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
ksedmp()+577         call     dbkedDefDump()       000000003 000000002
                                                   7FFF0998A860 ? 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
dbgexPhaseII()+2092  call     ksedmp()             0000003EB 000000002 ?
                                                   7FFF0998A860 ? 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
dbgexExplicitEndInc  call     dbgexPhaseII()       7FBAB95976D8 7FBAB47D3148
()+285                                             7FFF09991700 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
dbgeEndDDEInvocatio  call     dbgexExplicitEndInc  7FBAB95976D8 7FBAB47D3148
nImpl()+314                   ()                   7FBAB47D39F0 7FFF0998A978 ?
                                                   000000000 ? 000000082 ?
kqrHashTableInsert(  call     dbgeEndDDEInvocatio  7FBAB95976D8 7FBAB47D3148
)+2446                        nImpl()              7FBAB95D79C0 7FFF0998A978 ?
                                                   7FBAB95D79C0 000000082 ?
kqrRelinkToHashTabl  call     kqrHashTableInsert(  000000000 ? 16F5F05F70 ?
e()+226                       )                    15B7ED3EC0 ? FFFFFFFFF6B64B6B
                                                   7FBAB95D79C0 ? 2400000000
kqrUpdateHashTable(  call     kqrRelinkToHashTabl  000000000 ? 16F5F05F70 ?
)+417                         e()                  15B7ED3EC0 ?
                                                   FFFFFFFFF6B64B6B ?
                                                   7FBAB95D79C0 ? 2400000000 ?
kqrfpo()+729         call     kqrUpdateHashTable(  7FBAB95D79C0 16F5F05F70 ?
                              )                    FFFFFFFFF5F05F70 00000000B
                                                   000000003 ? 2400000000 ?
kkdcnco()+1749       call     kqrfpo()             16F5F05F70 16F5F05F70 ?
                                                   FFFFFFFFF5F05F70 ?
                                                   00000000B ? 24886FB6D8
                                                   2400000000 ?
kkdcico()+339        call     kkdcnco()            000000057 7FBAB39D5420
                                                   7FFF09992B80 16167E3500
                                                   000000000 2400000000 ?
ctcdrv()+40399       call     kkdcico()            000000057 7FBAB39D53F8
                                                   7FBAB9478950 16167E3500
                                                   14BF81D188 2400000000 ?
opiexe()+25553       call     ctcdrv()             7FBAB9479388 7FFF099B5D60
                                                   7FFF099B5E50 16167E3500 ?
                                                   14BF81D188 ? 2400000000 ?
opiosq0()+4494       call     opiexe()             000000004 7FFF099B5D60 ?
                                                   7FFF099B64A0 16167E3500 ?
                                                   14BF81D188 ? 2400000000 ?
kpooprx()+287        call     opiosq0()            000000003 7FFF099B5D60 ?
                                                   7FBAB95D79C0 ? 0000000A4
                                                   000000000 000000001
kpoal8()+821         call     kpooprx()            7FFF099BA5C4 7FBAB3967B58
                                                   000000736 000000001 000000000
                                                   0000000A4
opiodr()+1202        call     kpoal8()             00000005E 000000026
                                                   7FFF099BA5C0 000000001 ?
                                                   000000000 ? 0000000A4 ?
ttcpip()+1218        call     opiodr()             00000005E 000000026
                                                   7FFF099BA5C0 ? 000000000
                                                   000000000 ? 0000000A4 ?
opitsk()+1900        call     ttcpip()             7FBAB9601B30 ? 000000026 ?
                                                   7FFF099BA5C0 000000000 ?
                                                   7FFF099BA020 7FFF099BA810 ?
opiino()+936         call     opitsk()             000000000 000000000
                                                   7FFF099BA5C0 ? 000000000 ?
                                                   7FFF099BA020 ? 7FFF099BA810 ?
opiodr()+1202        call     opiino()             00000003C 000000004
                                                   7FFF099BC198 000000000 ?
                                                   7FFF099BA020 ? 7FFF099BA810 ?
opidrv()+1094        call     opiodr()             00000003C 000000004
                                                   7FFF099BC198 ? 000000000
                                                   7FFF099BA020 ? 7FFF099BA810 ?
sou2o()+165          call     opidrv()             00000003C 000000004
                                                   7FFF099BC198 000000000 ?
                                                   7FFF099BA020 ? 7FFF099BA810 ?
opimai_real()+422    call     sou2o()              7FFF099BC131 00000003C
                                                   000000004 7FFF099BC198
                                                   7FFF099BA020 ? 7FFF099BA810 ?
ssthrdmain()+417     call     opimai_real()        000000000 7FFF099BC988
                                                   000000004 ? 7FFF099BC198 ?
                                                   7FFF099BA020 ? 7FFF099BA810 ?
main()+256           call     ssthrdmain()         000000000 000000002
                                                   7FFF099BC988 000000001
                                                   000000000 7FFF099BA810 ?
__libc_start_main()  call     main()               000000002 7FFF099BCBC8
+245                                               7FFF099BC988 ? 000000001 ?
                                                   000000000 ? 7FFF099BA810 ?
_start()+41          call     __libc_start_main()  000DCD110 000000002
                                                   7FFF099BCBC8 000000000 ?
                                                   000000000 ? 7FFF099BA810 ?
[TOC00005-END]

问题重现

[oracle@oradb1 ~]$ sqlplus / as sysdba

SQL*Plus: Relorae 19.0.0.0.0 - Production on Tue Oct 20 21:45:57 2026
Version 19.14.0.0.0

Copyright (c) 1982, 2021, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Relorae 19.0.0.0.0 - Production
Version 19.14.0.0.0

SQL> create table t_test1020(id number not null);
create table t_test1020(id number not null)
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [12807], [], [], [], [], [], [], [],
[], [], [], []

分析故障原因(con$.con#=4294967294(_NEXT_CONSTRAINT)达到了理论最大值,无法继续增加所以报ORA-600 12807错误)

SQL> select 4294967294 - con# from sys.con$ where name='_NEXT_CONSTRAINT';

4294967294-CON#
---------------
              0

SQL> select max(con#) from sys.con$;

 MAX(CON#)
----------
4294967294

根据oracle官方描述打上25343563 patch可以实现con$.con#循环利用

[oracle@oradb1 25343563]$ opatch lspatches
25343563;MECHANISM TO REUSE CON#
33561310;OJVM RELoraE UPDATE: 19.14.0.0.220118 (33561310)
33529556;OCW RELoraE UPDATE 19.14.0.0.0 (33529556)
33515361;Database Relorae Update : 19.14.0.0.220118 (33515361)

OPatch succeeded.

测试问题解决

SQL> create table t_test1020(id number not null);

Table created.

SQL> 
SQL> select constraint_name
  2  from user_cons_columns
  3  where table_name = 'T_TEST1020'
  4    and column_name = 'ID';

CONSTRAINT_NAME
--------------------------------------------------------------------------------
SYS_C0012094

SQL> SELECT CON# FROM CON$ WHERE NAME='SYS_C0012094';

      CON#
----------
     12094

SQL> SELECT COUNT(1) FROM con$recycle;

  COUNT(1)
----------
 100032699

SQL> select  con# from sys.con$ where name='_NEXT_CONSTRAINT';

      CON#
----------
4294967294

分析实现原因，其实oracle是通过创建sys.con$recycle表，把使用过的记录存储到这个表里面(新删除的约束的con#也会自动增加到这个表里面)，后续使用直接从这个表中拿数据出来使用，从而实现con$中的con#循环使用，从而解决了ORA-600 12807问题,如果是12c之前版本参考:ORA-600 12807（CON$.CON#达到最大值）处理

MongoDB 离线提取工具—mongoext

Posted on 2026 年 10 月 11 日 by 惜分飞

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

标题：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 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.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文件可恢复

Posted on 2026 年 10 月 05 日 by 惜分飞

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

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

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

勒索信息为:id.readme文件

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

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

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