To configure SharePlex to replicate data, you create a configuration file. This is an ASCII text file in which you specify:
Only a SharePlex Administrator or operator has the authority to create a configuration file.
When your configuration file is completed and the SharePlex environment is set up to support your replication objectives, you activate the configuration with the activate config command to begin replication. For more information, see Activate replication in your production environment.
You can create a configuration file by hand or, if your data structure supports it, you can automate the creation of a configuration file. For more information, see Build a configuration file using a script.
Create the configuration file on the system from which data is to be replicated, typically the source system, but strategies such as active-active replication require configuration files on more than one system.
To create a configuration file
In sp_ctrl, issue the create config command.
sp_ctrl> create config config_name
This command opens a file in the default text editor that is set for the operating system. Note: You can change the default editor that sp_ctrl uses. For more information, see Set a default editor for sp_ctrl.
Complete the configuration file. For more information, see Structure of a configuration file.
Important! All configurations must reside in the config sub-directory of the SharePlex variable-data directory. Configuration files outside this directory cannot be activated. SharePlex places configurations in this directory by default when you create them through the sp_ctrl interface with the create config command. If you create the configuration directly through a text editor, make certain to save it to the config sub-directory.
A basic configuration file looks like the following:
# comment: basic SharePlex configuration file | ||
datasource_specification | ||
#source specification |
target specification |
routing map |
source_owner.object1 |
target_owner.object1 |
routing_map |
source_owner.object2 |
target_owner.object2 |
routing_map |
source_owner.object3 |
target_owner.object3 |
routing_map |
The basic components of a configuration file are as follows. For advanced configuration options, see Additional configuration options
Component | Description | Syntax examples |
---|---|---|
# Comments | Lines that describe the file or provide other information about the contents to viewers, but are not used by SharePlex. Precede each comment line with a pound (#) sign. Comments may be entered anywhere in the configuration file. | # This is a comment. |
Datasource specification |
Syntax that specifies the source database. This component must always be the first non-commented line of a configuration file. It has the following syntax elements, all on the same line with no spaces:
|
Datasource:o.SID |
Source specification |
The fully qualified name of a supported source object, in the form of owner.object, or a wildcard substitution that specifies multiple source objects. See Use Wildcards to specify multiple objects for more information about using wildcards. |
src_owner.table src_owner.sequence |
Target specification |
The target to which the replicated data is applied. Targets supported by SharePlex are:
For more information, see Target specifications in a configuration file. |
tgt_owner.table tgt_owner.sequence !file[:tgt_owner.table] !jms[:tgt_owner.table] !kafka[:tgt_owner.table] !cdc:tgt_owner.table |
Routing map |
One or more routes that send the data to the system that contains the target object specified with the target specification. A route consists of the following:
|
host@o.SID host@o.PDBalias host@o.tns_alias host@r.database_name host host@c.SID Compound routing map: host@o.SID+host@r.database[...] |
The following are additional configuration options that can be added to the configuration file:
Option | Where to look |
---|---|
Prevent INSERTs, UPDATEs, or DELETEs from being replicated, or prevent sequences and materialized views from being replicated | Filter DML operations |
Map a source column to a target column | Map source and target columns |
Define a key for SharePlex to use | Define a unique key |
Divide, parallelize, and filter data to meet specific requirements | Configure partitioned replication |
Divide and parallelize data for increased control and throughput | Configure named queues |
A database specification is required in the following components of the configuration file:
Database | Database type notation* | Database Identifiers |
---|---|---|
Oracle source or target |
o. |
Depending on the Oracle database configuration, use one of the following. This is the string that SharePlex will use to connect to the database.
|
Open Target targets |
r. |
Use to specify the name of an Open Target (non-Oracle) target database, as in r.mydb. Important! Use the actual database name. Do not use the ODBC datasource name (DNS) or database instance name. If the database name is case-sensitive, specify it that way. For more information about configuring SharePlex to replicate to a specific Open Target target, see Configure replication to Open Target targets. |
Oracle change-history target | c. |
Use in a routing map to specify the Oracle SID, tns_alias, or global RAC tns_alias of an Oracle change history database, as in c.ORA12CH. In this configuration, SharePlex applies all source transactions as INSERTs to the target tables, to maintain a history of every operation performed. For more information, see Configure replication to maintain a change history target. |
* Note: The dot is required.
The following table shows how to specify a target table or non-table target in a configuration file.
Target | Target Specification | Description |
---|---|---|
Database table | tgt_owner.table |
The fully qualified name of a database table. |
Database sequence |
tgt_owner.sequence |
The fully qualified name of a sequence. |
File | !file[:tgt_owner.table] |
The !file designator directs Post to write change operations to a file in SQL or SML format. The file name is applied internally by SharePlex. Optionally, you can specify the fully qualified name of a target table if the data will be consumed by a process that ultimately applies it to a database table. |
JMS | !jms[:tgt_owner.table] |
The !jms designator directs Post to write change operations to a JMS queue or topic in XML format. The queue or topic name can be defined by using the target command. Optionally, you can specify the fully qualified name of a target table if the data will be consumed by a process that ultimately applies it to a database table. |
Kafka |
!kafka[:tgt_owner.table] |
The !Kafka designator directs Post to write change operations to a Kafka topic in XML format. The topic name can be defined by using the target command. Optionally, you can specify the fully qualified name of a target table if the data will be consumed by a process that ultimately applies it to a database table. |
Change history table |
!cdc:tgt_owner.table |
The !cdc designator directs Post to insert every data change to the table as a new row, rather than overlay the old data with new data. Specify the fully qualified name of the change history table. See Configure replication to maintain a change history target. |
The following instructions show you how to build a routing map. A routing map sends replicated data to the correct target on the correct target system.
A simple routing map sends replicated data from one source object to one target object.
datasource_specification | ||
src_owner.table | tgt_owner.table2 | host2[@database_specification] |
src_owner.table | tgt_owner.table3 | host3[@database_specification] |
A compound routing map sends replicated data from one source object to multiple target objects. It enables you to specify the source and target objects once for all routes, rather than type a separate configuration entry for each route. Only one target specification can be used in a compound routing map, so all of the target objects must be identical as follows:
NoteS:
datasource_specification | ||
src_owner.table | tgt_owner.table |
host1[@database_specification]+host2[@database_specification][...] |
You can replicate between objects that are in the same database or in different databases on the same system. You can replicate between objects that have the same name, so long as their owners are different.
When SharePlex replicates between objects on the same system, it does not create Import and Export processes. You can force SharePlex to create Import and Export processes by using the following routing map. If you do not need the Import or Export processes, omit the host* portion of the routing map.
datasource_specification | ||
src_owner.table | tgt_owner.table |
host*host[@database_specification] |
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy