Chat now with support
Chat with Support

SharePlex 8.6.6 - Installation Guide

About this Guide Conventions used in this guide Introduction to SharePlex SharePlex pre-installation checklist Set up SharePlex in an Oracle cluster Set up SharePlex on Amazon Cloud Download SharePlex UNIX Installation and Setup Windows Installation and Setup Assign SharePlex users to security groups Basic SharePlex demonstrations Advanced SharePlex Demonstrations Solve Installation Problems Uninstall SharePlex SharePlex Utilities Appendix A: Advanced installer options Appendix B: Install SharePlex as root Appendix C: SharePlex installed items

Set up Oracle redo logging to support SharePlex

SharePlex captures from the online and archived Oracle redo logs. SharePlex supports redo logs and datafiles that are stored on raw devices, on filesystem devices, and ASM instances.

Set the appropriate logging level

Minimal supplemental logging must be set before you activate the SharePlex replication configuration.

In addition, SharePlex recommends that both primary key and unique key supplemental logging be set, or that a supplemental log group on unique columns be defined for every table in replication. When the key column values for a row update are in the redo log, SharePlex does not have to fetch them from the database. On a busy system, this greatly improves the performance of the Read process. Some SharePlex features require primary key and unique key logging to be enabled.

ALTER TABLE DDL commands that change the rowid of a table can affect subsequent DML operations if the primary or unique keys of the tables in replication are not being logged. When the keys are not logged, SharePlex fetches their values based on the rowid. Any operation that changes the rowid, such as ALTER TABLE...MOVE, can cause the wrong key values to be used for subsequent DML operations.

See Set up Oracle database objects for replication for more information about defining key values.

Ensure that the correct key is logged

When primary and unique key supplemental logging is enabled and a table does not have a primary key, Oracle has to decide what type of unique key to log. If the table has multiple unique keys, Oracle determines the best key to use and logs those column values for every UPDATE. If a table does not have any type of key, Oracle logs all columns that are not a LONG or a LOB.

SharePlex must also identify a key to use to replicate data. Like Oracle, SharePlex chooses a key in this order:

  • primary key if there is one
  • the best (or only) unique key if there is one
  • all the columns

If a table being replicated by SharePlex does not have a primary key, but does have multiple unique keys, it is possible that the key columns that Oracle logs are not those that SharePlex requires.

See Set up Oracle database objects for replication for more information about defining key values.

Configure the archive logs

If the Capture process stops (or is stopped by a SharePlex user) while replication is active, Capture records its location in the redo log and continues from that point when started again. If the redo logs wrap before Capture starts again, Capture reads through the archive logs to locate the records it missed.

Ideally, the redo logs should be configured so that SharePlex can avoid reading the archive logs. In most cases, reading the online logs is faster than reading the archives. Ensure that the online redo logs are large and numerous enough to minimize processing from the archive logs. At minimum, there should be enough redo log capacity to hold several hours worth of data without wrapping.

Note: On Exadata systems, you might get faster Capture speed by multiplexing the logs to a different system. See Tune Capture on Exadata

To test an appropriate online log configuration

In pre-production testing, you can determine if Capture is reading the archive logs by doing the following:

  1. Determine the log that SharePlex is processing by querying the SHAREPLEX_ACTID table.

    SQL> select seqno from splex.shareplex_actid

  2. Determine the log that Oracle is writing to by querying Oracle's V$LOG table.

    SQL> select sequence# from v$log where status='CURRENT'

  3. Subtract the seqno value from the sequence# value. This reveals how many logs Capture lags behind Oracle.
  4. Subtract the number of online redo logs from that value. If the number is negative, SharePlex is processing archive logs. For example, if you have 10 redo logs and SharePlex is 11 logs behind, it is processing archive logs. You can then use this result to adjust the online logging configuration.

If there is a long delay between when Capture stops and then starts again, Capture can lose pace with Oracle activity and there will be latency between the source and target data. Capture usually needs to read the archives in this case because the required log is no longer online. To avoid Capture issues, configure archive logging to support faster and uninterrupted replication as follows:

Requirement Description
Enable archive logging on the source system Archive logging must be enabled on the source system. Otherwise, if the online logs wrap before Capture is finished processing them, a resynchronization of the source and target data will be necessary.
Time compression properly Do not compress the archive logs until SharePlex is finished processing them. Otherwise, SharePlex returns a "log wrap detected" message and will stop because it cannot process the data. To determine the current log for SharePlex, issue the show capture command with the detail option in sp_ctrl on the source system. You can compress any logs that were generated before the current one.
Specify a non-default archive location If you are storing the archive logs in a location other than the Oracle default, set the SP_OCT_ARCH_LOC parameter to the full path name of the directory where the archive logs are located. If the redo logs wrap, SharePlex searches for the archive logs in Oracle’s archive log list. If SharePlex does not find the archive log there, it searches the directory or directories specified by the SP_OCT_ARCH_LOC parameter. To have Capture go directly to the SP_OCT_ARCH_LOC location and skip the read of the Oracle log list, set the SP_OCT_CK_LOC_FIRST to 1.
Configure Capture to wait for log-management processes If using SP_OCT_ARCH_LOC and you are using an automated method to move the logs to that location, you can configure Capture to wait a certain amount of time for the move to be completed. This prevents Capture from stopping because a log it needs is not yet available. Capture waits, checks for the logs, stops if they are not yet available, and continues checking and stopping until the logs are available. To configure Capture to wait, set the SP_OCT_LOGWRAP_RESTART parameter to the number of seconds that you want Capture to wait. Monitor these processes regularly to prevent replication latency.
Disable archive logging on the target You can disable archive logging on the target systems to eliminate unnecessary Oracle activity on that system, except for high availability or peer-to-peer strategies.
Do not place logs at the root ASM location

If the database uses ASM, the Oracle redo logs (online and archive) cannot be located under the ASM root directory. SharePlex will not be able to read them at that location.

Read from the archive logs on Exadata

Normally, SharePlex provides the least latency when reading from the online redo logs. On Exadata, however, SharePlex can process higher volumes of data when reading from a multiplexed archive location outside of the Exadata ASM file system. For more information, see Tune Capture on Exadata.

Important: If Capture falls behind the pace at which Oracle generates redo volume, the following may apply:

  • It might be more practical to resynchronize the data instead of waiting for SharePlex to restore parity by capturing from the archive logs.
  • It is possible to run out of disk space on the source system while Capture processes and queues the operations that it missed.
  • There is the potential for SharePlex to lose information needed for Post to construct SQL statements, especially if the needed archive logs no longer are available. Always monitor disk space and latency while SharePlex is running.
Related Documents