Chat now with support
Chat mit Support

SharePlex 11.0 - SharePlex Administration Guide

About this Guide Conventions used in this guide Revision History Overview of SharePlex Run SharePlex Run multiple instances of SharePlex Execute commands in sp_ctrl Set SharePlex parameters Configure data replication Configure replication to and from a container database Configure named queues Configure partitioned replication Configure replication to a change history target Configure a replication strategy Configure DDL replication Configure error handling Configure data transformation Configure security features Assign SharePlex users to security groups Start replication on your production systems Monitor SharePlex Prevent and solve replication problems Repair out-of-sync data Tune the Capture process Tune the Post process Recover replication after Oracle failover Make changes to an active replication environment Apply an Oracle application patch or upgrade Back up Oracle data on the source or target Troubleshooting Tips Appendix A: Peer-To-Peer Diagram Appendix B: SharePlex environment variables

Configure replication to and from a container database

SharePlex supports replication to and from Pluggable Databases (PDB) in Oracle multitenant container databases (CDB). This support is available on Unix and Linux platforms only.

Contents

Replicate to and from a PDB

Configure Capture and Delivery

SharePlex can replicate data from one PDB to:

  • another PDB in the same CDB
  • a PDB in a different CDB
  • a regular (non-PDB) target

SharePlex can replicate data from a regular source database to a PDB in a target Oracle CDB.

In one configuration file, you can replicate to any number of target PDBs in the same CDB or a different CDB.

To capture from a PDB:

  • In the configuration file, specify the TNS alias of a PDB as the datasource. For example, if the TNS alias is pdb1, the datasource specification is:

    Datasource: o.pdb1

  • You can replicate from as many pluggable databases (PDBs) in the same CDB as desired: Create a separate configuration file for each PDB. Because each PDB is a different datasource, all configurations can be active at the same time.
  • If replicating from more than one PDB on a system, use named export queues to separate the data streams from each one. This allows you to issue SharePlex commands that affect configurations, such as purge config or abort config, for one configuration without affecting the other configurations. For more information, see Configure Named Export Queues

To replicate to a PDB:

Specify the TNS alias of the target PDB in the routing map, as shown in the following example where pdb2 is the target:

sys02@o.pdb2

PDB configuration examples

Example 1: This example shows two configuration files, one replicating from pdb1 and the other replicating from pdb2, both replicating data to pdb3.

Datasource: o.pdb1
hr.emp    hr2.emp2    sys02@o.pdb3
Datasource: o.pdb2 	 
sales.cust    sales2.cust2    sys02@o.pdb3

Example 2: This example shows one configuration file replicating from pdb1 to pdb2 and pdb3, both targets being on different systems.

Configure named queues

This chapter contains instructions for using the advanced SharePlex configuration options of named queues. These options provide an additional level of flexibility to divide and parallelize data to meet specific processing and routing requirements. Before proceeding, make certain you understand the concepts and processes in Configure Data Replication.

Contents

Configure named export queues

A named export queue is an optional, user-defined export queue that is attached to its own Export process. SharePlex creates each named Export queue and associated Export process in addition to the default export queue-process pair. When SharePlex creates a named export queue-process pair, it also creates a dedicated Import process, post queue, and Post process on the target to contain that data stream.

You direct SharePlex to create one or more named export queues when you create your configuration file. Any data that is not configured for processing through a named export queue is processed through the default export queue.

Supported sources and targets

  • PostgreSQL to PostgreSQL, Oracle, SQL Server, and Kafka

  • Oracle to all targets

Benefits of named export queues

Use named export queues to isolate the replication of:

  • Individual configurations: By default, SharePlex sends data from all active configurations through one export queue-process pair per target system, but the use of named Export queues enables you to separate each of those replication streams into its own export queue and Export process. In this way, you ensure that purge config or abort config commands that are issued for one configuration do not affect any of the others.
  • Selected database objects: You can use a named export queue to isolate certain objects such as tables that contain LOBs. Because each named export queue has its own Import process, post queue, and Post process on the target, you are able to isolate the data the entire way from source to target. For more information about the benefits of named post queues, see Configure Named Post Queues.

Additional benefits:

  • You can stop the Export or Import process for one data stream, while allowing the others to continue processing.
  • You can set SharePlex parameters to different settings for each export queue-process pair. This enables you to tune the performance of the Export processes based on the objects replicating through each one.

Considerations when using named export queues

  • Make certain that each queue name is unique.
  • You can combine named export queues with default export queues. Tables in the configuration with a standard routing map (targetsys@database_spec without a named queue specification) are replicated through a default export queue.

  • All tables with referential integrity to one another must be in the same export queue.
  • SharePlex has a maximum number of allowed queues. For more information, see Routing Specifications in a Configuration File.

Configure a named export queue: Oracle to all targets

Use the following syntax to define a routing map that includes a named export queue.

source_host:export_queuename*target_host[@database]

Configuration with named export queue in routing map
Datasource: o.SID
src_owner.table tgt_owner.table

source_host:export_queue*target_host[@database_specification]

Routing component Description
source_host The name of the source system.
export_queue

The name of the export queue. Queue names are case-sensitive on all platforms. Use one word only. Underscores are permissible, for example:

sys1:export_q1*sys2@o.myora

target_host The name of the target system.
database specification

One of the following for the datasource:

o.oracle_SID

r.database_name

 

One of the following if the target is a database:

o.oracle_SID

o.tns_alias

o.PDBname

r.database_name

c.oracle_SID

NoteS:
  • Allow no spaces between any components in the syntax of the routing map.
  • For more information about the components of a configuration file, see Configure Data Replication.
Examples

The following configuration files show two different datasources that are being replicated to two different databases on the same target system. Each datasource is routed through a named export queue.

Datasource:o.oraA    
scott.emp scott.emp sysA:QueueA*sysB@o.oraC
scott.sales scott.sales sysA:QueueA*sysB@o.oraC

 

Datasource:o.oraB    
scott.prod scott.prod sysA:QueueB*sysB@o.oraD
scott.cust scott.cust sysA:QueueB*sysB@o.oraD

 

The following shows how to separate a table that contains LOBs from the rest of the tables by using named export queues.

Datasource:o.oraA    
scott.cust scott.cust sysA:QueueA*sysB@o.oraC
scott.sales scott.sales sysA:QueueA*sysB@o.oraC
scott.prod scott.prod sysA:QueueA*sysB@o.oraC
scott.emp_LOB scott.emp_LOB sysA:QueueB*sysB@o.oraC

 

Alternatively, you could simply define a named export queue for the LOB table and allow the remaining tables to be processed through the default export queue.

Datasource:o.oraA    
scott.cust scott.cust sysB@o.oraC
scott.sales scott.sales sysB@o.oraC
scott.prod scott.prod sysB@o.oraC
scott.emp_LOB scott.emp_LOB sysA:lobQ*sysB@o.oraC

Configure a named export queue for PostgreSQL

Use the following syntax to define a routing map that includes a named export queue.

source_host:export_queuename*target_host[@database]

Supported targets

PostgreSQL, Oracle, SQL Server, and Kafka

Configuration with named export queue in routing map
Datasource:r.dbname
src_schema.table tgt_schema.table

source_host:export_queue*target_host[@database_specification]

Routing component Description
source_host The name of the source system.
export_queue

The name of the export queue. Queue names are case-sensitive on all platforms. Use one word only. Underscores are permissible, for example:

sys1:export_q1*sys2@r.dbname

target_host The name of the target system.
database specification

r.database_name

Note: Allow no spaces between any components in the syntax of the routing map.

Examples

The following configuration files show two different datasources that are being replicated to two different databases on the same target system. Each datasource is routed through a named export queue.

Datasource:r.dbnameA    
scott.emp scott.emp sysA:QueueA*sysB@r.dbnameC
scott.sales scott.sales sysA:QueueA*sysB@r.dbnameC

 

Datasource:r.dbnameB    
scott.prod scott.prod sysA:QueueB*sysB@r.dbnameD
scott.cust scott.cust sysA:QueueB*sysB@r.dbnameD

 

The following shows how to separate a table that contains LOBs from the rest of the tables by using named export queues.

Datasource:r.dbnameA    
scott.cust scott.cust sysA:QueueA*sysB@r.dbnameC
scott.sales scott.sales sysA:QueueA*sysB@r.dbnameC
scott.prod scott.prod sysA:QueueA*sysB@r.dbnameC
scott.emp_LOB scott.emp_LOB sysA:QueueB*sysB@r.dbnameC

 

Alternatively, you could simply define a named export queue for the LOB table and allow the remaining tables to be processed through the default export queue.

Datasource:r.dbnameA    
scott.cust scott.cust sysB@r.dbnameC
scott.sales scott.sales sysB@r.dbnameC
scott.prod scott.prod sysB@r.dbnameC
scott.emp_LOB scott.emp_LOB sysA:lobQ*sysB@r.dbnameC

How to identify named export queues

You can view named export queues through sp_ctrl:

  • Use the qstatus command to view all queues on a system.
  • Use the show command to view all Export processes with their queues.

See the SharePlex Reference Guide for more infomation about theses commands.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen