This topic shows you how to specify case-sensitive names in the configuration file, for example when specifying table names or if you need to specify column names explicitly in a column mapping.
Case-sensitive object names
If the owner or name of an object is case-sensitive in the database, you must enclose that name within quotes in the SharePlex configuration file.
Important: This applies whether the database itself requires a case-sensitive name to be within quotes, such as Oracle, or whether the database accepts names that are spelled out in their case-sensitive form without quotes, like SQL Server.
To enforce case-sensitive object names:
Specify the name in its correct case and enclose it within double quotes.
Correct way
-
This is how to specify an object where both the owner and object names are both case-sensitive:
"Owner"."Object"
-
This is how to specify an object where only one of the components is case-sensitive:
owner."Object" or "Owner".object
The name that is not case-sensitive can be specified in any case.
Examples of both ways:
|
Datasource o.oraA |
|
|
|
sales."Emp" |
"Sales"."Emp" |
sysB@o.oraB |
Incorrect way
This is not correct, because both components are within one set of quotes:
"Sales.Employees"
Case-sensitive column names
Ordinarily, column names are not specified in the configuration file, unless source column names need to be mapped to different target column names by means of a column mapping (see Map Source and Target Columns). However, if the names of any pair of source and target columns have difference cases, you may need to include them in a column mapping to enforce their case sensitivity. Whether or not a column mapping is required depends on the target type: Oracle or Open Target.
To enforce case-sensitive column names for Oracle to Oracle replication
The Oracle Post process does not perform case conversion of column names automatically for Oracle to Oracle replication. If the case is different between source and target columns, you must use a column map to map the case of the source names to the case of the target names. To get Post to enforce the case, specify the name in its correct case and enclose it within double quotes.
This is an example of case-sensitive column name mapping in a column map:
|
Datasource o.oraA |
|
|
|
sales.emp(ID,"first","last") |
sales.emp(ID,"First","Last") |
sysB@o.oraB |
To enforce case-sensitive column names to Open Target:
The Open Target Post process performs case conversion of column names automatically. If replicating to target columns that have a different case from their source columns, no column mapping is needed.
A database specification is required in the following components of the configuration file:
- the datasource (source datastore) specification
- routing map (target datastore and location) specification
| 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.
- The Oracle SID of a regular (non-CDB) Oracle database, as in o.ora12.
- The TNS alias of a pluggable database (PDB) in an Oracle container database (CDB), as in o.pdb1.
- The global TNS alias of an Oracle RAC cluster, as in o.rac1. SharePlex connects to an Oracle RAC instance through this TNS alias, which is mapped locally on each node to the Oracle SID of the local Oracle instance. For more information about creating this alias, see Installation and Setup for HA Cluster in the SharePlex Installation Guide.
|
| 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.
| 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, XML, or JSON 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, AVRO, 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
Routing to one target
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] |
Routing to a cloud service
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, Google Cloud SQL for PostgreSQL, 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.
IaaS targets
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
PaaS targets
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.
Routing to multiple targets
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:
| datasource_specification |
| src_owner.table |
tgt_owner.table |
host1[@database_specification]+host2[@database_specification][...] |
Routing between objects on the same system
You can replicate between the following:
- For Oracle, 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.
Configuration with replication to objects in the same or different database on the same system
| datasource_specification |
| src_owner.table |
tgt_owner.table |
host*host[@database_specification] |
Routing limitations
- By default, SharePlex supports replication to a maximum of 19 direct target systems. That is the maximum number of processes that can read the export queue. To replicate to more than 19 targets, use named export queues. With each additional queue that you add, you can replicate to 19 additional targets. For more information, see Configure Named Export Queues.
- Each instance of sp_cop on a system permits a maximum of 1024 different routes. This limitation includes each route that uses a different named post queue (see Configure Named Post Queues.) If your replication strategy requires more than 1024 routes, consider using one or more intermediary systems to divide the routes among multiple sp_cop instances. For more information, see Configure Replication to Share or Distribute Data.
- By default, each sp_cop instance allows a total of 25 queues on a system. There will always be one capture queue on a source system and one post queue on a target. Therefore, you can have as many as 24 named export queues on a source system and 24 named post queues on a target system. If a system serves as both a source and target, you will have both a capture queue and a post queue. That allows you to create up to 23 named queues of either type (or a mix of both). If system memory permits, you can change the number of allowed queues by setting the SP_QUE_MAX_QUEUES parameter. See the SharePlex Reference Guide for more information about this parameter.
