This is a follow-up to DBZ-4276; On chat, ccranfor@redhat.com said this:

@Gunnar Morling I believe I may have misspoke when we were discussing the placeholder logic when LOB is disabled. After reviewing one of the tests, I realized that the test didn't have coverage for UPDATE and DELETE test cases so I gave an inaccurate representation. So here's the scoop.

CLOB
So handling of these by Oracle is a bit inconsistent. There is this threshold of about 2k bytes where if the CLOB text is smaller than this threshold, Oracle treats it similar to a VARCHAR2 in certain situations and like a CLOB in others.

Updates are tricky in that events are only emitted depending on how the redo entry is interpreted by LogMiner. For example, when LOB is disabled and if the CLOB field is treated like a VARCHAR2, then an event will be emitted and if the CLOB field is changed, it will have the updated value; otherwise it'll be emitted with the placeholder. If the CLOB field is larger than the threshold then it depends entirely on what is being changed that determines what is emitted. If only the CLOB field was modified, no event is emitted because its interpreted as a SELECT_LOB_LOCATOR event and these are excluded when LOB is disabled. If the update modifies the CLOB and another non-CLOB field, then the event will be emitted with the CLOB field using the placeholder.

For deletes, this works like they do when LOB is enabled, the CLOB fields will have the placeholder in the before.

BLOB
I'm still working on these but I suspect that when LOB is disabled, all use cases will likely have the placeholder. I'll confirm shortly. Again like CLOBs, if only a BLOB

I am not 100% sure whether docs reflect that situation; let's double check this and apply the right changes, if needed.