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
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
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.
Capture checkpoints it state to disk on a regular basis to support recovery. This information includes the log and location within that log of the most recently processes data. In a database environment where there are frequent log switches, a switch can occur before SharePlex writes its checkpoint. You can use the SP_OCT_CHECKPOINT_LOG parameter to ensure that Capture issues a checkpoint before a log switch.
The checkpoint is triggered when Capture lags a specified number of logs behind Oracle. For example, with the default of 2, Capture does a checkpoint when it falls 2 or more logs behind Oracle.
The range of permissible values for this parameter is from 2 (the default) to a value equal to the number of logs you are using. A value of 0 disables this feature.
You can set the SP_OCT_OLOG_RDS_MINER parameter to 1 to add a second thread to Capture. This thread can be used to address performance issues when Capture is lagging behind Oracle on a very busy system.
Due to the processing load incurred by using this thread, it is disabled by default. To enable it, set this parameter to 1.
This chapter contains instructions for improving the performance of the Post process. Because replicated data is applied through standard SQL mechanisms, the Post process provides the most potential for performance tuning.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center