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 Create configuration files.
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.
All
Use named export queues to isolate the replication of:
Additional benefits:
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.
Note: On a Windows system, the use of numerous queues may require the number of semaphores to be increased. If Post returns the error message "shs_SEMERR: an error occurred with the semaphore," see the Post stopped topic in Solve replication problems .
Use the following syntax to define a routing map that includes a named export queue.
source_host:export_queuename*target_host[@database]
Datasource:database_specification | ||
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 |
For the datasource: o.oracle_SID
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:
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 |
You can view named export queues through sp_ctrl:
See the SharePlex Reference Guide for more infomation about theses commands.
A named post queue is an optional component of the routing map in the configuration file. A named post queue is a user-defined post queue with its own Post process, which together operate in parallel to the default post queue and Post process. You can define one or more named post queue-process pairs to establish a set of parallel Post replication streams.
All
You can use named post queues to isolate data from different tables into two or more separate Post streams. By using named post queues, you can improve posting performance by isolating objects such as the following that cause processing bottlenecks:
Process the remaining objects through additional named post queues, or use the default post queue. Objects in the configuration file with a standard routing map (host@target) are replicated through a default post queue.
You can use horizontal partitioning to divide the rows of very large tables into separate named post queues as an added measure of parallelism. See Configure horizontally partitioned replication.
You can set SharePlex parameters to different settings for each queue-process pair. This enables you to tune the performance of the Post processes based on the objects replicating through each one.
Note: On a Windows system, the use of numerous queues may require the number of semaphores to be increased. If Post returns the error message "shs_SEMERR: an error occurred with the semaphore," see the Post stopped topic in Solve replication problems .
If you are using named export queues, SharePlex creates a named post queue-process pair for each one by default. If you are not using named export queues, use the following syntax to define a named post queue in the configuration file by adding the :queue component to the routing map:
host:queue@target
Datasource:database_specification | ||
src_owner.table | tgt_owner.table |
host:queue[@database_specification] |
Routing component | Description |
---|---|
host | The name of the target system. |
queue |
The unique name of the post queue. Queue names are case-sensitive on all platforms. One word only. Underscores are permissible, for example: sys2:post_q1@o.myora |
database_specification |
For the datasource: o.oracle_SID
One of the following if the target is a database:
|
NoteS:
The following configuration creates one post queue named Queue1 that routes data from table scott.emp and another post queue named Queue2 that routes data from table scott.cust.
Datasource:o.oraA | ||
scott.emp | scott.emp | sysB:Queue1@o.oraC |
scott.cust | scott.cust |
sysB:Queue2@o.oraC |
The following shows how a named post queue is specified when you are routing data in a pass-through configuration using an intermediary system. For more information about this replication strategy, see Configure replication to share or distribute data.
Datasource:o.oraA | ||
scott.emp | scott.emp | sysB*sysC:Queue1@o.oraC |
A named post queue is identified by the datasource (source of the data) and one of the following:
You can view named post queues through sp_ctrl:
See the SharePlex Reference Guide for more infomation about theses commands.
This chapter contains instructions for how to configure SharePlex to maintain a change-history target. SharePlex enables you to maintain this history, while also replicating the same data set to maintain up-to-date targets.
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy