Chatee ahora con Soporte
Chat con el soporte

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

How to use the repair and compare commands

The recommended procedure for maintaining synchronized data through the comparison and repair commands is to run the compare or compare using command first, then view the results with the repair status command. This command shows any rows that are out-of-sync and the possible cause. Unless the cause of the out-of-sync condition is corrected, replication will go out of synchronization again, even if you repair the rows this time. After the problem is fixed, issue the repair or repair using command.

You can run the repair or repair using command without doing a preliminary comparison. The command performs a comparison first, to identify the out-of-sync rows, and then it repairs those rows. However, the underlying cause of the out-of-sync condition must be corrected to prevent future out-of-sync conditions.

See for causes and solutions for out-of-sync conditions.

To view the status or results of a comparison, use the compare status command in sp_ctrl.

To view the status or results of a repair, use the repair status command in sp_ctrl.

When to run a repair

The best time to repair a target table depends on its size, the cause of the problem, the extent of out-of-sync rows, and how long you are willing to tolerate users being locked out. Before you initiate a repair, consider the following:

  • Although the users of the tables are not usually affected by the brief locks that are applied when tables are compared, they are locked out of the target table for the duration of the repair process. For a small table, this might not be disruptive, but for a large table needing extensive repairs, the wait can be significant.
  • Locks on a target table can reduce posting performance if Post must wait for the repair to finish before it can apply changes to that table and move on to other tables. This increases the latency of the target data and causes operations to accumulate in the post queue. If the objects that Post needs to change are different from those being repaired, the two processes run simultaneously.
  • If you must repair a table immediately, but cannot tolerate locks or replication latency, you can use the where option to limit the repair to certain rows. An alternative is to use the key option, but this option may cause the repair to miss some out-of-sync rows.

  • If the repair can wait, correct the cause of the problem immediately and then do the repair during non-peak hours.
  • Replication latency can slow down the compare and repair processing. The message sent from the source to spawn the command processes on the target is sent through the queues along with regular replicated data. Delays caused by a data backlog will delay the spawn message and cause the process on the source to lose its read consistency, which results in errors. If possible, perform comparisons and repairs during off-peak hours.

How to run the compare and repair commands

To get additional information and syntax for the compare and repair commands, see the command documentation in theSharePlex Reference Guide.

Tune the Capture process

This chapter contains instructions for improving the performance of the Capture process to prevent Capture from losing pace with the volume of redo that an Oracle source database generates.

Contents

Disable LOB Mapping

If you have PK/UK logging enabled on the source database (recommended to support more SharePlex features and faster processing), check the setting of the SP_OCT_ENABLE_LOBMAP parameter. This parameter controls whether or not SharePlex uses a LOB map when replicating tables that contain out-of-row LOB columns. The LOB map is used by the Capture process to map LOBIDs and rows when PK/UK logging is not enabled. LOB mapping is enabled by default. The SHAREPLEX_LOBMAP table stores these mappings.Transactions with numerous LOB operations can slow down Capture because it needs to maintain and refer to the mappings. If PK/UK logging is enabled on the database, you can disable LOB mapping by setting this parameter to 0.

To disable LOB mapping during active replication:

  1. Run sp_ctrl on the source system.
  2. Set SP_OCT_ENABLE_LOBMAP to 0.

    sp_ctrl> set param SP_OCT_ENABLE_LOBMAP 0

  3. Stop Capture.

    sp_ctrl> stop capture

  4. Truncate the SHAREPLEX_LOBMAP table.
  5. Restart Capture.

    sp_ctrl> start capture

Tune Capture on Exadata

The Capture process can be configured to use multiple capture threads for faster performance on an Exadata system. Capture reads directly from the logs on the Exadata ASM disks.

The SP_OCT_ASM_MULTI_OCI parameter controls the number of threads that Capture uses to read the redo logs.

The value for this parameter must be set to at least 2 but no more than the number of disks in the redo log disk group.

A large number of threads is not required, and performance actually diminishes with too many threads. The more threads, the more memory Capture requires. Start with a small number of threads and monitor performance, then add threads if needed until you obtain an ideal balance between performance gain and memory usage.

To configure SharePlex for multi-threaded capture on Exadata:

  1. Run sp_ctrl.
  2. Set the SP_OCT_ASM_MULTI_OCI parameter to the number of threads that you want Capture to use.

    sp_ctrl> set param SP_OCT_ASM_MULTI_OCI 3

  3. Restart Capture.

Note: Capture automatically adjusts its buffer size to the value of the AU_SIZE parameter that is set for the disk group where the logs reside. This is the recommended buffer size for best performance and should not be changed. The SP_OCT_ASM_MULTI_OCI_BLOCK_SIZE parameter can override the default behavior if necessary.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación