@RANGE function to divide the rows of any table across two or more Oracle GoldenGate processes. It can be used to increase the throughput of large and heavily accessed tables and also can be used to divide data into sets for distribution to different destinations. Specify each range in a
FILTER clause in a
@RANGE is safe and scalable. It preserves data integrity by guaranteeing that the same row will always be processed by the same process group. To ensure that rows do not shift partitions to another process group and that the DML is performed in the correct order, the column on which you base the
@RANGE partitioning must not ever change during a process run. Updates to the partition column may result in "row not found" errors or unique-constraint errors.
@RANGE computes a hash value of the columns specified in the input. If no columns are specified, the
KEYCOLS clause of the
MAP statement is used to determine the columns to hash, if a
KEYCOLS clause exists. Otherwise, the primary key columns are used.
Oracle GoldenGate adjusts the total number of ranges to optimize the even distribution across the number of ranges specified.
Because any columns can be specified for this function, rows in tables with relational constraints to one another must be grouped together into the same process or trail to preserve referential integrity.
Using Extract to calculate the ranges is more efficient than using Replicat. Calculating ranges on the target side requires Replicat to read through the entire trail to find the data that meets each range specification.
@RANGE (range, total_ranges [, column] [, column] [, ...])
The range assigned to the specified process or trail. Valid values are
3, and so forth, with the maximum value being the value defined by
The total number of ranges allocated. For example, to divide data into three groups, use the value
The name of a column on which to base the range allocation. This argument is optional. If not used, Oracle GoldenGate allocates ranges based on the table's primary key.
In the following example, the replication workload is split into three ranges (between three Replicat processes) based on the
ID column of the source
(Replicat group 1 parameter file)
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1, 3, ID));
(Replicat group 2 parameter file)
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (2, 3, ID));
(Replicat group 3 parameter file)
MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (3, 3, ID));
In the following example, one Extract process splits the processing load into two trails. Since no columns were defined on which to base the range calculation, Oracle GoldenGate will use the primary key columns.
RMTTRAIL /ggs/dirdat/aa TABLE fin.account, FILTER (@RANGE (1, 2)); RMTTRAIL /ggs/dirdat/bb TABLE fin.account, FILTER (@RANGE (2, 2));
In the following example, two tables have relative operations based on an
order_ID column. The
order_master table has a key of
order_ID, and the
order_detail table has a key of
item_number. Because the key
order_ID establishes relativity, it is used in
@RANGE filters for both tables to preserve referential integrity. The load is split into two ranges.
(Parameter file #1)
MAP sales.order_master, TARGET sales.order_master, FILTER (@RANGE (1, 2, order_ID)); MAP sales.order_detail, TARGET sales.order_detail, FILTER (@RANGE (1, 2, order_ID));
(Parameter file #2)
MAP sales.order_master, TARGET sales.order_master, FILTER (@RANGE (2, 2, order_ID)); MAP sales.order_detail, TARGET sales.order_detail, FILTER (@RANGE (2, 2, order_ID));