Monthly Archives: July 2026

On DB 19.31, ORA-600 [kaf lob buffer overwrite]   Recently updated !

This entry was posted in bug Oracle on by

After Oracle support did not accepted that there is bug with huge LOB segments and High IO due space manager KTSJ, this time it worked faster.

The move of the Table and LOB to a new Tablespace went ok, but soon we started seeing ORA-600 [kaf lob buffer overwrite] on the alertlog. These happened either from the application or also from DBMS_STATS daily process.

The culprit seems to be to parallel access to the segment. First I noticed the table had degree 4. After setting it back to 1, there were no more problems from the application, but only from DBMS_STATS – which is configured to run parallel. However setting it to run without parallel, does not help.

After sending all logs and a 10046 trace to Oracle, an automatic answer come:

Oracle has matched the symptom ‘ORA-600 [kaf lob buffer overwrite]’ from trace file xxxxx_p000_459134_i152080.trc in SR for version 19.31.0.0.0 to BUG 39180642 with a high level of confidence.

BUG 39180642 (unpublished) is still under investigation by Oracle Development. Update this SR if you wish to be kept informed of the progress of the investigation.

The error seems similar to: “KB348966 – Automatic Stats collection Task failing with ORA-20011: Approximate NDV failed: ORA-00600: internal error code, arguments: [kafger buffer overwrite]”, where the issue is some kind of corruption or invalid data.

Let’s see what Oracle says.

High IO due space manager (W00x process) doing db sequential read all the time – KTSJ Slave bug?

This entry was posted in bug Oracle Oracle 19c on by

On a client DB, after migrating it to OL8, the application started to complaint the DB seems slower. Checking the OEM, there is not much done by the application, but I see a good blue stripe from W00x processes doing sequential reads. Nonstop. This is a 19.31 single-instance database.

After tracing these sessions, they are reading two distinct LOB segments, each between 500 and 700GB, where a lot of deletes happened. All the time “db file sequential read”, up to 3 or 4 W00x parallel processes.

WAIT #0: nam='db file sequential read' ela= 199 file#=476 block#=2460662 blocks=1 obj#=53176 tim=1024371028390

I open an SR with Oracle. They ask more traces and session short stack. The short_stack looks like:

SQL> oradebug setospid 15297
Oracle pid: 28, Unix process pid: 15297, image: oracle@srv0nnnn.xxx.ch (W000)
SQL> oradebug unlimit
Statement processed.
SQL>  oradebug short_stack

ksedsts()+426<-ksdxfstk()+63<-ksdxcb()+872<-sspuser()+236<-__sighandler()<-semtimedop()+14<-sskgpwwait()+245<-skgpwwait()+187<-ksliwat()+2296<-kslwaitctx()+188<-ktsj_slave_main()+944<-ksvrdp_int()+1906<-opirip()+579<-opidrv()+581<-sou2o()+165<-opimai_real()+173<-ssthrdmain()+417<-main()+256<-__libc_start_main()+229<-_start()+46

No underscore parameters are set and changing “_enable_space_preallocation” to 0 has no immediate effect.

The tablespace is composed of several smallfiles, EXTENT_MANAGEMENT=LOCAL, ALLOCATION_TYPE=SYSTEM, SEGMENT_SPACE_MANAGEMENT=AUTO. All standard.

The LOB segment is securefile, configured in-row, with several larger values which go out of row.

I ask several times to Oracle: what triggers the KTSJ Slaves processes to fully read huge LOB segments? I do not get a satisfactory answer.

We do not have this problem with all other LOB segments of the DB. The workaround at the end was to defragment the LOBs, moving them to a new tablespace (which we wanted to do anyway). The LOB segment reduced from >500GB to 75G and the Space Manager processes disappeared completely. This lead to the next problem (next post).

I leave this post here just in case someone encounters the same.