标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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-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 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,769)
- DB2 (22)
- MySQL (77)
- Oracle (1,610)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (592)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
月归档:八月 2012
ORA-00600[kgscLogOff-notempty]
在查看一网友alert日志时发现很多ORA-00600[kgscLogOff-notempty]记录,通过查询MOS分析记录结果如下:
alert日志出现ORA-00600[kgscLogOff-notempty]
Wed Aug 1 10:28:35 2012 Errors in file /vgdata/oracle/admin/orcl1/udump/orcl1_ora_18430.trc: ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [1], [], [], [], [], [], [] Wed Aug 1 10:28:38 2012 Errors in file /vgdata/oracle/admin/orcl1/udump/orcl1_ora_18508.trc: ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [3], [], [], [], [], [], []
trace结合MOS分析原因
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options ORACLE_HOME = /vgdata/oracle/product System name: HP-UX Node name: hpdc1 Release: B.11.31 Version: U Machine: ia64 Instance name: orcl1 Redo thread mounted by this instance: 1 Oracle process number: 230 Unix process pid: 18430, image: oracleorcl1@hpdc1 *** SERVICE NAME:(orcl1) 2012-08-01 10:28:35.937 *** SESSION ID:(191.141) 2012-08-01 10:28:35.937 *** 2012-08-01 10:28:35.937 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [1], [], [], [], [], [], [] ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst()+64 call _etext_f()+23058430 000000000 ? 000000001 ? 09017233648 ksedmp()+1680 call _etext_f()+23058430 000000000 ? 09017233648 C000000000000D20 ? 40000000052C8C90 ? 000000000 ? 000000000 ? 000000000 ? ksfdmp()+48 call _etext_f()+23058430 000000003 ? 09017233648 kgerinv()+400 call _etext_f()+23058430 40000000093F4370 ? 09017233648 000000003 ? C000000000000612 ? 000008F07 ? 000000000 ? 000000000 ? kgeasnmierr()+144 call _etext_f()+23058430 6000000000015190 ? 09017233648 6000000000016248 ? 6000000000013770 ? 600000000009C808 ? 60000000000165B0 ? $cold_kgscLogOff()+ call _etext_f()+23058430 6000000000015190 ? 144 09017233648 9FFFFFFFBF562160 ? 9FFFFFFFBF562170 ? 60000000000165C0 ? 000000000 ? 000000001 ? kkslof()+320 call _etext_f()+23058430 6000000000015190 ? 09017233648 opifcs()+592 call _etext_f()+23058430 C000000360365908 ? 09017233648 C000000000000E21 ? 4000000002E1BF20 ? 000000000 ? 000000000 ? ksuxds()+1568 call _etext_f()+23058430 C000000360365908 ? 09017233648 4000000002EBA7A0 ? 000008F9F ? 000004810 ? 9FFFFFFFBF56BEF6 ? C000000360365908 ? 4000000001354140 ? 00000003F ? ksudel()+128 call _etext_f()+23058430 60000000000A7B54 ? 09016643752 60000000000A7CF8 ? 9FFFFFFFFFFF6C20 ? 600000000009D8A0 ? opilof()+3664 call _etext_f()+23058430 60000000000A7B54 ? 09016643752 60000000000A7CF8 ? 4000000003D681E0 ? C00000000000122A ? 00000814F ? 60000000000A7CE0 ? opiodr()+2016 call opilof()+3664 60000000002BE7B0 ? 60000000002BE7B8 ? 000000001 ? 9FFFFFFFFFFF71B0 ? 600000000009D8A0 ? 60000000002BE7E0 ? ttcpip()+1824 call _etext_f()+23058430 60000000000AA0BC ? 09017243504 000000001 ? 6000000000015310 ? 6000000000015310 ? 9FFFFFFFFFFF8250 ? 600000000009D8A0 ? 9FFFFFFFFFFF8250 ? 6000000000020D88 ? opitsk()+2224 call _etext_f()+23058430 6000000000020D80 ? 09017192128 9FFFFFFFFFFFA3D4 ? 6000000000020EE8 ? 000000001 ? 9FFFFFFFFFFFAA90 ? 9FFFFFFFFFFFA884 ? 6000000000020E88 ? 000000000 ? opiino()+2144 call _etext_f()+23058430 000000000 ? 000000000 ? 09016681384 600000000009D8A0 ? 4000000002AE7E10 ? 000008001 ? 9FFFFFFFFFFFA874 ? opiodr()+2016 call _etext_f()+23058430 00000003C ? 09016681384 9FFFFFFFFFFFF260 ? 9FFFFFFFFFFFF250 ? 9FFFFFFFFFFFBF90 ? 0000000B0 ? 600000000008F560 ? opidrv()+1136 call _etext_f()+23058430 60000000000AA0BC ? 09017243504 000000001 ? 6000000000015310 ? 6000000000015310 ? 9FFFFFFFFFFFCAE0 ? 600000000009D8A0 ? sou2o()+240 call 9fffffffffffcae0 00000003C ? 000000004 ? 9FFFFFFFFFFFF250 ? opimai_real()+480 call 9fffffffffffcae0 9FFFFFFFFFFFF270 ? 00000003C ? 000000004 ? 9FFFFFFFFFFFF250 ? main()+352 call 9fffffffffffcae0 000000000 ? 9FFFFFFFFFFFF2A0 ? main_opd_entry()+80 call 9fffffffffffcae0 000000002 ? 9FFFFFFFFFFFF750 ? C000000000033910 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
通过查询MOS发现ORA-600 [kgscLogOff-notempty] On Session Logoff [ID 413120.1]中记录有
The following error may occur on session logoff ORA-600 [kgscLogOff-notempty], [1] or ORA-600 [kgscLogOff-notempty], [2] with a Call Stack like: ... kgscLogOff kkslof opifcs ksuxds ksudel ...
和该数据库中的Stack Dump记录一致,数据库版本也在该bug范围内,从而可以确定是unpublished Bug 4887675
解决方案
该错误是在logoff时产生,对数据库影响不大,如果偶尔出现可以忽略,出现频率过高,建议按照下列方法解决
There is No Data Corruption (or) Data Loss due to this Error. This error occurs during the logoff operation, hence the impact should be negligible. This is fixed in 10.2.0.4 and above releases. One-off patches may be available depending on your current release and operating system. To obtain a patch from MetaLink: 1) Click on Patches. 2) Click on Simple Search 3) Enter patch number: 4887675 4) Select your O/S 5) Click Go. As workaround, avoid Killing/Terminating the Session Abnormally.
因为高版本引起ORA-00600[17059]
alert日志出现ORA-00600[17059]
Wed Aug 01 03:19:29 2012 Errors in file /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc (incident=682625): ORA-00600: 内部错误代码, 参数: [17059], [0x700000A18EE85E0], [0x70000085506A820], [0x700000A51F56E40], [], [], [], [] Incident details in: /oracle/diag/rdbms/sgerp5/sgerp5/incident/incdir_682625/sgerp5_ora_5177388_i682625.trc
查看trace文件
Dump continued from file: /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc ORA-00600: 内部错误代码, 参数: [17059], [0x700000A3ED7B240], [0x7000007C19384F8], [0x70000078BC51048], [], [], [], [] ========= Dump for incident 682624 (ORA 600 [17059]) ======== *** 2012-07-31 22:38:06.130 ----- Current SQL Statement for this session (sql_id=03vurqhdanbv6) ----- begin insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode) values('1521','20070115210130','连云港通灌路购物广场地堆130','200701','0201',1200,1,'0000','0000'); insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode) values('1521','20070115210131','连云港通灌路购物广场地堆131','200701','0201',1200,1,'0000','0000'); …………近5万条类此sql end; ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- skdstdst()+002c bl 105e27f1c ksedst1()+0064 bl 101fadb74 ksedst()+0028 bl ksedst1() 000000000 ? 000000000 ? dbkedDefDump()+07fc bl 101faf398 ksedmp()+0048 bl 101fadb70 ksfdmp()+0058 bl ksedmp() 000000000 ? dbgexPhaseII()+0130 bl _ptrgl() dbgexProcessError() bl dbgexPhaseII() 110383690 ? 000000000 ? +09bc 600000006 ? dbgeExecuteForError bl dbgexProcessError() 110383690 ? 110388B10 ? ()+0040 1729C5E38 ? 000004028 ? dbgePostErrorKGE()+ bl dbgeExecuteForError FFFFFFFFFFF02C0 ? 110000328 ? 03c0 () FFFFFFFFFFF0350 ? 484222407FFFFFF8 ? 100154D20 ? dbkePostKGE_kgsf()+ bl dbgePostErrorKGE() 000000258 ? 110000328 ? 003c 25810594518 ? kgeade()+0300 bl _ptrgl() kgeriv_int()+0068 bl kgeade() 1070DA620 ? 1070DADB8 ? 1070D9E48 ? 1070DB208 ? 1070DA784 ? 1070DA788 ? 1070DA77C ? 1070DA794 ? kgeriv()+0020 bl kgeriv_int() 7000007C19384F8 ? 000000000 ? 000000001 ? FFFFFFFFFFF11E0 ? 700000A62228320 ? 7000007C19384F8 ? kgesiv()+007c bl kgeriv() 10102D590 ? 700000A3ED7B350 ? 700000A62228320 ? 000000005 ? 000000000 ? kgesic3()+0040 bl kgesiv() 7000007C19384F8 ? 000000000 ? 000000001 ? FFFFFFFFFFF11E0 ? 700000A62228320 ? kgltba()+0134 bl kgesic3() 110000328 ? 110594518 ? 42A3000042A3 ? 000000002 ? 700000A3ED7B240 ? 000000002 ? 7000007C19384F8 ? 000000002 ? kglrdtin()+01d4 bl kgltba() FFFFFFFFFFF1470 ? 000000000 ? FFFFFFFFFFF1318 ? 000000000 ? 000000001 ? 12BFB90F8 ? kglrtl()+0020 bl kglrdtin() 000000001 ? 000000000 ? 000000001 ? 169F90F18 ? 169F8E7F0 ? 12BFB90F8 ? FFFFFFFFFFF1470 ? pdy3M06_Add_Sql_Str bl kglrtl() FFFFFFFFFFF14F0 ? ing()+00c4 7FFF000000007FFF ? 10262A2A8 ? 11032DD20 ? 26FDBFA00 ? pdy8M92_Fill_SQD()+ bl pdy3M06_Add_Sql_Str 102683768 ? 000000000 ? 006c ing() 10267265C ? pdy8M74_Fill_Descri bl 101faf1a4 ptor()+0124 pdy8F07_Materialize bl pdy8M74_Fill_Descri 164B00E58 ? 165BD0380 ? _Descriptors()+038c ptor() 7000008C99BA368 ? pdy1F82_Write_MCode bl pdy8F07_Materialize FFFFFFFFFFF3968 ? 000000000 ? ()+0084 _Descriptors() pdy1F01_Driver()+01 bl pdy1F82_Write_MCode FFFFFFFFFFF18D0 ? 10726667C ? 58 () 7000008EA0F18D8 ? pdw0F82_Run_Code_Ge bl pdy1F01_Driver() 1028771D4 ? 000000000 ? n()+0088 pdw0F01_Code_Gen()+ bl pdw0F82_Run_Code_Ge FFFFFFFFFFF1A50 ? 12BFC3E48 ? 0250 n() phpcog()+0010 bl pdw0F01_Code_Gen() FFFFFFFFFFF3968 ? 70000078BC51048 ? 000000004 ? phpcmp()+13a0 bl phpcog() 11037D140 ? 700000000003640 ? pcicog()+0234 bl phpcmp() FFFFFFFFFFF3968 ? 70000078BC51048 ? 000000000 ? 000000000 ? 400000110000BEC ? FFFFFFFFFFF33F0 ? 000000000 ? 000000000 ? kkxcog()+01cc bl pcicog() FFFFFFFFFFF3968 ? 70000078BC51048 ? opitca()+0a50 bl kkxcog() 10009697C ? kksFullTypeCheck()+ bl opitca() 11082EDB8 ? 7000008C99BA740 ? 001c rpiswu2()+03c0 bl _ptrgl() kksLoadChild()+31e4 bl rpiswu2() 700000A717262C8 ? 7000008EA0F1970 ? 7000008C99BAA78 ? 107267650 ? 000000000 ? 55D16B348 ? FFFFFFFFFFF72B8 ? 000000000 ? kxsGetRuntimeLock() bl kksLoadChild() 110000328 ? 70000078BC51048 ? +083c 700000A57852278 ? kksfbc()+2230 bl kxsGetRuntimeLock() 110000328 ? 11082EDB8 ? FFFFFFFFFFF72B8 ? 12C00000000 ? 100006300000000 ? kkspsc0()+106c bl kksfbc() 11082EDB8 ? 3FFFF8150 ? 1085D16C170 ? 149510630 ? 000AE3AD5 ? 000000000 ? 000000000 ? 000000000 ? kksParseCursor()+00 bl kkspsc0() 1105B2748 ? 149510630 ? cc 000AE3AD5 ? 31032DD20 ? 600000000 ? A4000000000000 ? 000000000 ? opiosq0()+0b18 bl 103ecdd38 kpooprx()+019c bl 101fadff0 kpoal8()+04c0 bl kpooprx() FFFFFFFFFFFB454 ? 149510630 ? AE3AD400AE3AD4 ? 100000001 ? 000000000 ? A40000000000A4 ? opiodr()+0b48 bl 103ec82b0 ttcpip()+114c bl _ptrgl() opitsk()+169c bl 103eca2bc opiino()+09a0 bl opitsk() 1100981E8 ? 000000000 ? opiodr()+0b48 bl 103ec82b0 opidrv()+0440 bl opiodr() 3C2F736765 ? 41032DD20 ? FFFFFFFFFFFF8C0 ? 05F353137 ? sou2o()+0090 bl opidrv() 3C05C052EC ? 4A0071E60 ? FFFFFFFFFFFF8C0 ? opimai_real()+01b0 bl 101fad8cc main()+0090 bl opimai_real() 000000000 ? 000000000 ? __start()+0070 bl main() 000000000 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
ORA-00600[17059]错误大部分都是因为高版本导致,对于本库的分析:因为该库的shared pool老化比较频繁,到我介入的时候,发现相关该类此sql已经不能找到,不能非常肯定的找出来原因,猜测可能原因是:这个库(版本为11.1.0.6 FOR AIX)因为开发基本上没有绑定参数,设置cursor_sharing=force,这里5万多条的insert会自动转换为参数形式,因为每个insert参数对应的值长度区别较大,使得BIND_MISMATCH不匹配导致高版本现象严重,从而出现了该Bug 9689310.
解决该问题
1.不要通过程序拼接sql出来,使用绑定参数形式
2.升级到相应新版本解决该问题
3.一次减少执行的sql数量,定时刷新shared pool[临时办法]
补充说明相关bug
Bug 5177766 OERI[17059] with SESSION_CACHED_CURSORS
Bug 8946311 Increase max children before reporting ORA-600 [17059]
BUG 9094984 ORA-600 [17059] WITH VERY HIGH CHILD CURSOR COUNTS BEING GENERATED
Bug 8922013 OERI [17059] / excess child cursors for SQL referencing REMOTE objects
Bug 9689310 Excessive child cursors / high VERSION_COUNT / OERI:17059 due to bind mismatch
BUG 8981059 HIGH VERSION COUNT:BIND_MISMATCH,USER_BIND_PEEK_MISMATCH,OPTIMIZER_MODE_MISMATCH