Page Comparison

The mine MINE processes imposes a certain load on the source database when parsing the redo logs (CPU and memory). This maybe around 5% and may not be desirable in certain environments. This is when the Fetcher process is very useful. It runs on the source database, reading the redo logs and sending them to mine MINE process, which is running on a different machine.
The only operations the fetcher process does are:

• queries the source database for the location of the redo logs.
• repeatedly queries the database to find out when the current log is switched.
• in case of ASM files, connects to ASM instance and reads the logs using internal PL/SQL API.
• in case of filesystem files, reads the files from disk using standard system I/O.
• connects to mine MINE over the network and transfers the redo log files to the mine MINE process.
• listens for user commands.

All of the resource-consuming work of parsing the redo logs, writing the plogs PLOGS and sending them to apply APPLY is done by the mine MINE process.
The fetcher process is optional and is not needed when the mine MINE runs on the primary server. In that case, the database querying and file reading is done directly by mineMINE.

Keep the TNS_ADMIN unchanged. Here, It is pointing to TNS_ADMIN location on windows but as Fetcher process runs on Linux, this values must be changed later before starting Mine MINE process.

As indicated by the Nextsteps.txt , the replication can be started by following the steps that are listed above. 
Starting the replication does the following:

• Starts the FETCHER, MINE and APPLY process in the background
• Creates the necessary log and plog PLOG directories.
• Once the APPLY and MINE process has been started, there is in INITIALIZATION process. This replicates the contents of the Dbvisit Replication repository from the source to the target database. The replication can not be started until this phase has been completed.