So we hypothesize there could be a case where with Oracle RAC, one node could be mining close to the CURRENT_SCN and might be a situation where we may fetch some records associated with a given SCN, but perhaps due to asynchronous flushes that the LGWR process may not have flushed all redo entries. In this case, we will add a new internal configuration option called log.mining.max.scn.deviation.ms.

Conceptually, this property is meant to be used in conjunction with SCN_TO_TIMESTAMP and TIMESTAMP_TO_SCN functions to calculate an end SCN value for the next mining session that isn't within the specified deviation milliseconds to the CURRENT_SCN. The net effect here implies a static latency value the connector will always operate under.

If the calculation results in an SCN before or equal to the next iteration's start SCN, the mining loop will pause and attempt a recalculation after its sleep period until the calculated SCN is greater than the starting SCN. In addition, if the algorithm fails due to the calculated SCN based on deviation being outside the database's flashback/undo space for any reason, it will fall back to the old behavior, where it will simply use the already resolved start/end range.