Tchater maintenant avec le support
Tchattez avec un ingénieur du support

SharePlex 10.1.1 - Installation and Setup for Oracle Source

About this Guide Conventions used in this guide SharePlex pre-installation checklist Download the SharePlex installer Installation and setup for Oracle cluster Installation and setup for remote capture Install SharePlex on Linux and UNIX Install SharePlex on Windows Assign SharePlex users to security groups Set up an Oracle environment for replication Set up replication from Oracle to a different target type Generic SharePlex demonstration-all platforms Advanced SharePlex demonstrations for Oracle Solve Installation Problems Database Setup Utilities General SharePlex Utilities Uninstall SharePlex Advanced installer options Install SharePlex as root Run the installer in unattended mode SharePlex installed items

Configure named post queues

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.

Supported sources


Supported targets


Benefits of named post queues

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:

  • large tables
  • objects that have LOB columns. Named post queues are recommended for objects that contain LOBs.
  • objects that involve large transactions.
  • any objects whose operations you want to isolate.

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.

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.

Considerations when using named post queues

  • The analyze config command can help you determine how to organize your tables into named queues, based on any dependencies they have and their individual transactional activity. Run the command over a period of time that captures typical database activity, and then view the command output.
  • Assign each post queue a unique name.
  • If objects are linked by relational dependencies, process all of those objects through the same named post queue. If interdependent objects are not replicated through the same post queue, parent and child operations may be applied out of order and will cause database errors. As an alternative to processing interdependent objects through the same queue, you can disable their referential constraints on the target. This may be acceptable, because the constraints are satisfied on the source system and then replicated to the target.
  • When using multiple Posts, the target objects might not be changed in the same order as the corresponding source objects, possibly causing the target database to be inconsistent with the source database at any given point in time.
  • If you implement named post queues for objects in an active configuration (thus changing the routing) SharePlex locks those objects to update its internal directions.
  • SharePlex has a maximum number of allowed queues. For more information, see Routing specifications in a configuration file.

    Note: If Post returns the error message "shs_SEMERR: an error occurred with the semaphore" on a Windows system, the number of semaphores may need to be increased to accommodate the queues that you created. For more information, see Post stopped .

Configure a named post queue

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:


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


Routing component Description
host The name of the target system.

The unique name of the post queue. Queue names are case-sensitive on all platforms. One word only. Underscores are permissible, for example:



One of the following for the datasource:



One of the following if the target is a database:

  • o.oracle_SID







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.

scott.emp scott.emp sysB:Queue1@o.oraC
scott.cust scott.cust



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, see Configure replication to share or distribute data.

scott.emp scott.emp sysB*sysC:Queue1@o.oraC

How to identify a named post queue

A named post queue is identified by the datasource (source of the data) and one of the following:

  • the name of an associated named export queue (if the Import is linked to a named export queue)
  • the user-assigned post-queue name (if the Import is linked to a default export queue).

You can view named post queues through sp_ctrl:

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

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

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation