The following errors are observed when Read stops due to error:
Info 2015-11-24 13:35:18.755221 18666 1 Reader exited with code=1, pid = 18716 (from server_name)
Error 2015-11-24 13:35:16.360060 18716 1 Reader stopped: Internal error encountered; cannot continue (from server_name)
Error 2015-11-24 13:35:16.359376 18716 1 Reader: 11000 - sp_ordr failed: Can't read capture queue (que_SHMERR: Shared memory error) (from server_name) [module ord]
Notice 2015-11-24 13:35:16.359177 18716 1 Reader: bu_gcb got NULL buffer pos = 2972162883584 (from server_name) [module que]
At that time Capture is behind Oracle and has a very large # of messages in it. There are no error messages in the Read log. Restarting Read is not helping so long as Capture is behind Oracle.
When Capture is way behind Oracle, the # of messages as well as backlog will keep increasing till Capture is current with Oracle. All the while Read fails to run and restarting it does not help as it errors out again due to shared memory errors. When Capture is trying to catch up with Oracle, Reader is not getting adequate shared memory. To get around the problem, carry out the following steps:
1. Keep issuing “show capture detail” from source sp_ctrl. This will show the Oracle and Capture current redo log. In our case Oracle’s redo log is ahead of Capture’s:
sp_ctrl>show capture detail
Host: hostname
Operations
Source Status Captured Since
---------- --------------- ---------- ------------------
o.sourceSID Running 653887934 04-Apr-16 10:33:01
Oracle current redo log : 30772
Capture current redo log : 30761
2. Once Capture is caught up, (which will be occur when Capture and Oracle redo log have same values) restart Read. This should most likely resolve the problem and you should not see any more shared memory errors.
As a good preventive measure to avoid these type of issues in a proactive manner, it is advisable to henceforth enable supplemental for Primary Key or Unique Key in the source database. If implemented, then the problem will not occur for new messages as read does not need to go through the pass1 and pass2 and in the process it keeps sending the changes continuously to the target. This prevents buildup of huge # of messages/backlog in Capture queue thereby eliminating the need to address the shared memory available for Read. For details on supplemental logging, please refer to Oracle documentation.
