Increasing readAheadBlocks can increase memory usage because the source endpoint may prefetch more blocks into memory for faster processing. With Oracle, a higher setting can therefore increase the amount of data held in buffers, especially when multiple tasks or connections are active at the same time. It’s usually better to increase it gradually while monitoring Oracle memory and workload rather than assuming a larger value will always improve performance. Visit here for more information.
The readAheadBlocks parameter controls how much Oracle redo data Qlik Replicate reads in each operation. The default is 100,000 blocks (~50 MB). Increasing it to 200,000–300,000 allows Replicate to read larger chunks and may help reduce CDC latency.
However, higher values can increase:
Network bandwidth usage, especially with multiple parallel tasks.
Source-side contention, as multiple tasks may read larger chunks from the same redo logs.
For example, increasing readAheadBlocks to 200,000 has helped reduce latency in some environments. However, the value should be balanced against available network and source database resources.
To clarify: the memory increase is on the Qlik Replicate server side, not the Oracle source machine.
readAheadBlocks controls how many blocks Replicate reads from the redo logs in one operation. That larger chunk of redo data is buffered in Replicate's own process memory for parsing. The Oracle server sees higher I/O and network transfer for the bigger read requests, but it is not the one allocating additional memory to hold the prefetched blocks.
So: bigger readAheadBlocks → more Qlik Replicate server RAM used. Source Oracle memory usage should remain largely unaffected, though you may observe brief spikes in source I/O as it fulfills the larger read requests.
