Oracle library_cache advice功能触发的ORA-600
适用范围
Oracle Database 11g
问题概述
数据库日志中报ORA-00600: internal error code, arguments: [kglsim_pinhp1]，这是是一个典型的与共享池（Shared Pool）和库缓存模拟器（Library Cache Simulator）相关的内部异常.
问题原因
library cache advice statistics simulator，共享池（Shared Pool）和库缓存模拟器（Library Cache Simulator）相关的内部异常。
解决方案
1、临时关闭库缓存的 advice 功能
SQL>ALTER SYSTEM SET “_library_cache_advice” = FALSE SCOPE=spfile sid=’*’;并重启数据库，修改参数前做好参数文件备份。
说明：关闭此参数仅会导致缺失Shared Pool Advice 的预估数据区，在shared pool不⾜的情况下会⾃动调整shared pool的⼤⼩，也就是缺少⼀个预估的过程。
2、固定share pool大小
如果系统物理内存和SGA充足且业务模型相对固定，建议关闭 ASMM 的动态调整，为 Shared Pool、Buffer Cache 设置固定的合理下限（即 SHARED_POOL_SIZE 和 DB_CACHE_SIZE 等于 SGA_TARGET 的合理分配比例），这能规避大量由于内存动态收缩导致的内部 Bug。
3、升级到19c
由于11g扩展支持（Extended Support）早已结束，从长远考虑建议将数据库升级到19c并应用次新补丁。
ORA-00600: internal error code, arguments: [kglsim_pinhp1]说明：
kglsim_pinhp1
1）kgl 代表 Kernel Generic Library（即 Library Cache，库缓存）。
2）sim 代表 Simulator（模拟器），主要用于支撑 V$LIBRARY_CACHE_ADVICE。它通过在专门的 Hash 表中记录被淘汰出内存的对象数据，来估算增加共享池大小能够带来的预期性能。
3）pinhp1 = Pin Heap 1，说明在尝试固定（Pin）模拟器的内存堆时发生了问题。
分析过程
1、trc分析
*** 2026-08-18 19:25:31.947
*** SESSION ID:(567.30691) 2026-08-18 19:25:31.947
*** CLIENT ID:() 2026-08-18 19:25:31.947
*** SERVICE NAME:(XFSVC) 2026-08-18 19:25:31.947
*** MODULE NAME:(JDBC Thin Client) 2026-08-18 19:25:31.947
*** ACTION NAME:() 2026-08-18 19:25:31.947
Dump continued from file: /u01/app/oracle/diag/rdbms/xfdb/xfdb1/trace/xfdb1_ora_33233651.trc
ORA-00600: internal error code, arguments: [kglsim_pinhp1], [0x7000102E2464C78], [], [], [], [], [], [], [], [], [], []
========= Dump for incident 91897 (ORA 600 [kglsim_pinhp1]) ========
*** 2026-08-18 19:25:31.955
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 0000000109B55A84 000000000 ? 000000001 ?
000000003 ? 000000000 ?
000000000 ? 000000001 ?
000000003 ? 000000000 ?
ksedst1()+112 call skdstdst() 18CBB433D8BD2FAE ?
4845284100000000 ?
FFFFFFFFFFF0360 ?
2FC01E47C7686 ? 10A8255F4 ?
000000000 ? 1107290E0 ?
2050033FFFF0368 ?
ksedst()+40 call ksedst1() 700010350D0AF28 ?
700010307324AC8 ?
7000102D559D4C8 ?
70001030781E848 ? 000000000 ?
000000000 ? 000002004 ?
000000001 ?
dbkedDefDump()+1516 call ksedst() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 300000003 ?
ksedmp()+72 call dbkedDefDump() 3107290E0 ? 110000390 ?
FFFFFFFFFFF0B70 ? 1106ABCF8 ?
100125678 ? 1109C3BC0 ?
10011B0E8 ? 1106ABCF8 ?
ksfdmp()+100 call ksedmp() 000000002 ? 000000000 ?
000000002 ? 10AAF0518 ?
10A085E30 ? 000000000 ?
1108E9688 ? 1107290E0 ?
dbgexPhaseII()+1904 call ksfdmp() 700010350D0AF28 ?
700010307324AC8 ? 000000002 ?
000000000 ? 000000002 ?
10A085E28 ? 000000000 ?
001050005 ?
dbgexProcessError() call dbgexPhaseII() 1107290E0 ? 11072B138 ?
+1556 0000166F9 ? 200000000 ?
FFFFFFFFFFF1A88 ? 000000078 ?
1109CD6B0 ? 1109CBF58 ?
dbgeExecuteForError call dbgexProcessError() 1107290E0 ? 1108E9688 ?
()+72 100000000 ? 000000000 ?
FFFFFFFFFFF4F48 ?
FFFFFFFFFFF4E10 ?
FFFFFFFFFFF5310 ? 1108EB3D0 ?
dbgePostErrorKGE()+ call dbgeExecuteForError 1106ABCF8 ? 00000FFFF ?
2044 () FFFFFFFFFFFA960 ? 1106DEF38 ?
00000001A ? 000000000 ?
000000001 ? 000000000 ?
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 7000102D559D4C8 ?
68 70001030781E848 ?
25807324B20 ? 109E8E370 ?
000000000 ? 000000000 ?
FFFFFFFFFFF5DB0 ? 110980040 ?
kgeadse()+380 call dbkePostKGE_kgsf() 000000000 ?
7FFFFFF7256C6C75 ?
001020000 ? 109FB6D98 ?
70001034D13C5C0 ? 109E8E370 ?
000000000 ? 1100003C8 ?
kgerinv_internal()+ call kgeadse() 256C6C7500D0CE10 ?
48 256C6C7500FF6190 ?
256C6C7500FF5D50 ?
3544532000000000 ?
256C6C7500FF5DE0 ?
256C6C7500000000 ?
FFFFFFFFFFF5C98 ?
7000103363C2478 ?
kgerinv()+48 call kgerinv_internal() 256C6C7500000001 ?
000000000 ? FFFFFFFFFFF5CD0 ?
3538353837313434 ?
38003531000001 ? 110000390 ?
3000333239323436 ?
353600FFFFFF5C70 ?
kgesinv()+32 call kgerinv() 000000011 ? 000000AA0 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
109FB2A90 ? 000000003 ?
kgesin()+52 call kgesinv() 000000001 ? 700010338642D90 ?
70001030F970E28 ? 000000000 ?
000000001 ? FFFFFFFFFFF6FA0 ?
7000102E2464C78 ? 1100003C8 ?
kglsim_pin_simhp()+ call kgesin() FFFFFFFFFFF5E70 ?
292 7000103363D38C0 ? 000002960 ?
100000001 ? 000000002 ?
7000102E2464C78 ?
F1000A01C2244400 ?
000000000 ?
kglhpn()+112 call kglsim_pin_simhp() 04FE9CEDA ? 0051C3686 ?
100112CE0 ? 110A78F88 ?
FFFFFFFFFFF5F60 ?
700010338642D90 ?
70001030F970E28 ? 000000000 ?
kglobpn()+296 call kglhpn() FFFFFFFFFFF6648 ?
FFFFFFFFFFF5EB0 ?
FFFFFFFFFFF63D0 ? 1106ABCF8 ?
100F82F40 ? FFFFFFFFFFFA960 ?
FFFFFFFFFFF5F40 ? 00000001A ?
kglpim()+972 call kglobpn() 1100003C8 ? 000000001 ?
70001030F970F68 ?
700010307324AC8 ?
FFFFFFFFFFF60D0 ? 1106ABCF8 ?
100F92BF8 ? 1106ABCF8 ?
IPRA.$kglpin()+1292 call kglpim() 1100003C8 ? FFFFFFFFFFF6FA0 ?
7000102D5EBE1F8 ? 1109CF000 ?
1109CE3B0 ? 1106ABCF8 ?
000000000 ? FFFFFFFFFFF6550 ?
kglpin()+96 call IPRA.$kglpin() 1100003C8 ? FFFFFFFFFFF6FA0 ?
70001030F9EAF60 ?
70001030F970E28 ? 200000006 ?
000000067 ? FFFFFFFFFFF6EF0 ?
FFFFFFFFFFF6DF0 ?
kkspsc0()+3200 call kglpin() 1100003C8 ? FFFFFFFFFFF6FA0 ?
100000000 ? 300000000 ?
FFFFFFFFFFF6EA0 ? 000000000 ?
000000000 ? 000000000 ?
kksParseCursor()+11 call kkspsc0() 1109A1E48 ? FFFFFFFFFFFA598 ?
6 000000067 ? 300000000 ?
600255D70 ? A40001106ABCF8 ?
000000000 ? 000000055 ?
opiosq0()+2072 call kksParseCursor() 1001178C0 ? 70001030FA3E1F0 ?
1100003C8 ? 1100003C8 ?
000000001 ? 1109B3588 ?
000000000 ?
2216414400000000 ?
kpooprx()+316 call opiosq0() 3FFFF7F90 ? 1106ABCF8 ?
000000000 ? A4000000000000 ?
000000000 ?
4442434A00007F10 ?
2715005700000000 ?
10AD8E30C ?
kpoal8()+884 call kpooprx() 000000000 ? 70001034ED386E0 ?
110A8D278 ? 100000001 ?
000000000 ? A40000000000A4 ?
000000001 ? 109E8B9D0 ?
opiodr()+908 call kpoal8() 100000000 ? 200000000 ?
000000000 ? 000000000 ?
FFFFFFFFFFF8DE0 ? 000000000 ?
000000000 ? 000000000 ?
ttcpip()+1028 call opiodr() 5EFFFFA350 ? 1C000004B0 ?
FFFFFFFFFFFA8C8 ? 000530058 ?
100000000 ? 000000028 ?
FFFFFFFFFFFA270 ? 1108B0650 ?
opitsk()+1612 call ttcpip() 110134BE0 ? 1107346A8 ?
FFFFFFFFFFFA820 ?
4222842400000000 ?
1000EFD54 ? 1106ABCF8 ?
FFFFFFFFFFFA8F0 ? 1106ABCF8 ?
opiino()+940 call opitsk() 1100242A8 ? 000000000 ?
11078CE50 ? 110792150 ?
1107290E0 ? FFFFFFFFFFFC9B0 ?
FFFFFFFFFFFEA0C ? 000000101 ?
opiodr()+908 call opiino() 3C006C921C ?
BFF0000000000000 ?
FFFFFFFFFFFEE30 ?
FFFFFFFFFFFD4B9 ?
FFFFFFFFFFFD500 ? 1106ABCF8 ?
FFFFFFFFFFFD520 ?
9FFFFFFF000E3D8 ?
opidrv()+1132 call opiodr() 3CFFFFEA60 ? 400000000 ?
FFFFFFFFFFFEE30 ? 06F726163 ?
6C652F6170702F6F ?
1106ABCF8 ?
61672F7264626D73 ?
2F776664622F5746 ?
sou2o()+136 call opidrv() 3C067EA570 ? 413F1009D ?
FFFFFFFFFFFEE30 ?
1A002D02120000 ? 0E0DDF00D ?
1106ABCF8 ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
opimai_real()+560 call sou2o() FFFFFFFFFFFEEA0 ?
BADC0FFEE0DDF00D ?
90000000009BB90 ?
BADC0FFEE0DDF00D ?
000000002 ? 9001000A0293EE8 ?
A0000000A000000 ? 10B6C1870 ?
ssthrdmain()+276 call opimai_real() 10B7023C4 ? 9001000A02980D8 ?
FFFFFFFFFFFEF80 ?
302284340B701BE8 ?
FFFFFFFFFFFEFA0 ?
FFFFFFFFFFFF2F8 ?
9000000000921EC ?
9001000A0293EE8 ?
main()+204 call ssthrdmain() 240000000 ? FFFFFFFFFFFF2E8 ?
8FFFFFFF0000090 ? 000000000 ?
000000000 ? 000000000 ?
BADC0FFEE0DDF00D ?
BADC0FFEE0DDF00D ?
__start()+112 call main() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------trc中报ORA-00600: internal error code, arguments: [kglsim_pinhp1]，
2、检查SGA中share pool使用情况
SQL>SELECT component, oper_type, oper_mode, initial_size, target_size, end_time
FROM v$sga_resize_ops
WHERE component = 'shared pool'
ORDER BY end_time DESC;检查近期或报ORA-600时段，share pool是否频繁发生抖动。除了使用上面的SQL查询也可以收集AWR报告进行分析。
3、检查 KGL Simulator 内存占用
SQL>SELECT * FROM v$sgastat
WHERE lower(name) LIKE '%sim%' AND pool = 'shared pool';【小结】由于该报错涉及 kglsim 组件，如果报错比较频繁，最有效且对业务影响最小的解决方案是禁用库缓存模拟器library cache advice statistics simulator，这会停止收集 Advice 数据，关闭此参数仅会导致缺失Shared Pool Advice 的预估数据区，在shared pool不⾜的情况下会⾃动调整shared pool的⼤⼩，也就是缺少⼀个预估的过程；既然关闭了_library_cache_advice 会导致缺乏共享池不足的预估，就需要加强监控以防止出现 ORA-0403报错;也可以手工管理share pool，给share pool固定大小。由于11g扩展支持（Extended Support）早已结束，从长远考虑建议将数据库升级到19c并应用次新补丁。
笔者文章集合详见：
https://www.myhfxf.com
https://www.xiaofeihuangfu.com
CSDN:https://blog.csdn.net/xfhuangfu
ITPUB:https://blog.itpub.net/28373936/
微信公众号：xfhuangfu