Oracle GoldenGate Veridata is a powerful and versatile data comparison and synchronization tool that empowers businesses to maintain data integrity, optimize decision-making, and ensure seamless operations across diverse platforms.

It is a high-speed, data-comparison and repair solution that identifies, reports on, and fixes data discrepancies between heterogeneous databases without interrupting ongoing business processes automatically.

A commonly recurring question regarding Veridata pertains to its sizing, and addressing this query is quite challenging due to its dependency on several variables. Nevertheless, I’ve made every effort to furnish as much information as possible to assist you in determining the appropriate sizing for Oracle GoldenGate Veridata.

Regrettably, there’s no one-size-fits-all figure we can provide, but by conducting internal testing and considering the numerous factors at play, you can arrive at an appropriate Veridata sizing. Several factors that influence your sizing are outlined below.

 

  • Number of rows

  • Size of the rows in bytes

  • Total number of Columns

  • Column data types (e.g., LOBs take longer to generate hash value versus integers)

  • Number of columns in the key & the size of those columns

  • Type of processor chip (the newer, the faster)

  • Amount of RAM available

  • Amount of sorting that can be done in memory versus spilling to disk

  • Network latency between the database and the Veridata agent and the Veridata server

  • Number of initially out of sync rows found (determines how many need to be re-checked)

  • Number of final rows found out of sync

  • Whether the decision is made to “repair” data found out of sync

 

Below are some numbers that we typically have seen with customers.

  • A typical customer (32 OGG CPU) with mid-size DB, they go for around 8 to 16 proc for Veridata.

  • Enterprise customers having 100+ OGG proc, usually go for 16 to 24 proc of a machine having 124-256 GB memory for Standalone Veridata server, they usually have DB sizing in a couple of hundreds to TBs.

  • We have seen Veridata runs on 4 OCPU/128GB as their DB comparison size was less than 50GB, deployed on Oracle Cloud Compute. They would be segregating jobs to run throughout the week. i.e., once a week.

 

Some Benchmark results which will help in sizing Oracle GoldenGate Veridata are below,

  • Approximately 30 minutes were required to process 5,000 pairs of tables, each containing 75 million records, with a total data volume of around 140 gigabytes, using a 48-CPU Linux server.
  • An instance equipped with 8 cores and 32 GB of memory successfully processed 832 GB of data within just three hours, all contained within a single table.
  • Using an instance with 20 cores and 400 GB of memory, we were able to process 220 million rows of data with Auto Partition enabled in just 1 hour and 20 minutes.
  • An instance equipped with 20 cores and 250 GB of memory, focusing solely on the initial step comparison, successfully compared 13 million data within a 10-minute timeframe.

 

These benchmarks are reliant on a range of factors, including network performance, Disk IO, and other system resources. Workloads can vary from one system to another. We have shared this information to offer guidance on determining the appropriate sizing for GoldenGate Veridata.

 

The links below provides you with more information about tuning of Oracle GoldenGate Veridata.

Veridata Disk and Memory Requirements for the Server Component:

Oracle GoldenGate Veridata Agent Disk and Memory Requirements

Memory for the sorting process:

Oracle GoldenGate Veridata Server Configuration Parameters

General Veridata Tuning Performance:

Tuning Performance of Oracle GoldenGate Veridata

A review of the server configuration parameters should be done as well to ensure the server can use the additional memory resources.

Relevant Veridata Server Configuration Parameters (veridata.cfg):

server.max_concurrent_jobs – This parameter specifies the maximum number of jobs that can be run simultaneously.
 
server.max_concurrent_comparison_threads – Sets the maximum number of concurrent comparisons that can be executed. You can lower this number to reduce the impact of the server on your system. When this limit is reached, no new comparisons, starts until an active comparison completes.
 
server.mapped_sort_buffers – Indicates whether sort buffers are allocated as a memory mapped file or allocated on the JVM heap.
 
server.max_sort_memory – Sets the maximum amount of sort virtual memory that is available to all running comparisons that use server-side sorting. The value of this parameter varies depending on the value of server.mapped_sort_buffers.

 

I trust that this information will assist you in effectively sizing and optimizing Oracle GoldenGate Veridata.