标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,881)
- DB2 (22)
- MySQL (82)
- Oracle (1,706)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (660)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
分类目录归档:Oracle
记录一次云存储资源到期之后引起的数据库恢复
客户环境是运行在xx厂商上的云环境的Oracle RAC,由于其中一块asm disk资源到期没有进行续费,云厂商对该盘进行了限速(1MB/s,并且异步写入),导致运行在该rac上的数据库直接crash,客户续费之后磁盘速度恢复正常但是数据库启动报ORA-00353 ORA-00312错误(redo异常),客户找了以前的服务商进行恢复尝试没有成功.对接手后的现场进行检测,发现有20个数据文件被初始化(dbv检测全部是空块,没有写入任何表和索引数据)[直接变成了空文件,一般sqlplus中执行alter database create datafile或者在没有对应的数据文件备份的情况下执行restore datafile会出现这个情况],数据库被强制拉库,但是启动没有成功报ORA-00704 ORA-01555错误.由于客户明天领导会过来检查,所以着急启动系统,我们只能基于现在的现况给客户强制拉起来库,赌运气看看核心业务是否可以跑起来
回溯处理过程,续费欠费资源之后,数据库启动报错(估计是当时限速之后,云存储层面异步写入导致部分写丢失)
Mon Oct 26 11:38:19 2026 alter database open This instance was first to open Beginning crash recovery of 1 threads parallel recovery started with 15 processes Started redo scan Incomplete read from log member '+DATA/xff/onlinelog/group_3.312.1210628353'. Trying next member. Incomplete read from log member '+DATA/xff/onlinelog/group_3.312.1210628353'. Trying next member. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc (incident=682004): ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' Incident details in: /oracle/diag/rdbms/xff/xff1/incident/incdir_682004/xff1_ora_19144_i682004.trc Abort recovery for domain 0 Aborting crash recovery due to error 368 Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' Abort recovery for domain 0 Mon Oct 26 11:38:22 2026 Sweep [inc][682004]: completed Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' ORA-368 signalled during: alter database open...
屏蔽一致性,强制resetlogs的时候报ORA-00704 ORA-01555错误
Mon Oct 26 15:47:43 2026 Setting recovery target incarnation to 2 Initializing SCN for created control file Database SCN compatibility initialized to 3 Warning - High Database SCN: Current SCN value is 16917769616373, threshold SCN value is 0 Mon Oct 26 15:47:43 2026 Assigning activation ID 2556751686 (0x9864ef46) LGWR: STARTING ARCH PROCESSES Mon Oct 26 15:47:43 2026 ARC0 started with pid=32, OS id=14392 ARC0: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Mon Oct 26 15:47:44 2026 ARC1 started with pid=33, OS id=14446 Mon Oct 26 15:47:44 2026 ARC2 started with pid=34, OS id=14448 Mon Oct 26 15:47:44 2026 ARC3 started with pid=35, OS id=14450 ARC1: Archival started ARC2: Archival started ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH ARC2: Becoming the heartbeat ARCH Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: +DATA/xff/onlinelog/group_1.314.1210628351 Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Oct 26 15:47:44 2026 SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 7bd391hat42zk, SCN: 0x0f62.f9a5fbf8): select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp, DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_13439.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 2 ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_13439.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 2 ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small Error 704 happened during db open, shutting down database USER (ospid: 13439): terminating the instance due to error 704 Instance terminated by USER, pid = 13439 ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS... opiodr aborting process unknown ospid (13439) as a result of ORA-1092
从这个时候开始我接手这个故障,数据完全恢复已经不太可能,只能基于现在的情况,给客户尝试拉起来库,看看核心业务是否可以跑起来.
数据库open过程报ORA-01555错误,这个是一个比较常见的问题,以前专门写过类似文章:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
对于这个客户问题,我也一样尝试修改scn的方式来解决
SQL> set numw 16 col CHECKPOINT_TIME for a40 set lines 150 set pages 1000 SELECT status, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY,checkpoint_change#, count(*) ROW_NUM FROM v$datafile_header GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy ORDER BY status, checkpoint_change#, checkpoint_time;SQL> SQL> SQL> SQL> 2 3 4 5 6 STATUS CHECKPOINT_TIME FUZ CHECKPOINT_CHANGE# ROW_NUM ------- ---------------------------------------- --- ------------------ ---------------- ONLINE 2026-10-26 15:47:44 YES 16917769616374 191
使用obet的patch_scn功能来修改数据库scn(obet的patch_scn功能)
OBET> patch_scn 89103 0x06001AE70 0xF62FBA5FBF6 === Oracle SCN Patch === PID: 89103 Address: 0x06001AE70 New Value: 0xF62FBA5FBF6 (16917803170806) Original SCN: 0x0 Are you sure you want to modify Oracle SCN? (yes/no): y SCN modified: 0x0 -> 0xF62FBA5FBF6 Oracle SCN successfully modified. SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [06001AE70, 06001AEA0) = FBA5FBF6 00000F62 00000000 00000000 00000000
然后尝试打开数据库依旧报ORA-01555错误,证明我们处理的scn不正确
SQL> recover database using backup controlfile;
ORA-00279: change 16917769616374 generated at 10/26/2026 15:47:44 needed for
thread 1
ORA-00289: suggestion : +ARCH
ORA-00280: change 16917769616374 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DATA/xff/onlinelog/group_1.314.1210628351
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small
Process ID: 18169
Session ID: 3681 Serial number: 2825
分析异常block的scn
*** 2026-10-27 01:05:42.156
Start dump data block from file +DATA/xff/system01.dbf minblk 558 maxblk 558
V10 STYLE FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=2195614447=0x82de6aef, Db Name='xff'
Activation ID=0=0x0
Control Seq=542=0x21e, File size=446720=0x6d100
File Number=1, Blksiz=8192, File Type=3 DATA
Dump all the blocks in range:
buffer tsn: 0 rdba: 0x0040022e (1/558)
scn: 0x0f63.c1efd2ab seq: 0x01 flg: 0x04 tail: 0xd2ab0201
frmt: 0x02 chkval: 0x75a3 type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
发现该block的scn非常大0x0f63.c1efd2ab,我之前处理的scn明显不合适,继续换上新的scn,再次打开数据库成功
OBET> patch_scn 89103 0x06001AE70 0xF64C1EFD2AB === Oracle SCN Patch === PID: 89103 Address: 0x06001AE70 New Value: 0xF64C1EFD2AB(16925424865963) Original SCN: 0x0 Are you sure you want to modify Oracle SCN? (yes/no): y SCN modified: 0x0 -> 0xF64C1EFD2AB Oracle SCN successfully modified. SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [06001AE70, 06001AEA0) = C1EFD2AB 00000F64 00000000 00000000 00000000 SQL> SQL> SQL> SQL> alter database open; Database altered.
后续大量异常undo问题
ORA-00376: file 182 cannot be read at this time ORA-01111: name for data file 182 is unknown - rename to correct file ORA-01110: data file 182: '/oracle/product/11.2.0/db_1/dbs/MISSING00182' ORACLE Instance xff1 (pid = 20) - Error 1578 encountered while recovering transaction (21, 29) on object 99404. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-01578: ORACLE data block corrupted (file # 8, block # 1471227) ORA-01110: data file 8: '+DATA/xff/users04.dbf' ORACLE Instance xff1 (pid = 20) - Error 376 encountered while recovering transaction (2, 27) on object 599926. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-00376: file 211 cannot be read at this time ORA-01111: name for data file 211 is unknown - rename to correct file ORA-01110: data file 211: '/oracle/product/11.2.0/db_1/dbs/MISSING00211' ORACLE Instance xff1 (pid = 20) - Error 376 encountered while recovering transaction (10, 6) on object 99591. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-00376: file 182 cannot be read at this time ORA-01111: name for data file 182 is unknown - rename to correct file ORA-01110: data file 182: '/oracle/product/11.2.0/db_1/dbs/MISSING0018
由于这些文件已经被初始化掉了,恢复已经没有意义,直接没有加入到ctl中,现在主要是由于有些事务涉及这些文件,导致smon回滚的时候报这些错误,对于这样的异常,直接对于undo进行重建更换新undo即可.处理好这些问题之后,数据库open运行问题,客户自行安排业务测试和论证
Oracle 19c 202610补丁(RUs+OJVM)-19.33
| Release | Database Update | GI Update | Windows Bundle Patch |
| OCT2026 (19.33.0.0.0) | 39915792 | 39922757 | 39898799 |
| JUL2026 (19.32.0.0.0) | 39472050 | 39467003 | 39418910 |
| APR2026 (19.31.0.0.0) | 39034528 | 39036936 | 38818049 |
| JAN2026 (19.30.0.0.0) | 38632161 | 38629535 | 38597735 |
| OCT2025 (19.29.0.0.0) | 38291812 | 38298204 | 38111211 |
| JUL2025 (19.28.0.0.0) | 37960098 | 37957391 | 37962957 |
| APR2025 (19.27.0.0.0) | 37642901 | 37641958 | 37532350 |
| JAN2025 (19.26.0.0.0) | 37260974 | 37257886 | 37486199 |
| OCT2024 (19.25.0.0.0) | 36912597 | 36916690 | 36878821 |
| JUL2024 (19.24.0.0.0) | 36582781 | 36582629 | 36521936 |
| APR2024 (19.23.0.0.0) | 36233263 | 36233126 | 36219938 |
| JAN2024 (19.22.0.0.0) | 35943157 | 35940989 | 35962832 |
| OCT2023 (19.21.0.0.0) | 35643107 | 35642822 | 35681552 |
| JUL2023 (19.20.0.0.0) | 35320081 | 35319490 | 35348034 |
| APR2023 (19.19.0.0.0) | 35042068 | 35037840 | 35046439 |
| JAN2023 (19.18.0.0.0) | 34765931 | 34762026 | 34750795 |
| Oct2022 (19.17.0.0.0) | 34419443 | 34416665 | 34468114 |
| JUL2022 (19.16.0.0.0) | 34133642 | 34130714 | 34110685 |
| APR2022 (19.15.0.0.0) | 33806152 | 33803476 | 33829175 |
| JAN2022 (19.14.0.0.0) | 33515361 | 33509923 | 33575656 |
| OCT2021(19.13.0.0.0) | 33192793 | 33182768 | 33155330 |
| JUL2021 (19.12.0.0.0) | 32904851 | 32895426 | 32832237 |
| APR2021 (19.11.0.0.0) | 32545013 | 32545008 | 32409154 |
| JAN2021 (19.10.0.0.0) | 32218454 | 32226239 | 32062765 |
| OCT2020 (19.9.0.0.0) | 31771877 | 31750108 | 31719903 |
| JUL2020 (19.8.0.0.0) | 31281355 | 31305339 | 31247621 |
| APR2020 (19.7.0.0.0) | 30869156 | 30899722 | 30901317 |
| JAN2020 (19.6.0.0.0) | 30557433 | 30501910 | 30445947 |
| OCT2019 (19.5.0.0.0) | 30125133 | 30116789 | 30151705 |
| JUL2019 (19.4.0.0.0) | 29834717 | 29708769 | - |
| APR2019 (19.3.0.0.0) | 29517242 | 29517302 | - |
| Release | OJVM Update | OJVM + DB Update | OJVM + GI Update |
| OCT2026 (19.33.0.0.261020) | 39803650 | 40121635 | 40121665 |
| JUL2026 (19.32.0.0.260721) | 39222882 | 39618649 | 39618711 |
| APR2026 (19.31.0.0.260421) | 38906621 | 39062931 | 39062956 |
| JAN2026 (19.30.0.0.260120) | 38523609 | 38658587 | 38658588 |
| OCT2025 (19.29.0.0.251021) | 38194382 | 38273545 | 38273558 |
| JUL2025 (19.28.0.0.250715) | 37847857 | 37952354 | 37952382 |
| APR2025 (19.27.0.0.250415) | 37499406 | 37591483 | 37591516 |
| JAN2025 (19.26.0.0.250121) | 37102264 | 37262172 | 37262208 |
| OCT2024 (19.25.0.0.241015) | 36878697 | 36866623 | 36866740 |
| JUL2024 (19.24.0.0.240716) | 36414915 | 36522340 | 36522439 |
| APR2024 (19.23.0.0.240416) | 36199232 | 36209492 | 36209493 |
| JAN2024 (19.22.0.0.240116) | 35926646 | 36031426 | 36031453 |
| OCT2023 (19.21.0.0.231017) | 35648110 | 35742413 | 35742441 |
| JUL2023 (19.20.0.0.230718) | 35354406 | 35370174 | 35370167 |
| APR2023 (19.19.0.0.230418) | 35050341 | 35058163 | 35058172 |
| JAN2023 (19.18.0.0.230117) | 34786990 | 34773489 | 34773504 |
| OCT2022 (19.17.0.0.221018) | 34411846 | 34449114 | 34449117 |
| JUL2022 (19.16.0.0.220719) | 34086870 | 34160831 | 34160854 |
| APR2022 (19.15.0.0.220419) | 33808367 | 33859194 | 33859214 |
| JAN2022 (19.14.0.0.220118) | 33561310 | 33567270 | 33567274 |
| OCT2021 (19.13.0.0.211019) | 33192694 | 33248420 | 33248471 |
| JUL2021 (19.12.0.0.210720) | 32876380 | 32900021 | 32900083 |
| APR2021 (19.11.0.0.210420) | 32399816 | 32578972 | 32578973 |
| JAN2021 (19.10.0.0.210119) | 32067171 | 32126828 | 32126842 |
| OCT2020 (19.9.0.0.201020) | 31668882 | 31720396 | 31720429 |
| JUL2020 (19.8.0.0.200714) | 31219897 | 31326362 | 31326369 |
| APR2020 (19.7.0.0.200414) | 30805684 | 30783543 | 30783556 |
| JAN2020 (19.6.0.0.200114) | 30484981 | 30463595 | 30463609 |
| OCT2019 (19.5.0.0.191015) | 30128191 | 30133124 | 30133178 |
| JUL2019 (19.4.0.0.190716) | 29774421 | 29699079 | 29699097 |
| APR2019 (19.3.0.0.190416) | 29548437 | 29621253 | 29621299 |
参考:Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases KA958
由于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#达到最大值) 处理

加我微信(17813235971)
加我QQ(107644445)

