分类目录归档: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备份恢复 | 标签为 , , , | 留下评论

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

发表在 Oracle安装升级 | 标签为 , , , , , | 留下评论

由于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#达到最大值) 处理

发表在 Oracle | 标签为 , , | 留下评论