Streams Setup from RAC to Single instance

Question

Does anyone have a document to setup streams from RAC to Non RAC. I successfully setup streams on 2 single instances but I am having issues in replicating, Streams is setup on node1 or Rac and Apply process is also setup on single node. but data is not replicating.
Appreciate any suggestions.

Answer 1

From Metalink Note 418755.1:
Additional Configuration for RAC Environments for a Source Database Archive Logs
The archive log threads from all instances must be available to any instance
running a capture process. This is true for both local and downstream capture.
Queue Ownership
When Streams is configured in a RAC environment, each queue table has an
"owning" instance. All queues within an individual queue table are owned by
the same instance. The Streams components (capture/propagation/apply) all
use that same owning instance to perform their work. This means that
+ a capture process is run at the owning instance of the source queue.
+ a propagation job must run at the owning instance of the queue
+ a propagation job must connect to the owning instance of the target queue.
Ownership of the queue can be configured to remain on a specific instance,
as long as that instance is available, by setting the PRIMARY _INSTANCE
and/or SECONDARY_INSTANCE parameters of DBMS_AQADM.ALTER_QUEUE_TABLE.
If the primary_instance is set to a specific instance (ie, not 0), the queue
ownership will return to the specified instance whenever the instance is up.
Capture will automatically follow the ownership of the queue.If the ownership
changes while capture is running, capture will stop on the current instance
and restart at the new owner instance.
For queues created with Oracle Database 10g Release 2, a service will be
created with the service name= schema.queue and the network name
SYS$schema.queue.global_name for that queue. If the global_name of the
database does not match the db_name.db_domain name of the database, be sure
to include the global_name as a service name in the init.ora.
For propagations created with the Oracle Database 10g Release 2 code with
the queue_to_queue parameter to TRUE, the propagation job will deliver only
to the specific queue identified. Also, the source dblink for the target
database connect descriptor must specify the correct service (global name of
the target database ) to connect to the target database. For example, the
tnsnames.ora entry for the target database should include the CONNECT_DATA
clause in the connect descriptor for the target database. This claus should
specify (CONNECT_DATA=(SERVICE_NAME='global_name of target database')).
Do NOT include a specific INSTANCE in the CONNECT_DATA clause.
For example, consider the tnsnames.ora file for a database with the global name
db.mycompany.com. Assume that the alias name for the first instance is db1 and
that the alias for the second instance is db2. The tnsnames.ora file for this
database might include the following entries:
db.mycompany.com=
(description=
(load_balance=on)
(address=(protocol=tcp)(host=node1-vip)(port=1521))
(address=(protocol=tcp)(host=node2-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)))
db1.mycompany.com=
(description=
(address=(protocol=tcp)(host=node1-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)
(instance_name=db1)))
db2.mycompany.com=
(description=
(address=(protocol=tcp)(host=node2-vip)(port=1521))
(connect_data=
(service_name=db.mycompany.com)
(instance_name=db2)))
Use the italicized tnsnames.ora alias in the target database link USING clause.
DBA_SERVICES lists all services for the database. GV$ACTIVE_SERVICES identifies
all active services for the database In non_RAC configurations, the service
name will typically be the global_name. However, it is possible for users to
manually create alternative services and use them in the TNS connect_data
specification . For RAC configurations, the service will appear in these views
as SYS$schema.queue.global_name.
Propagation Restart
Use the procedures START_PROPAGATION and STOP_PROPAGATION from
DBMS_PROPAGATION_ADM to enable and disable the propagation schedule.
These procedures automatically handle queue_to_queue propagation.
Example:
exec DBMS_PROPAGATION_ADM.stop_propagation('name_of_propagation'); or
exec DBMS_PROPAGATION_ADM.stop_propagation('name_of_propagation',force=>true);
exec DBMS_PROPAGATION_ADM.start_propagation('name_of_propagation');
If you use the lower level DBMS_AQADM procedures to manage the propagation schedule,
be sure to explicitly specify the destination_queue name when queue_to_queue propagation has been configured.
Example:
DBMS_AQADM.UNSCHEDULE_PROPAGATION('source_queue_name','destination',destination_queue=>'specific_queue');
DBMS_AQADM.SCHEDULE_PROPAGATION('source_queue_name','destination',destination_queue=>'specific_queue');, DBMS_AQADM.ENABLE_PROPAGATION_SCHEDULE('source_queue_name','destination',destination_queue=>'specific_queue');,
DBMS_AQADM.DISABLE_PROPAGATION_SCHEDULE('source_queue_name','destination',destination_queue=>'specific_queue');, DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE('source_queue_name','destination',destination_queue=>'specific_queue');
Changing the GLOBAL_NAME of the Source Database
See the OPERATION section on Global_name below. The following are some
additional considerations when running in a RAC environment.
If the GLOBAL_NAME of the database is changed, ensure that any propagations
are dropped and recreated with the queue_to_queue parameter set to TRUE.
In addition, if the GLOBAL_NAME does not match the db_name.db_domain of the
database, include the global_name for the queue (NETWORK_NAME in DBA_QUEUES)
in the list of services for the database in the database parameter
initialization file.
Section 4. Target Site Configuration
The following recommendations apply to target databases, ie, databases in which
Streams apply is configured.
1. Privileges
Grant Explicit Privileges to APPLY_USER for the user tables
Examples:
Privileges for table level DML: INSERT/UPDATE/DELETE,
Privileges for table level DDL: CREATE (ANY) TABLE , CREATE (ANY) INDEX,
CREATE (ANY) PROCEDURE
2. Instantiation
Set Instantiation SCNs manually if not using export/import. If manually
configuring the instantiation scn for each table within the schema, use the
RECURSIVE=>TRUE option on the DBMS_STREAMS_ADM.SET_SCHEMA_INSTANTIATION_SCN
procedure
For DDL Set Instantiation SCN at next higher level(ie,SCHEMA or GLOBAL level).
3. Conflict Resolution
If updates will be performed in multiple databases for the same shared
object, be sure to configure conflict resolution. See the Streams
Replication Administrator's Guide Chapter 3 Streams Conflict Resolution,
for more detail.
To simplify conflict resolution on tables with LOB columns, create an error
handler to handle errors for the table. When registering the handler using
the DBMS_APPLY_ADM.SET_DML_HANDLER procedure, be sure to specify the
ASSEMBLE_LOBS parameter as TRUE.
In Streams Concepts manual 10.2 chapter 22: Monitoring Apply
Displaying detailed information about Apply errors.
4. Apply Process Configuration
A. Rules
If the maintain_* procedures are not suitable for your environment,
please use the ADD_RULES  procedures (ADDTABLE_RULES , ADD_SCHEMA_RULES ,
ADD_GLOBAL_RULES (for DML and DDL), ADD_SUBSET_RULES (DML only).
These procedures minimize the number of steps required to configure Streams
processes. Also, it is possible to create rules for non-existent objects,
so be sure to check the spelling of each object specified in a rule carefully.
APPLY can be configured with or without a ruleset. The ADD_GLOBAL_RULES can
be used to apply all changes in the queue for the database. If no ruleset is
specified for the apply process, all changes in the queue are processed by the apply process.
A single Streams apply can process rules for multiple tables or schemas
located in a single queue that are received from a single source database .
For best performance, rules should be simple. Rules that include LIKE clauses are
not simple and will impact the performance of Streams.
To eliminate changes for particular tables or objects, specify the
include_tagged_lcr clause along with the table or object name in the
negative rule set for the Streams process. Setting this clause will
eliminate all changes, tagged or not, for the table or object.
B. Parameters
Set the following parameters after a apply process is created:
+ DISABLE_ON_ERROR=N Default: Y
If Y, then the apply process is disabled on the first unresolved error,
even if the error is not fatal.
If N, then the apply process continues regardless of unresolved errors.
+ PARALLELISM=3* Number of CPU Default: 1
Apply parameters can be set using the SET_PARAMETER procedure from the
DBMS_APPLY_ADM package. For example, to set the DISABLE_ON_ERROR parameter
of the streams apply process named APPLY_EX, use the following syntax while
logged in as the Streams Administrator:
exec dbms_apply_adm.set_parameter('apply_ex','disable_on_error','n');
Change the apply parallelism parameter recommendation to a lower number.
In general, try 4 or 8 and increase or decrease as necessary for your workload.
In some cases, performance can be improved by setting the following hidden
parameter. This parameter should be set when the major workload is UPDATEs
and the updates are performed on just a few columns of a many-column table.
+ DYNAMICSTMTS=Y Default: N
If Y, then for UPDATE statements, the apply process will optimize the
generation of SQL statements based on required columns.
CHECKPOINTFREQUENCY=1000
Increase the frequency of logminer checkpoints especially in a
database with significant LOB or DDL activity.
exec dbms_capture_adm.set_parameter('capture_ex','_checkpoint_frequency','1000');
5. Additional Configuration for RAC Environments for a Apply Database
Queue Ownership
When Streams is configured in a RAC environment, each queue table has an
"owning" instance. All queues within an individual queue table are owned
by the same instance. The Streams components (capture/propagation/apply)
all use that same owning instance to perform their work. This means that
the database link specified in the propagation must connect to the owning
instance of the target queue. the apply process is run at the owning instance
of the target queue
Ownership of the queue can be configured to remain on a specific instance,
as long as that instance is available, by setting the PRIMARY _INSTANCE and
SECONDARY_INSTANCE parameters of DBMS_AQADM.ALTER_QUEUE_TABLE. If the
primary_instance is set to a specific instance (ie, not 0), the queue
ownership will return to the specified instance whenever the instance is up.
Apply will automatically follow the ownership of the queue. If the ownership
changes while apply is running, apply will stop on the current instance and
restart at the new owner instance.
Changing the GLOBAL_NAME of the Database
See the OPERATION section on Global_name below. The following are some
additional considerations when running in a RAC environment.
If the GLOBAL_NAME of the database is changed, ensure that the queue is
empty before changing the name and that the apply process is dropped and
recreated with the apply_captured parameter = TRUE. In addition, if the
GLOBAL_NAME does not match the db_name.db_domain of the database, include
the GLOBAL_NAME in the list of services for the database in the database
parameter initialization file.