Streams in a RAC
Environment
-
In order to improve the performance of
Streams for RAC databases, a Capture process can now capture
changes from the archived redo logs or from the online redo.
This feature allows changes to be captured closer to the time
they were executed, thereby reducing the capture latency. In
other words, the moment database changes are effected and
committed the transactions are available for the Capture process
to extract.
-
When the owner instance for a
queue table containing a queue used by a Capture process or
Apply process fails, queue ownership is transferred
automatically to another instance in the cluster. Then the
Capture process or Apply process is restarted automatically, if
it had been running. In previous releases, the Capture process
or Apply process used to be ABORTED under these circumstances
which would warrant a manual restart. This is an important
improvement from the administrative point of view. Without the
intervention of the DBA, the Streams process will be restarted.
Capture and Apply Processes in a RAC
Instance
Since there are multiple instances in a RAC
database, the database changes can occur at any instance. Such
database changes are recorded in the respective instance’s redo
logs and corresponding archive log files. A Capture process
configured within any instance of the RAC database can scan and
extract the transactional activity from the all the
participating instance’s redo log files and convert them into
LCR events. In this way, even though the Capture process is only
running on one instance, it is aware of all the redo logs of all
the RAC instances and does not miss any transactions.
Each Capture process is started on the
owner instance for its SYS.AnyData queue, even if the start
capture is executed on a different instance. The
dba_queue_tables data dictionary view contains information
about the owner instance for a queue table. Any parallel
execution servers used by a single Capture process run on a
single instance in a RAC environment.
