You can use the following procedures in the DBMS_STREAMS_ADM package to configure tablespace replication:
■ MAINTAIN_SIMPLE_TTS
■ MAINTAIN_TTS
■ PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP
You can use the MAINTAIN_SIMPLE_TTS procedure to configure Streams replication for a simple tablespace, and you can use the MAINTAIN_TTS procedure to configure Streams replication for a set of self-contained tablespaces. These procedures use transportable tablespaces, Data Pump, the DBMS_STREAMS_TABLESPACE_ADM package, and the DBMS_FILE_TRANSFER package to configure the environment.
A self-contained tablespace has no references from the tablespace pointing outside of the tablespace. For example, if an index in the tablespace is for a table in a different tablespace, then the tablespace is not self-contained. A simple tablespace is a self-contained tablespace that uses only one datafile. When there is more than one tablespace in a tablespace set, a self-contained tablespace set has no references from inside the set of tablespaces pointing outside of the set of tablespaces.
These procedures clone the tablespace or tablespaces being configured for replication from the source database to the destination database. The MAINTAIN_SIMPLE_TTS procedure uses the CLONE_SIMPLE_TABLESPACE procedure in the DBMS_STREAMS_
TABLESPACE_ADM package, and the MAINTAIN_TTS procedure uses the CLONE_
TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package. When a tablespace is cloned, it is made read-only automatically until the clone operation is complete.
The example in this section uses the MAINTAIN_TTS procedure to configure a Streams replication environment that maintains the following tablespaces using Streams:
■ tbs1
■ tbs2
The source database is stm1.net, and the destination database is stm2.net. Assume that the following decisions were made about the configuration:
■ DDL changes to these tablespaces and the database objects in these tablespaces will be maintained.
■ A downstream capture process running on the destination database (stm2.net) will capture changes made to the source database (stm1.net).
■ The replication environment will be bi-directional.
■ The MAINTAIN_TTS procedure will configure the replication environment directly. A configuration script will not be generated.
In addition, this example makes the following assumptions:
■ The tablespaces tbs1 and tbs2 make a self-contained tablespace set at the source database stm1.net.
■ The datafiles for the tablespace set are both in the /orc/dbs directory at the source database stm1.net.
See Also: "Decisions to Make Before Configuring Streams
Replication" on page 6-6 for more information about these decisions
Configuring Replication Using the DBMS_STREAMS_ADM Package
■ The stm2.net database does not contain the tablespace set currently.
The MAINTAIN_SIMPLE_TTS and MAINTAIN_TTS procedures automatically exclude database objects that are not supported by Streams from the replication environment by adding rules to the negative rule set of each capture and apply process. The PRE_
INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures enable you to specify which database objects to exclude from the replication environment.
Query the DBA_STREAMS_UNSUPPORTED data dictionary view to determine which database objects are not supported by Streams. If unsupported database objects are not excluded, then capture errors will result.
Complete the following steps to use the MAINTAIN_TTS procedure to configure the environment:
1. Complete the required tasks before running the MAINTAIN_TTS procedure. See
"Tasks to Complete Before Configuring Streams Replication" on page 6-13 for instructions.
For this configuration, the following tasks must be completed:
■ Configure a Streams administrator at both databases.
■ Create a database link from the source database stm1.net to the destination database stm2.net.
■ Because the replication environment will be bi-directional, and because downstream capture will be configured at the destination database, create a database link from the destination database stm2.net to the source database stm1.net.
■ Create the following required directory objects:
– A source directory object at the source database. This example assumes that this directory object is SOURCE_DIRECTORY.
– A destination directory object at the destination database. This example assumes that this directory object is DEST_DIRECTORY.
■ Make sure both databases are in ARCHIVELOG mode.
■ Because the destination database will be the capture database for changes made to the source database, configure log file copying from the source database stm1.net to the destination database stm2.net.
■ Make sure the initialization parameters are set properly at both databases.
2. While connected as the Streams administrator to the database that contains the tablespace set, create a directory object for the directory that contains the datafiles for the tablespaces in the tablespace set. For example, the following statement creates a directory object named tbs_directory that corresponds to the /orc/dbs directory:
CONNECT strmadmin/strmadminpw@stm1.net CREATE DIRECTORY tbs_directory AS '/orc/dbs';
If the datafiles are in multiple directories, then a directory object must exist for each of these directories, and the user who runs the MAINTAIN_TTS procedure in Step 3 must have READ privilege on these directory objects. In this example, the Streams administrator has this privilege because this user creates the directory object.
Configuring Replication Using the DBMS_STREAMS_ADM Package
3. While connected as the Streams administrator to the destination database, run the MAINTAIN_TTS procedure:
CONNECT strmadmin/strmadminpw@stm2.net DECLARE
t_names DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
-- Tablespace names t_names(1) := 'TBS1';
t_names(2) := 'TBS2';
DBMS_STREAMS_ADM.MAINTAIN_TTS(
tablespace_names => t_names,
source_directory_object => 'SOURCE_DIRECTORY', destination_directory_object => 'DEST_DIRECTORY', source_database => 'stm1.net',
When this procedure completes, the Streams bi-directional replication
environment is configured. The procedure automatically generates names for the ANYDATA queues, capture processes, propagations, and apply processes it creates.
If you do not want system-generated names for these components, you can specify names by using additional parameters available in the MAINTAIN_TTS procedure.
This procedure also starts the queues, capture processes, propagations, and apply processes.
Because the procedure is run at the destination database, downstream capture is configured at the destination database for changes to the source database.
The procedure does not specify the apply_name parameter. Therefore, the default, NULL, is specified for this parameter. When the apply_name parameter is set to NULL, no apply process that applies changes from the source database can exist on the destination database. If an apply process that applies changes from the source database exists at the destination database, then specify a non-NULL value for the apply_name parameter.
If this procedure encounters an error and stops, then see "Recovering from Configuration Errors" on page 13-1 for information about either recovering from the error or rolling back the configuration operation.
4. Configure conflict resolution for the database objects in the tablespace set if necessary.
Typically, conflicts are possible in a bi-directional replication environment. If conflicts are possible in the environment created by the MAINTAIN_TTS procedure, then configure conflict resolution before you allow users to make changes to the objects in the tablespace set.
The resulting bi-directional replication environment has the following characteristics:
■ Supplemental logging is configured for the shared database objects at both databases.
■ The stm1.net database has a queue and queue table with system-generated names. This queue is for the apply process.
Configuring Replication Using the DBMS_STREAMS_ADM Package
■ The stm2.net database has three queues and queue tables with
system-generated names. One queue is for the downstream capture process, one queue is for the local capture process, and one queue is for the apply process.
■ At the stm2.net database, a downstream capture process with a
system-generated name captures DML and DDL changes made to the source database. Specifically, this downstream capture process captures DML changes made to the tables in the tbs1 and tbs2 tablespaces and DDL changes to these tablespaces and the database objects in them.
■ At the stm2.net database, a local capture process with a system-generated name captures DML and DDL changes made to the destination database. Specifically, this local capture process captures DML changes to the tables in the tbs1 and tbs2 tablespaces and DDL changes to these tablespaces and the database objects in them.
■ A propagation running on the stm2.net database with a system-generated name propagates the changes captured by the downstream capture process from the queue for the downstream capture process to the queue for the apply process within the stm2.net database.
■ A propagation running on the stm2.net database with a system-generated name propagates the changes captured by the local capture process from the queue for the local capture process to the queue in the stm1.net database.
■ At the stm1.net database, an apply process with a system-generated name dequeues the changes from the queue and applies them to the shared database objects.
■ At the stm2.net database, an apply process with a system-generated name dequeues the changes from its queue and applies them to the shared database objects.
■ Tags are used to avoid change cycling. Specifically, each apply process uses an apply tag so that redo records for changes applied by the apply process include the tag. Each apply process uses an apply tag that is unique in the replication environment. Each propagation discards changes that have the tag of the apply process running on the same database.