By design, capture currently only supports maximum of 5000 concurrent transactions.
Range of the SP_OCT_MAX_SESSIONS parameter is not set properly (i.e. it's allowed to be set to max value of 65535 transactions instead of max of 5000). In current implementation of capture in maintaining/supporting concurrent open transaction, capture can handle > 5000 concurrent transactions with a couple of limitations.
Any out-of-band LOB data (i.e. huge Varray stored as LOB) can be sent to the wrong session, since the out-of-band LOB is sent in high subqueue (session > 5000) even though the actual session is in low session (<5000). In this case, the result could be OOS or stuck message in post queue.
If there is any DDL transaction that happens to be mapped to session > 5000, capture could core, since the DDL session limit is hard-coded to be 5000 sessions.
Pay attention to the number of concurrent sessions on source database when capture runs into core dump with DDL message.
Resolution:
The best practice is to keep the concurrent sessions less than 5000.
Workaround:
Rename colcache file and cmap file when core dump occurs.
