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.
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.
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:
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.
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:
Determine the log that SharePlex is processing by querying the SHAREPLEX_ACTID table.
SQL> select seqno from splex.shareplex_actid
Determine the log that Oracle is writing to by querying Oracle's V$LOG table.
SQL> select sequence# from v$log where status='CURRENT'
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:
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy
