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
...
| Note |
|---|
Unless noted otherwise, the practices are same for MINE, APPLY and optional fetcherFETCHER. |
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 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 fetcherFETCHER) or target (APPLY) database.Console keeps connection to both of them, but only if it is used to change the configuration.
...
| Info | ||
|---|---|---|
| ||
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 optinal optional and it just limits the impact of a node going down on the console.
...
Create resource for Replicate
As oracle, create the cluster resource for the dbvrep process:
...