The Number of Objects Replicated listed in the report output for the replication job is the number of objects written to the dump file. That is, the number of objects processed by the dump command.
The dmrepfilter program then processes the dump file (after it is transferred to the replica Docbase) and removes a few items. For example, in the replication report, you will see lines similar to the following.
xxxx objects processed from input file.
yyyy objects written to output file.
zz types written to output file."
Here, xxxx objects were written to the dump file and yyyy were the number of objects after filtering, that is, xxxx-yyyy objects were filtered out. These are written to the dump_filtered file.
However, the number of objects actually loaded is much smaller, but we need a few other objects placed into the dump file that are associated with this object in case they don't exist in the replica Docbase. With a large number of folders, the auxiliary object count can be extremely high.
It is only folders that are dumped regardless of the replication mode. For the other objects under the replication root, they are only written to the dump file under incremental mode if their current version in the source Docbase has not been replicated by this job.
This is verified by checking in the dm_replica_catalog registered table. Then the load code processes the (filtered) dump file and checks the replica Docbase to see whether it already has the version of the object described in the dump file. If so, it just skips the object; it doesn't load everything in the dump file, only the objects it needs.
However, we need all of the folders first in the dump file so that when we load any objects into the replica Docbase we can update their folder paths with the correct folder paths from the replica Docbase. The folders aren't loaded either unless they don't exist in the replica Docbase, but they are loaded into memory into a map type of object/list. |