Creating a New Streams Single-Source Environment
This section lists the general steps to perform when creating a new single-source Streams environment. A single-source environment is one in which there is only one source database for shared data. There can be more than one source database in a single-source environment, but no two source databases capture any of the same data.
Before starting capture processes and configuring propagations in a new Streams environment, make sure any propagations or apply processes that will receive LCRs are configured to handle these LCRs. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the LCRs appropriately. If these propagations and apply processes are not configured properly to handle these LCRs, then LCRs can be lost.
This example assumes that the shared database objects are read-only at the destination databases. If the shared objects are read/write at the destination databases, then the replication environment will not stay synchronized because Streams is not configured to replicate the changes made to the shared objects at the destination databases.
Figure 7–1 shows an example Streams single-source replication environment.
Figure 7–1 Example Streams Single-Source Environment
You can create a Streams environment that is more complicated than the one shown in Figure 7–1. For example, a single-source Streams environment can use downstream capture and directed networks.
Source Database
Database link for propagation
Includes:
· A SYS.AnyData queue
· Supplemental logging specifications
· A capture process
· One propagation for each destination database
· Rule sets for the capture process and the propagations
· Each shared object prepared for instantiation
Destination Database
Includes:
· A SYS.AnyData queue
· Instantiation SCN set for each shared object
· An apply process for the source database
· Rule sets for the apply process
· · ·
Additional Destination Databases
Creating a New Streams Single-Source Environment
In general, if you are configuring a new Streams single-source environment in which changes for shared objects are captured at one database and then propagated and applied at remote databases, then you should configure the environment in the following order:
1. Complete the necessary tasks to prepare each database in your environment for Streams:
■ Configure a Streams administrator.
■ Set initialization parameters relevant to Streams.
■ For each database that will run a capture process, prepare the database to run a capture process.
■ Configure network connectivity and database links.
Some of these tasks might not be required at certain databases.
2. Create any necessary ANYDATA queues that do not already exist. When you create a capture process or apply process, you associate the process with a specific ANYDATA queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating an ANYDATA Queue to Stage LCRs" on page 9-7 for instructions.
3. Specify supplemental logging at each source database for any shared object. See
"Managing Supplemental Logging in a Streams Replication Environment" on page 9-3 for instructions.
4. At each database, create the required capture processes, propagations, and apply processes for your environment. You can create them in any order.
■ Create one or more capture processes at each database that will capture changes. Make sure each capture process uses rule sets that are appropriate for capturing changes. Do not start the capture processes you create. Oracle recommends that you use only one capture process for each source database.
See "Creating a Capture Process" on page 9-1 for instructions.
When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_
INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_
GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.
You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:
– You use the DBMS_RULE_ADM package to add or modify rules.
– You use an existing capture process and do not add capture process rules for any shared object.
– You use a downstream capture process with no database link to the source database.
If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" on page 10-1 for instructions.
See Also: Oracle Streams Concepts and Administration for more information about preparing a database for Streams
Creating a New Streams Single-Source Environment
■ Create all propagations that propagate the captured LCRs from a source queue to a destination queue. Make sure each propagation uses rule sets that are appropriate for propagating changes. See "Creating a Propagation that Propagates LCRs" on page 9-7 for instructions.
■ Create one or more apply processes at each database that will apply changes.
Make sure each apply process uses rule sets that are appropriate for applying changes. Do not start the apply processes you create. See "Creating an Apply Process that Applies LCRs" on page 9-9 for instructions.
5. Either instantiate, or set the instantiation SCN for, each database object for which changes are applied by an apply process. If the database objects do not exist at a destination database, then instantiate them using export/import, transportable tablespaces, or RMAN. If the database objects already exist at a destination database, then set the instantiation SCNs for them manually.
■ To instantiate database objects using export/import, first export them at the source database. Next, import them at the destination database. See "Setting Instantiation SCNs Using Export/Import" on page 10-28 for information. Also, see "Instantiating Objects in a Streams Replication Environment" on page 10-3 for information about instantiating objects using export/import, transportable tablespaces, and RMAN.
If you use the original Export utility, then set the OBJECT_CONSISTENT export parameter to y. Regardless of whether you use Data Pump export or original export, you can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.
If you use the original Import utility, then set the STREAMS_INSTANTIATION import parameter to y.
■ To set the instantiation SCN for a table, schema, or database manually, run the appropriate procedure or procedures in the DBMS_APPLY_ADM package at the destination database:
– SET_TABLE_INSTANTIATION_SCN – SET_SCHEMA_INSTANTIATION_SCN – SET_GLOBAL_INSTANTIATION_SCN
When you run one of these procedures, you must ensure that the shared objects at the destination database are consistent with the source database as of the instantiation SCN.
If you run SET_GLOBAL_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to true so that the instantiation SCN also is set for each schema at the destination database and for the tables owned by these schemas.
If you run SET_SCHEMA_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to true so that the instantiation SCN also is set for each table in the schema.
If you set the recursive parameter to true in the SET_GLOBAL_
INSTANTIATION_SCN procedure or the SET_SCHEMA_INSTANTIATION_
SCN procedure, then a database link from the destination database to the source database is required. This database link must have the same name as the global name of the source database and must be accessible to the user who executes the procedure. See "Setting Instantiation SCNs Using the DBMS_
APPLY_ADM Package" on page 10-29 for instructions.