SharePlex 12.0 - Installation and Setup Guide

The SharePlex Post process can connect and write to a Kafka broker. The data can be written in JSON, AVRO, and XML output as a sequential series of operations as they occurred on the source, which can then be consumed by a Kafka consumer.

These instructions contain setup instructions that are specific to this target. Install SharePlex on the source and target according to the appropriate directions in this manual before performing these setup steps.

For the versions, data types and operations that are supported when using SharePlex to replicate to this target, see the SharePlex Release Notes.

Guidelines for posting to Kafka

A SharePlex Post process acts as a Kafka producer. A SharePlex Post process can write to one or more topics that have one or more partitions.
The SharePlex Post process does not create a topic itself, but you can configure the Kafka broker to auto-create topics.

Configure SharePlex on the source

You need to setup SharePlex and the database on the Oracle source system. For detailed setup steps, see Configure SharePlex on the source.

Configure SharePlex on the target

These instructions configure the SharePlex Post process to connect to Kafka. You must have a running Kafka broker.

To configure post to Kafka:

Create a Kafka topic.
Start sp_cop. (Do not activate the configuration yet.)
Run sp_ctrl.
Issue the target command to configure posting to a Kafka broker and topic. The following are example commands.

sp_ctrl> target x.kafkaset kafka broker=host1:9092,host2:9092,host3:9092

sp_ctrl> target x.kafka set kafka topic=shareplex

See View and change Kafka settings for command explanations and options.

Note: Specify more than one broker so that SharePlex will attempt to connect to the other brokers in the list if any one of them is down.

To configure posting to multiple Kafka instances using a single SharePlex instance:

For details on setting up multiple Kafka instances with a single SharePlex instance, refer to Replicating from a regular Oracle instance to multiple Kafka instances using a single SharePlex instance in the SharePlex Admin Guide.

Set the Kafka record format

SharePlex can output to either JSON, AVRO, and XML format as input to Kafka. XML is the default. To set the input format and specify format options, use one of the following target commands:

target x.kafka set format record=json

target x.kafka set format record=xml

target x.kafka set format record=avro

To view samples of these formats, see the format category of the target command documentation in the SharePlex Reference Guide.

Note: When replicating data from Oracle to Kafka in JSON format, SharePlex does not support the varray data type or the varray type inside the SDO_GEOMETRY data type.

View and change Kafka settings

To view current property settings for output to Kafka, use the following target command:

target x.kafka show

To change a property setting, use the following command.

target x.kafka [queue queuename] set kafka property=value

where:

queue queuename is the name of a Post queue. Use this option if there are multiple Post processes.
property and value are shown in the following table.

Table 1: Kafka target properties

Property

Input Value

Default

broker=broker

Required. The host and port number of the Kafka broker, or a comma delimited list of multiple brokers. This list is the bootstrap into the Kafka cluster. So long as Post can connect to one of these brokers, it will discover any other brokers in the cluster.

localhost:9092

client_id=ID

Optional. A user-defined string that Post will send in each request to help trace calls.

None

compression.code={none, gzip, snappy}

Optional. Controls whether data is compressed in Kafka. Options are none, gzip or snappy.

None

partition={number | rotate | rotate trans| messagekey}

Required. One of the following:

A fixed partition number: Directs Post to post messages only to the specified partition number. For example, setting it to 0 directs Post to post only to partition 0. This option is suitable for use in testing or if the target has multiple channels of data posting to the same Kafka topic.
The keyword rotate: Directs Post to apply messages to all of the partitions of a topic in a round-robin fashion. The partition changes with each new message. For example if a topic has three partitions, the messages are posted to partitions 0,1,2,0,1,2, and so on in that order.
The keyword rotate trans: This is similar to the rotate option, except that the partition is incremented with each transaction rather than with each message. For example, if a topic has three partitions, the messages are posted to partition 0 until the commit, then to partition 1 until the commit, and so on in that order. This option is suitable if you are replicating multiple tables to a single topic. It allows you to distribute data across several partitions, while still preserving all of the operations of a transaction together in a single partition. This enables a consumer that reads from a single partition to receive a stream of complete transactions.
The keyword messagekey: Directs Post to post messages to partitions. The Kafka topics are divided into several partitions. These partitions are selected based on the default partition hash function. The hash value is calculated based on messagekey. Use the messagekey partition to place all messages with the same key values in the same partition.

Notes:

The LOB and CLOB columns are not considered Kafka partition keys.
For a table without a primary key, unique key, composite key, or unique index, all columns (except LOB and CLOB columns) will be considered key columns. When performing an alter query on such a table, the DDL statement will be replicated to all partitions, and subsequent DML statements will be sent to specific partitions based on the existing columns.
If the replication table has no key defined, SharePlex will consider all table columns as Kafka messagekey. For non-key tables, it is recommended to use SharePlex user-defined keys. For more information, see the Define a Unique Key: PostgreSQL to PostgreSQL section in the SharePlex Admin Guide.
In cases where multiple tables are involved in replication, if we want a specific table to have a different partition type, while the remaining tables are partitioned based on the messagekey, we can define a named post queue for those specific tables.

For example:

target x.kafka queue <queue_name> set kafka partition={number/rotate/rotate trans}

For the rest of the tables, use the below command:

target x.kafka set kafka partition=messagekey

Important:

When partitioning is based on the messagekey, messages that do not contain key information will be mapped according to Kafka's internal hash function. These messages may include commit, schema, rollback, savepoint, and DDL statements.

During replication, if the number of partitions is increased, the existing mapping of keys to partitions will no longer remain valid.

For tables with a few columns serving as indexes and no other constraints defined, use those indexes as unique keys in the SharePlex config file.

For example, the following table has a unique index defined on two columns: ID and NAME.

create table mytable(ID NUMBER(25,2),NAME CHAR(200),COL_VARCHAR2 VARCHAR2(400),COL_RAW RAW(1000));

CREATE INDEX indx_mytable ON mytable(ID,NAME);

In the SharePlex config file, define the index columns as a unique key.

datasource:o.SID
src.mytable	!key(ID,NAME)	host

For more information, see the Define a Unique Key: Oracle to Oracle section in the SharePlex Admin Guide.

For tables with no constraints or indexes defined, users can define unique keys during configuration in SharePlex.

For a table that has a composite key, if any of the key values are modified, the modification message will be placed in the current partition, and subsequent messages may or may not be assigned to the same partition.

request.required.acks=value

Optional. This is a Kafka client parameter. By default it is set to a value of -1, which means all. Consult the Kafka documentation about this subject, because all really means all in-sync replicas. This parameter can be used in conjunction with the min.insync.replicas broker parameter to tune behavior between availability and data consistency.

Important: It is possible for data to be lost between a Kafka producer (SharePlex in this case) and a Kafka cluster, depending on these settings.

-1

topic=topic_name

Required. The name of the target Kafka topic.

This string may contain the special sequences %o or %t. The %o sequence is replaced by the owner name of the table that is being replicated. The %t sequence is replaced by the table name of the table that is being replicated. This feature may be used in conjunction with a Kafka server setting of auto.create.topics.enabled set to 'true'. Also view your server settings for default.replication.factor and num.partitions because these are used as defaults when topics are auto created.

Important! If using multiple topics, you must also set the following properties with the target command:

The output must be in JSON. Set the record property of the format category to json:

target x.kafka set format record=json
Commits must be disabled. Set the commit property of the json category to no:

target x.kafka set json commit=no

shareplex

* To avoid latency, if Post detects no more incoming messages, it sends the packet to Kafka immediately without waiting for the threshold to be satisfied.

Set recovery options

If the Kafka process aborts suddenly, or if the machine that it is running on aborts, row changes may be written twice to the Kafka topic. The consumer must manage this by detecting and discarding duplicates.

Every record of every row-change operation in a transaction has the same transaction ID and is also marked with a sequence ID. These attributes are id and msgIdx, respectively, under the txn element in the XML output (see Set up replication from Oracle to Kafka).

The transaction ID is the SCN at the time the transaction was committed, and the sequence ID is the index of the row change in the transaction. These two values are guaranteed to be the same if they are re-written to the Kafka topic in a recovery situation.

If desired, you can configure Post to include additional metadata with every row-change record by using the following command:

target x.kafka [queue queuename] set metadata property[, property]

Table 2: Optional metadata properties

Property	Description
time	The time the operation was applied on the source.
userid	The ID of the database user that performed the operation.
trans	The ID of the transaction that included the operation.
size	The number of operations in the transaction.

Example:

target x.kafka set metadata time, userid, trans, size

To reset the metadata:

target x.kafka [queue queuename] reset metadata

To view the metadata:

target x.kafka [queue queuename] show metadata

Set up replication from Oracle to JMS

Overview

The SharePlex Post process can connect and write to a JMS (Java Messaging Service) queue or topic. The data is written as XML records that include the data definitions, the operation type, and the changed column values. This data is written as a sequential series of operations as they occurred on the source, which can then be posted in sequential order to a target database or consumed by an external process or program.

For the versions, data types and operations that are supported when using SharePlex to replicate to this target, see the SharePlex Release Notes.

Configure SharePlex on the source

You need to setup SharePlex and the database on the Oracle source system. For detailed setup steps, see Configure SharePlex on the source.

Configure SharePlex on the target

These instructions establish the Java provider on the target and configure the SharePlex Post process to connect to a JMS provider.

Prerequisites

Java Runtime Environment 1.8 or later. JRE 1.8 (or later) is required and installed along with SharePlex except on the following operating systems:

CentOS Linux 7.x and 8.x
Oracle Linux 7.x and 8.x
RHEL Linux 7.x and 8.x

Prior to installing SharePlex on one of these systems, ensure JRE 1.8 (or later) is installed. Then after installing SharePlex, modify the bridge configuration file to point to the JRE binary. See the "Custom JRE" steps in each of the following procedures.

Using a JRE version later than 1.8. If you are using JMS Provider libraries compiled with a version of JRE later than 1.8, use that later version of JRE and modify the bridge (Linux/Unix) or bridge.ini (Windows) configuration file to point to that JRE binary. See the "Custom JRE" steps in each of the following procedures.

Configure SharePlex on the JMS target

These instructions configure the SharePlex Post process to post to a JMS queue or topic.

NoteS:

The JMS Provider does not necessarily need to be installed on the same machine where SharePlex is running, but you will need to copy the Provider's JMS libraries to a location in the SharePlex installation directory according to these instructions.
Ensure that you are using a compatible version of client libraries for your JMS Provider.
SharePlex is distributed with JRE 1.8. If the JMS libraries for the JMS Provider you are using are compiled with a JRE version later than 1.8, modify the bridge (or bridge.ini) configuration file as described here. Otherwise, SharePlex returns an error similar to one of the following.

INFO 2016-05-10 01:43:42.000860 [x.jms+jsd-olinux-01] com.quest.shareplex.openbridge.stomp.internal.Connector - Connector x.jms+jsd-olinux-01 at tcp://localhost:61613 stopped.

ERROR 2016-05-10 01:43:42.000861 [x.jms+jsd-olinux-01] com.quest.shareplex.openbridge.stomp.internal.Connector - org/apache/activemq/jndi/ActiveMQInitialContextFactory : Unsupported major.minor version 51.0

java.lang.UnsupportedClassVersionError: org/apache/activemq/jndi/ActiveMQInitialContextFactory : Unsupported major.minor version 51.0

The following directory naming conventions are used in the examples in this procedure:

Name	Directory
SharePlex	The SharePlex installation directory

To configure post to the JMS target:

Create a directory for your Provider under SharePlex/lib/providers. For example:

shareplex/lib/providers/provider_name

If your Provider is Active MQ, the path may look similar to the following:

shareplex/lib/providers/amq
Copy the client library files you require to the provider_name directory.

For example, if your Provider is Active MQ, you might copy the following JAR files to the amq directory.

shareplex/lib/providers/amq/activemq-all.jar

shareplex/lib/providers/amq/slf4j.jar
(Custom JRE) If you are using a JRE version later than 1.8, set the JAVA_HOME and JRE_HOME variable values to the path to your JRE home directory. In addition, add the JAVA_HOME path to the PATH variable.
(Custom JRE) If you are using a JRE other than the one installed with SharePlex which is 1.8.0_312 (e.g., SharePlex did not install JRE on your operating system or you must use a JRE version later than 1.8), modify the bridge.ini or bridge file to point to the JRE binary you intend to use.

Use the following methods:
- On Windows:
  1. The bridge.ini file is located in the following directory:
    
    SharePlex/bin/openbridge
  2. If a JRE was installed during the SharePlex installation, it is located in the following directory:
    
    SharePlex/bin/openbridge/jre
  3. In the bridge.ini file, locate the line containing the "-vmargs" option. On a separate line before "-vmargs" add the "-vm" option and use it to specify the full path to the JRE you intend to use. For example:
    
    -vm
    
    C:\Java\JDK\1.8\bin\javaw.exe
    
    -vmargs
    
    You must specify the absolute path to your JRE, not the relative path.
- On Linux or Unix:
  1. The bridge file is located in the following directory:
    
    SharePlex/.app-modules/openbridge
  2. If a JRE was installed during the SharePlex installation, it is located in the following directory:
    
    SharePlex/.app-modules/openbridge/jre
  3. In the bridge file, locate the _jvm option (for example< _jvm = "jre/bin/java") and replace the current path with the full path to the JRE you intend to use. You must specify the absolute path to your JRE, not the relative path.
Start sp_cop. (Do not activate the configuration yet.)
Run sp_ctrl.
Issue the target command to configure Post to post to the JMS queue or topic. The values you set using the target command tell SharePlex how to instantiate on the target. In the following examples, user-defined values are shown in italics. Replace these with values specific to your JMS Provider and your provider-specific JMS libraries.

Issue the following commands, as necessary. For detailed descriptions of the properties and values, see View and change JMS settings. For more information about the target command, see the SharePlex Reference Guide.

If posting to a JMS queue:

sp_ctrl> target x.jmsset jms factory_class=factory_class

sp_ctrl> target x.jms set jms provider_url=url

sp_ctrl> target x.jms set jms lib_location=path

For example, if using Active MQ you might set the following:

sp_ctrl> target x.jms set jms lib_location=shareplex/lib/providers/amq

sp_ctrl> target x.jms set jms queuename=JMS_topic_queuename

If posting to a JMS topic:

sp_ctrl> target x.jmsset jms factory_class=factory_class

sp_ctrl> target x.jms set jms provider_url=url

sp_ctrl> target x.jms set jms lib_location=path

For example, if using Active MQ you might set the following:

sp_ctrl> target x.jms set jms lib_location=shareplex/lib/providers/amq

sp_ctrl> target x.jmsset jms destination=topic

sp_ctrl> target x.jms set jms queuename=JMS_topic_queuename

Enable logs for JMS replication

We need to implement the logging mechanism with a different approach than the one we used earlier for legacy framework. In the current version, we have removed the -OB_debugToLog, -OB_debugToConsole parameters. Now, users get more control to generate and retain the log details by resetting properties inside the log4j2.properties file.

To enable the logs for JMS, follow the below steps:

Navigate to <Prod/Opt_Directory>/.app-modules/openbridge/configuration/ location and update the required parameters in the log4j2.properties file.
Restart SharePlex.
To enable full debug, set rootLogger.level to All. There are other possible values for rootLogger.level which are mentioned in the form of comments in the log4j2.properties file.
To enable console logging, set appender.console.filter.threshold.level to All. There are other possible values for appender.console.filter.threshold.levelwhich are mentioned in the form of comments in the log4j2.properties file.

Note: You can change other parameters as per standard log4j2.properties syntax. Refer to the below link for information.
https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties

View and change JMS settings

To view current property settings for output to JMS, use the following command:

target x.jms show

To change a property setting, use the following command.

target x.jms [queue queuename] set jms property=value

where:

queue queuename is the name of a Post queue. Use this option if there are multiple Post processes.
property and value are shown in the following table.

Table 3: JMS target properties

Property	Input Value	Default
factory_class=factory_class	Required Fully qualified class name of the factory class. Sets the JNDI environmental property java.naming.factory.initial to specify the class name of the initial context factory for the provider.	None
provider_url=url	Required RMI URL with no object name component. This sets the JNDI environmental property java.naming.provider.url to specify the location of the registry that is being used as the initial context. Use the correct format depending your JMS Provider and type of URL. For example, if using LDAP your URL might be similar to the following: ldap://hostname.company.com/contextName Ask your JMS Provider Administrator for the JMS Provider URL.	None
lib_location=path	Required Path to the directory where you installed the client library files.	None
destination={queue \| topic}	Messaging domain. Valid values are queue (port-to-port) or topic (publisher-subscriber model).	queue
factory_name=factory_name	Name of a JNDI connection factory lookup. You can specify multiple names with a comma-separated list, for example: (jndi.name1, jndi.name2).	None
user=user	Name of the user that is attaching to JMS. If authentication is not required, omit this and the password option.	None
password=password	Password of the JMS user.	None
queuename=JMS_topic_queuename	Name of the JMS queue or topic.	OpenTarget
persistent={yes \| no}	yes logs messages to disk storage as part of send operations. no prevents logging.	yes
session_transacted ={yes \| no}	no directs Post to issue a JMS commit for every replicated message, making each one immediately visible and consumable. This is the default. yes directs Post to operate in a transactional manner. In this mode, Post issues a JMS commit (to make messages visible and consumable) at intervals based on the following: Issue a commit before the data is read-released from the Post queue, as controlled by the value set for the SP_OPX_READRELEASE_INTERVAL parameter. Issue a commit every JMS write, as controlled by the value set for the SP_OPX_CHECKPOINT_FREQ parameter, until the SP_OPX_READRELEASE_INTERVAL is reached.	no
properties	Use this option if the JMS provider that you are using cannot consume messages that contain the default set of properties supplied by SharePlex. It enables you to remove or add properties. Supply the properties as a comma-delimited list. To add a property, specify it as name=value. To remove a SharePlex property, prefix the name with a dash. For example this string removes two SharePlex properties: -JMSXDeliveryCount,-JMSXGroupSeq.	None
client_id	Use this option if the JMS provider that you are using cannot consume messages that contain the default SharePlex client ID. Set this value to the client ID that your provider accepts.	None
commit_frequency	Use this option when Post is configured to post to a JMS server in transactional style (issue a JMS commit at intervals, rather than after every message as directed by the session_transacted property). This parameter specifies the interval between JMS commits. It works in conjunction with the SP_OPX_READRELEASE_INTERVAL parameter. Valid values are 1 to any positive integer.	1500

Set recovery options

If the JMS process aborts suddenly, or if the machine that it is running on aborts, row changes may be written twice to the JMS target. The consumer must manage this by detecting and discarding duplicates.

The transaction ID is the SCN at the time the transaction was committed and the sequence ID is the index of the row change in the transaction. These two values are guaranteed to be the same if they are re-written to the JMS queue in a recovery situation.

If desired, you can configure the target to include additional metadata with every row-change record by using the following command:

target target [queue queuename] set metadata property[, property]

Table 4: Optional JMS metadata properties

Property	Description
time	The time the operation was applied on the source.
userid	The ID of the database user that performed the operation.
trans	The ID of the transaction that included the operation.
size	The number of operations in the transaction.

Example

target x.jms set metadata time, userid, trans, size

To reset the metadata:

target x.jms [queue queuename] reset metadata

To view the metadata:

target x.jms [queue queuename] show metadata

Control memory settings

If you configured Post to process large amounts of transactions to JMS through multiple named Post queues, you may need to allocate more memory to the Post JMS bridge. The default settings are 256MB and 512MB.

To increase the JMS bridge memory:

Open the openbridge.ini file and set the following parameters in the format shown:

-Xms=512m

-Xmx=1024m

-XX:PermSize=512m

-XX:MaxPermSize=1024m

Configure debugging

You can configure Post to log whether each write to a queue or topic succeeded or failed. This is controlled with the debugging setting.

To enable debugging:

Open the openbridge.ini file and set the -OB_debugToLog parameter to true.

-OB_debugToLog=true

View the XML format

To view the XML formatting of the records that SharePlex sends to JMS, see the format category of the target command documentation in the SharePlex Reference Guide.

Set up replication from Oracle to MariaDB

Pre-requisite: Schema support must be enabled in the MySQL DSN configuration to properly reference the table name during the replication process.

Overview

SharePlex can post replicated Oracle data to a MariaDB target database through an Open Database Connectivity (ODBC) interface.

For the versions, data types and operations that are supported when using SharePlex to replicate to this target, see the SharePlex Release Notes.

Install SharePlex

Important! If replicating to MariaDB on a PaaS cloud server (no access to the operating system), see the installation instructions in Installation and setup for cloud-hosted databases.

Review column names

To support replication between a source of one database type and a target of another type, the letter case of the names of the source and target columns must be the same, for example the column names on both sides in lower case or both sides in upper case. If the case differs between the source and target column names, use the column mapping feature to map the column names in the configuration file.

See SharePlex Administration Guide for more information about column mapping with SharePlex.

Configure SharePlex on the source

Set up SharePlex and the database on the Oracle source system as follows.

Make keys available to SharePlex

To replicate from an Oracle source to an Open Target target, you must make key information available to SharePlex.

Enable Oracle supplemental logging

Enable PK/UK supplemental logging in the Oracle source database. SharePlex must have the Oracle key information to build an appropriate key on the target.

Set SP_OCT_USE_SUPP_KEYS parameter

This parameter directs SharePlex to use the columns set by Oracle's supplemental logging as the key columns when a row is updated or deleted. When both supplemental logging and this parameter are set, it ensures that SharePlex can always build a key and that the SharePlex key will match the Oracle key.

See the SharePlex Reference Guide for more information about this parameter.

Configure replication

On the source, create a SharePlex configuration file that specifies capture and routing information.

Datasource:o.SID
src_owner.table	tgt_owner.table	host@r.database_name

where:

SID is the Oracle SID of the source Oracle database..
src_owner.table is the owner and name of the source table.
tgt_owner.table is the owner and name of the target table.*
host is the name of the target system.
database_name is the name of the target database.

* Important! If target owner or table name is defined in the database as anything other than UPPERCASE, be certain to:

Type the name in the correct case.
Enclose the name in quotation marks, for example "MySchema"."MyTable".

To support replication between a source of one database type and a target of another type, the letter case of the names of the source and target columns must be the same, for example the column names on both sides in lower case or both sides in upper case. If the case differs between the source and target column names, use the column mapping feature to map the column names in the configuration file.

Note: This is a basic one-source, one-target configuration using no additional SharePlex configuration features. See "Configure SharePlex to replicate data" in the SharePlex Administration Guide for important information about creating a configuration file and for additional setup instructions for more complex replication scenarios.

Source configuration example

The following configuration file replicates table HR.Emp from Oracle instance ora112 to target table region1.emp in database mydb on target system sysprod. The source table is case-sensitive.

Datasource:o.ora112

HR."Emp" region1.emp sysprod@r.mydb

Configure SharePlex on the target

Perform the following steps to configure SharePlex on the target:

Make certain that the database setup meets all of the requirements in Open target checklist .
Run Database Setup for MariaDB (mariadb_setup) to establish a database account and connection information for SharePlex. For more information, see Database setup for MySQL.

Set up replication from Oracle to MySQL

Set up replication from Oracle to MySQL or Aurora

Pre-requisite: Schema support must be enabled in the MySQL DSN configuration to properly reference the table name during the replication process.

Overview

SharePlex can post replicated Oracle data to a MySQL or Aurora target database through an Open Database Connectivity (ODBC) interface.

For the versions, data types and operations that are supported when using SharePlex to replicate to this target, see the SharePlex Release Notes.

Install SharePlex

Important! If replicating to MySQL or Aurora on a PaaS cloud server (no access to the operating system), see the installation instructions in Installation and setup for cloud-hosted databases.

Review column names

See SharePlex Administration Guide for more information about column mapping with SharePlex.

Configure SharePlex on the source

Set up SharePlex and the database on the Oracle source system as follows.

Make keys available to SharePlex

To replicate from an Oracle source to an Open Target target, you must make key information available to SharePlex.

Enable Oracle supplemental logging

Enable PK/UK supplemental logging in the Oracle source database. SharePlex must have the Oracle key information to build an appropriate key on the target.

Set SP_OCT_USE_SUPP_KEYS parameter

See the SharePlex Reference Guide for more information about this parameter.

Configure replication

On the source, create a SharePlex configuration file that specifies capture and routing information.

Datasource:o.SID
src_owner.table	tgt_owner.table	host@r.database_name

where:

SID is the Oracle SID of the source Oracle database..
src_owner.table is the owner and name of the source table.
tgt_owner.table is the owner and name of the target table.*
host is the name of the target system.
database_name is the name of the target database.

* Important! If target owner or table name is defined in the database as anything other than UPPERCASE, be certain to:

Type the name in the correct case.
Enclose the name in quotation marks, for example "MySchema"."MyTable".

To support replication between a source of one database type and a target of another type, the letter case of the names of the source and target columns must be the same, for example the column names on both sides in lower case or both sides in upper case. If the case differs between the source and target column names, use the column mapping feature to map the column names in the configuration file.

Source configuration example

The following configuration file replicates table HR.Emp from Oracle instance ora112 to target table region1.emp in database mydb on target system sysprod. The source table is case-sensitive.

Datasource:o.ora112

HR."Emp" region1.emp sysprod@r.mydb

Configure SharePlex on the target

Perform the following steps to configure SharePlex on the target:

Make certain that the database setup meets all of the requirements in Open target checklist .
Run Database Setup for MySQL (mysql_setup) to establish a database account and connection information for SharePlex. For more information, see Database setup for MySQL.

제품을 선택하십시오.

더 나은 서비스 제공을 위해 채팅 목적을 작성해 주십시오.

문제에 대한 권장 솔루션

SharePlex 12.0 - Installation and Setup Guide

Set up replication from Oracle to Kafka

Overview

Guidelines for posting to Kafka

Configure SharePlex on the source

Configure SharePlex on the target

Set the Kafka record format

View and change Kafka settings

Set recovery options

Set up replication from Oracle to JMS

Overview

Configure SharePlex on the source

Configure SharePlex on the target

Prerequisites

Configure SharePlex on the JMS target

Enable logs for JMS replication

View and change JMS settings

Set recovery options

Example

Control memory settings

Configure debugging

View the XML format

Set up replication from Oracle to MariaDB

Overview

Install SharePlex

Review column names

Configure SharePlex on the source

Make keys available to SharePlex

Enable Oracle supplemental logging

Set SP_OCT_USE_SUPP_KEYS parameter

Configure replication

Source configuration example

Configure SharePlex on the target

Set up replication from Oracle to MySQL

Set up replication from Oracle to MySQL or Aurora

Overview

Install SharePlex

Review column names

Configure SharePlex on the source

Make keys available to SharePlex

Enable Oracle supplemental logging

Set SP_OCT_USE_SUPP_KEYS parameter

Configure replication

Source configuration example

Configure SharePlex on the target