Oracle® Streams Replication Administrator's Guide 10g Release 1 (10.1) Part Number B10728-01 |
|
|
View PDF |
This chapter contains instructions for configuring Streams single source and multiple source replication environments. This chapter also includes instructions for adding objects and databases to an existing Streams replication environment.
This chapter contains these topics:
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 may 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 events are configured to handle these events. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the events appropriately. If these propagations and apply processes are not configured properly to handle these events, then events may 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 in sync because Streams is not configured to replicate the changes made to the shared objects at the destination databases.
Figure 6-1 shows an example Streams single source replication environment.
Text description of the illustration strep038.gif
You may create a Streams environment that is more complicated than the one shown in Figure 6-1. For example, a single source Streams environment may 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:
Some of these tasks may not be required at certain databases.
See Also:
Oracle Streams Concepts and Administration for more information about preparing a database for Streams |
SYS.AnyData
queues that do not already exist. When you create a capture process or apply process, you associate the process with a specific SYS.AnyData
queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating a SYS.AnyData Queue to Stage LCRs" 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:
DBMS_RULE_ADM
package to add or modify rules.If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
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 may 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
.
DBMS_APPLY_ADM
package at the destination database:
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.
START_APPLY
procedure in the DBMS_APPLY_ADM
package.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 events 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:
|
You add existing database objects to an existing single source environment by adding the necessary rules to the appropriate capture processes, propagations, and apply processes. Before creating or altering capture or propagation rules in a running Streams environment, make sure any propagations or apply processes that will receive events as a result of the new or altered rules are configured to handle these events. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the events appropriately. If these propagations and apply processes are not configured properly to handle these events, then events may be lost.
For example, suppose you want to add a table to a Streams environment that already captures, propagates, and applies changes to other tables. Assume only one capture process will capture changes to this table, and only one apply process will apply changes to this table. In this case, you must add one or more table rules to the following rule sets:
If you perform administrative steps in the wrong order, you may lose events. For example, if you add the rule to a capture process rule set first, without stopping the capture process, then the propagation will not propagate the changes if it does not have a rule that instructs it to do so, and the changes may 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 in sync because Streams is not configured to replicate the changes made to the shared objects at the destination databases.
Figure 6-2 shows the additional configuration steps that must be completed to add shared database objects to a single source Streams environment.
Text description of the illustration strep041.gif
To avoid losing events, you should complete the configuration in the following order:
STOP_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package to stop a capture process.DISABLE_PROPAGATION_SCHEDULE
procedure in the DBMS_AQADM
package to disable a propagation job.STOP_APPLY
procedure in the DBMS_APPLY_ADM
package to stop an apply process.
See Also:
Oracle Streams Concepts and Administration for more information about completing these tasks |
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
Excluding the ADD_SUBSET_RULES
procedure, these procedures can add rules to the positive or negative rule set for an apply process. The ADD_SUBSET_RULES
procedure can add rules only to the positive rule set for an apply process.
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES
Excluding the ADD_SUBSET_PROPAGATION_RULES
procedure, these procedures can add rules to the positive or negative rule set for a propagation. The ADD_SUBSET_PROPAGATION_RULES
procedure can add rules only to the positive rule set for a propagation.
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
Excluding the ADD_SUBSET_RULES
procedure, these procedures can add rules to the positive or negative rule set for a capture process. The ADD_SUBSET_RULES
procedure can add rules only to the positive rule set for a capture process.
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:
DBMS_RULE_ADM
to create or modify rules in a capture process rule set.If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
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 may 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
.
DBMS_APPLY_ADM
package at a destination database:
When you run one of these procedures at a destination database, you must ensure that every added object at the destination database is 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 every added object at the importing destination database is 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.
START_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package to start a capture process.ENABLE_PROPAGATION_SCHEDULE
procedure in the DBMS_AQADM
package to enable a propagation job.START_APPLY
procedure in the DBMS_APPLY_ADM
package to start an apply process.
See Also:
Oracle Streams Concepts and Administration for more information about completing these tasks |
You must stop the capture process, disable one of the propagation jobs, or stop the apply process in Step 2 to ensure that the table or schema is instantiated before the first LCR resulting from the added rule(s) reaches the apply process. Otherwise, events could be lost or could result in apply errors, depending on whether the apply process rule(s) have been added.
If you are certain that the added table is not being modified at the source database during this procedure, and that there are no LCRs for the table already in the stream or waiting to be captured, then you can perform Step 7 before Step 6 to reduce the amount of time that a Streams process or propagation job is stopped.
See Also:
"Add Objects to an Existing Streams Replication Environment" for a detailed example that adds objects to an existing single source environment |
You add a destination database to an existing single source environment by creating one or more new apply processes at the new destination database and, if necessary, configuring one or more propagations to propagate changes to the new destination database. You may also need to add rules to existing propagations in the stream that propagates to the new destination database.
As in the example that describes "Adding Shared Objects to an Existing Single Source Environment", before creating or altering propagation rules in a running Streams environment, make sure any propagations or apply processes that will receive events as a result of the new or altered rules are configured to handle these events. Otherwise, events may 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 in sync because Streams is not configured to replicate the changes made to the shared objects at the destination databases.
Figure 6-3 shows the additional configuration steps that must be completed to add a destination database to a single source Streams environment.
Text description of the illustration strep040.gif
To avoid losing events, you should complete the configuration in the following order:
Some of these tasks may not be required at certain databases.
See Also:
Oracle Streams Concepts and Administration for more information about preparing a database for Streams |
SYS.AnyData
queues that do not already exist at the destination database. When you create an apply process, you associate the apply process with a specific SYS.AnyData
queue. See "Creating a SYS.AnyData Queue to Stage LCRs" for instructions.Keeping the apply processes stopped prevents changes made at the source databases from being applied before the instantiation of the new database is completed, which would otherwise lead to incorrect data and errors.
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. See "Preparing Database Objects for Instantiation at a Source Database" for instructions.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 may 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
.
DBMS_APPLY_ADM
package at the new destination database:
When you run one of these procedures, you must ensure that the shared objects at the new 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 the importing destination database 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.
START_APPLY
procedure in the DBMS_APPLY_ADM
package.
See Also:
"Add a Database to an Existing Streams Replication Environment" for detailed example that adds a database to an existing single 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 6-4 shows an example multiple source Streams environment.
Text description of the illustration strep039.gif
You may create a Streams environment that is more complicated than the one shown in Figure 6-4. For example, a multiple source Streams environment may 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. |
Some of these tasks may not be required at certain databases.
See Also:
Oracle Streams Concepts and Administration for more information about preparing a database for Streams |
SYS.AnyData
queues that do not already exist. When you create a capture process or apply process, you associate the process with a specific SYS.AnyData
queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating a SYS.AnyData Queue to Stage LCRs" 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:
DBMS_RULE_ADM
package to add or modify rules.If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
After completing these steps, complete the steps in each of the following sections that apply to your environment. You may need to complete the steps in only one of these sections or in both of these sections:
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:
For each populated database, you can set these instantiation SCNs in one of the following ways:
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.
After completing the steps in "Creating a New Streams Multiple Source Environment", complete the following steps for the import databases:
SET_GLOBAL_INSTANTIATION_SCN
procedure in the DBMS_APPLY_ADM
package for this import database at all of the other databases in the environment.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.
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 may 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
.
You can set these instantiation SCNs in one of the following ways:
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.
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:
START_APPLY
procedure in the DBMS_APPLY_ADM
package.START_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package.
See Also:
Chapter 14, "Multiple Source Replication Example" for a detailed example that creates a multiple source environment |
You add existing database objects to an existing multiple source environment by adding the necessary rules to the appropriate capture processes, propagations, and apply processes.
This example uses the following terms:
Before creating or altering capture or propagation rules in a running Streams environment, make sure any propagations or apply processes that will receive events as a result of the new or altered rules are configured to handle these events. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the events appropriately. If these propagations and apply processes are not configured properly to handle these events, then events may be lost.
For example, suppose you want to add a new table to a Streams environment that already captures, propagates, and applies changes to other tables. Assume multiple capture processes in the environment will capture changes to this table, and multiple apply processes will apply changes to this table. In this case, you must add one or more table rules to the following rule sets:
If you perform administrative steps in the wrong order, you may lose events. For example, if you add the rule to a capture process rule set first, without stopping the capture process, then the propagation will not propagate the changes if it does not have a rule that instructs it to do so, and the changes may be lost.
Figure 6-5 shows the additional configuration steps that must be completed to add shared database objects to a multiple source Streams environment.
Text description of the illustration strep042.gif
To avoid losing events, you should complete the configuration in the following order:
STOP_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package to stop a capture process.DISABLE_PROPAGATION_SCHEDULE
procedure in the DBMS_AQADM
package to disable a propagation job.STOP_APPLY
procedure in the DBMS_APPLY_ADM
package to stop an apply process.
See Also:
Oracle Streams Concepts and Administration for more information about completing these tasks |
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
Excluding the ADD_SUBSET_RULES
procedure, these procedures can add rules to the positive or negative rule set for an apply process. The ADD_SUBSET_RULES
procedure can add rules only to the positive rule set for an apply process.
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES
Excluding the ADD_SUBSET_PROPAGATION_RULES
procedure, these procedures can add rules to the positive or negative rule set for a propagation. The ADD_SUBSET_PROPAGATION_RULES
procedure can add rules only to the positive rule set for a propagation.
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
Excluding the ADD_SUBSET_RULES
procedure, these procedures can add rules to the positive or negative rule set for a capture process. The ADD_SUBSET_RULES
procedure can add rules only to the positive rule set for a capture process.
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:
DBMS_RULE_ADM
to create or modify rules in a capture process rule set.If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
After completing these steps, complete the steps in each of the following sections that apply to your environment. You may need to complete the steps in only one of these sections or in both of these sections:
After completing the steps in "Adding Shared Objects to an Existing Multiple Source Environment", complete the following steps for each populated database if your environment has more than one populated database:
For each populated database, you can set these instantiation SCNs for each added object in one of the following ways:
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.
After completing the steps in "Adding Shared Objects to an Existing Multiple Source Environment", complete the following steps for the import databases:
SET_GLOBAL_INSTANTIATION_SCN
procedure in the DBMS_APPLY_ADM
package for this import database at all of the other databases in the environment.SET_SCHEMA_INSTANTIATION_SCN
procedure in the DBMS_APPLY_ADM
package for the schema for this import database at each of the other databases in the environment. 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 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.
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 may 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
.
For each populated database, you can set these instantiation SCNs for the added objects in one of the following ways:
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.
Before completing the configuration, you should have completed the following tasks:
When all of the previous configuration steps are finished, complete the following steps:
START_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package to start a capture process.ENABLE_PROPAGATION_SCHEDULE
procedure in the DBMS_AQADM
package to enable a propagation job.START_APPLY
procedure in the DBMS_APPLY_ADM
package to start an apply process.
See Also:
Oracle Streams Concepts and Administration for more information about completing these tasks |
Figure 6-6 shows the additional configuration steps that must be completed to add a source/destination database to a multiple source Streams environment.
Text description of the illustration strep043.gif
Complete the following steps to add a new source/destination database to an existing multiple source Streams environment:
Note: Make sure no changes are made to the objects being shared at the database you are adding to the Streams environment until the instantiation at the database is complete. |
Some of these tasks may not be required at certain databases.
See Also:
Oracle Streams Concepts and Administration for more information about preparing a database for Streams |
SYS.AnyData
queues that do not already exist. When you create a capture process or apply process, you associate the process with a specific SYS.AnyData
queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating a SYS.AnyData Queue to Stage LCRs" for instructions.Keeping the apply processes stopped prevents changes made at the source databases from being applied before the instantiation of the new database is completed, which would otherwise lead to incorrect data and errors.
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. See "Preparing Database Objects for Instantiation at a Source Database" 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:
DBMS_RULE_ADM
package to add or modify rules.If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
START_CAPTURE
procedure in the DBMS_CAPTURE_ADM
package.After completing these steps, complete the steps in the appropriate section:
After completing the steps in "Adding a New Database to an Existing Multiple Source Environment", complete the following steps if the objects that are to be shared with the new database already exist at the new database:
For each source database of the new database, you can set these instantiation SCNs in one of the following ways:
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.
You can set these instantiation SCNs for the new database in one of the following ways:
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.
START_APPLY
procedure in the DBMS_APPLY_ADM
package.After completing the steps in "Adding a New Database to an Existing Multiple Source Environment", complete the following steps if the objects that are to be shared with the new database do not already exist at the new database:
SET_GLOBAL_INSTANTIATION_SCN
procedure in the DBMS_APPLY_ADM
package for the new database at each destination database of the new database.SET_SCHEMA_INSTANTIATION_SCN
procedure in the DBMS_APPLY_ADM
package for the schema at each destination database of the new 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 new database, and because the local capture process is configured already at the new database, you will not need to run the SET_TABLE_INSTANTIATION_SCN
procedure for each table created during 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 new database.
If the new database will not be a source database, then do not complete this step, and continue with the next step.
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 may 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
.
For each source database, you can set these instantiation SCNs in one of the following ways:
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.
START_APPLY
procedure in the DBMS_APPLY_ADM
package.