What are the challenges of RAC with Dbvisit Replicate?
The database instances can go up and down
Instances can be added and dropped
The machine running Replicate can go down
Replicate can connect to database that goes down
The concepts are similar for any clusterware involved, examples are provided for Oracle Clusterware 11.2
Unless noted otherwise, the practices are same for MINE, APPLY and optional FETCHER.
Location of Dbvisit Replicate To provide HA for Dbvsit Replicate, run it on a machine configured in a cluster. The simplest way is to run it on the cluster running the database itself.
For MINE, MINE_PLOG directory must be on shared filesystem. If FETCHER is used, then the MINE_STAGING_DIR must be shared as well.
For APPLY, the APPLY_STAGING_DIR must be on shared filesystem.
The dbvrep executable and the DDC locations must be identical on all nodes. If the DDC files are not on
shared storage, they must be copied to each node.
This requirement may be made obsolete in future versions.
The archive logs must be on shared storage (cluster file system or ASM).
Dbvisit Replicate keeps a connection to the source (for MINE and FETCHER) or target (APPLY) database.Console keeps connection to both of them, but only if it is used to change the configuration.
Configure separate TNS identifier for the databases.
For each source node, configure the TNS identifier to connect to the local instance only. If possible, do that for target nodes as well.
This ensures that when Replicate is running on a node, it is connecting to one instance only.This limits its dependencies to current node only. The database load imposed by MINE is very low on source, so no load balancing is needed. APPLY currently executes only one SQL at a time, so the load is also not high – but this will change in the future.
Configure TAF (transparent application failover) for this TNS identifier for the machine running the console (if it is run on one node of the source, configure TAF for the APPLY connection only).
This is optional and it just limits the impact of a node going down on the console.
For each cluster, set up an Application VIP mamaged by the clusterware. Use this address as the name of node when the Replicate process run. This IP will be always assigned to just one node and the Replicate process will follow it in case of node failure.
To create an application VIP, use the following syntax:
Configure the Dbvisit Replication as usual, using the previously connected TNS identifiers for source and target databases and the Applicatio VIPs for location where processes will run (*_LISTEN_INTERFACE settings).
Start the replication (use the nodes where the Application VIPs currently reside) and test that your configuration works.
Create action scripts Create scripts that will manage (start/stop/check/clean/abort) the dbvrep processes. Use the action_script.scr and:
modify the settings at the top of the script (DDC name, process name, paths)
save the script to a directory and make it executable by oracle user; do this on all cluster nodes
An example name of such script would be:
Create resource for Replicate
As oracle, create the cluster resource for the dbvrep process:
Use any name for resource_name, e.g. dbvrepMINE_DDCname like dbvrepMINE_ERP. For action script, use the path to the script created earlier. For start dependencies, use resource name for your database (like ora.orcl.db) and if ASM is used, use ora.asm for ASMresource.
The resource was created with “restore” (the default) AUTO_START setting and thus clusterware will try to start it automatically if it was running last time the cluster was shut down. The resource was created with default placement policy and thus any node will be eligible to host the resource. Use placement=favored/restricted and hosting_members/server_pools to change this. How does this interact with the VIP?
Manage the processes Stop the replication if was started manually.
Do not use “shutdown” from the console; this would cause clusterware to restart the process.
Dbvisit Replicate does not support online addition and dropping of cluster instances, or to be more precise, redo threads. For such operation, Dbvisit Replicate MINE process on such database must be stopped.
Running appvipcfg fails with error:
CRS-0160: The attribute '"USR_ORA_VIP' is not supported in this resource type.
Reason: Oracle bug 9964188.
edit appvipcfg.pl and remote \” in front of USR_ORA_VIP.
See also : patch shown in the bug description at My Oracle Support.