Various Memory Corruption Related Errors Involving "kccdef" Memory When Executing DML on a Table With Virtual Columns - ORA-600 [17147] / ORA-600 [17148] / ORA-600 [17114] / ORA-600 [kghfrmrg:nxt]
(Doc ID 2772150.1)
Last updated on JULY 20, 2024
Applies to:
Oracle Database - Enterprise Edition - Version 12.2.0.1 and laterInformation in this document applies to any platform.
Symptoms
Various internal errors are noted in the alert log, including one or more of the following but not limited to:
ORA-00600 [17114]
ORA-00600 [17126]
ORA-00600 [17128]
ORA-00600 [17147]
ORA-00600 [17148]
ORA-00600 [510]
ORA-00600 [526]
ORA-00600 [kghfrmrg:nxt]
ORA-00600 [KGHFRE3]
ORA-00600 [kkqcscpopnWithMap: 0]
ORA-00600 [kghfrmrg:pchk]
ORA-00600 [kdlferror597: unknown status]
Call stacks for the errors vary, but the incident traces show frequent references to "kccdef"-related memory, e.g.
...
EXTENT 35 addr=0x1a6cdf390
Chunk 1a6cdf3a0 sz= 56 freeable "KGHSC_ALLOC_BUF"
Chunk 1a6cdf3d8 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf400 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf428 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf450 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf478 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf4a0 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdf5a8 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf5d0 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf5f8 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdf700 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf728 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf750 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdf858 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf880 sz= 40 freeable "kccvcbc : qkxrM"
Chunk 1a6cdf8a8 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdf9b0 sz= 40 freeable "kccdef*[]: qkxr"
Chunk 1a6cdf9d8 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdfae0 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdfbe8 sz= 264 freeable "kccdef: qkxrMem"
Chunk 1a6cdfcf0 sz= 1144 BAD MAGIC NUMBER IN NEXT CHUNK (7FADCCC70FA8)
freeable "kccdef pointers"
The SQL that created this memory can be determined by querying v$sqlarea using the memory tag hash value. In the above example, the SQL that the "SQLA^280e4f8e" memory heap was created to support has a SQL hash value of "280e4f8e". Assuming that this SQL is currently in the library cache, you can find out the SQL that created the memory as follows:
This should return the DML that is modifying the problem table.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |
| References |