Capture is not processing any changes when earlier the system clock was incorrectly set an hour ahead even though the clock was subsequently reset back to the correct time. (4331062)

Capture is not processing any changes when earlier the system clock was incorrectly set an hour ahead even though the clock was subsequently reset back to the correct time.

During a source server crash and subsequent starting of source server, system clock was inadvertently set an hour ahead of the prevailing time. After realizing the mistake, the clock was reset back to the correct time. After this the SharePlex was showing Capture state as "processing" but in reality it was not processing anything.  As you will note from the output below, the system time (19:41:06) was behind the timestamp of the last redo record processed (20:06:48) due to the clock set wrongly earlier:

sp_ctrl> show capture detail

Host: hostname        System time: 20-Nov-17 19:41:06

                           Operations

Source     Status            Captured Since

---------- --------------- ---------- ------------------

o.YES      Running               1551 20-Nov-17 19:16:04

   Oracle current redo log          : 100509

   Capture current redo log         : 100503

   Capture log offset               : 3761499152

   Last redo record processed:

        Operation on "OWNER"."TABLE_NAME" at 11/20/17 20:06:48

   Capture state                    : Processing

   Activation id                    : 36

   Error count                      : 0

   Operations captured              : 1551

   Transactions captured            : 322

   Concurrent sessions              : 1

   HWM concurrent sessions          : 4

   Checkpoints performed            : 0

   Total operations processed       : 1794

   Total transactions completed     : 329

   Total Kbytes read                : 0

   Redo records in progress         : 281

   Redo records processed           : 36544

   Redo records ignored             : 34699

   Redo records - last HRID         : ABB49CAArAAF434AAu

The system time is wrongly set behind the current time which causes Capture to pause till the system time is equal to or ahead of the timestamp of the last redo record. 

To resolve the problem, carry out one of the following steps:

A.     Let SharePlex run (even though it is not processing anything yet) and once the system time is equal to or higher than the timestamp of the last redo record processed (20:06:48), Capture will advance forward.

B.     On source sp_ctrl set SP_OCT_REDOLOG_ENSURE to 0 from its default of 2 and then bounce Capture as below:

sp_ctrl>set param SP_OCT_REDOLOG_ENSURE 0

sp_ctrl>stop capture  (make sure it is “stopped by user” and not “stopping”)

sp_ctrl>start capture

Once the system time and the time of the last redo record processed matches, then unset the above parameter (or set it to its previous value if it was a non-default value) by:

sp_ctrl>reset param SP_OCT_REDOLOG_ENSURE

sp_ctrl>stop capture   (make sure it is “stopped by user” and not “stopping”)

sp_ctrl>start capture

When SharePlex starts, capture inherits the system time and compares it with the database transaction time before processing. The SharePlex parameter SP_OCT_REDOLOG_ENSURE which by default is enabled (set to 2) ensures that the capture process never gets ahead of Oracle by ensuring that capture is always 2 seconds behind oracle. If the parameter is set to 0, then Capture process will not check for the timestamp of the redo log record and will start processing immediately, thus reading ahead of Oracle.