Skip Headers
Oracle® Streams Replication Administrator's Guide
10g Release 2 (10.2)

Part Number B14228-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

7 Flexible Streams Replication Configuration

This chapter describes flexible methods for configuring Streams replication between two or more databases. This chapter includes step-by-step instructions for configuring each Streams component to build a single-source or multiple-source replication environment.

If possible, consider using a simple method for configuring Streams replication described in Chapter 6, "Simple Streams Replication Configuration". You can either use the Streams tool in Enterprise Manager or a single procedure in the DBMS_STREAMS_ADM package configure all of the Streams components in a replication environment with two databases. Also, you can use a simple method and still meet custom requirements for your replication environment in one of the following ways:

However, if you require more flexibility in your Streams replication configuration than what is available with the simple methods, then you can follow the instructions in this chapter to configure the environment.

This chapter contains these topics:


Note:

  • The instructions in the following sections assume you will use the DBMS_STREAMS_ADM package to configure your Streams environment. If you use other packages, then extra steps might be necessary for each task.

  • Certain types of database objects are not supported by Streams. When you configure a Streams environment, ensure that no capture process attempts to capture changes to an unsupported database object. To list unsupported database objects, query the DBA_STREAMS_UNSUPPORTED data dictionary view.


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

Description of strep038.gif follows
Description of the illustration strep038.gif

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.

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.


    See Also:

    Oracle Streams Concepts and Administration for more information about preparing a database for Streams

  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" for instructions.

  3. Specify supplemental logging at each source database for any shared object. See "Managing Supplemental Logging in a Streams Replication Environment" 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" 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" for instructions.

    • 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" 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" 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" for information. Also, see "Instantiating Objects in a Streams Replication Environment" 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" for instructions.

      Alternatively, you can perform a metadata export/import to set the instantiation SCNs for existing database objects. If you choose this option, then make sure no rows are imported. Also, make sure the shared objects at all of the destination databases are consistent with the source database that performed the export at the time of the export. If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

  6. Start each apply process you created in Step 4 using the START_APPLY procedure in the DBMS_APPLY_ADM package.

  7. Start each capture process you created in Step 4 using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.

When you are configuring the environment, remember that capture processes and apply processes are stopped when they are created, but propagations are scheduled to propagate LCRs immediately when they are created. The capture process must be created before the relevant objects are instantiated at a remote destination database. You must create the propagations and apply processes before starting the capture process, and you must instantiate the objects before running the whole stream.


See Also:


Creating a New Streams Multiple-Source Environment

This section lists the general steps to perform when creating a new multiple-source Streams environment. A multiple-source environment is one in which there is more than one source database for any of the shared data.

This example uses the following terms:

Figure 7-2 shows an example multiple-source Streams environment.

Figure 7-2 Example Streams Multiple-Source Environment

Description of strep039.gif follows
Description of the illustration strep039.gif

You can create a Streams environment that is more complicated than the one shown in Figure 7-2. For example, a multiple-source Streams environment can use downstream capture and directed networks.

Complete the following steps to create a new multiple-source environment:


Note:

Make sure no changes are made to the objects being shared at a database you are adding to the Streams environment until the instantiation at the database is complete.

  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.


    See Also:

    Oracle Streams Concepts and Administration for more information about preparing a database for Streams

  2. At each populated database, specify any necessary supplemental logging for the shared objects. See "Managing Supplemental Logging in a Streams Replication Environment" for instructions.

  3. 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" 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" for instructions.

      When you 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" for instructions.

    • 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" 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" for instructions.

After completing these steps, complete the steps in each of the following sections that apply to your environment. You might need to complete the steps in only one of these sections or in both of these sections:

Configuring Populated Databases When Creating a Multiple-Source Environment

After completing the steps in "Creating a New Streams Multiple-Source Environment", complete the following steps for the populated databases if your environment has more than one populated database:

  1. For each populated database, set the instantiation SCN at each of the other populated databases in the environment that will be a destination database of the populated source database. These instantiation SCNs must be set, and only the changes made at a particular populated database that are committed after the corresponding SCN for that database will be applied at another populated database.

    For each populated database, you can set these instantiation SCNs in one of the following ways:

    1. Perform a metadata only export of the shared objects at the populated database and import the metadata at each of the other populated databases. Such an import sets the required instantiation SCNs for the populated database at the other populated databases. Make sure no rows are imported. Also, make sure the shared objects at each populated database performing a metadata import are consistent with the populated database that performed the metadata export at the time of the export.

      If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

    2. Set the instantiation SCNs manually at each of the other populated databases. Do this for each of the shared objects. Make sure the shared objects at each populated database are consistent with the instantiation SCNs you set at that database. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

Adding Shared Objects to Import Databases When Creating a New Environment

After completing the steps in "Creating a New Streams Multiple-Source Environment", complete the following steps for the import databases:

  1. Pick the populated database that you will use as the export database. Do not perform the instantiations yet.

  2. For each import database, set the instantiation SCNs at all of the other databases in the environment that will be a destination database of the import database. In this case, the import database will be the source database for these destination databases. The databases where you set the instantiation SCNs can include populated databases and other import databases.

    1. If one or more schemas will be created at an import database during instantiation or by a subsequent shared DDL change, then run the SET_GLOBAL_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for this import database at all of the other databases in the environment.

    2. If a schema exists at an import database, and one or more tables will be created in the schema during instantiation or by a subsequent shared DDL change, then run the SET_SCHEMA_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for the schema at all of the other databases in the environment for the import database. Do this for each such schema.

    See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

    Because you are running these procedures before any tables are instantiated at the import databases, and because the local capture processes are configured already for these import databases, you will not need to run the SET_TABLE_INSTANTIATION_SCN procedure for each table created during the instantiation. Instantiation SCNs will be set automatically for these tables at all of the other databases in the environment that will be destination databases of the import database.

  3. At the export database you chose in Step 1, perform an export of the shared objects. Next, perform an import of the shared objects at each import database. See "Instantiating Objects in a Streams Replication Environment" and Oracle Database Utilities for information about using export/import.

    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.

  4. For each populated database, except for the export database, set the instantiation SCNs at each import database that will be a destination database of the populated source database. These instantiation SCNs must be set, and only the changes made at a populated database that are committed after the corresponding SCN for that database will be applied at an import database.

    You can set these instantiation SCNs in one of the following ways:

    1. Perform a metadata only export at each populated database and import the metadata at each import database. Each import sets the required instantiation SCNs for the populated database at the import database. In this case, ensure that the shared objects at the import database are consistent with the populated database at the time of the export.

      If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

    2. For each populated database, set the instantiation SCN manually for each shared object at each import database. Make sure the shared objects at each import database are consistent with the populated database as of the corresponding instantiation SCN. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

Complete the Multiple-Source Environment Configuration

Before completing the steps in this section, you should have completed the following tasks:

When all of the previous configuration steps are finished, complete the following steps:

  1. At each database, configure conflict resolution if conflicts are possible. See "Managing Streams Conflict Detection and Resolution" for instructions.

  2. Start each apply process in the environment using the START_APPLY procedure in the DBMS_APPLY_ADM package.

  3. Start each capture process the environment using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.


    See Also:

    Chapter 16, "Multiple-Source Replication Example" for a detailed example that creates a multiple-source environment