Capture and Apply Processes in a RAC
Instance
That is the reason that when the Non-RAC
instance, DNYTST10, receives or propagates the captured events,
it needs to use the instance specific database link to DNYDBA2A.
Whenever the owner instance for a queue
table containing a destination queue becomes unavailable, the
queue ownership is transferred automatically to another instance
in the cluster.
Since the queue is migrated to a new
instance, the database link will need to be recreated. For the
propagations that were configured with the failed instance as
the destination, the database link should be dropped and then
recreated using the same global name. During recreation, the
link will be pointed to the new instance that now owns the
queue. Scripts that drop and re-create all necessary database
links can be created and then run at the sites that are
attempting to propagate to the failed instance. The propagation
details do not need to be modified since the name of the
database link is not being changed.
Next, the failover process with in the RAC
environment will be illustrated with an example. Information on
the effect of the failover process on the Streams related
components will be presented.
As seen in Figure 9.2, the DNYTST10
database propagates and receives replication changes from the
RAC database, DNYDBA20. The RAC database has two instances:
DNYDBA2A and DNYDBA2B.
The DNYTST10 instance will have a database
link to the RAC database named DNYDBA20, which corresponds to
the database name. Assuming that the initial queue is on the
DNYDBA2A instance, it will use the TNS entry that points to
DNYDBA2A instance as shown below:
