| Oracle® Streams Replication Administrator's Guide 11g Release 1 (11.1) Part Number B28322-01 |
|
|
View PDF |
| Oracle® Streams Replication Administrator's Guide 11g Release 1 (11.1) Part Number B28322-01 |
|
|
View PDF |
This chapter contains conceptual information about instantiation and Oracle Streams replication.
This chapter contains these topics:
See Also:
Chapter 10, "Performing Instantiations"In an Oracle Streams environment that shares a database object within a single database or between multiple databases, a source database is the database where changes to the object are generated, and a destination database is the database where these changes are dequeued by an apply process. If a capture process or synchronous capture captures, or will capture, such changes, and the changes will be applied locally or propagated to other databases and applied at destination databases, then you must instantiate these source database objects before you can replicate changes to the objects. If a database where changes to the source database objects will be applied is a different database than the source database, then the destination database must have a copy of these database objects.
In Oracle Streams, the following general steps instantiate a database object:
Prepare the object for instantiation at the source database.
If a copy of the object does not exist at the destination database, then create an object physically at the destination database based on an object at the source database. You can use export/import, transportable tablespaces, or RMAN to copy database objects for instantiation. If the database object already exists at the destination database, then this step is not necessary.
Set the instantiation SCN for the database object at the destination database. An instantiation SCN instructs an apply process at the destination database to apply only changes that committed at the source database after the specified SCN.
All of these instantiation steps can be performed automatically when you use one of the following Oracle-supplied procedures in the DBMS_STREAMS_ADM package that configure replication environments:
In some cases, Step 1 and Step 3 are completed automatically. For example, when you add rules for a database object to the positive rule set for a capture process by running a procedure in the DBMS_STREAMS_ADM package, the database object is prepared for instantiation automatically.
Also, when you use export/import, transportable tablespaces, or the RMAN TRANSPORT TABLESPACE command to copy database objects from a source database to a destination database, instantiation SCNs can be set for these database objects automatically.
Note:
The RMAN
DUPLICATE command can be used to instantiate an entire database, but this command does not set instantiation SCNs for database objects.If the database object being instantiated is a table, then the tables at the source and destination database do not need to be an exact match. However, if some or all of the table data is replicated between the two databases, then the data that is replicated should be consistent when the table is instantiated. Whenever you plan to replicate changes to a database object, you must always prepare the object for instantiation at the source database and set the instantiation SCN for the database object at the destination database. By preparing an object for instantiation, you are setting the lowest SCN for which changes to the object might need to be applied at destination databases. This SCN is called the ignore SCN. You should prepare a database object for instantiation after a capture process or synchronous capture has been configured to capture changes to the database object.
When you instantiate tables using export/import, transportable tablespaces, or RMAN, any supplemental log group specifications are retained for the instantiated tables. That is, after instantiation, log group specifications for imported tables at the import database are the same as the log group specifications for these tables at the export database. If you do not want to retain supplemental log group specifications for tables at the import database, then you can drop specific supplemental log groups after import.
Database supplemental logging specifications are not retained during export/import, even if you perform a full database export/import. However, the RMAN DUPLICATE command retains database supplemental logging specifications at the instantiated database.
Note:
During an export for an Oracle Streams instantiation, ensure that no DDL changes are made to objects being exported.
When you export a database or schema that contains rules with non-NULL action contexts, the database or the default tablespace of the schema that owns the rules must be writeable. If the database or tablespace is read-only, then export errors result.
See Also:
"Instantiating Objects in an Oracle Streams Replication Environment"
"Configuring Replication Using the DBMS_STREAMS_ADM Package"
"Managing Supplemental Logging in an Oracle Streams Replication Environment" for information about adding and dropping supplemental log groups
The following subprograms in the DBMS_CAPTURE_ADM package prepare database objects for instantiation:
The PREPARE_TABLE_INSTANTIATION procedure prepares a single table for instantiation when changes to the table will be captured by a capture process.
The PREPARE_SYNC_INSTANTIATION function prepares a single table or multiple tables for instantiation when changes to the table will be captured by a synchronous capture.
The PREPARE_SCHEMA_INSTANTIATION procedure prepares for instantiation all of the database objects in a schema and all database objects added to the schema in the future. This procedure should only be used when changes will be captured by a capture process.
The PREPARE_GLOBAL_INSTANTIATIONprocedure prepares for instantiation all of the database objects in a database and all database objects added to the database in the future. This procedure should only be used when changes will be captured by a capture process.
These procedures record the lowest SCN of each object for instantiation. SCNs subsequent to the lowest SCN for an object can be used for instantiating the object. If you use a capture process to capture changes, then these procedures also populate the Oracle Streams data dictionary for the relevant capture processes, propagations, and apply processes that capture, propagate, or apply changes made to the table, schema, or database being prepared for instantiation. In addition, these procedures optionally can enable supplemental logging for key columns or all columns in the tables that are being prepared for instantiation.
Note:
Replication with synchronous capture does not use the Oracle Streams data dictionary.When you add rules to the positive rule set for a capture process or synchronous capture by running a procedure in the DBMS_STREAMS_ADM package, a procedure or function in the DBMS_CAPTURE_ADM package is run automatically on the database objects whose changes will be captured. Table 2-1 lists which procedure or function is run in the DBMS_CAPTURE_ADM package when you run a procedure in the DBMS_STREAMS_ADM package.
Table 2-1 DBMS_CAPTURE_ADM Package Procedures That Are Run Automatically
| When you run this procedure in the DBMS_STREAMS_ADM package | This procedure or function in the DBMS_CAPTURE_ADM package is run automatically |
|---|---|
|
|
|
|
|
|
|
|
|
More than one call to prepare for instantiation is allowed. If you are using downstream capture, and the downstream capture process uses a database link from the downstream database to the source database, then the objects are prepared for instantiation automatically when you run one of these procedures in the DBMS_STREAMS_ADM package. However, if the downstream capture process does not use a database link from the downstream database to the source database, then you must prepare the objects for instantiation manually.
When capture process rules are created by the DBMS_RULE_ADM package instead of the DBMS_STREAMS_ADM package, you must run the appropriate procedure manually to prepare each table, schema, or database whose changes will be captured for instantiation, if you plan to apply changes that result from the capture process rules with an apply process.
Note:
A synchronous capture only captures changes based on rules created by theADD_TABLE_RULES or ADD_SUBSET_RULES procedures.Whenever you add, or modify the condition of, a capture process, propagation, or apply process rule for a database object that is in a positive rule set, you must run the appropriate procedure to prepare the database object for instantiation at the source database if any of the following conditions are met:
One or more rules are added to the positive rule set for a capture process that instruct the capture process to capture changes made to the object.
One or more conditions of rules in the positive rule set for a capture process are modified to instruct the capture process to capture changes made to the object.
One or more rules are added to the positive rule set for a propagation that instruct the propagation to propagate changes made to the object.
One or more conditions of rules in the positive rule set for a propagation are modified to instruct the propagation to propagate changes made to the object.
One or more rules are added to the positive rule set for an apply process that instruct the apply process to apply changes made to the object at the source database.
One or more conditions of rules in the positive rule set for an apply process are modified to instruct the apply process to apply changes made to the object at the source database.
Whenever you remove, or modify the condition of, a capture process, propagation, or apply process rule for a database object that is in a negative rule set, you must run the appropriate procedure to prepare the database object for instantiation at the source database if any of the following conditions are met:
One or more rules are removed from the negative rule set for a capture process to instruct the capture process to capture changes made to the object.
One or more conditions of rules in the negative rule set for a capture process are modified to instruct the capture process to capture changes made to the object.
One or more rules are removed from the negative rule set for a propagation to instruct the propagation to propagate changes made to the object.
One or more conditions of rules in the negative rule set for a propagation are modified to instruct the propagation to propagate changes made to the object.
One or more rules are removed from the negative rule set for an apply process to instruct the apply process to apply changes made to the object at the source database.
One or more conditions of rules in the negative rule set for an apply process are modified to instruct the apply process to apply changes made to the object at the source database.
When any of these conditions are met for changes to a positive or negative rule set, you must prepare the relevant database objects for instantiation at the source database to populate any relevant Oracle Streams data dictionary that requires information about the source object, even if the object already exists at a remote database where the rules were added or changed.
The relevant Oracle Streams data dictionaries are populated asynchronously for both the local dictionary and all remote dictionaries. The procedure that prepares for instantiation adds information to the redo log at the source database. The local Oracle Streams data dictionary is populated with the information about the object when a capture process captures these redo entries, and any remote Oracle Streams data dictionaries are populated when the information is propagated to them.
Synchronous captures do not use Oracle Streams data dictionaries. However, when you are capturing changes to a database object with synchronous capture, you must prepare the database object for instantiation when you add rules for the database object to the synchronous capture rule set. Preparing the database object for instantiation is required when rules are added because it records the lowest SCN for instantiation for the database object. Preparing the database object for instantiation is not required when synchronous capture rules are modified, but modifications cannot change the database object name or schema in the rule condition.
See Also:
"Capture Process Overview" for more information about local and downstream capture
"Preparing Database Objects for Instantiation at a Source Database"
If a replication environment uses a capture process to capture changes, then supplemental logging is required. Supplemental logging places additional column data into a redo log whenever an operation is performed. The procedures in the DBMS_CAPTURE_ADM package that prepare database objects for instantiation are PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, and PREPARE_GLOBAL_INSTANTIATION. These procedures include a supplemental_logging parameter which controls the supplemental logging specifications for the database objects being prepared for instantiation.
Table 2-2 describes the values for the supplemental_logging parameter for each procedure.
Table 2-2 Supplemental Logging Options During Preparation for Instantiation
| Procedure | supplemental_logging Parameter Setting | Description |
|---|---|---|
|
|
|
The procedure enables supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the table being prepared for instantiation. The procedure places the logged columns for the table in three separate log groups: the primary key columns in an unconditional log group, the unique key columns and bitmap index columns in a conditional log group, and the foreign key columns in a conditional log group. |
|
|
|
The procedure enables supplemental logging for all columns in the table being prepared for instantiation. The procedure places all of the columns for the table in an unconditional log group. |
|
|
|
The procedure enables supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the tables in the schema being prepared for instantiation and for any table added to this schema in the future. Primary key columns are logged unconditionally. Unique key, bitmap index, and foreign key columns are logged conditionally. |
|
|
|
The procedure enables supplemental logging for all columns in the tables in the schema being prepared for instantiation and for any table added to this schema in the future. The columns are logged unconditionally. |
|
|
|
The procedure enables database supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the tables in the database being prepared for instantiation and for any table added to the database in the future. Primary key columns are logged unconditionally. Unique key, bitmap index, and foreign key columns are logged conditionally. |
|
|
|
The procedure enables supplemental logging for all columns in all of the tables in the database being prepared for instantiation and for any table added to the database in the future. The columns are logged unconditionally. |
|
Any Prepare Procedure |
|
The procedure does not enable supplemental logging for any columns in the tables being prepared for instantiation. |
If the supplemental_logging parameter is not specified when one of prepare procedures is run, then keys is the default. Some of the procedures in the DBMS_STREAMS_ADM package prepare tables for instantiation when they add rules to a positive capture process rule set. In this case, the default supplemental logging option, keys, is specified for the tables being prepared for instantiation.
Note:
When all is specified for the supplemental_logging parameter, supplemental logging is not enabled for columns of the following types: LOB, LONG, LONG RAW, user-defined type, and Oracle-supplied type.
Specifying keys for the supplemental_logging parameter does not enable supplemental logging of bitmap join index columns.
Oracle Database 10g Release 2 introduced the supplemental_logging parameter for the prepare procedures. By default, running these procedures enables supplemental logging. Prior to this release, these procedures did not enable supplemental logging. If you remove an Oracle Streams environment, or if you remove certain database objects from an Oracle Streams environment, then you can also remove the supplemental logging enabled by these procedures to avoid unnecessary logging.
See Also:
"Preparing Database Objects for Instantiation at a Source Database"
"DBMS_STREAMS_ADM Package Procedures Automatically Prepare Objects"
"Aborting Preparation for Instantiation at a Source Database" for information about removing supplemental logging enabled by the prepare procedures
The following sections contain information about Oracle Streams instantiations that use Oracle Data Pump.
See Also:
Oracle Streams Concepts and Administration for information about performing a full database export/import on a database using Oracle Streams
Oracle Database Utilities for more information about Data Pump
During export, Oracle Data Pump automatically uses the Oracle Flashback feature to ensure that the exported data and the exported procedural actions for each database object are consistent to a single point in time. When you perform an instantiation in an Oracle Streams environment, some degree of consistency is required. Using the Data Pump Export utility is sufficient to ensure this consistency for Oracle Streams instantiations.
If you are using an export dump file for other purposes in addition to an Oracle Streams instantiation, and these other purposes have more stringent consistency requirements than those provided by Data Pump's default export, then you can use the Data Pump Export utility parameters FLASHBACK_SCN or FLASHBACK_TIME for Oracle Streams instantiations. For example, if an export includes objects with foreign key constraints, then more stringent consistency might be required.
The following sections provide more information about Oracle Data Pump import and Oracle Streams instantiation.
During Data Pump import, an instantiation SCN is set at the import database for each database object that was prepared for instantiation at the export database before the Data Pump export was performed. The instantiation SCN settings are based on metadata obtained during Data Pump export.
A Data Pump import session can set its Oracle Streams tag to the hexadecimal equivalent of '00' to avoid cycling the changes made by the import. Redo entries resulting from such an import have this tag value.
Whether the import session tag is set to the hexadecimal equivalent of '00' depends on the export that is being imported. Specifically, the import session tag is set to the hexadecimal equivalent of '00' in either of the following cases:
The Data Pump export was in FULL or SCHEMA mode.
The Data Pump export was in TABLE or TABLESPACE mode and at least one table included in the export was prepared for instantiation at the export database before the export was performed.
If neither one of these conditions is true for a Data Pump export that is being imported, then the import session tag is NULL.
Note:
If you perform a network import using Data Pump, then an implicit export is performed in the same mode as the import. For example, if the network import is in schema mode, then the implicit export is in schema mode also.
The import session tag is not set if the Data Pump import is performed in TRANSPORTABLE TABLESPACE mode. An import performed in this mode does not generate any redo data for the imported data. Therefore, setting the session tag is not required.
See Also:
Chapter 4, "Oracle Streams Tags"The STREAMS_CONFIGURATION Data Pump Import utility parameter specifies whether to import any general Oracle Streams metadata that is present in the export dump file. This import parameter is relevant only if you are performing a full database import. By default the STREAMS_CONFIGURATION Import utility parameter is set to y. Typically, specify y if an import is part of a backup or restore operation.
The following objects are imported regardless of the STREAMS_CONFIGURATION setting if the information is present in the export dump file:
ANYDATA queues and their queue tables
Queue subscribers
Advanced Queuing agents
Rules, including their positive and negative rule sets and evaluation contexts. All rules are imported, including Oracle Streams rules and non-Oracle Streams rules. Oracle Streams rules are rules generated by the system when certain procedures in the DBMS_STREAMS_ADM package are run, while non-Oracle Streams rules are rules created using the DBMS_RULE_ADM package.
If the STREAMS_CONFIGURATION parameter is set to n, then information about Oracle Streams rules is not imported into the following data dictionary views: ALL_STREAMS_RULES, ALL_STREAMS_GLOBAL_RULES, ALL_STREAMS_SCHEMA_RULES, ALL_STREAMS_TABLE_RULES, DBA_STREAMS_RULES, DBA_STREAMS_GLOBAL_RULES, DBA_STREAMS_SCHEMA_RULES, and DBA_STREAMS_TABLE_RULES. However, regardless of the STREAMS_CONFIGURATION parameter setting, information about these rules is imported into the ALL_RULES, ALL_RULE_SETS, ALL_RULE_SET_RULES, DBA_RULES, DBA_RULE_SETS, DBA_RULE_SET_RULES, USER_RULES, USER_RULE_SETS, and USER_RULE_SET_RULES data dictionary views.
When the STREAMS_CONFIGURATION Import utility parameter is set to y, the import includes the following information, if the information is present in the export dump file; when the STREAMS_CONFIGURATION Import utility parameter is set to n, the import does not include the following information:
Capture processes that capture local changes, including the following information for each capture process:
Name of the capture process
State of the capture process
Capture process parameter settings
Queue owner and queue name of the queue used by the capture process
Rule set owner and rule set name of each positive and negative rule set used by the capture process
Capture user for the capture process
The time that the status of the capture process last changed. This information is recorded in the DBA_CAPTURE data dictionary view.
If the capture process disabled or aborted, then the error number and message of the error that was the cause. This information is recorded in the DBA_CAPTURE data dictionary view.
Synchronous captures, including the following information for each synchronous capture:
Name of the synchronous capture
Queue owner and queue name of the queue used by the synchronous capture
Rule set owner and rule set name of each rule set used by the synchronous capture
Capture user for the synchronous capture
If any tables have been prepared for instantiation at the export database, then these tables are prepared for instantiation at the import database.
If any schemas have been prepared for instantiation at the export database, then these schemas are prepared for instantiation at the import database.
If the export database has been prepared for instantiation, then the import database is prepared for instantiation.
The state of each ANYDATA queue that is used by an Oracle Streams client, either started or stopped. Oracle Streams clients include capture processes, propagations, apply process, and messaging clients. ANYDATA queues themselves are imported regardless of the STREAMS_CONFIGURATION Import utility parameter setting.
Propagations, including the following information for each propagation:
Name of the propagation
Queue owner and queue name of the source queue
Queue owner and queue name of the destination queue
Destination database link
Rule set owner and rule set name of each positive and negative rule set used by the propagation
Oracle Scheduler jobs related to Oracle Streams propagations
Apply processes, including the following information for each apply process:
Name of the apply process
State of the apply process
Apply process parameter settings
Queue owner and queue name of the queue used by the apply process
Rule set owner and rule set name of each positive and negative rule set used by the apply process
Whether the apply process applies captured LCRs in a buffered queue or messages in a persistent queue
Apply user for the apply process
Message handler used by the apply process, if one exists
DDL handler used by the apply process, if one exists.
Precommit handler used by the apply process, if one exists
Tag generated in the redo log for changes made by the apply process
Apply database link, if one exists
Source database for the apply process
The information about apply progress in the DBA_APPLY_PROGRESS data dictionary view, including applied message number, oldest message number (oldest SCN), apply time, and applied message create time
Apply errors
The time that the status of the apply process last changed. This information is recorded in the DBA_APPLY data dictionary view
If the apply process disabled or aborted, then the error number and message of the error that was the cause. This information is recorded in the DBA_APPLY data dictionary view
DML handlers
Error handlers
Update conflict handlers
Substitute key columns for apply tables
Instantiation SCN for each apply object
Ignore SCN for each apply object
Messaging Clients, including the following information for each messaging client:
Name of the messaging client
Queue owner and queue name of the queue used by the messaging client
Rule set owner and rule set name of each positive and negative rule set used by the messaging client
Message notification settings
Some data dictionary information about Oracle Streams rules. The rules themselves are imported regardless of the setting for the STREAMS_CONFIGURATION parameter.
Data dictionary information about Oracle Streams administrators, messaging clients, message rules, extra attributes included in LCRs captured by a capture process or synchronous capture, and extra attributes used in message rules.
Note:
Downstream capture processes are not included in an import regardless of theSTREAMS_CONFIGURATION setting.The RMAN DUPLICATE and CONVERT DATABASE commands can instantiate an entire database, and the RMAN TRANSPORT TABLESPACE command can instantiate a tablespace or set of tablespaces. Using RMAN for instantiation usually is faster than other instantiation methods. The following sections contain information about using these RMAN commands for instantiation.
The RMAN DUPLICATE command creates a copy of the target database in another location. The command uses an RMAN auxiliary instance to restore backups of the target database files and create a new database. In an Oracle Streams instantiation, the target database is the source database and the new database that is created is the destination database. The DUPLICATE command requires that the source and destination database are running on the same platform.
The RMAN CONVERT DATABASE command generates the datafiles and an initialization parameter file for a new destination database on a different platform. It also generates a script that creates the new destination database. These files can be used to instantiate an entire destination database that runs on a different platform than the source database but has the same endian format as the source database.
The RMAN DUPLICATE and CONVERT DATABASE commands do not set the instantiation SCN values for the database objects. The instantiation SCN values must be set manually during instantiation.
See Also:
Oracle Database Backup and Recovery User's Guide for instructions on using the RMAN DUPLICATE command and the RMAN CONVERT DATABASE command
The RMAN TRANSPORT TABLESPACE command uses Data Pump and an RMAN-managed auxiliary instance to export the database objects in a tablespace or tablespace set while the tablespace or tablespace set remains online in the source database. RMAN automatically starts up an auxiliary instance with a system-generated name. The RMAN TRANSPORT TABLESPACE command produces a Data Pump export dump file and datafiles for the tablespace or tablespaces.
Data Pump can be used to import the dump file at the destination database, or the ATTACH_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package can be used to attach the tablespace or tablespaces to the destination database. Also, instantiation SCN values for the database objects in the tablespace or tablespaces are set automatically at the destination database when the tablespaces are imported or attached.
Note:
The RMANTRANSPORT TABLESPACE command does not support user-managed auxiliary instances.