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 mineMINE, apply 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.
Shared files
- For mineMINE, MINE_PLOG directory must be on shared filesystem. If fetcher FETCHER is used, then the MINE_STAGING_DIR must be shared as well.
- For applyAPPLY, 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 MINE and fetcherFETCHER) or target (applyAPPLY) database.Console keeps connection to both of them, but only if it is used to change the configuration.
...
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 MINE is very low on source, so no load balancing is needed. Apply APPLY currently executes only one SQL at a time, so the load is also not high – but this will change in the future.
| 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 APPLY connection only). |
This is optinal optional and it just limits the impact of a node going down on the console.
...
To create an application VIP, use the following syntax:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
appvipcfg create -network=network_number -ip=ip_address -vipname=vip_name-user=user_name [-group=group_name] [-failback=0 | 1]
Where
...
network_number
...
is
...
the
...
number
...
of
...
the
...
network,
...
ip_address
...
is
...
the
...
IP
...
address,
...
vip_name
...
is
...
the
...
nameof
...
the
...
VIP
...
(we
...
use
...
dbvrepVIP
...
further
...
on),
...
user_name
...
is
...
root
...
(as
...
root
...
privileges
...
are
...
needed
...
to
...
reconfigure
...
network
...
interfaces).
The
...
default
...
value
...
of
...
the
...
-failback
...
option
...
is
...
0.
...
If
...
you
...
set
...
the
...
option
...
to
...
1,
...
then the
...
VIP
...
(and
...
therefore
...
Replicate
...
as
...
well)
...
fails
...
back
...
to
...
the
...
original node when
...
it
...
becomes
...
available
...
again.
As root, allow the Oracle Grid infrastructure software owner (e.g. oracle) to run the script to start the VIP.
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
crsctl setperm resource dbvrepVIP -u user:oracle:r-x
To check the status, run:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
crsctl status res dbvrepVIP -p
As oracle user, start the VIP.
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
crsctl start resource dbvrepVIP
Configure and test
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).
...
An example name of such script would be:
| No Format |
|---|
/home/oracle/REP/action_script_MINE.scr |
Create resource for Replicate
As oracle, create the cluster resource for the dbvrep process:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
crsctl add resource resource_name -type cluster_resource -attr"ACTION_SCRIPT=resource_action_script.scr, CHECK_INTERVAL=30,
START_DEPENDENCIES='hard(dbvrepVIP,dbresource,ASMresource) pullup(dbvrepVIP)',
STOP_DEPENDENCIES='hard(dbvrepVIP)'"
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.
...
Manage the processes
Stop the replication if was started manually.
To manage the replication processes, use:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
crsctl start resource resource_namecrsctl stop resource resource_name
| No Format |
|---|
crsctl relocate resource resource_name -n nodename -f -- -f will |
Will relocate
...
the
...
VIP
...
as
...
well.
| Note |
|---|
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 MINE process on such database must be stopped.
...
Running appvipcfg fails with error:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
CRS-0160: The attribute '"USR_ORA_VIP' is not supported in this resource type.Reason:
...
Oracle
...
bug
...
9964188.
Workaround:
...
edit
...
appvipcfg.pl
...
and
...
remote
...
\”
...
in
...
front
...
of
...
USR_ORA_VIP.
See also : patch shown in the bug description at My Orale Oracle Support.