Problem: DA server runs out of memory space and exhibits performance issues.
Possible cause one: During a comparison, DA server receives row data from DA agents at different rates, so at any given time, the server may be buffering tens or hundreds of rows for each source or target. If individual rows are large (user-database-table-dependent) and the number of comparisons is sufficiently high (configured by the user), this buffering might cause DA server to run out of memory.
Solution: Set comparer_max_concurrent_threads to a lower value.
Possible cause two: The configuration parameter lob_fetch_size is set to a high value.
Solution: Set lob_fetch_size to a lower value.
Possible cause three: The external sort option uses a large amount of memory. By default, the external sort keeps thousand of rows in memory. While this is not usually a problem, it depends on the size of each row and the simultaneous activity occurring within the same Java Virtual Machine (JVM). For instance, if there are five concurrent comparisons using the DA agent, the memory requirement increases fivefold. Or if the “localagent” is being used, the source and target agents, and the compare function are sharing the same JVM memory allocation.
Solution: Decrease the number of rows the DA agent stores in the memory by changing the external_sort_max_size configuration parameter value.
Global solution: For all the three possible causes for out of memory issues, configure DA server to start with more memory. By default, the JVM where the DA server runs uses 512 MB. Increase the value (dependent on the platform and the amount of system memory available) by editing the RUN_<instance>.bat file to change the value.