Sites that process large amount of data in a given time may run into this question about how much data (in terms of redo log per hour or day) can be processed by Capture. This is especially true if the rate of transaction is very demanding on Shareplex whereby Capture keeps working hard to keep pace with the Oracle.
General information about factors that can affect how much redo Shareplex (or Capture) processes in a given time.
NOTE: This solution provides general information regarding variables that affect Shareplex performance or throughput. This is NOT a benchmark document, any values referred below are for example purposes only. This solution does not guarantee that Shareplex will perform at a particular speed or have any particular throughput. Shareplex does not provide any benchmarking documentation because each system is unique and there are many factors that impact Shareplex.
On some sites Shareplex Capture process easily processes 200GB+ redo per day whereas on others even 40 GB may be tough to process. There is no easy way to quantify the rate of redo log (say GB per hour) processed by Shareplex. There is no hard and fast rule that applies here. It depends on several factors. The most common ones are listed below:
The fraction of the total # of tables in replication: If a very small fraction of the total # of tables is in replication, then the rate of redo log processed by Shareplex (or Capture process) is very high since it does not have to deal with that many transactions.
I/O efficiency: The better the I/O due to the way the disk device is configured, the better is the Capture performance.
Supplemental logging: If supplemental logging is enabled, Shareplex performs much better.
Oracle version: Shareplex fares better when on later versions of Oracle, part of the reason being the availability of Supplemental logging, among others.
Resource availability on server: Factors such as # of CPUs on server, the availability of CPU for Capture out of a number of processes running on that server, availability of memory, etc, can have a bearing on how Shareplex fares.
Capture tuning: How well the Capture is tuned also matters. Tuning should always be done with the specifics of a situation in mind since every situation is different and warrants a different approach to tuning.
Capture debug: If Capture is set in debug mode for any purpose, it will have a drag on Capture. This overhead depends on the debug flag setting and can wary from one flag to another. If the debug is left on inadvertently, this will impact the performance.
For more authoritative info on this the Product Management may be contacted through Support.
Disclaimer:
Support is not normally involved in tuning, benchmarking, performance tuning/optimization, etc...This is typically carried out by Professional Services (a consulting arm of Quest). Support can provide their contact information upon request.
Overall hardware/speed/load of the server contribute greatly to Shareplex performance, and this is the reason why a definite answer in terms of numbers cannot be given.
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center