Capture Process is uses too much memory.
At times the symptoms are slightly different, as the following log wrap errors are seen in event_log followed by a core dump even though the archive logs exist and Capture was earlier able to process previous archive logs without any issues:
Notice 2018-05-16 12:26:00.811000 7948 22096 Capture: Using archive log I:\FLASH_RECOVERY_AREA\PROVDB1\ARCHIVELOG\ARC96442_0800980515.001 (capturing from SID1) [module oct]
Warning 2018-05-16 12:26:08.065000 7948 22096 Capture: A portion of the redo log could not be parsed (capturing from SID1) [module oct]
Error 2018-05-16 12:26:24.508000 7468 10096 Capture killed due to SIGQUIT, core file = e:\Program Files\Quest Software\SharePlex\bin/core.4576 was generated at this time in the SharePlex/bin Directory, pid = 4576 (capturing from SID1)
Notice 2018-05-16 12:26:26.271000 17092 22064 Capture: Replicating according to target compatibility of "7.5.0.0" (capturing from SID1) [module utl]
Info 2018-05-16 12:26:26.287000 17092 22064 Capture launched, pid = 17092 (capturing from SID1)
The latest *ocap* log may show a log parser error with code 1 which is typical of memory issues:
ocap 2018-05-16 12:26:08.065000 7948 22096 Log parser error 1
If that problem archive log is skipped by advancing the SHAREPLEX_ACTID table to point to the next archive log, the error may stop happening for a while until Capture core dumps on another archive log. So the issue does not go away by skipping the archive log.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center