We mention instantiation as part of this chapter to stress its importance. Instantiation refers to the creation of the replicated object at target databases, based on the source object. It also provides Streams with the information needed to determine what transactions to apply at the destination site(s). You can think of it as an agreement (starting point) that needs to be established between the source and destination before any Streaming can be accomplished. The main purpose of instantiation is to prepare the object structure and data at the destination site to receive changes from the source.

Instantiation is a process composed of three steps:

The database objects, which are either tables or other objects, need to exist on both the source and destination site. Table structures between a source and destination database can differ if there is a transformation or subsetting involved, though often the tables will have the same data and the same structure. If there is data that needs to be replicated in the table(s) then the data should be the same at the source and destination sites at the time of instantiation, unless there is some sort of transformation, subsetting, or other apply or error handler put in place to compensate for the data differences. This becomes apparent when an update or delete DML fails due to data NOT being at the destination site(s) or having different values in the replicated columns.

Once instantiation is complete, the instantiation SCN will be the same at both the source and destination site(s), indicating to Streams that it is from this SCN forward that changes should be captured, propagated, and applied for the destination. The following image demonstrates this concept as it shows the instantiated Inventory Table with the same instantiation SCN at both the Source and Destination site.

Instantiation Levels and Methods can be accomplished at different levels depending on your requirements. These instantiation levels include:

The possible combinations of Instantiation Levels that can be used with Instantiation Methods can become confusing. So, with a handful of different methods to instantiate tables; How does one decide which method to use? In general, you can use Data Pump to instantiate all (or some) of the tables at Schema Level. You can also decide to move all tables to a particular tablespace and use transportable tablespaces. For now, we will focus on two methods that we use most often due to its ease of use and flexibility.

Using Data Pump to instantiate tables and schemas is fairly straightforward. The Data Pump export utility EXPDP will use Oracle Flashback to ensure that the export is consistent and at the same time capture the instantiation data. For greater control use the FLASHBACK_SCN or FLASHBACK_TIME parameters. On the import side, use the DataPump import utility IMPDP. If it is a full database import, use the parameter STREAMS_CONFIGURATION=y (the default value) to direct IMPDP to include any Streams related metadata that may be contained in the export.

If the replicated structures and data are the same on both sites, we recommend that you use DataPump Export/Import to instantiate (this can be done via DBMS_STREAMS_ADM.MAINTAIN_* scripts).

If the replicated structures are the same, but the data different between sites, we recommend instantiating objects via DataPump with CONTENT=METADATA_ONLY, and manual calls to necessary DBMS_STREAMS_ADM.ADD_RULE and DBMS_CAPTURE_ADM subprograms.

If the replicated structures and data are different between sites, we recommend that you create and populate the objects at each site manually, then call the necessary DBMS_STREAMS_ADM.ADD_RULE and DBMS_CAPTURE_ADM subprograms manually. Make sure to configure transformation rules for the structural differences, and handlers for the data differences. One important thing to remember is that if Capture, Propagation and Apply processes and rules are added, or modified, you will need to re-instantiate the SCN between the source and destination. You can do this by following the manual method.