Although the Shareplex Admin Guide does cover this in some depth, there have been problems encountered with the use of compound routing map for handling multiple targets that are worth covering vide a solution since they are not documented elsewhere.
N.A.
There are two ways in which one can handle replication to multiple targets through one source. The simplest approach is to combine the route for all targets in one line if the source table is replicated to all targets and the source and target schema are identical. This requires least amount of typing. Shareplex Admin Guide Chapter 4, section titled "Configuration for replicating to multiple target systems" covers this. Here is the excerpt:
"When target objects for a source object have identical owners and names on two or
more target systems, you can use a compound routing map in the configuration entry for
those objects. You start with a basic configuration line, but instead of using a separate
line for each target system, you specify them all in one routing map."
Here is a sample entry for config file as taken from from that section in Admin Guide:
scott.emp scott.emp sysB@o.oraB + sysC@o.oraC + sysD@o.oraD
It is assumed that the source and target table names are identical and that the targets involved are sysB, sysC and sysD with SID names as given in the entry. This approach would create a single Export queue on source, with name identical to the source server.
The other approach is to either separate the entries for the source/target table pair for each target by having a separate line for each route. This would create a named Export queue by default for each target with a naming convention governed by Shareplex rules. Here is the corresponding change to the config file:
scott.emp scott.emp sysB@o.oraB
scott.emp scott.emp sysC@o.oraC
scott.emp scott.emp sysD@o.oraD
Another manifestation of this approach is to create named Export queues by specifying your own Export queue names. (see Admin Guide Chapter 4 section titled "Configuration for isolating data using named export Queues" for more details.
Additional Information:
Here are some advantages of using named Export queues (Please see the Shareplex Admin Guide for more details):
When running Shareplex replicating to multiple targets with single Export queue, there may be problems when:
a. Queue corruption occurring due to network glitch between source and one target will put all data at risk even though the problem has to do with one target.
b. A wrong target name is specified whereby one Export process does not send any data to target and consequently the number of messages in the single Export queue do not get readreleased.
c. Removing one target from replication will require the Reader to the Export queue (another name for the Export process) going to that target to be removed before the # of messages in the Export queue get readreleased.
The following excerpt from Admin Guide explains some other advantages of using named Export queue:
"You can purge or abort one configuration without affecting the others, and you can stop Export or Import for one datasource while allowing other Export and Import processes to continue.
Named export queues can be used to separate data destined for different target systems.
You can create a named export queue for each target so that you can stop Export for
each one separately.
Because each Export process creates an Import process on the target system, named post
queues with their own Post processes are generated. This is effective for isolating tables
with large operations or LOB datatypes. For more information about named post
queues, see page 153.
You can set SharePlex parameters for processes associated with named queues on an
individual basis, enabling you to tune performance based on the objects replicating
through each one. For more information about setting process-specific parameters, see
the SharePlex Reference Manual."
Please see Solution 22568 to see how to add named export queues to a current replicated environment.
