A database specification is required in the following components of the configuration file:
Database | Database type notation* | Database Identifiers |
---|---|---|
Oracle source |
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 Targe 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. |
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 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. For more information, see How to qualify object names. |
Database sequence |
tgt_owner.sequence |
The fully qualified name of a sequence. For more information, see How to qualify object names |
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 or JSON 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. For more information, see Configure replication to a change history target. |
The following instructions show you how to build a routing map based on where you want to send the source data. A routing map sends replicated data to the correct target on the correct target system, or systems.
For details about the components of these configurations, see:
Database specifications in a configuration file
Target specifications in a configuration file
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] |
There are special routing requirements for database targets that are hosted by a cloud service such as EC2 and RDS on Amazon AWS, Azure SQL in Microsoft Azure, and Compute Virtual Machines in Oracle Cloud Infrastructure. Whether the service is Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) makes a difference in how you install and configure SharePlex. The following explains these requirements.
If replicating to a database target hosted in an IaaS cloud service, specify the full endpoint URL as the target host in the routing map.
datasource_specification | ||
src_owner.table | tgt_owner.table2 | endpointURL@database_specification |
src_owner.table | tgt_owner.table3 | endpointURL@database_specification |
For example, the following routing map routes to a cloud database on Amazon EC2:
ec2-12-345-678-910.compute-1.amazonaws.com@o.myora
Alternately, you can map the private IP address of the cloud service to a short name in the local hosts file, and then specify that name as the host in the routing map, for example:
shortname@o.myora
If replicating to a database target hosted in a PaaS cloud service, there are special installation, setup, and routing requirements. Because SharePlex cannot be installed directly on a PaaS cloud server, you must install SharePlex on either the source server or an intermediary server, from which Post connects to the target cloud database. For more information, see Installation and setup for cloud-hosted databases in the SharePlex Installation and Setup Guide.
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:
All have identical column mappings or key mappings, if used. For more information about these mappings, see:
NoteS:
datasource_specification | ||
src_owner.table | tgt_owner.table |
host1[@database_specification]+host2[@database_specification][...] |
You can replicate between the following:
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] |
These are examples of basic configuration files according to each possible datasource type and target type.
This configuration applies to on-premises and IaaS cloud deployments. See the System Requirements in the SharePlex Installation and Setup Guide for supported database versions and platforms.
Datasource:o.SID | ||
src_owner.table | tgt_owner.table |
host@o.SID |
The following example replicates table SCOTT.EMP from Oracle instance oraA to target table SCOTT.EMP2 in Oracle instance oraB on target system sysprod.
Datasource:o.oraA SCOTT.EMP SCOTT.EMP2 sysprod@o.oraB
To replicate from an on-premises or IaaS-based Oracle source to a target Oracle database hosted in a PaaS cloud, the SharePlex target components (Import and Post) must run on the source server or on an intermediary server. Post connects through a remote connection using a TNS alias. To set up this topology, see Installation and setup for cloud-hosted databases in the SharePlex Installation and Setup Guide.
Datasource:o.SID | ||
src_owner.table | tgt_owner.table |
source_or_intermediary_host@o.SID |
The following example replicates table SCOTT.EMP from Oracle instance oraA to target table SCOTT.EMP2 in the PaaS cloud Oracle instance oraB. Post runs on intermediary target system sysprod2.
datasource:o.oraA SCOTT.EMP SCOTT.EMP2 sysprod2@o.oraB
This configuration applies to on-premises and IaaS cloud deployments. See the System Requirements in the SharePlex Installation and Setup Guide for supported database versions and platforms.
Datasource:o.SID | ||
src_owner.table | tgt_owner.table | host@r.database_name |
The following example replicates table SCOTT.EMP from Oracle instance oraA to target table Scott2.Emp2 in Open Target database mydb on target system sys2. The target table is case-sensitive.
Datasource:o.oraA SCOTT.EMP "Scott2"."Emp2" sys2@r.mydb
Datasource:o.SID | ||
src_owner.table | !file | host |
The following example replicates table SCOTT.EMP from Oracle instance oraA to a file on target system sysprod.
Datasource:o.oraA SCOTT.EMP !file sysprod
Datasource:o.SID | ||
src_owner.table | !jms | host |
The following example replicates table SCOTT.EMP from Oracle instance oraA to a JMS queue on target system sysprod.
Datasource:o.oraA SCOTT.EMP !jms sysprod
Datasource:o.SID | ||
src_owner.table | !kafka | host |
The following example replicates table SCOTT.EMP from Oracle instance oraA to a Kafka topic on target system sysprod.
Datasource:o.oraA SCOTT.EMP !kafka sysprod
This configuration applies to on-premises and IaaS cloud deployments. See the System Requirements in the SharePlex Installation and Setup Guide for supported database versions and platforms.
Datasource:o.PDBalias | ||
src_owner.table | tgt_owner.table |
host@o.PDBalias |
This example replicates table SCOTT.EMP from an Oracle PDB that uses the TNS alias of aliasA to target table SCOTT.EMP in an Oracle PDB that uses the TNS alias of aliasB on target system sysprod.
Datasource:o.aliasA SSCOTT.EMP SCOTT.EMP sysprod@o.aliasB
* You can also replicate data from an Oracle PDB to any other supported target. For more information, see Configure capture and delivery.
This configuration applies to on-premises and IaaS cloud deployments. See the System Requirements in the SharePlex Installation and Setup Guide for supported database versions and platforms.
Datasource: o.SID | ||
src_owner.table |
!cdc:tgt_owner.table |
host@c.SID |
The following example replicates table SCOTT.EMP from Oracle instance oraA to change-history target table SCOTT.EMP2 in Oracle instance oraB on target system sysprod.
Datasource:o.oraA SCOTT.EMP !cdc:SCOTT.EMP2 sysprod@c.oraB
For more information, see Configure replication to a change history target.
© ALL RIGHTS RESERVED. 使用条款 隐私 Cookie Preference Center