All of the resource-consuming work of parsing the redo logs, writing the plogs and sending them to apply is done by the mine process.
The fetcher process is optional and is not needed when the mine runs on the primary server. In that case, the database querying and file reading is done directly by mine.
Remote apply replication
The apply process does not need to run directly on the server running the target database, as it uses
network connection 4 to that database.
However, it is advised to run it on the target server, as the network communication overhead decreases the performance of the apply.
Still, it can be useful:
• if the target server has no capacity left to accommodate the apply process.
• if the target server is not running on a supported platform.
There is no special configuration to enable this – just use the apply-running-server when configuring listen/remote interfaces in the wizard, and set up database connectivity there so apply can reach the database.
Triggers
Triggers on target tables of any replication deserve special consideration, and Dbvisit Replicate is no exception. The concern is whether triggers defined on the target tables should fire when data changes are applied to the table. This depends on the logic in the trigger and thus has to be decided by the user.
In general, triggers carried over from source database are not intended to fire, but triggers created on apply should fire. But other criteria can be considered as well, e.g. whether other tables referenced in the trigger are replicated or not.
Dbvisit Replicate support
For Oracle 10.2.0.5 and 11.2.0.2 and later:
•
Dbvisit Replicate honors setting of dbms_ddl.set_trigger_firing_property
5 – use this procedure for
each trigger to set whether it should fire when data change is done by replication.
On every Oracle target, you can check boolean variable DBRSAPPLY_PKG.is_dbreplicate_session to determine whether it's an apply session or not. Using this variable, the trigger can check whether to actually do something or not. This will require code changes in the triggers to enable this.
On every MySQL target, you can check variable @ is_dbreplicate_session (valued 0/1) to find out whether it's an apply session or not.
On every MS SQL target, you can check context_info to find out whether it's an apply session (set to 1) or not.
Variable
APPLY_SET_TRIGGER_FIRE_ONCE
can be used to disable or further control this functionality.
Oracle Client and configuration files
For ASM, Dbvisit Replicate uses bequeath connection and thus has to use the ASM home for as the client, setting ORACLE_HOME accordingly (setup wizards thus asks for this ORACLE_HOME when ASM is in use).
For all other Oracle connections, Dbvisit Replicate uses SQL*Net connections. As it comes with it's own
Oracle client, it has to be told where to look for sqlnet.ora/tnsnames.ora files. Setup wizard thus asks for
TNS_ADMIN.
4 SQL*Net for Oracle, client-server for MySQL, ODBC for MS MSQL.
5
According to Oracle documentation, the default is TRUE, i.e. fire only once.
Dbvisit Replicate Installation Guide and User Manual © Dbvisit Software Limited.
Except as specifically set out the Dbvisit license agreement, nothing in this Documentation constitutes a warranty as to the operation of the Dbvisit software.
page 45
