beatrizia wrote:In short, no. But I'm not sure what the goal is... GoldenGate more or less handles this automatically already; the record size can be larger than 4K in some cases (which creates certain limitations, e.g,. w/ RmtTask -- in which case, just don't use RmtTask and instead use a normal extract with RmtFile + MaxFiles 99999).
Does anyone know if the trail record size can be changed from its default value of 4K?
What about how long the data pump process delays before searching for more data to proccess in its source trail while it waits for the end of a uncommitted transaction (which is 1 second)?See EofDelay or EofDelayCSecs option (or EofDelayMS for RAC). In low volume replication, this setting can be used to either increase the delay between checks for more data in the redo logs to reduce I/O on the DB, or it can be used to decrease latency by checking more frequently (at the expense of hitting the disk more frequently). For data pumps (i.e., extract reading trails, vs. extract reading DB redo logs), I don't think you can set it less than a second, though. Check the docs in your specific release of GG, as this default has changed across versions to be optimal for most people. The default for the DB redo as the source is different than the default for a trail file source. (I think the default is 250ms in GG 11.2 for RAC.)